[postgis-users] Help shaping the future: how do your use of spatial_ref_sys ?

Jim Klassen klassen.js at gmail.com
Wed Feb 9 07:55:14 PST 2022



On 2/8/22 19:12, Greg Troxel wrote:
> Paul Ramsey <pramsey at cleverelephant.ca> writes:
>
>> On Fri, Feb 4, 2022 at 2:23 PM Jim Klassen <klassen.js at gmail.com> wrote:
>>
>>> We've been starting at 200000 and using EPSG (misusing the "EPSG"
>>> auth kept Proj 4/GDAL/MapServer happier, this likely isn't necessary
>>> with Proj 8).  We maintain matching record(s) in our proj4 epsg
>>> database file (again this will change as we transition to Proj 8
>>> which supports PROJ_AUX_DB).
>> Slightly off topic, but a note to your and Paul Moen, that putting
>> "EPSG" into the auth_name means that in dereferencing the spatial
>> reference info PostGIS ends up calling into proj and saying "is this
>> bogus projection EPSG:9999999 projection valid?" which takes time.
>> Whereas if auth_name is null, PostGIS just skips right on down to
>> using the WKT. And if *that* is null, it can skip directly to using
>> the proj4text. So if you're really only using the proj4text, it
>> behooves you to leave everything else null.
> Separately from the efficiency, I'm also a little conflicted about the
> EPSG dataset.  Certainly it's a great contribution, but it doesn't meet
> the Free Software definition.  We as a community have more or less made
> our peace with that, but it seems best to avoid injecting local
> resources into that namespace -- as well as against the spirit of how
> EPSG asks the dataset be handled.
>

Interesting on the efficiency bit.  I just tried to make the row look as much like the existing rows as possible.  In our case, our proj.4 install does think it is a valid code.  I always thought it was cumbersome that I had to maintain the custom coordinate system in so many places (PROJ, PostGIS, older versions of GDAL, older versions of QGIS) when most of them are reaching back to PROJ to do the actual reprojection anyway.

I'm not suggesting that I expect anyone/everyone else should recognize our 200,xxx codes as valid EPSG codes, I just gave it as an example of a custom spatial_ref_sys entry we use.

The reason we used the EPSG namespace is because at the time this was implemented using the EPSG namespace was (is?) necessary to be able to pass the coordinates around in their original projection using WMS/WFS.  Frankly, if we couldn't pass the original coordinates around, the whole lets use WMS/WFS project would have been rejected outright.  I would have greatly preferred to use our own namespace, and I spent significant effort at the time in trying to make that work.  I also looked into submitting the SRSs to EPSG so we could have official numbers assigned, but at the time they didn't appear interested in county sized coordinate systems.  So between not being able to get an official EPSG code and WMS/WFS requiring SRSs start with "EPSG:", it forced our hand.

Personally, from a Free Software perspective, I was more upset with WMS/WFS as "open" standards requiring everyone use only the EPSG dataset than I was that EPSG has their own rules for how they want to maintain their dataset.


More information about the postgis-users mailing list