Google's Complete Map Content Specifications

Introduction

This document provides Google's specifications for the format and delivery of aerial imagery, digital terrain models, 3D models and transit route and schedule data for publication on Google Maps, Google Earth and other Google services.

3D Models

Data format
Google supports 3D models with and without textures, and extruded 2.5D building footprints without textures. The formats we support for each are:
  • 3D textured - .skp, .kmz (.kml + .dae)
  • 3D non-textured - .shp, .skp, .kmz (.kml + .dae)
  • 2.5D non-textured - .shp, .csv, .kmz (.kml + .dae)
Note: Non-georeferenced data formats such as .3ds and .max must be accompanied by geo-referencing materials such as .kmz placemarks or UTM coordinates

ESRI .shp file notes
  • Include the .prj file which contains information describing the geospatial coordinates
  • Include a "HEIGHT" value in the .shp file Attribute Table for setting the relative heights for the buildings. (it's a common term that helps identify building heights when doing the processing.) If using another value, supply us with the name of the value (e.g. "Building Heights")
  • Set building heights to Relative elevation
  • If using height extrusion, add ~3 meters to the extrusion to ensure terrain intersection
  • Align your building data to structure's foundation using Google Earth imagery prior to submitting the data for evaluation (.shp files can be imported in Google Earth to test this)
  • Each building and it's components should be a single element (i.e. Dormers, roofs, chimneys, etc., and the main structure should be consolidated or merged into one element) - This can be done easily if there is shared data field associating the components, such as a parcel or address data, in the .shp file Attribute Table.
  • Ensure efficient and accurate geometry. This includes: no broken vertices, no missing faces, no gaps in structures, no internal geometry, and no z-fighting on faces
Geometry
The following guidelines apply to the model's geometries:
  • Individual models should have fewer than 5000 polygons each.
  • They should never be complex; photo-textures should be used in lieu of geometries where possible.
  • Polygons should never have broken vertices, T intersections, spiderweb faces, hidden/missing faces, z-fighting, self-intersections or internal/unseen geometry.
  • Individual buildings should be represented by a single group of geometries, not multiple stacked primitives.
Textures
The following guidelines apply to the model's textures:
  • They must be JPEGs (exception is .png materials with alpha channel representing elements such as railings, windows, grates, stair cases, etc..).
  • They must never exhibit Z-fighting.
  • They must be sized in powers of two, preferably 1024 x 1024 (max resolution:2048 x 2048).
  • They must have accurate and non-repeating images for street-side faces.
In addition to the above, we do not accept:
  • Auto-generated textures such as repeating facades, or procedural textures.
  • Partial textures such as single facades only.
Alignment
The following guidelines apply to the model's alignment:
  • Models must be correctly aligned to the underlying imagery published in Google Earth.
  • Models must have their height set as relative to the underlying DEM, not absolute; 2.5D and .shp data must have a 3 meter extrusion applied to account for variances in published terrain.
  • Models should never float above the terrain when loaded into Google Earth, unless provided with the corresponding DEM they were cut to match.
Model directory and file structure
The following guidelines apply to the directory and file structure of the models:
  • Data must not have double-byte or extended ASCII characters in the model names, texture names, file/folder, or subdirectory names.
  • Data should not be packaged using excessive nested directories.
Metadata
The following metadata should also be included in a separate text file:
  • A complete list of model files
  • Indicate scale in meters or feet
  • A complete building count (not just a model count, but a count of the buildings/structures that the data set represents)

Aerial Imagery

 
Data format
We accept 24-bit 3 band RGB imagery (no alpha channel) delivered as uncompressed GeoTIFF or JPEG2000 files at quality level 25 or better.

As a general note, we prefer to receive individual imagery tiles rather than a single mosaic.

Projection information
Each image must be accompanied by one of: a text description of the map projection (WKT), an ESRI .prj file describing the projection or the European Petroleum Survey Group (EPSG) code for the projection. We also accept the projection information embedded directly in the imagery headers.

We accept imagery projected using a standard cartographic projection such as Universal Transverse Mercator (UTM), a satellite-based datum such as GRS80, or WGS84; or in Geographic Coordinates (aka "latitude/longitude") with WGS84 datum. Images should be north-aligned and have rotation parameters set to zero.

As a general note, we prefer data that has undergone the least amount of transformations, as the resampling process degrades the data with each iteration.  If given a choice with no other background information, a projected coordinate system (UTM, national grid, stateplane, etc.) is preferred over a geographic coordinate system (latitude-longitude).  This is because pixel dimensions vary with latitude in geographically projected data.

Metadata
The following metadata should also be included in a separate text file:
  • Data acquisition start data: dd/mm/yyyy - end date: dd/mm/yyyy
  • Pixel resolution size
  • Map projection used when the image set was orthorectified
  • Final map projection of the delivered product (if different from original projection)
  • Best known positional accuracy of the final product
  • Any known issues with the imagery
A tile index shapefile or KML should be included that shows the area covered by each image tile in the data set.

Imagery directory and file structure
All files should be grouped into a logical folder structure based on geography, date, resolution, and type. There should be no spaces in the names of any files or folders.

For example:

    --> Las_Vegas
                -> 2007_1ft_RGB
                          -> 2007_1ft_RGB.tif
                          -> 2007_1ft_RGB.tfw
                          -> 2007_1ft_RGB.prj
                          -> 2007_1ft_RGB_metadata.txt
                          -> 2007_1ft_RGB.shp
                          -> 2007_1ft_RGB.shx
                          -> 2007_1ft_RGB.dbf
                -> 2008_1ft_BW
                -> 2000_6in_RGB
                -> 1990_2ft_CIR
    --> Reno
                -> 2009_3in_RGB
                -> 2004_6in_RGB

Additional information
Color infrared as well as black and white may be acceptable for older and historical imagery. Also, in some cases we may acceptimagery that has been georeferenced as opposed to orthorectified. This imagery must be in one of the above formats.

 

We generally do not accept un-referenced film/plate scans (images that have just been scanned in and not referenced).  However, feel free to tell us about the data you have to share so we can determine if it is accepable.


Base Map (Vector) Data

Types of base map data Google is most interested in:

We are currently most interested in:
  • Parks and Protected Areas.
  • Points of Interest (hospitals, tourist attractions, government buildings).
  • New Developments and Construction (residential, commercial) with the focus on:
    • Road Networks
    • Geocoded Addresses
    • Parcel Boundaries
  • Bicycle and pedestrian paths and road facilities.

Data formats

We do accept all formats of base map (vector) data; however, when data is submitted in the formats described below, it makes it easier and quicker for Google to ingest it.

Supported data formats are:

 

  • ESRI Shapefile
  • MapInfo TAB
  • KML/KMZ with the data represented as SchemaData and SimpleFields (preferred) or ExtendedData.
  • DBF or CSV - If CSV, make sure it is comma-delimited, with each column surrounded by quotes to prevent issues with commas in names, etc. Also ensure that there is a header row.
  • ESRI GeoDatabase (prefer data exported into individual shapefiles)
Google is aware that some users may use AutoCad. However, the above formats are strongly preferred.

Additionally:
  • Please use UTF-8 character encoding for vector attributes. UTF-16 and UTF-32 are also accepted.
  • Please, no special character encodings!
  • We prefer files to be < 1GB.
  • For lookup tables, DBF or CSV is acceptable. If CSV, make sure it is comma-delimited, with each column surrounded by quotes to prevent issues with commas in names, etc. Also ensure that there is a header row.
  • FGDC formatted Metadata recommended.
  • We do not have standards on field types, field widths, domains, etc.
  • See here for questions on contributing your data via WMS or WFS.

Common concepts in data format

Throughout this specification, we refer to the following basic representations for fields that are shared between different types of data.
Formatting Addresses
Addresses are used for points of interest and geocodes as below, plus a slight variant is used for streets. Address should include the following in separate columns:
Field Description Example
ST_NUM Street Number  125
ST_NAME Street Name and Type (the words StreetAvenue, etc., can be abbreviated) Powell St
NEIGHBH (optional) Neighborhood Name  Union Square
CITY City Name San Francisco
STATE State (Two Letter Abbreviation) CA
ZIP 5-digit zip code 94108 
CNT_NAME (optional) County Name San Francisco
CNT_FIPS (optional) County FIPS 6-4 code (see here and here) 06075
Geometry
In the case of polygons, multipolygons are preferred, rather than one feature with the same name each with geometry. If a feature is comprised of several polygons, use one multipolygon to represent them. For example, if you have a park that is in two sections, then include the park in one polygon. Please also note that Inner loops/donuts (for example to exclude lakes from a park, or an island from a water feature) are accepted, polygons should have correct windings (preferred order is clockwise for both internal and external polygons), and they must not self-intersect.

In the case of polylines, please provide clean geometry - i.e. no dangling lines, undershoots, overlapping lines, or nearly overlapping lines.
Alternate names

The primary name of a POI should be given as NAME. Alternate names are very important in making it possible to find places. The NAME field is the one that will appear visibly in our maps, but if people search for the alternate names, we can point them to the right location.

Hence for POIs and so on, names can be represented as follows:

 

Field Description Example
NAME Most well-known Name Alcatraz
ALT_NM_1 Alternate Name 1 (second most well known) Alcatraz Island
ALT_NM_2 Alternate Name 2 (Third most well known) Golden Gate Recreation Park (Alcatraz)

Properties of individual data types

Parks and Protected Areas
Parks and protected areas should have the following information:
  • Polygon geometry is preferred over point geometry (scale better than 1:25,000 preferred).
  • Name of park/protected area (in a field called NAME, with alternates in ALT_NM_1, ALT_NM_2).
  • Optionally, parks should include an address.
  • An MTFCC field for the classification of the park. For a description of preferred classification, refer to the U.S. Bureau of Census TIGER MTFCC standards. If you have a different categorization, please include a data dictionary describing the types.
  • under Documentation (stored in a field called MTFCC).
  • Optionally, any data related to park operating hours, parking, facilities, etc can be added in fields of the form with X_DESCRIPTION, such as: X_USAGE, X_HOURS, X_PARKING, etc.


MTFCC Short description Long description
K2180 Park Open space; major category used alone when the minor category could not be determined
K2185 Regional Park, Forest, or Recreation Area A place or area set aside for recreation or preservation of a cultural or natural resource and under the administration of a regional government.
K2186 County Park, Forest, or Recreation Area A place or area set aside for recreation or preservation of a cultural or natural resource and under the administration of a county government.
K2187 County Subdivision Park, Forest, or Recreation Area A place or area set aside for recreation or preservation of a cultural or natural resource and under the administration of a minor civil division (town/township) government.
K2188 Incorporated Place Park, Forest, or Recreation Area A place or area set aside for recreation or preservation of a cultural or natural resource and under the administration of a municipal government.
K2189 Private Park, Forest, or Recreation Area A privately owned place or area set aside for recreation or preservation of a cultural or natural resource.
K2190 Other Park, Forest, or Recreation Area (quasi-public, independent park, commission, etc.) A place or area set aside for recreation or preservation of a cultural or natural resource and under the administration of some other type of government or agency such as an independent park authority or commission.
Points of Interest (POIs)
Requirements and Recommendations for POIs:
  • Polygons are preferred to points.
  • If some POIs are points and some are polygons please have separate files for each and please be sure the classification is the same in both cases and the fields of the shape file are the same (aside from geometry).
  • Point or Polygon Geometry (scale should be be better than 1:25,000).
  • Please use a field called 'NAME' for the name of the POI.
  • For POI categories, we recommend using the U.S. Bureau of Census TIGER FCC standards.
  • Please use a field called 'MTFCC' for category name.
  • If providing Polygons, please Indicate if the the geometry refers to the entire grounds or to building outlines. You may Indicate this during data submission, or add a field to the data and indicate "Grounds" or "Buildings". Optional Field naming guidelines (data related to park operating hours, parking, facilities, etc) should start with X_DESCRIPTION, such as: X_USAGE, X_HOURS, X_PARKING, etc.
  • Other standards and/or custom categories will be accepted, but be please be sure to include a data dictionary.
  • Generally speaking as fine-grained a classification as possible should be provided.
For your reference, here is a list of frequently used MTFCC codes.
Building footprints
The following apply to building footprints:
Parcel data
The following apply to parcel data:
Address Points
The following apply to address points:
  • Include full address information
  • Do not include invalid geocoded points (e.g. no latitude/longitude values).
  • The geocode should link to the segment it belongs to (using the unique id).
  • They should be placed so that it is closest to the most natural access point. For instance, if a house is on the corner of a major roadway with no access from the house directly and a local road, make sure the geocode point is closer to the local road -- in other words, closer to the main entryway of the building.
  • Standardize the format, so that, for example, all the addresses in an area are the same format and are consistent. For example, it is bad if one house in an area is 1-A and another one is 2B. They should all have the same format (for example, 1A and 2B).
New roads and bicycle and pedestrian paths
Google is presently accepted two specific types of network data: new roads, and bicycle and pedestrian paths.
  • Use a segment-based representation: a segment is part of a road between two intersections. We can not accept roads that have multiple intersections hanging off of them.
  • The street format is similar in many ways to the address format, with the exception of the different street number format.
  • All address ranges should be specified relative to the the geometry (that is, the right side is to the right of the path from the start of the segment to the end of the segment).
The following fields are useful for roads and bike and pedestrian paths. Fields marked as "optional for BP" are not necessary for bike and pedestrian paths:

Field Description Example values
ID A unique and stable identifier for the road segment Any alphanumeric string (e.g. "14232514")
AR_RT_FR (optional for BP) Starting address on right hand side, relative to geometry 42
AR_RT_TO (optional for BP) Ending address on right hand side, relative to geometry 58
AR_LT_FR (optional for BP) Starting address on left hand side, relative to geometry 41
AR_LT_TO (optional for BP) Ending address on left hand side, relative to geometry 57
ST_NAME Street Name and Type (the words StreetAvenue, etc., can be abbreviated) Powell St
ST_NM_A1 (optional) Alternative Name 1 U.S. 101
ST_NM_A2 (optional) Alternative Name 2  
NEIGHBH (optional) Neighborhood Name  Union Square
CITY City Name San Francisco
STATE State (Two Letter Abbreviation) CA
ZIP (optional for BP) 5-digit zip code 94108 
CNT_NAME (optional) County Name San Francisco
CNT_FIPS (optional) County code (see here and here.) 06075
ONEWAY (optional for BP) One-wayness - relative to the direction of geometry "None", "To-From", and "From-To"
PRIORITY (optional for BP) We would consider the following levels: interstate, federal/state highway, expressway, minor arterial, local, not intended for public traffic. minor arterial
LANES (optional) Number of lanes 2
SURFACE (optional) Road Surface Paved or Unpaved
SPEED_LM (optional) Speed limit in MPH 55
AVG_SP (optional) Average Speed 25 
CAR (optional) Cars are allowed on this segment? Allowed, Small vehicles only (mopeds etc), None, Disallowed
PEDEST (optional) Whether the segment allows bikes, and if so, what type it is One of: Trail, Walkway, Mall, Sidewalk, Wide Shoulder, None, Disallowed
BIKE (optional) Whether the segment allows bikes, and if so, what type it is One of: Trail, Bike Lane, Wide Shoulder, Recommended, None, Disallowed
SEPARATED (optional) Whether the road is separated by a barrier in the middle Y/N
TURN_R (optional) Turn Restrictions (or see below for exact format) Freeform text
ELEVATION (optional) If the road is elevated, or a bridge or a tunnel One of: bridge, tunnel, overpass, underpass


We are happy to accept turn restrictions as freeform text to make it easier for people to submit data as turn restriction formats can be very complicated. We can accept turn restrictions in any format. However, to assist, here is a model format that would typically be delivered as a CSV file or a DBF file:

Field

Description

Example

FROM_ID

The ID (see the id column above of a road segment) of the segment where the turn restriction starts

14232514

FROM_END

The end of the segment the turn restriction applies to relative to its geometry. 

Either "FROM" or "TO"

TO_ID

The ID (see the id column of a road segment) of the segment where the turn restriction ends 

14232599

TO_END

The end of the segment the turn restriction applies to relative to its geometry

Either "FROM" or "TO"

MODE

The mode of transportation the limitation applies to. 

Either "ALL", "PEDESTRIAN", "CAR", "TRUCK", "BUS" or "NON-HOV"

START_TM

The start time of the turn restriction, in 24 hour notation. Leave this and END_TM blank for permanent restriction

06:00

END_TM

The end time of the turn restriction, in 24 hour notation. Leave this and START_TM blank for permanent restriction

10:00

TYPE

Type of turn restriction  

Either "NO LEFT TURN", "NO RIGHT TURN" or "NO U-TURN" 



Digital Terrain Models

Data format
We accept most GDAL supported, single band, type Float32, uncompressed raster data formats with a height value in meters.  

Supported formats are:
  • GeoTIFF (GTiff: ".tif")
  • Arc/Info Binary Grid (AIG: ".adf")
  • Arc/Info ASCII Grid (AAIGrid: ".asc")
  • Erdas Imagine Images (HFA: ".img")
  • SDTS Raster (SDTS: ".DDF")
  • USGS ASCII DEM (USGSDEM: ".dem")
Supported data types:
  • Int16, UInt16, UInt32, Int32, Float32
Vector formats (LIDAR point clouds, contour lines, TIN models) are not supported for direct input and must be converted prior to delivery to a supported raster format.

Projection information
Terrain data has the same horizontal projection requirements as imagery.

Vertical reference should be expressed in units relative to the geoid (i.e. ETM96).  This approximates an elevation of zero for mean sea level.  If the vertical reference is directly expressed as mean sea level, as with USGS DEM data, this is acceptable.  Preferred height unit is meter.

Terrain directory and file structure
Terrain data has the same directory and file structure requirements as imagery.

Additional information
It is important that the NODATA value is defined, and in coastal areas not set to 0 so as to avoid confusion with the water surface.

 

Transit Route and Schedule Data

Data format
Transit route and schedule information should be formatted according to the Google Transit Feed Specification (GTFS), available at:
http://code.google.com/transit/spec/transit_feed_specification.html
 
Optional fields should be populated when the relevant information is known by the exporting system.
 
Any GTFS feed change should be supported by partners as soon as possible, but no later than 6 months after the change is published at http://code.google.com/transit/spec/transit_feed_specification.html

Data validation
The feed must pass the GTFS feed validator, located at:
http://code.google.com/p/googletransitdatafeed/wiki/FeedValidator.
 
Warnings should be corrected when the relevant information is known by the exporting system.