[postgis-devel] GDAL and Proj versions for PostGIS 3

[Darafei "Komяpa" Praliaskouski]

пн, 17 дек. 2018 г. в 15:23, Even Rouault <even.rouault at spatialys.com>:

> > For using proj6 in full looks like it requires redesign in
> spatial_ref_sys
> > table, dropping it non-user part of it and relying on internal proj6
> > database?
>
> That's a good question. You could at least conceptually imagine to
> dynamically
> populate part of the table: perhaps foreign table mechanism to
> automatically
> generate entries that come from the PROJ database by using the PROJ API,
> normal table for the user entries, and spatial_ref_sys being a view of the
> two
> ?
>

So, what we have now in spatial_ref_sys:
 - EPSG and other registries codes and their proj4text.
 - some user entries.
 - internal entries for _ST_BestSRID or how is it called, to perfrom
geography-by-geometry-engine.
 - clever users editing preexisting entries.
 - I think there are some manual patches over the database.

Who needs it:
 - ST_Transform, to know how to transfrom.
 - userland software that wants to know what is that they just read from db.
 - I'm not sure what happens in Raster.

I just want to warn that iterating over all CRS from the PROJ database and
> export them as WKT and PROJ string takes a few seconds, so the above would
> only perform well if clever instanciation can be done (that is if you do
> SELECT * FROM spatial_ref_sys WHERE srid = 12345, only 12345 will only be
> generated on the fly)
>

Can we live without proj at all? I believe most web map cases are covered
by SRID 0, 4326, 3857, 900913 and rarely 3395. All those have
transformations in one-two lines of math.

If we can do some wrapper similar to what LWGEOM does to GEOS, I think then
we can survive the migration and juice some performance profits from it.


>
> > Looks like we have to do it since proj7 is going to drop old way.
>
> You could still have a full spatial_ref_sys table. It is just that it has
> a
> risk of being unsynchronized with the PROJ database.
>

What happens if it is? How large is error margin, who is affected?

Another thing to be aware of is that the generated WKT1 and PROJ strings
> will
> now lack in a lot of cases the TOWGS84 clause when there are several
> candidate
> datum transformations from the CRS to WGS84 (previously the libgeotiff
> script
> that created the GDAL .csv files would select the TOWGS84 transform whose
> area
> of use was the largest). The new way will be to pass to
> proj_create_crs_to_crs() an optional area of interest, and it will
> determine
> from the database the more appropriate datum transformation.
>
> You also have the question to which part of the spatial_ref_sys entry you
> consider authoritative. The auth_name+auth_srid, the srtxt, the proj4text
> ?
> Currently PostGIS must certainly use the proj4text to use pj_init*() +
> pj_transform(). With PROJ 6, you can potentially use the 3 possibilities
> with
> proj_create_crs_to_crs(), but if you use the proj4text, you will not be
> able
> to benefit from the late-binding capabilities.
>

Can we add a constraint to have just one of them filled at all times?


>
> >
> > Looks like PostGIS is going to have mandatory transitive SQLite
> dependency
> > via Proj.
>
> Yes
>





>
> Even
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com
>
-- 
Darafei Praliaskouski
Support me: http://patreon.com/komzpa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20181217/38a151e7/attachment-0001.html>