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.

Aerial Imagery

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.

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.

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.

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.

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).

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.

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).

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.

Parcel data

Address Points

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 Street, Avenue, etc., can be abbreviated)

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

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.