[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 rouault):

 Using a string to express is probably the best approach here (you could
 also pass transformations as WKT or PROJJSON, although that would be super
 verbose). The integer as being a code of an EPSG registered transformation
 would of course restrict it to EPSG, but also would prevent pipelines
 from/to a projected CRS.
 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.), proj_create() makes the arbitrary choice to
 return the CRS in case of ambiguity. So EPSG:XXXX might return if you're
 lucky a transformation, but if at the next update of the database that
 code is also attributed to a new CRS, game over. 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.

 The to_srid argument is probably useful indeed. If using a registered
 transformation, you can query the target CRS on it with the proj API, but
 that don't necessarily give you the corresponding PostGIS SRID if the
 target is not a EPSG CRS. And if you use a PROJ pipeline, PROJ won't be
 able to know the target CRS at all.

 The axis order might be a tricky. If the user pass a PROJ pipeline that
 does axis switching (like the GDA94 to GDA2020), then I'm not sure what
 PostGIS can do. 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.
 Three solutions I can think of:
 - document that users must strip any leading and trailing +proj=axisswap
 steps from their pipelines
 - or implement that in PostGIS
 - or implement that in proj_normalize_for_visualization()

-- 
Ticket URL: <https://trac.osgeo.org/postgis/ticket/5006#comment:4>
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.