I have been experimenting with the GIS support in MySQL 8. There are some significant improvements (proper support for SRID’s, for example), but there seems to be a big longitude domain problem for objects defined in a spheroidal coordinate system. We have a large dataset in the 0,360 longitude domain, however, near as I can tell, MySQL 8 does not support any spheroidal coordinates that are not in the -180,180 longitude domain regardless of the SRID. In addition, I can’t seem to find any reference for defining a 0,360 SRID… Is it even possible to do that?
We use Postgres, but haven’t bothered to even try going with a 0-360 coordinate domain. We’ve always worked in ‘Earth Friendly’ -180 to 180 with the Mars data we use for landing site analysis and other webGIS tools.
Yeah, storing data in the -180,180 domain seems to be the path of least resistance… Especially since there seems to be very little documentation about defining a custom SRID in that domain (assuming it’s even possible).
We have been using 0-360 in PostGIS for years but that doesn’t mean it was the most interoperable choice. Using a -180 to 180 (East) system just helps with compatibility across all the different tools and clients. For example, we have always used 0-360 for our nomenclature database but we also support writing out KML files for Google Earth. KML only allows -180 to 180 (East), so during export we swap Longitude range of all points from 180-360 to -180 to 0. I think we leave the Esri shapefile export as 0 to 360 (East) which doesn’t always work well for GISs (like QGIS). This example tutorial in QGIS was more about learning the process, since there there are Python scripts to help swap longitude systems (even in ogr2ogr – the trick is to clip lines and polygons before moving the feature).
But I am surprise the MySQL database is forcing your hand though, it shouldn’t care. That said, we might be playing some games to get this to work – I think by setting the SRID to “-1” (undefined). That means we probably step in-front of any coordinates system transformation and do it our self (for example, projecting from degrees to polar (in meters)). And I know when we export to shapefile, we assign the projection (*.prj WKT projection string) after export.
Another example where we had to play games was to support WorldWind JavaScript client (for a phone app). That client refused to render anything higher that 180. So we created a PostGres view which virtually swaps the system to -180 to 180 prior to serving as a WMS layer. See Nomenclature -180 to 180 (Mars) on this page: http://planetarygis.blogspot.com/2014/09/tips-to-interact-with-astros-wms-maps.html
In summary, if you want things to (usually) just work – use a -180 to 180 system. If you must use a 0 to 360 system, it should work, but be ready to play some games and potentially manually step-in for some use cases. Another method is to use meters (meaning a map projection, where you can set a central meridian to 180).