[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