Move import function from postgis dir to liblwgeom (GML/KML)

[colivier]

Imply to:

• Add link beetween liblwgeom to external libs (geos/proj4/libxml2) from configure step
• Move most code from postgis dir to liblwgeom
• Use cunit to regress (huge work as there's ~500 tests to rewrite)

[colivier]

I met 2 problems on this ticket:

1) I use Proj in some code of GeomFromGML (automagic reprojection if GML mixed SrsName)

So it implies to also move libxml and proj (and then to be consistant GEOS) from postgis dir to liblwgeom dir.

⇒ This one is not that difficult, just to be sure it doesn't hurt anyone.

2) I need to query spatial_ref_sys table (to know if a given projection

is planar or geocentric) so to use SPI.

⇒ I see now only 2 solutions: A) Don't do anything and keep in_gml and in_kml in postgis dir

B) Move everything but the this SPI function to liblwgeom and call it

from liblwgeom. But it this case the lib will not be really standalone anymore.

Any thoughts ?

[pramsey]

Why do we actually need to do the reprojection during the GML reading? Could we generate an LWGEOM with mixed SRID and then reproject it to a consistent SRID in the PostGIS code?

[mcayland]

Mixed SRID columns are bad, full stop and we don't want to be encouraging this. I'd suggest making the liblwgeom GML API take a separate parameter indicating whether or not the projection is planar or geocentric and starting from there. We can then figure out whether it has to be passed in by hand in the liblwgeom case or whether we can somehow automate this.

[pramsey]

This is not about mixed columns. The GeomFromGML function takes in one geometry representation and spits out one new geometry. The issue is that it's possible to have mixed SRS *within* the geometry itself. Imagine a collection with a different geometries in different SRIDs.

Now, that is entirely illegal inside PostGIS, it was one of our earliest design decisions to not allow that (so, for example, the EWKT representation only provides a single SRID= tag at the front, and the EWKB representation expects SRID to be inherited from the parent geometries).

However.

It is not IMPOSSIBLE to represent a mixed-srid geometry, since each sub-geometry in an LWGEOM can have its own srid value. So we could, for this one case temporarily allow a mixed-SRID LWGEOM to be produced by the lwgeom_from_gml() liblwgeom function, on the understanding that the next call will be to a posgis_transform() function to flip it all into a single SRS.

[pramsey]

A worthy goal, but not critical for 2.0

[strk]

I've been thinking that the liblwgeom version of GML parser could accept an optional function returning a projPJ given an SRSName, and an optional target projPJ. That way the caller could do the lookups and the core library would take care of GML parsing and transformations.

This way we should be fine (see #1591)

[strk]

The callback could also only return proj4text from srsName, the rest of the code seems to do everything else from that.

[robe]

who are we kidding — this isn't going to happen in 2.1

[robe]

Milestone renamed