<div dir="ltr"><div class="gmail_quote"><div dir="ltr">пн, 17 дек. 2018 г. в 19:02, Even Rouault <<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> Can we live without proj at all? I believe most web map cases are covered<br>
> by SRID 0, 4326, 3857, 900913 and rarely 3395. All those have<br>
> transformations in one-two lines of math.<br>
<br>
That's certainly one use case of PostGIS, but people use it for more exotic <br>
CRS transforms<br></blockquote><div><br></div><div>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 :)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> > You could still have a full spatial_ref_sys table. It is just that it has<br>
> > a<br>
> > risk of being unsynchronized with the PROJ database.<br>
> <br>
> What happens if it is? How large is error margin, who is affected?<br>
<br>
inconsistent results when people doing transforms with PROJ / GDAL command <br>
line utilities or through PostGIS ST_Transform()<br>
In case of incorrect datum shift, error can be up to several hundred meters.<br></blockquote><div><br></div><div>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. </div><div><br></div><div><a href="https://github.com/postgis/postgis/commit/92c39e8120e3c0407d1889725253b2a9470fb4fb#diff-4fadddd57dee6dd418d1cec4b45a0a09">https://github.com/postgis/postgis/commit/92c39e8120e3c0407d1889725253b2a9470fb4fb#diff-4fadddd57dee6dd418d1cec4b45a0a09</a> <br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> Can we add a constraint to have just one of them filled at all times?<br>
<br>
That's not implemented, and I'm not really willing to do it, since that would <br>
give incorrect results in some cases (which is already the case, where people <br>
regularly complain that the inappropriate datum shift is selected. For <br>
example, for Pulkovo-42, currently we use the datum shift of Romania, and <br>
Polish people complain it is not correct for their use cases (or the reverse, <br>
but you get the point))<br></blockquote><div><br></div><div>Pulkovo-42 is a patchy thing by itself and its meaning depends on the zone and date of map. </div><div><br></div><div>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):</div><div><a href="https://youtu.be/3bpFv99QuYU?t=1541">https://youtu.be/3bpFv99QuYU?t=1541</a> <br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Yes, coordinate tranformation is a tricky business...<br><br>
</blockquote></div></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Darafei Praliaskouski<br>Support me: <a href="http://patreon.com/komzpa">http://patreon.com/komzpa</a></div></div>