Opened 14 years ago

Last modified 7 years ago

#444 new task

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

Reported by: colivier Owned by: colivier
Priority: medium Milestone: PostGIS Fund Me
Component: liblwgeom Version: master
Keywords: Cc:

Description

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)

Change History (11)

comment:1 by colivier, 14 years ago

Type: defecttask

comment:2 by colivier, 14 years ago

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 ?

comment:3 by pramsey, 13 years ago

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?

comment:4 by mcayland, 13 years ago

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.

comment:5 by pramsey, 13 years ago

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.

comment:6 by pramsey, 12 years ago

Milestone: PostGIS 2.0.0PostGIS 2.1.0

A worthy goal, but not critical for 2.0

comment:7 by strk, 12 years ago

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)

comment:8 by strk, 12 years ago

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

comment:9 by robe, 11 years ago

Milestone: PostGIS 2.1.0PostGIS Future

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

comment:10 by strk, 8 years ago

Component: postgisliblwgeom

comment:11 by robe, 7 years ago

Milestone: PostGIS FuturePostGIS Fund Me

Milestone renamed

Note: See TracTickets for help on using tickets.