U.S. National Grid

A Google Maps demonstration of the official map coordinate system of the United States.

This application displays geographic and map coordinates for any point, and allows U.S. National Grid (USNG) coordinates to be used for search and directions. This is a Google Maps mashup, that uses the Google API for base map and navigation, and Javascript code to compute coordinate values.

Open the map in a new window

Send comments and bug reports to Larry Moore at jane.larry@gmail.com



Single-click anywhere on the map to display a variety of coordinates and optionally create a marker for the point.

The seach and direction forms mimic those of the native Google Maps interface, which of course allows search by street addresses and place names. Directions are displayed in a new window using the native Google Maps directions interface. By doing this rather than displaying the directions in the mashup window, additional capabilities such as dragging and dropping points along the route are available.

Although it is not well advertised in Google's documentation, Google Maps also allows search by geographic coordinates in decimal degrees, degrees and decimal minutes, and degrees-minutes-seconds. These capabilities are slightly enhanced by this application. See search below.

The primary additional feature of this application is to allow search by USNG string. Any legal USNG or Military Grid Reference System (MGRS) string for anywhere in the world between latitudes 80S and 84N will work.

Street address searches use Google's geocoder, which is very flexible. However, geocoding in general is much less accurate than geographic coordinate systems such as lat/lng or the USNG. The directions feature is also provided by the Google API, and only works for street navigation - don't use it for cross-country or open-water navigation.

The base map is a normal Google Maps display.

Start-up parameters

The default URL is

. The following parameters are optional:

URL parameters are separated with the ampersand character [&], and need not be in any particular order. Error trapping for these parameters is not sophisticated. Illegal values and incorrect syntax may cause the map display to fail in unpredictable ways. It is up to the calling application to construct the URL correctly.


A URL that will center the screen on the Washington Monument, zoomed into the National Mall area: An equivalent URL using lat/lng instead of USNG: This link will open a new window and zoom to the Washington Monument in Hybrid view: The HTML code for this link is
<a href=http://www.fidnet.com/~jlmoore/usng?zoom=14&disp=h&usng=18SUJ23480647 target="_blank">Washington Monument</a>

Return to top

Coordinate systems


Above the map are two coordinate readouts that change as the cursor is moved: U.S. National Grid coordinates, and latitude/longitude in degrees and decimal minutes (DD-MM.mmm). The format of the lat/lng readout conforms to recommendations made by the National Search and Rescue Committee in July 2007 (see references).

Clicking on the map displays an information balloon with two tabs. The default tab shows:

  1. US National Grid coordinates, equivalent to Military Grid Reference System coordinates over the areas of the United States. Outside the U.S., MGRS coordinates are displayed.
  2. Latitude/longitude in degrees and decimal minutes (DDD-MM.mmm).
  3. A direction search form that opens a second window and gives directions through the native Google Maps interface. (Moving to the native interface loses the coordinate systems that are the primary focus of this mashup, but gains the benefit of being able to alter routes by dragging points.)
  4. A button to set a marker at this point.

The second tab shows several other coordinate values:

  1. Universal Transverse Mercator (UTM): zone, easting, northing.
  2. Latitude/Longitude in two other formats:
  3. Global Area Reference System (GARS) value of the 5x5 minute geographic square this point fall in. GARS is a world-wide areal grid system used for battlespace management and large-area search and rescue operations. The GARS computations were added in January 2009 and are not yet well-tested.

Google Maps is based on the WGS84 datum. NAD83 is commonly described as the "North American equivalent" of WGS84. The two datums are within a few centimeters in most cases, and within a few meters in the worst case. For all purposes other than (for example) scientific studies of continental drift they can be regarded as equivalent. All coordinates in this application are on NAD83/WGS84.


A primary feature of this mashup is that USNG and MGRS strings may be used for search and directions in addition to the normal place names or street addresses.

The following latitude/longitude coordinate formats can also be used:

  1. Decimal degrees. Example: 38.88948, -77.03525
  2. Degrees and decimal minutes. Example: 38-53.369N, 77-2.115W
  3. Degrees, minutes, and decimal seconds. Example: 38-53-22.1N, 77 2 6.9W

In all cases, the following guidelines apply:

Zone and grid lines

Grid lines are a paper-map tool for finding coordinate values. Software does this in online maps, so there is arguably no need for grid lines. On the other hand, grid lines provide context and a sense of scale, so might be desireable even though they have little analytic value. The current version of this mashup displays UTM zones, 100,000-meter USNG lines, 1,000-meter lines, 100-meter lines, and appropriate labels (at appropriate scales when check boxes are selected).

