Google's Complete Map Content Specifications

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.  If you do not submit in an shp or CSV with spatial attributes, you can expect delays in processing. 

Supported data formats are (In order of preference):

  • ESRI Shapefile (most preferred)
  • 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.
  • KML/KMZ with the data represented as SchemaData and SimpleFields (preferred) or ExtendedData.
  • ESRI GeoDatabase is not ideal, please export into individual shapefiles

Google is aware that some users may use AutoCad or MapInfo TAB. 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. 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" 


 

Was this helpful?
How can we improve it?