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

Darafei "Komяpa" Praliaskouski me at komzpa.net
Sat Dec 22 22:37:04 PST 2018


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

> > 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.
>
> That's certainly one use case of PostGIS, but people use it for more
> exotic
> CRS transforms
>

Thinking of a backup solutions if we won't be able to use Proj somewhere.
We already have a assert(0) stub geos implementation that we use to link
statically against in scenario where we can't link dynamically, under
OSS-Fuzz namely :)


> > > 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?
>
> inconsistent results when people doing transforms with PROJ / GDAL command
> line utilities or through PostGIS ST_Transform()
> In case of incorrect datum shift, error can be up to several hundred
> meters.
>

We already have contributed patches on spatial_ref_sys in PostGIS. I don't
yet know their meaning, but some kind of benchmark is required at least for
those records.

https://github.com/postgis/postgis/commit/92c39e8120e3c0407d1889725253b2a9470fb4fb#diff-4fadddd57dee6dd418d1cec4b45a0a09




>
> > Can we add a constraint to have just one of them filled at all times?
>
> That's not implemented, and I'm not really willing to do it, since that
> would
> give incorrect results in some cases (which is already the case, where
> people
> regularly complain that the inappropriate datum shift is selected. For
> example, for Pulkovo-42, currently we use the datum shift of Romania, and
> Polish people complain it is not correct for their use cases (or the
> reverse,
> but you get the point))
>

Pulkovo-42 is a patchy thing by itself and its meaning depends on the zone
and date of map.

There is a talk on this in Russian on the local meetup how it happened to
be so wrong (by today's standards) everywhere. If you happen to understand
(or try enable translated subtitles):
https://youtu.be/3bpFv99QuYU?t=1541


>
> Yes, coordinate tranformation is a tricky business...
>
> --
Darafei Praliaskouski
Support me: http://patreon.com/komzpa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20181223/6802dc5f/attachment.html>


More information about the postgis-devel mailing list