Zone lines are straight and grid lines are curved, the opposite of what most people would consider normal. This is a side effect of the projection used by Google Maps. UTM grid lines are straight lines on Transverse Mercator projections. Google Maps uses the Standard Mercator projection, which has a very different geometry.

Notes on precision and accuracy

The real-time coordinate displays have precisions of 10 meters for USNG coordinates and 0.001 minutes (about 2 meters of latitude) for the geographic coordinates. The info window balloon displays have a precision of 1 meter for USNG coordinates, 0.001 minutes for D-M.m coordinates, and 0.1 seconds (about 3 meters of latitude) for D-M-S.s coordinates. Precision is not the same thing as accuracy. Accuracy depends on the quality and resolution of the base data, which is generally very good in Google applications, but is not necessarily on the order of 1 meter for all areas.

The length of a USNG string depends on the precision desired in position referencing. On a paper map with visible grid lines and fixed scale, the meaning of precision is obvious. For example, 18S UJ 12345 12345 has a precision of one meter, so for all practical purposes refers to a unique ground point. 18S UJ 12 12 has a precision of 1,000 meters; on a 1:24,000-scale map it refers to a particular 1,000-meter grid square. But on a variable-scale online map it is less obvious what these different levels of precision mean, or how they should be displayed. The search and driving directions functions of this application require USNG precision of at least 10,000 meters, on the theory that allowing search at lower precisions is confusing without being useful. In all cases, USNG positions are shown with a point marker placed at the SW corner of the referenced grid square. That is, for computational purposes 18S UJ 12 12 is equated to 18S UJ 12000 12000.

The program will accept some USNG strings that are not strictly legal and convert them to strings that are legal. For example, 15S YE 56101 32070 is not a USNG value, because the coordinates do not fall within UTM zone 15S. But the string is illegal as a matter of definition -- the math works just fine, and a legal string describing the same ground point (16T BK 43902 32070 in this case) can be determined from this input. The code does these kinds of conversions. The limits of this functionality have not been tested, and it is unwise to depend on this type of software capability; users and other applications should make every effort to use legal inputs.

Return to top

Acknowledgements and disclaimers

This site has no formal or official relationship with Google or any of the Government agencies referenced.

This application uses algorithms and code developed by other people:

Most of the borrowed code has been modified for this application. Errors should be assumed to be the responsibility of the present author, not the original sources.

This is free software, it comes with no accuracy guarantees, use at your own risk, etc. The source is released under the terms of the MIT License

Send comments to Larry Moore, jane.larry@gmail.com. This application has been up since mid-2007, and seems to be pretty well tested. Still, if you use it for anything that is actually important in the real world, especially outside North America, I recommend some testing with independent data and calculations. If you find any point where some coordinates appear to be wrong or inconsistent, please email the values to me.

Return to top

Commentary: Why the U.S. National Grid is important

During the Hurricane Katrina emergency in September 2005, a mapping problem briefly made national news. People trapped in their houses used their cell phones to call for rescue. These people could describe their location only with a street address, but street addresses were of limited use to rescuers, because a) many of the rescue crews were not from the immediate area and b) street signs and house numbers were either destroyed or under water.

The problem was partially solved by having GIS specialists use geocoding software to convert street addresses to standard coordinates. This was new technology to many of the first-response organizations, so implementing it took time. And it was only a partial solution: first-response procedures were not standardized on one coordinate system, workers in the field had no easy way to convert coordinate values, and many were not trained to use any standard coordinate system.

Military and disaster-relief professionals refer to such problems, with studied casualness, as "operational friction." In the calm of a normal office environment it sounds incredible that coordinate conversions could be such a problem, but during the chaos of combat or hurricanes this is serious business. This flavor of operational friction can cause air strikes to fall on friendly forces, ambulances to arrive late, and flood victims to remain trapped in their attics far longer than necessary.

