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

[Jim Klassen]

On 2/9/22 03:31, Sandro Santilli wrote:
> On Fri, Feb 04, 2022 at 04:23:48PM -0600, Jim Klassen wrote:
>
>> We've been starting at 200000 and using EPSG
> I shall note 200,000 is also not in the "user range" as proposed in
> https://lists.osgeo.org/pipermail/postgis-devel/2012-February/018440.html
>
> The official PostGIS Manual doesn't currently advertise what ranges
> should user custom entries be in, so I think it's tipical for users to
> pick whatever range they guess will remain available over time
> https://postgis.net/docs/using_postgis_dbmanagement.html#user-spatial-ref-sys
>
> Would you be disappointed/surprised by a PostGIS upgrade
> replacing your custom entries above 200000 with some new
> "official" entry ? What strategy did you set in place to
> prevent this ?
>
> --strk;
>
Using the EPSG:200,xxx range is a historical oddity at this point. This came about in 2005 or 2006 and our use of UMN MapServer.  There wasn't (and still isn't) a standard EPSG code, but there was a statewide list floating around listing all of the county coordinate systems that used the 100,000 range. However, the definition it used for Ramsey County was wrong (IIRC it used the wrong units something like ft vs us-ft).  To avoid confusion, I fixed it and went 100,000 higher.  I can't remember this many years later, but I think >100,000 was in the EPSG user range at the time.  I also tried at first putting these codes in a custom namespace at first, and made some progress with that until we started using WMS and WFS.  I'm not sure if this is still true, but at the time only EPSG:xxxxxx numbers were being accepted by MapServer for WMS/WFS.  Thus, without adding the codes to the EPSG namespace, we couldn't pass around the coordinates (between our own systems) unmodified which 
was unacceptable as some of the data we were handing was survey data. (For compatibility with other systems, we also supported several standard EPSG codes in our WMS/WFS, and if someone external wanted the data in the native projection they either needed to add the code to their system or ask us for shapefiles.)  When we started using PostGIS a couple years later, I stuck with the 200068 code that we were using everywhere else as it was easiest to use the same number across all systems.

Ideally, it would be in its own namespace, or I think there is now also a code in the ESRI namespace (ESRI:104760) that basically matches (it differs in the least significant decimals in flattening).  And that is probably worth transitioning to (especially if the WMS/WFS limitation of only allowing EPSG namespaced codes has been fixed), but that will be a significant effort given all the places the number has appeared over the years.