[postgis-tickets] [PostGIS] #5387: ST_Transform(geom, str, str) is very slow

PostGIS trac at osgeo.org
Mon Jun 19 15:44:25 PDT 2023


#5387: ST_Transform(geom, str, str) is very slow
-------------------------+---------------------------
  Reporter:  cdestigter  |      Owner:  pramsey
      Type:  defect      |     Status:  new
  Priority:  medium      |  Milestone:  PostGIS 3.4.0
 Component:  postgis     |    Version:  3.3.x
Resolution:              |   Keywords:
-------------------------+---------------------------
Comment (by pramsey):

 We cache based on srid, which in turn maps to auth/auth_srid. If an
 auth/auth_srid pair exists in the proj.db, then that is the definition
 that is used, not the proj4text or srtext. If you need to add non-EPSG
 systems, yes you'll have to add an entry to spatial_ref_sys with as
 detailed an SRTEXT as you can find. In a just world, the transform(geom,
 str, str) wouldn't even exist, as the SFSQL is pretty clear about the
 centrality of SRID and spatial_ref_sys as the mechanisms for CRS
 definitions. It is a holdover from the days when proj strings were the
 only way of representing CRSs. An good proj person could explain in even
 more detail, but basically dereferencing to an auth/auth_srid doesn't just
 get you a look-up to an SRTEXT. It gets you a lookup into the full EPSG
 database, which also referentially gives you all the best transforms
 between different systems, a rich extra layer of information that doesn't
 exist inside the SRTEXT.

 Anyways, no, we won't be changing the proj cache, so str/str transforms
 are going to remain slow. You can always add systems you want to formalize
 into the spatial_ref_sys table.
-- 
Ticket URL: <https://trac.osgeo.org/postgis/ticket/5387#comment:9>
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.


More information about the postgis-tickets mailing list