An important part of a solution is obviously a standard coordinate system. There are arguably three geospatial coordinate systems that are accurate enough and universal enough to be candidates:
  1. Latitude/longitude. Programmers and GIS specialists might think this is the obvious choice, but for non-GIS specialists working in stressful field conditions it is less attractive. One problem is that nobody thinks in angular units (quick: what is the ground distance of 0.3 minutes of longitude at 36-00N? how about at 42-00N?). Another is that there is no broad consensus on how lat/lng values should be expressed. Decimal degrees, degrees with decimal minutes, and degrees-minutes-seconds are all in common use, and each has variations in how letters, sign, and punctuation are used. These variations cause trouble even in written communication, and the problems can become severe when coordinate information is transmitted by voice radio.

  2. Universal Transverse Mercator (UTM). This is a plane (as opposed to spherical) coordinate system, but as the name implies, it covers the globe: a UTM zone number and X,Y coordinate pair uniquely identify a point anywhere in the world (except for areas near the poles). But for military and disaster response applications, the UTM grid has some shortcomings. One ground point can have more than one valid UTM designation, and there is no firm convention for how the three pieces of a UTM location should be ordered and formatted.

  3. The Military Grid Reference System (MGRS) was developed in part to reduce the ambiguities of the UTM system. Except for the polar regions, the mathematics of MGRS and UTM are equivalent, but the MGRS has a more rigorous syntax. The U.S. National Grid (USNG) is a civilian adoption of MGRS for the United States. In the United States and on the WGS84 or NAD83 datums, the MGRS and USNG are equivalent except for some relatively minor editorial differences.
The USNG represents an X,Y position as an alpha-numeric string of 15 or fewer characters with no punctuation (for example: 15SXC0900). To someone unfamiliar with the system, this does not look like a Cartesian coordinate pair at all. The USNG standard is complex in the sense that understanding it well enough to write a software encoder from scratch is difficult. It may not be obvious that the USNG is a good solution to the problem, but in fact it is almost certainly the best solution. Reasons why this is true include: a) the burden of the USNG's complexity is borne by map producers and software developers, not by users; b) the USNG system is designed to reduce ambiguities in coordinate communication, especially voice communication; c) the USNG standard is rigorously written, widely reviewed, and thoroughly tested.

On paper, the USNG is the official geographic coordinate system of the Federal Government. In practice, implementation is far from complete, as illustrated by the problems associated with Katrina search and rescue.

To GIS professionals and Google Earth enthusiasts this may all sound a bit quaint -- why use mid-20th century paper-map standards in an age when cell phones and other pocket devices integrate GPS, online maps, and instant communication? One answer is that the world made possible by current technology is quite a bit different than the world most people actually live in. "Operational friction" is one description of the difference.

Less critical, but still interesting, uses of the USNG

As a method for navigating in unfamiliar territory, street addresses are pretty unsatisfactory. Who hasn't had the frustrating experience of searching for a business in a congested urban area with nothing to go on except the street address? Geocoding is a weak solution to this problem because address ranges are neither well standardized nor stable. Even in the best case, a geocoder probably won't tell you which side of the street.

The U.S. National Grid provides a strong technical solution. This mashup demonstrates that finding a location by grid address is both easier and more accurate than using a street address. Street addresses are long, ambiguous, and have a weak relationship to geographic position; USNG strings are concise and very accurate. If online maps routinely implemented search by USNG coordinates, giving directions to anyone with online access would be simple: "Meet me at Joe's Restaurant, 15SYC25927019." This may look a little intimidating, but is actually no more complex than a typical street address. From a user's perspective it is more concise and more accurate. From a programmer's perspective it is not only more accurate, it is also much cleaner: unlike geocoding, it does not depend on look-up tables of address ranges.

Return to top

Information for programmers

The Google API documentation section on geocoding contains a simple search example. The sample code contains a function called showAddress():

function showAddress(address) {
    function(point) {
      if (!point) {
        alert(address + " not found");
      } else {
        map.setCenter(point, 13);
        var marker = new GMarker(point);
To add the capability to search by USNG in addition to place name and street address, add the following code block at the top of the function:
function showAddress(address) {
  var usngstr = isUSNG(address)
  if (usngstr) {
      // convert USNG string to lat/lng
      var point = GUsngtoLL(usngstr)
      map.setCenter(point, 13);
      var marker = new GMarker(point);
  else {
// continue as above...

The functions isUSNG() and GUsngtoLL() are in the file usng.js (along with several other functions). Be sure to declare usng.js as an external .js file. Note: A significant bug, affecting MGRS-to-lat/lng calculations in the first grid zone north of the equator, was discovered in this module in December 2008.

A tar file of the source for this mashup is here.

Return to top

References and more information


Primary sources

Source code

Return to top

Initial release May 2007. Last modified April 2009.