GCS WGS84: Why should you care about it?

By Charlie Frye, Esri Chief Cartographer

I’ve spent the last few months immersing myself in ArcGIS 9.3, particularly ArcGIS Server and ArcGlobe in order to create some map and globe services and see how they work in ArcGIS clients, Google Earth, and Virtual Earth. These services need to look good and draw fast. One factor that can dramatically influence drawing performance is whether projection-on-the-fly is being used.  Projection-on-the-fly will slow your map down, anywhere from 30% to 1000% slower (depending on the coordinate systems involved).

I decided I wanted to optimize drawing performance for each of my map services by having my data in the same projection as the final map (not surprising since that’s the same advise I’d give anyone making a paper map).  What I discovered was that for Virtual Earth and Google Maps, I needed my maps and data to use the WGS_1984_Web_Mercator projected coordinate system (new in 9.3); and for ArcGIS clients and Google Earth, I needed to use WGS_84. There is additional information about this in the online help in 9.3 in a new topic called How to build online base maps.

I had planned from the beginning to cache these maps because I knew this would mean that the cached map service would let people see the best cartography I could create in ArcMap without having to wait for ArcMap to draw it. What I didn’t plan on was that drawing speed in ArcMap directly impacts the time it takes to cache these maps. I had chosen to make map services that either covered a large area at a number of smaller scales (continental U.S.) or a smaller region in great detail (Lower Colorado River Basin at 1:4,500). This meant I was either using large datasets (5 million or more features in a feature class), which are often not as efficient to query using definition queries and labeling SQL queries, or I had a lot of features drawing at a given map scale — both of these cases can slow down the drawing speed. Avoiding projection-on-the-fly turned out to be one of the most significant time savers for producing the map caches.

Here are a few things I learned as I projected my data and created these map services.

  1. Much of my data used coordinate systems based on NAD83.  It’s easy enough to use the Project tool to change the coordinate system to WGS 84. However, learning which was the correct transformation method tripped me up:  for the North America use NAD_1983_To_WGS_1984_1; and for the continental U.S. use NAD_1983_To_WGS_1984_5 (there are eight to choose from). TIP: Use the project tool, and once it’s run, copy the Transformation method string from the geoprocessing results window and paste it into a notepad session.  This will make it easier to use the Batch Project Tool which does not automate the pre-selection of the transformation methods–doing it this way, you’ll be able to just paste the method into that tool.
  2. Some of my source data was in NAD27, which needed to be projected to NAD83 first, and then to WGS84 as a transformation was required for each of these steps.
  3. To project data to WGS_84_Web_Mercator, I had to first project my data to WGS84 because an additional transformation is necessary to project data from WGS84 to Web Mercator.
  4. Make sure all of your data have spatial indexes because spatial indexes ensure optimum drawing speed. Spatial indexes are not always automatically created, so check your feature class properties on the Indexes tab to see if it has one.
  5. There will also be times when projecting your data isn’t practical, and relying on projection-on-the-fly is the only way to go. In my case, this applied to the imagery and elevation GRIDs I was using — these were either datasets or map services for the U.S. and the data sets were so large that the projection operation could take many hours, even more than a day! In these cases, I would strongly recommend the data you are mapping be stored in WGS84. The reason is that these data can be projected on-the-fly with a minimum loss of accuracy.  Storing your data in a coordinate system based on NAD83, or worse NAD27, means you could very likely see “datum shifts” in the display when using the WGS_84_Web_Mercator coordinate system. An additional incentive to store your map data in WGS84 is that our development teams are also working on further optimizing the projection-on-the-fly routines from WGS84 to Cube (used by ArcGlobe).

    Finally, I also saw that WGS84 based services performed very well on all web clients (not as fast as Web Mercator services on Virtual Earth — I didn’t have a license for Google Maps, but I have been assured the same is true here). So, based on my recent experiences, if you know that map and globe services are among the products you are expected to produce with your GIS data, I would strongly recommend storing your data first in WGS84, and then if needed extract data for product databases in the specific coordinate system required by each product.

This entry was posted in Mapping and tagged , . Bookmark the permalink.

Leave a Reply

2 Comments

  1. duanewilkins says:

    Hi there,

    As a datum, all fine, the use of WGS84 for Cartographic output maps in countries like Afghanistan where its heavily distorted just feels bad. Yet its use is widespread if not total.

    Why does it seem to me to be a bad idea to print maps in wgs84 instead of Web mercator or so?

  2. cfrye says:

    If preserving shape, area, & distance are critical in your cartographic depiction, then neither WGS84 or Web Mercator are good choices for a geographic or a projected coordinate system for your map. Web Mercator is useful because it’s the basis for mash-up that the rest of the world using (like it or not). WGS84 is just a go-between; In my opinion, it should never see the light of day even at fairly large scales, but I usually have high standards for how I communicate things geographically.

    ArcGIS Server and ArcGIS Online both support serving and presenting maps in any coordinate system that ArcGIS can support. We discussed this in our An Alternative to Web Mercator: Winkel Tripel blog post last year. It all comes down to whether you want your content to be used in mash-ups, and if not, then make and serve the map the best way you know how.