Definition: Spatial Reference System (SRS) codes are used to communicate the desired coordinate system and projection between a web client and a web mapping service. Part of the purpose of this page is to educate/share with others on this topic and to assess whether there is enough consensus to recommend "Best Practices" to the rest of the community.
Web mapping and mashups have always been driven by the need for application. In the 1990s and early 2000s, ESRI and the OGC (with help from the USGS) put a great deal of effort into creating elaborate standards for "Internet Mapping Services" and "Web Mapping Services". The biggest positive factor to these standards were their status as de juris standards.
When Google launched Google Maps (and perhaps even before), an ecosystem of web mapping arose based on application around as set of de facto standards. Google hadn't even anticipated the uses of its mapping platform. The first "mashups" using Google Maps involved reverse-engineering the API.
One of the standards that came out of Google Maps was the use of the "Web Mercator" or "Web Mercator (auxilary sphere)" reference system. Of historic note, Google originally used a non-Mercator projection but switched to a more azmithul projection because they wanted large scale road maps at high latitudes to properly represent intersections (follow this link to see the discussion).
Noel Zinn from Hydrometronics gave a technical critique of the Web Mercator projection at GIS in the Rockies 2010.
(this section is still forming up. The title may not be accurate as the content evolves. If so, feel free to change).
The history of SRS:900913 is somewhat contentious.
Chris Schmidt (creator of OpenLayers) http://crschmidt.net/blog/archives/243/google-projection-900913/
-900913: what is it? EPSG vs. OGC, standard/non-standard? -ESRI support: should it/shouldn't it?
-other projections like this? 102113
-replace both with 3857?
-getCapabilities snafu (just remove it from the catalog?)
-anecdote for TNM WMS
-idea: web redirect service that'll replace 900913 in a WMS getMap call with 3857. The same thing could be done for 102113. The following service works similarly (but actually does quite a bit more): http://thinkwhere.wordpress.com/2010/07/15/whoots-a-small-wms-to-tile-proxy-wms-in-potlatch/
(this is pretty rough; hopefully ideas will be extracted an placed above in a more structured way).
Email from Eric Wolf on March 4, 2011: Vendor Favoring and Disenfranchised TNM Users
I was talking to someone at the GeoData 2011 workshop in Broomfield. They've been trying to use WMS services from The National Map with other data sources. Like many people out on the wilds of the web, they are building their data visualization using open source software. They are not using ESRI ArcAnything. Like many of these people I speak with, they gave up trying to use TNM services because it just doesn't work. In the Data Integration Community (which GeoData 2011 is focused on - it's like an extension of the CDI outside of the USGS), OGC standard interfaces are used probably 100 times for every time an ESRI REST service is used. These people love OGC standards. I get up in front of rooms of scientists and citizens on a regular basis, showing off that TNM has these great standard services. I end up with egg on my face and the users end up frustrated because these services don't work.
This user's problem turns out to be the EPSG codes supported by TNM WMS services. This must be the third time I've complained about this. The EPSG codes reported by the WMS getCapabilities for TNM layers fail. Requesting data through getMap fails with an "Invalid SRS code" despite the fact the getCapabilities says it should work. This violates the OGC standards and is a consistent source of pain for potential users of TNM data. I say "potential users" because it's this kind of problem that makes people throw their hands up and use Google, Bing or OSM. We are actively disenfranchising TNM users through shoddy support de facto and de juris standards.
In the example here, I am trying grab a piece of large scale imagery layer via WMS. The links below both are valid according to OGC standards and the getCapabiltiies reported by the service. The only difference between the three is the EPSG code specified. All three EPSG codes are listed as valid by the getCapabiltities call. Two work, one doesn't.
There is a philosophical argument saying that we should only worry about 3857 and not 900913. But pragmatically, we need to support the EPSG codes in demand. Just as we support 102113 (ESRI's own version of 3857), we should support 900913. There is a political argument that we need to either support both 102113 and 900913 or neither. And we definitely shouldn't advertise in the getCapabilities support for something that doesn't work.
This may be a bug that we need to lean on ESRI over. I'm not one to don a tin-foil hat, but the fact that we are using ESRI's software and it seems to work perfectly with ESRI's proprietary EPSG code which works if you are paying ESRI for software to use with our services. But this fails regularly with the EPSG code that Google originated. This makes me think there are efforts in Redlands to try to undermine the efforts of competitors. The USGS is complicit in this corporate battle because we are following ESRI's lead. This is especially a problem since both are supposed to be following OGC standards. The USGS is a strategic member in the OGC. Shouldn't we be encouraging (if not demanding) our the software we buy from our vendors follow those standards?
I was just reading over Wyatt Anderson's email from January when this came up last. Evidently ArcServer doesn't support custom SRS codes and 900913 is considered a "custom" code. Isn't 102113 also custom, but proprietary to ESRI? Should we be supporting a custom code to the benefit of ESRI users but not a custom code to the benefit of people who adopted Google's custom code? If we are taking the stance that we cannot support 900913, we need to remove it from the getCapabiltiies.
Ultimately this kind of problem means The National Map is not being used in places where it could be. Poor support of standards (de facto, like EPSG:900913 and EPSG:102113 and de juris, like EPSG:3857) disenfranchises potential National Map users. We cannot take the stance that we are the only provider of maps any more. Especially in the realm of web-based mapping, the USGS is not the leader in any respect. We have to be responsive to our users needs or they won't be our users.
I do not think we should be telling our users to use a different EPSG. That will just drive more users to our competitors. We have to respond to our users' needs, not force our users to comply to our limitations. I also argue that we cannot fall back on claiming ESRI's software prevents us from supporting 900913. Send ESRI a bug report. It's their problem and we should hold them accountable. As a "strategic member" of OGC, we should be doing everything we can to encourage adoption of OGC standards. By letting ESRI get away with half-baked implementations of those standards undermines the entire standards process. And if we are not going to support 900913 (for whatever reason), we cannot support 102113. We cannot favor one vendor's proprietary "standards" over another. Finally, we absolutely cannot have getCapabiltiies specify things that we know does not work. We should have unit tests that verify functionality advertised by getCapabilities.
Mike Schramek’s (contractor at NGTOC) reply (with a possible work-around for ArcServer):
Thanks for the update, I fully agree. I didn't know there were still any problems, although, the imagery services are currently being served out of EROS, not here in Denver, so I may be out of the loop. Please let me know if you are still seeing any problems with any service coming out of "services.nationalmap.gov..." or "basemap.nationalmap.gov...". And, you might pass along the email address "email@example.com
As far as this issue, it does seem a little weird that the GetCapabilities lists both projections, but one works and one doesn't. Wyatt, I do have one idea you could try: add a BoundingBox line for 900913 for each layer. You might have to use ArcMap to figure out what the bounding box extents should actually be. See below, where all the CRS' are listed, but the layer only has bounding boxes for 84 and 4326 (included in each service by default), and 102113 (probably the projection your mxd is in). Maybe this is why 102113 works but 900913 doesn't? I did test this when I switched to all manual capabilities files for my services, and it didn't seem to make any difference whether it was included or not, so I didn't do it, but maybe I missed something. Let me know if it does make it work. If not, then maybe ESRI needs to look into it.
Wyatt Anderson’s (contractor at EROS) Reply:
Our servers are using ESRI ArcGIS Server. ESRI has chosen NOT to implement a custom SRS/CRS code of 900913. So yes, we should take the 900913 projection out of the capabilities file, as it does not work with WMS requests. The 900913 projection was added to the capabilities file to satisfy a National Map requirement for Google access (JIRA 943, 960)
Note: We have successfully used our services in non-ESRI viewers (like OpenLayers) by changing the default projection from 900913 to another projection that ESRI ArcGIS Server supports. We will be happy to assist anyone trying to use our services within Google Earth, Bing, OpenLayers, etc, who are having projection issues.
Matt Tricomi’s comments on Wyatt’s replay:
Wyatt is right.
2 weeks ago, Wiese, Dollison, and I met with open geo (actually, the author of 900913) and he suggested by no means is the issue have anything to do with ESRI. Actually, he said 900913 was rejected by OGC, and that there appears to be some "disagreement" in the open source community around that EPSG.
There are plenty of other ESRI delivery issues, but this "favoring" point has nothing to do with ESRI - they are implementing the spec correctly as Wyatt noted. And, Kevin Hope has made absurdly clear to the blueprint team that standards will be key to addressing the next set of TNM solutions. He has also followed up with open geo groups recently and we have had active weekly threads with open groups as research related to the blueprint.
Your issue has been OK'd by Kevin Hope and Rob Dollison to add as part of the delivery blueprint, and CEGIS has been identified as SMEs per our discussions with our respective bosses last month - stay tuned, interviews are coming!