[postgis-tickets] [PostGIS] #5006: ST_Transform: Support PROJ pipelines

[PostGIS]

#5006: ST_Transform: Support PROJ pipelines
--------------------------+-----------------------------
  Reporter:  cdestigter   |      Owner:  strk
      Type:  enhancement  |     Status:  assigned
  Priority:  medium       |  Milestone:  PostGIS Fund Me
 Component:  liblwgeom    |    Version:  master
Resolution:               |   Keywords:  proj
--------------------------+-----------------------------

Comment (by rcoup):

 Thanks :-)

 > I'd note that proj_create() with a "EPSG:XXXX" string is an ambiguous
 operation. As there are EPSG objects with the same code but different type
 (CRS, transformations, etc.)

 Ah, of ''course'' there are. <sarcasm>Because we can't waste unique
 numbers, there's so few of them...</sarcasm>

 > The URN syntax "urn:ogc:def:coordinateOperation:EPSG::1671" would have
 to be used. PostGIs could still decide to parse FOO:BAR and transform that
 to urn:ogc:def:coordinateOperation:FOO::BAR in the context of that
 function.

 PostGIS uses `1234` in context of CRS lookups, so even `EPSG:1234` would
 be a "new" way of expressing CRS-related things. Might as well just
 document "use `urn:ogc:def:coordinateOperation:FOO::BAR` or use a
 pipeline/WKT string".

 OT: @rouault is un-overloading `proj_create()` maybe a sensible API
 progression for Proj? To differentiate "EPSG:1234 and I want a CRS" from
 "EPSG:1234 and I want a transformation"? ie: "I expect an object of type X
 from this string".

 > My idea of an integer ID was NOT to query spatial_ref_sys but a
 different, new table. Sometihng like spatial_ref_sys_transforms or
 similar. Such table could have a column expressing source SRID, a column
 expressiong target SRID and a proj4 string expressing the actual
 transformation/pipeline. The key to access it could even not be an integer
 but a descriptive name.

 Seems to me like a lot of (ongoing) effort when 99.9% of the time Proj
 will use the right transform automatically? From my point of view this is
 more being able to escape the automatic route if there are some
 special/specific needs. As you say, can always be enhanced in the future
 with an integer lookup if it proves popular.

 > The proj_normalize_for_visualization() accept PROJ coordinate operation
 objects, but that won't work with a PROJ pipeline, as it, at least
 currently, requires a PROJ coordinate operation for which the source and
 target CRS are known, and as mentionned above this is not the case for a
 PROJ pipeline.

 But if the pipeline was specified as
 `urn:ogc:def:coordinateOperation:EPSG::8447` Proj does know the
 source/target CRS and it'll work?

 Q2: Is source/target CRS settable on a transformation after creating it?
 If so and the user passes a pipeline string, PostGIS does know the source
 CRS, and the user can provide a target CRS ala `ST_TransformPipeline(geom,
 '+proj=pipeline ...', 1234)` (after mapping SRIDs to CRS via `AUTH:CODE`).

 I guess might be complicated somewhat with horizontal+vertical compound
 CRS/transforms, though `normalize_for_visualization()` only applies to
 horizontal anyway.

-- 
Ticket URL: <https://trac.osgeo.org/postgis/ticket/5006#comment:6>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.