Content requirements: specifications for sharing data

To ensure data is processed quickly, make sure to submit data using the file types, schema, formats, and templates provided in this article.

Important to Note: Submitting data that doesn't follow these guidelines may lead to delays.

Supporting Documentation: To ensure the highest quality and accuracy of our map data, our team may occasionally need to request additional information regarding your submission. In certain cases, we may reach out to specifically ask for supplementary imagery or visual references to help verify and process your changes.

Supported file types for Google Maps Content Partners (GMCP)

.SHP (Shapefile): Submit required file extensions (at least the .shp, .shx, .dbf, and .prj) in a .zip file (zipped file)

.CSV (Comma Separated Value): Submit data separated by commas, with each column surrounded by quotes.  Header row and spatial attributes (latitude and longitude coordinates) are required.

.KML/.KMZ (Keyhole Markup Language): Represent the data as SchemaData and SimpleFields (preferred) or ExtendedData. KML/KMZ files can be created with Google Earth and must have address fields. See the Google Earth YouTube Channel for more information.

.GeoJSON/.JSON: Ensure your file structure follows the guidelines outlined by the OGC [GeoJSON] 

.GML/.XML: Ensure your file structure follows the guidelines outlined by the OGC [GML] or W3C [GML] [XML]

.TIF/.TIFF (GeoTIFF): for Drone or Overhead Imagery only

.RTF (Text Metadata File): for Overhead Imagery only

.SVG (Scalable Vector Graphics): for Transit Logos only

Unsupported feature types

• AutoCAD files, MrSID, MapInfo TAB, or OSM
  • Note: Most software has an option to convert to SHP or CSV so you can export into an accepted format.
• GDBs & GPKGs
• WMS, WFS, or other OGC-compliant web services
• PDFs are only accepted for a small number of features, in limited cases, and never for Political Features. 

 Data Format Concepts 

For specific Data Type field/attribute requirements and options, please review the respective Data Type sections. Here are fields/attributes requirements applicable to all Data Types:

• Table attributes cannot contain special character encodings; We accept UTF-8, UTF-16, and UTF-32.
• For lookup tables, you can use .dbf or .csv files
  • If you use a .csv file, separate the data by commas. Limit commas in other fields
  • Surround each column by quotes to prevent issues with commas in names
  • Make sure there’s a header row
• We don’t have standards on field types, field widths, or domains
• We recommend OGC, FGDC or other internationally recognized standard of formatted Metadata

Geometry

Please provide geometry free of the following:

• Cul-de-sac geometry or driveways
• Dangling lines
• Overlapping lines or nearly overlapping lines
• Overlapping polygons
• Polylines for polygonal features such as political boundaries or parcels
• Undershoots

Additionally, please note:

• Features with the same name or containing the same feature must be represented by a single polygon rather than multiple polygons
• Inner loops/donuts are acceptable for excluding  features like lakes from a park or islands from a water feature
• Polygons should have correct windings and must not self-intersect. Our preferred order is clockwise for both internal and external polygons

Supported types of data 

Common types of data

• Address points (geocodes)
• Points of interest (POIs)
• Political and postal boundaries
• Roads, trails, and pedestrian paths

Other types of data

• Bicycle facilities
• Building footprints, property boundaries, and parcels
• Environmental Insights Explorer (EIE) custom boundaries
• Imagery (drone, overhead, and other images)
• Indoor mapping data format (IMDF)
• Restriction zones
• New housing developments
• Parks and protected areas
• Road closures
• Ski lifts and runs (or trails)
• Speed limits
• Transit
• Trucking restrictions
• Water bodies

If you'd like to share another type of data, please visit Google Maps Help.

Data requirements

Each of the feature-types we expect document the specific data requirements as well as include a fields/attributes table; this table lists the various fields and lists the Requirement Level, Description, and Example or Valid Options to choose from.

Requirement Levels

Required (Mandatory)

• Definition: These are the baseline attributes essential for data ingestion.

• Impact: Failure to provide these fields will result in processing delays or automatic rejection of the dataset, as the data cannot be accurately processed without them.

• Example: Geocode address or Political feature name

Recommended (High Priority)

• Definition: These attributes represent the "Gold Standard" for high-quality data.
• Impact: Providing these fields allows for more complex and complete modeling for the end-users. While not a "blocker" for submission, omitting these may result in lower data quality scores.
• Example: Road Surface or Bike Route Name

Supplemental (Context-Dependent)

• Definition: Attributes that provide specialized depth or functionality beyond the core requirements.
• Impact: These allow for extended features (such as specialized routing or safety alerts) that are impossible to generate with core data alone.
• xample: A street’s address range or Apt, Suite, Floor, or Building Name (within a complex).

Common types of data

Address points (geocodes)

Geocodes example files

Geocode Example

Data requirements

• Preferred file formats: CSV, Shapefile, KML/KMZ, or GeoJSON
  • A shapefile should include .shp, shx, .dbf and .prj to ensure alignment
  • KML/KMZ files must not contain z-coordinates, only latitude and longitude
• Geometry type: point features (no linestring, polygon*, or multipolygon features)

Partner steps to verify before uploading:

• Include full address information required for a valid address or we may be unable to process your request for updates
• (ideally) Expand abbreviations in street names (example: expand BLVD to BOULEVARD)
• Center address points on the property or house structure they represent, not on the road in front of the house
• Standardize the format. All the addresses in an area should be in a consistent format.
  • For example, one house in an area shouldn’t be 1-A and another one 2B. The format should be 1A and 2B or 1-A and 2-B.

Important to Note:

• If the address updates you are providing reflect associated postal code or city boundary changes, please also submit the updated postal or city polygon as a political upload.

• If you only have polygons or parcels to indicate your addresses, please create a point file by using the centerpoint of your polygons.

Address fields/attributes

The following fields are listed as either Required, Preferred, or Optional for address points (geocode) datasets. Failure to include the required information could result in processing delays or rejection.

Field	Requirement Level	Description	Example
ST_NUM	Required (unless not used by your addressing bylaws)	Street / House / Building Number	“29”
HOUSE_ID	Supplemental (but required if used by your addressing bylaws)	House ID / House Name	“RHOA7732” “Rose Cottage”
UNIT_INFO	Supplemental	Apt, Suite, Floor, or Building Name (within a complex)	“PIER 57” “18º Andar” “Floor G”
ST_NAME	Required  (unless not used by your addressing bylaws)	Street Name and Type  Note: Street, Avenue, etc., can be abbreviated but expansion of abbreviations is preferred)	“Spear Street” “Av. Brig. Faria Lima”  “3 St Margaret St”
NEIGHBH	Supplemental (unless required by your addressing bylaws)	Addressing area lower than the main 'locality' (e.g., Bairro, Neighborhood, Borough, Ward, or District)	“Manhattan” “Itaim Bibi” “Westminster”
LOCALITY	Required (unless not used by your addressing bylaws)	Highest level of locality (e.g., city, post town, etc) used in addressing	“New York” “São Paulo” “London”
ADMIN	Required (unless not used by your addressing bylaws)	Highest level of administrative area used in addressing	“NY” “SP”
POSTAL	Required (unless not used by your addressing bylaws)	Postal / Zip Code	“10011” “04538-133”  “SW1P 3JX”
CNTRY	Required	County Name / ISO Code	“US” “Brasil” “United Kingdom”
LAT	Supplemental (but required if you are only providing data in table format such as CSV)	Contains the latitude that corresponds to the location of the geocode	“40.7484”
LON	Supplemental (but required if you are only providing data in table format such as CSV)	Contains the longitude that corresponds to the location of the geocode	“-73.9857”

Points of interest (POIs)

Example POI files

• POI Example (Shapefile)
• POI Example (CSV)
• POI Template (CSV)

Accepted POI Categories:

• Businesses and government institutions with a fixed location and/or storefront
• Buildings such as corporate offices and warehouses (except airport terminals)
• Facilities or kiosks where unmanned transactions^[1] can be completed
• Unmanned public facilities including public bathrooms and drinking water fountains
• Natural features such as national forests and parks
• Landmarks such as monuments^[2], towers, and castles
• Places of public interest such as stadiums, schools, theme parks, and places of worship
• Large area features such as universities, hospitals, and airports

^{[1] An occasion when money is exchanged
[2] A freestanding structure created specifically to commemorate a person or event}

Data requirements

• Preferred fiile formats: shapefile, CSV, or KML/KMZ 
  • Shapefile uploads must include .SHP, .PRJ, .SHX, and .DBF files
• Geometry type: point features (no linestring, polygon, multipolygon features)
• Required Attributes: Name, Type, Lat, Long

Partner steps to verify before uploading:

• Are you a business owner uploading a business location? Claim this POI through Google Business Profile to update it in the future and customize how it’s seen by users.

• Include relevant attributes like wheelchair accessibility, curbside pick-up (see list in the Description and Definitions tab of the template)

Parking Spots and Lots

• We do not currently accept single parking spaces
• If you want us to model your parking feature you need to submit your data as a part of a “Parks” dataset, as well as include:
  • A point to represent the feature on Google Maps
  • A polygon to represent the boundaries of your parking feature
  • The type of parking feature (lot, garage, disabled accessible parking lot, etc)

POI fields/attributes

The following fields are listed as either Required, Preferred, or Optional for POI datasets. Failure to include the required information could result in processing delays or rejection.

Field	Requirement Level	Description	Example
NAME	Required	Contains the business name for a particular listing.	“Empire State Building”
TYPE	REQUIRED	Contains the business category to which the business belongs.	“historical landmark” “fitness centre” “grocery store”
LAT	Recommended	Latitude that corresponds to the location of the building	“40.7484”
LONG	Recommended	Longitude that corresponds to the location of the building	“-73.9857”
FULL_AD	Recommended	Full formatted address, including all available details	“20 W 34th St, Suite 201, New York, NY 10011”
ST_NUM	Recommended	Parsed out address Note: For full details on these row refer to the Address points (geocodes) section	“29”
HOUSE_ID			“RHOA7732” “Rose Cottage”
UNIT_INFO			“PIER 57” “18º Andar” “Floor G”
ST_NAME			“Spear Street” “Av. Brig. Faria Lima”  “3 St Margaret St”
NEIGHBH			“Manhattan” “Itaim Bibi” “Westminster”
LOCALITY			“New York” “São Paulo” “London”
ADMIN			“NY” “SP”
POSTAL			“10011” “04538-133”  “SW1P 3JX”
CNTRY			“US” “Brasil” “United Kingdom”
PHONE	PREFERRED	Contains the main phone number of the business (including country code e.g. +86).	[phone]
WEBSITE	OPTIONAL	Contains the URL for the official website of the business. Please make sure your URLs begin with "http://" and include your domain name.	https://www.esbnyc.com/
MON	OPTIONAL	Please check this link for more information on how to format business hours:  Preferred Business Hours Format	09:00-17:00
TUES	OPTIONAL		09:00-17:00
WED	OPTIONAL		09:00-17:00
THURS	OPTIONAL		09:00-17:00
FRI	OPTIONAL		09:00-17:00
SAT	OPTIONAL		09:00-17:00
SUN	OPTIONAL		09:00-17:00
ATTR	OPTIONAL	Additional POI attribute(s) - see examples below	has_parking_street_paid
AP_LAT	Supplemental	Contains the latitude that corresponds to the location of the feature's access point.	“40.74817“
AP_LON	Supplemental	Contains the longitude that corresponds to the location of the feature's access point.	“-73.98499“
AP_TYP	Supplemental	Specifies the type of access point.	One of: Walking and Driving Walking-only Driving-only
ALT_AP_LAT	Supplemental	Contains the latitude that corresponds to the location of the feature's access point.	“40.74811“
ALT_AP_LON	Supplemental	Contains the longitude that corresponds to the location of the feature's access point.	“-73.98559“
ALT_AP_TYP	Supplemental	Specifies the type of access point.	One of: Walking and Driving Walking-only Driving-only
GMAPS_LINK	Supplemental	The link to the feature in Google Maps.	“https://maps.app.goo.gl/KUVyzUe7bmmuE4wS9“
ID	Supplemental	A unique and stable (alphanumeric string) identifier for the road segment	"AX232514"

Additional POI attributes accepted:

• accepts_reservations: establishment accepts/doesn't accept reservations
• existence: status of an establishment's operations (open, temporary closed or permanently closed)
• has_curbside_pickup: customers can/cannot pick up order without going inside
• has_delivery: establishment offers/doesn't offer delivery to customers
• has_in_store_pickup: establishment allows/doesn't allow online orders to be picked up in store
• has_in_store_shopping: establishment allows/doesn't allow customers to go inside the store
• has_no_contact_delivery: establishment offers/doesn't offer delivery at the customer's door without face-to-face interaction
• has_takeout: establishment allows/doesn't allow patrons to purchase and take away food
• serves_dine_in: establishment offers/doesn't offer indoor dining 

Important to Note:

The preceding list is not exhaustive, and there are additional attributes available.

Access Points

To ensure users are directed to your establishment at a specific location we encourage you to add in the access point (AP) location. The “AP” (see point A below) needs to be the location where all users (by car or on foot) can access your establishment. If there are additional APs, or if there are separate APs for vehicles and/or pedestrians you may also include those in your dataset (as "ALT APs").

To claim a business POI please visit Google Business Profile.

Stadium and Arenas

To model complete stadiums and arenas, in addition to the POI for the stadium/arena itself, you will also need to to include the compounds grounds and/or the building footprint(s) for your feature.

 

 

See Building footprints, property boundaries, and parcels and Parks, protected areas, and parking features for more information on how to format these features.

Political and postal boundaries

Example political files: 

Single feature: Wyoming

Multiple features: Country Multiple Types

Data requirements:

Name requirements:

• Every feature needs to have the name in both the local language and English (unless English is the local language)
• The language code needs to be found in the column headers OR in the Dataset description 
• Standard capitalization is required for all names, preserving original lowercase particles (e.g. Rio de Janeiro).
• Do not include special characters or punctuation marks (e.g. -, /, !, ?, #) unless they are part of the official name (e.g. Arespalditza / Respaldiza, Castro-Urdiales)

Geometry requirements: 

• Polygons must accurately reflect the exact boundaries of the political feature.
• Boundaries should extend out to the water if coastal.
• If a river is the boundary, political features should be snapped to each other.
• The polygons must tile seamlessly, leaving no gaps, overlaps, or sliver segments.

Example - correct data
Example – incorrect data

 

• Polygons should have the highest possible level of geometric detail, using aerial imagery as the primary reference.

Example - correct data
Example – incorrect data

What qualifies as a political feature:

• Postal codes
  • Postal prefix and suffix
  • Post towns
• Administrative areas (State, Province, County)
• Municipal features (City, Town, Village, Subdistricts)
• Neighborhoods
• Colloquial areas and cities (Cultural or historical regions)
• School districts (Educational boundaries governing public school enrollment)
• Reservations (Land collectively held or governed by indigenous people, Tribal Areas)

Important to note:

• All political uploads will be reviewed by Google. We do not guarantee updates.
• Authoritative providers (governments) are the only sources considered through this site for Political features. 
• Polygons are preferred but we also accept point features for Municipal features or smaller.
• Supported file format(s) for Political data:
  • Shapefile
  • KML/KMZ
  • Geojson
  • CSV
• Unsupported file format(s) for Political data:
  • PDF

Political and postal boundaries fields/attributes

The following fields are listed as either Required, Preferred, or Optional for Political and postal boundaries datasets. Failure to include the required information could result in processing delays or rejection.

Field	Requirement Level	Description	Example
NAME_EN	Required	Official Name of the Feature in English	NAME_EN: "Geneva"
NAME_XX Note: insert the ISO code if there is  local language	Required (unless the local language is English)	Official Name of the Feature in your local language	NAME_FR: "Genève"
NAME_YY Note: insert the ISO code if there is another local language	Supplemental	Official Name of the Feature in another local language	NAME_DE: "Genf" NAME_IT: "Geneva"
TYPE	Required	Administrative Level of the Feature	"City"

Roads, trails, and pedestrian paths

Roads, trails, and pedestrian paths examples

Roads: Roads Example

Pedestrian Paths: Pedestrian Paths Example

Data requirements:

• Preferred file formats: Shapefile, CSV, or KML/KMZ 
  • Shapefile uploads must include .shp, .prj, .shx, and .dbf files
• Geometry type: linestring features (no polygon, multipolygon, or point features)
• Include only the attributes you want updated (e.g. geometry corrections, route names, address ranges, private restrictions, surface types, speed limits, turn restrictions, construction, directionality, etc.)
• Use a segment-based representation: a segment is part of a road between two intersections. We can’t accept roads that have multiple intersections hanging off them.

Address Range Example and Notes

 

Partner steps to verify before uploading:

• Specify all address ranges relative to the geometry.  For example, the right side is to the right of the path from the start of the segment to the end of the segment. 

Important to Note:

• We are not prioritizing railways or ferries at this time

• For the full list of bicycle facility information and requirements: see the Bicycle facilities section below
• For the full list of speed limit information and requirements: see the Speed Limits section below
• For the full list of trucking restrictions information and requirements: see the Trucking restrictions section below
• For the full list of restriction zones (or limited-traffic-zones) information and requirements: see the Restriction zone section below 
• For the full list of road closures information and requirements: see the Road closures section below

Roads, trails, and pedestrian paths fields/attributes

The following fields are listed as either Required, Recommended, or Supplemental for road, trail, and pedestrian path datasets. Failure to include the required information could result in processing delays or rejection.

Field	Requirement Level	Description	Example
ST_NAME	Recommended	Street Name and Type (the words Street, Avenue can be abbreviated)	"208th St. SE"
ST_NM_A1	Supplemental	Alternative name 1	“U.S. 101”
ST_NM_A2	Supplemental	Alternative name 2	”RT 101”
RT_Name	Recommended	Route Name	"Washington 524"
NEIGHBH	Supplemental	Neighborhood Name	"Upper West Side"
CITY	Recommended	City Name	"Seattle" "Dublin"
ADMIN	Recommended	Highest level of administrative area	"WA" "New South Wales" "County Cork"
POSTAL	Recommended	Zip code / postal code	"98103" "EH1 1BB"
AR_RT_FR	Supplemental	The starting address range value on the right-hand side, relative to geometry	“2” - (address range example)
AR_RT_TO	Supplemental	The ending address range value on the right-hand side, relative to geometry	“98” - (address range example)
AR_LT_FR	Supplemental	The starting address range value on the left-hand side, relative to geometry	“1” - (address range example)
AR_LT_TO	Supplemental	The ending address range value on the left-hand side, relative to geometry	“99” - (address range example)
SURFACE	Recommended	Road Surface	One of:  PAVED UNPAVED
DIR	Recommended	Identifies the direction of travel and whether there is a one way restriction Note: If this column is left null Google will assign the road as bi-directional	One of:  BI-DIRECTIONAL FORWARD REVERSE
ELEV	Supplemental	If the road is elevated, or a bridge or a tunnel Note: If this column is left null Google will assign the road as ground-level	One of: BRIDGE TUNNEL OVERPASS UNDERPASS
SEPARATE	Supplemental	The road segment is separated by a barrier in the middle	One of: YES / Y NO / N
SPEED_LM	Supplemental	Speed limit in MPH or KPH	"20mph" "32 km/h" Note: For the full list of speed limit information and requirements: see the Speed Limits section below
CAR_RESTR	Required (if a restriction is known)	Whether the segment allows motor vehicle use	One of:  ALLOWED DISALLOWED
BIKE_RESTR	Required (if a restriction is known)	Whether the segment allows bicycle use	One of:  ALLOWED DISALLOWED
PED_FAC	Supplemental	The type of pedestrian facility	One of:  TRAIL WALKING_PATH SIDEWALK DISALLOWED
U_TURN_FRNDLY	Supplemental	Whether the road segment allows u-turns Note: If this column is left null Google will assume the road is not u-turn friendly	One of:  Y / YES  N / NO / null
PRIVATE_RESTR	Required (if a restriction is known)	Whether the segment is a private road Note: If this column is left null Google will assume the road is public	One of:  Y / YES / PRIVATE RESTRICTED ACCESS N / NO / PUBLIC / null
TOLL_RESTR	Supplemental	Whether the segment is a toll road Note: If this column is left null Google will assume the road has no tolls	One of:  Y / YES / HAS_TOLLS N / NO / TOLL_FREE / null
UNDER_CONST	Supplemental	If the road is under construction, what type of construction is it?	One of:  CONSTRUCTION_PLANNED CONSTRUCTION_STARTED CONSTRUCTION_COMPLETE CLOSED_FOR_MAINTENANCE DISTURBED_BY_MAINTENANCE
CON_START_TIME	Required (if under construction)	The start / end time for the construction  Format: YYYY-MM-DD HH:mm [Zone] If unknown simply say: “unknown” or “Planned reopening in Q3”, etc	"2026-09-20" "2026-09-20 23:59" "2026-09-20 23:59 [PST]"
CON_END_TIME
USAGE	Recommended	Special usage of the segment	Example of special usage such as: Roundabout Ramp Turn segment Parking
ROAD_TYPE	Recommended	Is it a road, trail, sidewalk, , ferry route, railway or bicycle road only Note: If this column is left null Google will assume the road is a car traffic road	Example: Trail Rail Ferry
TEMPORARY	Supplemental	In the case where the road is present for only a short period of time, and after that time will no longer be present (i.e. the road is created for a only a festival)	One of:  Y / YES  N / NO / null
TEMP_START	Required (if temporary)	The start / end time for the temporary road operating time  Format: YYYY-MM-DD HH:mm [Zone]	"2026-09-20" "2026-09-20 23:59" "2026-09-20 23:59 [PST]"
TEMP_END
REMOVAL	Supplemental	If the geometry/route name is no longer present, and removal is required, please provide information If this column is left null Google will not guarantee removal of the feature or feature name	Example: Road removed Geometry not existing Remove name Hickory Lane Renamed from Northlights Avenue
ID	Supplemental	A unique and stable (alphanumeric string) identifier for the road segment	"AX232514"

Other types of data

Bicycle facilities

Bicycle facilities example (coming soon)

Data requirements:

• Preferred file formats: Shapefile, KML/KMZ, or GeoJSON
  • A shapefile should include .shp, shx, .dbf and .prj to ensure alignment
  • KML/KMZ files must not contain z-coordinates, only latitude and longitude

• Geometry type: linestring features (no polygon, multipolygon, or point features)

• If possible include only the attributes you want updated (e.g. bike category, bike type, bike safety, route names, directionality, etc.)

Important to Note:

• Please specify in the description if you are updating a previous upload. Subsequent uploads of the same network should only contain geometry and attributes of any updated information.
• The Google Maps bike mode layer has not been launched yet in every city or country; however, biking directions will still be available.
• Google only accepts official biking roads, routes, and trails. We cannot accept biking data that directs users on private roads, private lands, or open areas with no defined biking path.

Bicycle facility definitions

The following are our definitions for the various different types of bicycle route types we support.

Note: If you are unsure of the exact bicycle facility type, please provide the bicycle facility category instead.

Bicycle Facility Category	Bicycle Facility Type	Description
BIKE TRAIL	BIKE TRAIL	A trail or path for bikes only, or mixed bicycle and pedestrian usage.  Prioritized Cycling Zone: The path must have an area dedicated to cycling only, or a mixed usage area where bikes are prioritized equal to or above pedestrian traffic. Separation From Roadway: Cars are not allowed on this trail and the trail deviates significantly from roadways (>10m separation). For bike trails that run directly alongside a road, classify these as one of the following: ROADSIDE SEPARATED BIKE PATH: If the path contains a prioritized cycling zone and is separated from the roadway by an impenetrable barrier. ROADSIDE BIKE FRIENDLY PEDESTRIAN PATH: If the path runs directly alongside a road (within 10m) where bicycles share the path equally with or are prioritized above pedestrians.  ROADSIDE PEDESTRIAN PATH: A path/sidewalk running directly alongside a road (within 10m) where bikes are legally allowed, but pedestrians are prioritized.   Examples: A "twin-track" greenway (one side for bikes, one for walkers), a wide greenway where pedestrians and bikes are equally prioritized. We cannot accept biking trails through fields or greenspaces with no defined path
	ROADSIDE SEPARATED BIKE PATH	A bike-only path running directly alongside a road (within 10m) where bicycles are separated from motor vehicles by an impenetrable barrier. Prioritized Cycling Zone: The path must have an area dedicated to cycling only Roadside: Cars are not allowed on this path and it does not deviate significantly from roadways (<10m separation).  Example: Cycling paths on roads with concrete barriers, cycling paths separated from pedestrian path and roads with sidewalks and curbs
	ROADSIDE BIKE FRIENDLY PEDESTRIAN PATH	A path running directly alongside a road (within 10m) where bicycles share the path equally with or are prioritized above pedestrians. Prioritized Cycling Zone: The path must have an area dedicated to cycling only, or a mixed usage area where bikes are prioritized equal to or above pedestrian traffic. There should either be signage that bikes and pedestrians should share the path, or road markings designating part of the path as reserved for bikes. Roadside: The path itself does not allow car traffic and runs directly alongside a road. The path should be within 10m of the side of the road. Examples: A wide sidewalk with explicit pedestrian / bike signage indicating both traffic types are allowed, a roadside path with a dedicated bike portion and dedicated pedestrian portion
none	ROADSIDE PEDESTRIAN PATH	A path/sidewalk running directly alongside a road (within 10m) where bikes are legally allowed, but pedestrians are prioritized.  Roadside: The path itself does not allow car traffic and runs directly alongside a road. The path should be within 10m of the side of the road. Examples: Sidewalks in areas where cyclists are legally allowed to bike on sidewalks. Note the lack of explicit signage.
BIKE LANE	BIKE LANE	A bike lane is used when a road has explicit markings such as painted lines that reserve part of the road that supports vehicular traffic for bicycle use.  Painted shoulders without explicit bicycle markings are not considered bicycle lanes.  Common examples: Bike lanes that run with traffic, against traffic, or along the center divider. Provides no physical barrier between cyclists and vehicular traffic. If there is a physical barrier between cyclists and traffic, then choose one of the facility types above. Example of a bike lane:
	PROTECTED BIKE LANE	A protected bike lane has a striped bicycle lane separated from driving lanes by a buffer area creating additional horizontal separation and/or permeable barriers like flexposts, spaced bollards, or parking.
SHARED ROAD SIGNED	SHARED ROAD SIGNED	For roads with explicit bicycle signage or road markings indicating that bicycles are allowed to share the road with vehicular traffic.
	NEIGHBORHOOD BIKEWAY	This road segment has been optimized for bicycle traffic and is part of a designated neighborhood bikeway or bike boulevard. These roads must have explicit shared road signage, road markings, or other visible treatment (ex: pavement color) and have features that make it safer to bike on such as speed bumps, prioritized cycling signals, traffic circles, diverters or barriers restricting vehicle access.
SHARED_ROAD (unsigned)		For roads without explicit bicycle signage or road markings indicating that bicycles are allowed to share the road with vehicular traffic. Only set this if there are no other bicycle facilities present and this road segment does not fall into any of the categories above.
DISALLOWED		Roads/trails where bikes are strictly prohibited from operating on these segments The following segment types where the DISALLOWED facility is automatically applied are: Bus-only roads Highways, expressways and freeways  Tunnels Note: Upon request, Google can enable cycling on these restricted segments, provided there is verifiable evidence that cyclists are legally permitted to use them.

 

Combination / Multiple Bicycle Facilities Bicycle infrastructure that satisfies the definitions of multiple bicycle facilities.

In general, if the bicycle infrastructure meets the criteria of multiple bicycle facilities, choose the “highest” applicable bicycle facility type. The priority from highest to lowest is: BIKE TRAIL ROADSIDE SEPARATED BIKE PATH ROADSIDE BIKE FRIENDLY PEDESTRIAN PATH PROTECTED BIKE LANE BIKE LANE NEIGHBORHOOD BIKEWAY SHARED ROAD SIGNED ROADSIDE PEDESTRIAN PATH Note on Hierarchy: The "Highest" to "Lowest" ranking is based on the level of physical separation and protection from motor vehicle traffic. "Highest" facilities offer the greatest degree of cyclist comfort and safety, while "Lowest" facilities involve sharing the roadway with vehicles. This hierarchy ensures that mapping and navigation tools prioritize the safest, most dedicated infrastructure available.

 

Bicycle safety definitions

The following are our definitions for the various safety attributes:

Note: If you are unsure of the associated bicycle safety attribute, leave the field empty or with a Neutral value.

Safety Attribute	Description
RECOMMENDED	This route is officially recommended as a safer option for cyclists.
NEUTRAL or empty	Cyclists are permitted here, whether sharing the road with vehicular traffic or utilizing a dedicated lane or trail, but there is no official guidance recommending or avoiding this particular route.
CAUTION	While cycling is permitted on this route, it is recognized that there are known safety risks that make this road more dangerous for cyclists than other roads of the same facility.
ILLEGAL	Bikes are not allowed on this route.

The bicycle safety attribute plays a role in ensuring a safer routing experience for cyclists. Road segments with a bicycle facility (with clear signage) will be displayed on Google Maps by default and/or could be used in routing. However, if a bicycle safety field is marked with a "caution" or "illegal" attribute, the corresponding road segment will be excluded from display on Google Maps cycling layer and significantly deprioritized in routing.

Bicycle facility fields/attributes

The following fields are listed as either Required, Preferred, or Optional for bicycle facility datasets. Failure to include the required information could result in processing delays or rejection.

Field	Requirement Level	Description	Example
BIKE_FACILITY_CATEGORY	Required	The broader category that the specific facility type belongs to	One of:  BIKE TRAIL BIKE LANE SHARED ROAD SIGNED
BIKE_FACILITY_TYPE	Recommended	Whether the segment allows bikes, and if so, what route type it is	One of:  BIKE TRAIL ROADSIDE SEPARATED BIKE PATH ROADSIDE BIKE FRIENDLY PEDESTRIAN PATH ROADSIDE PEDESTRIAN PATH PROTECTED BIKE LANE BIKE LANE NEIGHBORHOOD BIKEWAY SHARED ROAD SIGNED DISALLOWED
BIKE_SAFETY	Recommended	Are there any known safety concerns with this bicycle route	One of:  RECOMMENDED NEUTRAL CAUTION ILLEGAL
ST_NAME	Recommended	Street Name and Type (the words Street, Avenue can be abbreviated)	"208th St. SE"
RT_Name	Recommended	Route Name	"Washington 524"
BIKE_RT	Recommended	Bike Route Name	"Burke-Gilman Trail"
NEIGHBH	Supplemental	Neighborhood Name	"Upper West Side"
CITY	Recommended	City Name	"Seattle" "Dublin"
ADMIN	Recommended	Highest level of administrative area	"WA" "New South Wales" "County Cork"
POSTAL	Recommended	Zip code / postal code	"98103" "EH1 1BB"
SURFACE	Recommended	Road Surface	One of:  PAVED UNPAVED
SPEED_LM	Supplemental	Speed limit in MPH or KPH	"20mph" "32 km/h"
CAR_RESTR	Required (if a restriction is known)	Whether the segment allows motor vehicle use	One of:  ALLOWED DISALLOWED
PED_RESTR	Required (if a restriction is known)	Whether the segment allows pedestrian use	One of:  ALLOWED DISALLOWED
BIKE_DIR	Recommended	Identifies the direction(s) of bicycle travel possible on the specified facilities	One of:  BI-DIRECTIONAL FORWARD REVERSE
ID	Supplemental	A unique and stable (alphanumeric string) identifier for the road segment	"AX232514"

Building footprints, property boundaries, and parcels

Data requirements:

• Preferred file formats: Shapefile, KML/KMZ, or GeoJSON
  • A shapefile should include .shp, shx, .dbf and .prj to ensure alignment
  • KML/KMZ files must not contain z-coordinates, only latitude and longitude
• Geometry type: polygon or multipolygon features (no linestring or point features)

Important to Note

• Parcel data (a house’s tax parcel, for instance) is still accepted, but it is not actively added to the map. 
• Building footprints and property boundaries (boundary of a hospital, for instance) are accepted but imported as best effort only.
• 3D building footprints are not currently accepted.

Building footprints, property boundaries, and parcels fields/attributes

The following fields are listed as either Required, Recommended, or Supplemental for building footprints, property boundaries, and parcels datasets. Failure to include the required information could result in processing delays or rejection.

Field	Requirement Level	Description	Example
APN	Required (for parcel datasets)	Property’s parcel number	“392700-0150”
NAME	Recommended	Building name	“Empire State Building”
TYPE	Recommended	Boundary data type	One of: Building Footprint Property Boundaries Parcel
CATEG	Recommended	Boundary data category	“Residential” “Business” “Mixed Use”
LAT	Recommended	Latitude that corresponds to the location of the building	“40.7484”
LONG	Recommended	Longitude that corresponds to the location of the building	“-73.9857”
FULL_AD	Recommended	Full formatted address, including all available details	“20 W 34th St, Suite 201, New York, NY 10011”
ST_NUM	Recommended	Parsed out address Note: For full details on these row refer to the Address points (geocodes) section	“29”
HOUSE_ID			“RHOA7732” “Rose Cottage”
UNIT_INFO			“PIER 57” “18º Andar” “Floor G”
ST_NAME			“Spear Street” “Av. Brig. Faria Lima”  “3 St Margaret St”
NEIGHBH			“Manhattan” “Itaim Bibi” “Westminster”
LOCALITY			“New York” “São Paulo” “London”
ADMIN			“NY” “SP”
POSTAL			“10011” “04538-133”  “SW1P 3JX”
CNTRY			“US” “Brasil” “United Kingdom”

Events

Events example files - Coming soon!

Data requirements:

• Preferred file formats: Shapefile (preferred), CSV, or KML/KMZ 
  • Shapefile uploads must include .SHP, .PRJ, .SHX, and .DBF files
• Geometry type: 
  • Roads: linestring features (no polygon, multipolygon, or point features)
  • Property information: polygon or multipolygon features (no linestring or point features)
  • POIs: point features (no linestring, polygon, or multipolygon features
  • Geocodes: point features (no linestring, polygon, multipolygon features)
• Attributes:
  • Road centerlines with street names (see Roads, trails, and pedestrian paths section for more info).
  • Address points should be centered on the structures or parcels they occupy. Street number and street name are required, but include all address components if possible (Address points (Geocodes) section for more info).

Partner steps to verify before uploading:

• You can upload one zip file that includes all road centerlines, addresses, boundaries, and parcels. We can process these as a package.

• For the full list of geocodes (address) information and requirements: see the Address points (geocodes) section above
• For the full list of property information and requirements: see the Building footprints, property boundaries, and parcels section above.
• For the full list of POI information and requirements: see the Points of interest (POIs) section above
• For the full list of roads information and requirements: see the Roads, trails, and pedestrian paths section above
• For the full list of road closures information and requirements: see the Road closures section below

EV charging stations  

Important to Note:

We’re currently only accepting EV charging stations with Real Time Data availability (RTA). If you have both Static and RTA data in feeds and have a live API endpoint (e.g. https://<servername>/ocpi/cpo/2.2/locations) which can be used to fetch your data, please proceed with next steps of uploading EV data through GMCP portal which now supports a self-serve EV feed validator functionality.  

EV charging stations without RTA (real-time availability) may be eligible to be added on Google Maps via Google Business Profile.

Google Maps Content Partners currently only supports EV charging data feeds for Light-Duty Vehicles (LDVs), such as private cars and SUVs (Sport Utility Vehicles). 

Data feeds for heavy-duty transport, including public buses and commercial trucks, are not supported at this time but those EV charging stations may be eligible to be added on Google Maps without RTA via Google Business Profile.

If you have any questions, please feel free to reach out to [e-mail]

An electric vehicle charging station (also known as EVSE - Electric Vehicle Supply Equipment) is a publicly-accessible physical kiosk, pole, pillar or outlet that supplies electric energy to recharge batteries in plug-in electric and hybrid vehicles. An EV Charging Station is typically located on streets, retail shopping centers, restaurants or parking places.

Open Charge Point Interface (OCPI)

OCPI example

OCPI Example

The Open Charge Point Interface (OCPI) enables a scalable, automated EV roaming setup between Charge Point Operators and eMobility Service Providers. It supports authorization, charge point information exchange, charge detail record exchange, remote charge point commands and the exchange of smart-charging related information between parties. If your data is in OCPI format (even if you are not a part of OCPI) we can onboard your data.

Check section 8.3. Object Description in the OCPI document for more details about objects in this format.

Questions to ask yourself before using this format:

• Are you the direct CPO?
• Is your data /business growing and you will need to update it frequently?
  • Would you be able to share your locations API endpoint?
  • Can you provide a sample of your data for data evaluation first?

Imagery

Drone imagery

Data requirements

2D nadir (top-down) aerial imagery:

• File format: GeoTIFF (.tif, .tiff)
• Bit depth type: 8-bit (byte)
• CRS: WGS84 EPSG:4326
• No data value: 0 (black), not 255 (white)
• 3-band RGB. Band 1/2/3 need to have ColorInterp=Red/Green/Blue
• Single image or tiled mosaic
• ​​Approximate resolution: 3-7cm/px

Partner steps to verify before uploading:

• Run gdalinfo on the .tif file to confirm that the output (red, bolded sections) is similar to the following example:  TIF example
• Additional metadata should be provided as outlined in the following example:  Imagery metadata example

Important to Note:

If your drone imagery file is 2GB or larger, please upload as an Overhead type imagery file.

Drone imagery fields/attributes

The following fields are listed as either Required, Recommended, or Supplemental for drone imagery datasets. Failure to include the required information could result in processing delays or rejection.

Field	Requirement Level	Description	Example
CRS	Required	WGS 84 or another local coordinate reference system for placing the data in the right geolocation.	“WGS84”
LOCAT	Required	Include the lat/long location for the center of your Aerial Imagery asset	“37.421863, -122.079659”
CAPT_DT	Required	The earliest date the imagery was captured in Month/Day/Year format. If the imagery was captured between 6/23/2026 and 7/02/2026 then use 6/23/2026.	“6/23/2026”
RES_GSD	Recommended	The resolution or ground sample distance of your data in px/cm.	“10 cm/px”
AREA_SZ	Recommended	Area in sqkm the data covers	“10 sqkm”
NAME	Recommended	Basic Description of the Data	“2D orthophoto of downtown Mountain View California”
CITY	Recommended	City Name	“Mountain View”
ADMIN	Recommended	Highest level of administrative area	"CA"  "New South Wales"  "County Cork"
CTRY	Recommended	Country Name pdf/ima	“USA”

Please Note: Failure to provide accurate metadata or correctly formatted image files could result in publication delays.

Overhead imagery

Data requirements

2D nadir (top-down) aerial imagery

• File format: GeoTIFF (.tif, .tiff) and text metadata file (.rtf)
• Bit depth type: 8-bit (byte)
• CRS: WGS84 EPSG:4326
• No data value: 0 (black), not 255 (white)
• 3-band RGB. Band 1/2/3 need to have ColorInterp=Red/Green/Blue
• Single image or tiled mosaic
• ​​Approximate resolution 7-15cm/px

 Partner steps to verify before uploading:

• Run gdalinfo on the .tif file to confirm that the output (red, bolded sections) is similar to the following example:  TIF example
• Additional metadata should be provided as outlined in the following example:  Imagery metadata example

Important to Note:

If you share more than (5) Overhead images, ensure they are in a zip folder

Overhead imagery fields/attributes

The following fields are listed as either Required, Recommended, or Supplemental for overhead imagery datasets. Failure to include the required information could result in processing delays or rejection.

Field	Requirement Level	Description	Example
CRS	Required	WGS 84 or another local coordinate reference system for placing the data in the right geolocation.	“WGS84”
LOCAT	Required	Include the lat/long location for the center of your Aerial Imagery asset	“37.421863, -122.079659”
CAPT_DT	Required	The earliest date the imagery was captured in Month/Day/Year format. If the imagery was captured between 6/23/2026 and 7/02/2026 then use 6/23/2026.	“6/23/2026”
RES_GSD	Recommended	The resolution or ground sample distance of your data in px/cm.	“10 cm/px”
AREA_SZ	Recommended	Area in sqkm the data covers	“10 sqkm”
CAPT_METH	Recommended	How was the imagery captured? Satellite, Airplane, etc.	“Satellite” “Airplane”
NAME	PREFERRED	Basic Description of the Data	“2D orthophoto of downtown Mountain View California”
CITY	Recommended	City Name	“Mountain View”
ADMIN	Recommended	Highest level of administrative area	"CA"  "New South Wales"  "County Cork"
CTRY	Recommended	Country Name	USA

Please Note: Failure to provide accurate metadata or correctly formatted image files could result in publication delays.

Images

Data requirements

File Format: GeoTIFF (.tif, .tiff), PDF, PNG, JPEG

Partner steps to verify before uploading:

• Ensure there is an adequate description that accompanies your image upload
• Ensure that all the required attributes of the data that is included within your image are included - please see the associated content requirements section
• Ensure that the associated content requirements section of the data type you are submitting an image for does not prohibit a PDF/image submission (ex: Political datasets are not allowed to be submitted via a PDF/image)

Important to Note:

If you share more than (5) Overhead images, ensure they are in a zip folder

Indoor mapping data format (IMDF)

Data requirements

File Format: (16) GeoJSON files (as noted) below zipped/compressed together as an Archive

• Venue
• Building
• Footprint
• Level
• Unit
• Fixture
• Section
• Geofence
• Kiosk
• Detail
• Opening
• Amenity
• Anchor
• Occupant
• Address
• Relationship
• Manifest (JSON - optional) 

Partner steps to verify before uploading:

Ensure all of your (16) files follow the Open Geospatial Consortium (OGC) Community Standard(s) as per their documentation.

Please note the metadata details below provide a only simplified version of the OGC standard

IMDF file attributes

The following table provides a definition, the feature structure, and a link to the capturing rules for each of the required (16) files. Failure to include the required information could result in processing delays or rejection.

File	Definition	Feature structure	Capturing rules
Address	An Address represents a postal address, of official or proprietary designation, associated with an element of a venue.	Address objects are unlocated Feature objects Address objects MUST have an "id" member with a FEATURE-ID value Address objects MUST have a "feature_type" member with the value "address" Address objects MUST have a "geometry" member with a null value	link
Amenity	An Amenity models the physical presence and approximate point location of a pedestrian amenity that serves a utilitarian purpose or other convenience that serves to enhance the pedestrian “experience.”	Amenity objects are Feature objects Amenity objects MUST have an "id" member with a FEATURE-ID value Amenity objects MUST have a "feature_type" member with the value "amenity" Amenity objects MUST have a "geometry" member with a POINT value	link
Anchor	An Anchor represents the curated Point used as the preferred display location of a specific Address OR non-addressable device, service, equipment or physical environment. In both cases, the record serves as the anchoring point from which another feature (i.e. Occupant) can derive, reference or inherit the Anchor's attribution.	Anchor objects are Feature objects Anchor objects MUST have an "id" member with a FEATURE-ID value Anchor objects MUST have a "feature_type" member with the value "anchor" Anchor objects MUST have a "geometry" member with a POINT value	link
Building	A Building describes a physical building structure associated with a Venue.   Building records are captured as unlocated features, deferring representation of their physical extents to associated Footprint features	Building objects are unlocated Feature objects Building objects MUST have an "id" member with a FEATURE-ID value Building objects MUST have a "feature_type" member with the value "building" Building objects MUST have a "geometry" member with a null value	link
Detail	A Detail models the presence, location and extent of a physical object. Recognition of the feature in a map is heavily dependent upon the spatial context and cognitive recognition.	Detail objects are Feature objects Detail objects MUST have an "id" member with a FEATURE-ID value Detail objects MUST have a "feature_type" member with the value "detail" Detail objects MUST have a "geometry" member with a LINEAL value	link
Fixture	A Fixture models the presence and approximate physical extent of a moveable or semi-permanent physical asset possessing any of the following characteristics:   An asset that, if removed, does not impact the structural integrity of the physical building or outdoor level An asset that has utility within the defined space and serves to support a service/business function An asset that serves a decorative function, may have limited or no utility from a service/business standpoint, but enhances the pedestrian "experience"	Fixture objects are Feature objects Fixture objects MUST have an "id" member with a FEATURE-ID value Fixture objects MUST have a "feature_type" member with the value "fixture" Fixture objects MUST have a "geometry" member with a POLYGONAL value	link
Footprint	A Footprint models the approximate physical extent of one or more referenced Buildings.	Footprint objects are Feature objects. Footprint objects MUST have an "id" member with a FEATURE-ID value Footprint objects MUST have a "feature_type" member with the value "footprint" Footprint objects MUST have a "geometry" member with a POLYGONAL value	link
Geofence	A Geofence models the extent of a geofence.	Geofence objects are Feature objects Geofence objects MUST have an "id" member with a FEATURE-ID value Geofence objects MUST have a "feature_type" member with the value "geofence" Geofence objects MUST have a "geometry" member with a POLYGONAL value	link
Kiosk	A Kiosk models the presence and physical extent of furniture that facilitates the distribution of products and/or services.   A manned kiosk Including but not limited to the distribution of consumables such as newspapers, magazines, cigarettes, confections, health & beauty products, electronics, food & beverage Vending kiosk Including but not limited to the vending of electronics, cosmetics, food and beverage A manned or automated information kiosk   A Kiosk models the extent of the physical object, only. It is not used to describe the business or service that is operating out of the Kiosk. An Occupant (via Anchor) or Amenity would model the operation.	Kiosk objects are Feature objects Kiosk objects MUST have an "id" member with a FEATURE-ID value Kiosk objects MUST have a "feature_type" member with the value "kiosk" Kiosk objects MUST have a "geometry" member with a POLYGONAL value	link
Level	A Level models the presence, location and approximate physical extent of a floor area in:   A physical building where the Level's extent is expected to be analogous to the surface (facade) of the physical building at the height where the floor is positioned An outdoor environment that is functionally inseparable from the physical Venue   Note 1: The modeling of multiple integrated buildings, with both integrated and non-integrated floor arrangements is a non-trivial undertaking. IMDF does NOT offer definitive guidance that is capable of responding to all architectural scenarios. IMDF, instead, offers guidance that is generally applicable.   Note 2: The objective of IMDF is to provide guidance with respect to the modeling of ground truth conditions. A Level is NOT expected to possess a form that makes it immediately amenable for rendering in a map application. Additionally, IMDF is not expressly concerned with cartographic requirements or aesthetic rules, though rules do, to the extent possible, take these needs into consideration.	Level objects are Feature objects Level objects MUST have an "id" member with a FEATURE-ID value Level objects MUST have a "feature_type" member with the value "level" Level objects MUST have a "geometry" member with a POLYGONAL value	link
Occupant	An Occupant models the presence and location (via Anchor) of a business entity that trades goods and/or services.	Occupant objects are unlocated Features Occupant objects MUST have an "id" member with a FEATURE-ID value Occupant objects MUST have a "feature_type" member with the value "occupant" Occupant objects MUST have a "geometry" member with a a null value	link
Opening	With few exceptions, an Opening models the presence, location and physical extent (width) of an entrance. An entrance may be a physical presence such as a door that swings, slides or rotates, a gate/turnstile, or threshold.	Opening objects are Feature objects Opening objects MUST have an "id" member with a FEATURE-ID value Opening objects MUST have a "feature_type" member with the value "opening" Opening objects MUST have a "geometry" member with a LINE-STRING value	link
Relationship	A Relationship models the physical or conceptual association between two map elements as an edge, with the optional inclusion of an intermediary element that plays a contributing contextual role in the relationship. The semantic intent of a Relationship is determined by the nature of the referenced elements and their respective roles in the map itself.	Relationship objects are Feature objects and MAY be unallocated Relationship objects MUST have an "id" member with a FEATURE-ID value Relationship objects MUST have a "feature_type" member with the value "relationship" Relationship objects MUST have a "geometry" member with a null or GEOMETRY value	link
Section	A Section models the presence and approximate extent of a theme. The boundary of a theme may be a threshold or an indeterminate border.	Section objects are Feature objects Section objects MUST have an "id" member with a FEATURE-ID value Section objects MUST have a "feature_type" member with the value "section" Section objects MUST have a "geometry" member with a POLYGONAL value	link
Unit	A Unit models the presence, location and approximate extent of a space. Extent may be characterized by: A barrier, such as a wall A physical boundary, not necessarily delimitted by a barrier, but beyond which traversal is not expected, such as the edge of a train platform A legal instrument, such as the description of a gross leasable area	Unit objects are Feature objects Unit objects MUST have an "id" member with a FEATURE-ID value Unit objects MUST have a "feature_type" member with the value "unit" Unit objects MUST have a "geometry" member with a POLYGONAL value	link
Venue	A Venue models the presence, location and approximate extent of a place. A Venue is an abstract modeling concept whose only tangible elements are the associated descriptive properties, and the other feature types that lay within it which model physical items such as buildings, floors and rooms. Ideally, the polygonal geometry of a Venue feature represents a formal property boundary associated with the Venue.	Venue objects are Feature objects Venue objects MUST have an "id" member with a FEATURE-ID value Venue objects MUST have a "feature_type" member with the value "venue" Venue objects MUST have a "geometry" member with a POLYGONAL value	link

Restriction zones

Low-emission zones (LEZs) / Limited-traffic zones (LTZs)

Data requirements

LEZs / LTZs require the following, at a minimum:

• Polygon or multipolygon features (no point or linestring features)
• Name, restriction info, and URL

LEZ / LTZ fields/attributes

The following fields are listed as either Required, Recommended, or Supplemental for LEZ / LTZ datasets. Failure to include the required information could result in processing delays or rejection.

Field	Requirement Level	Description	Example
NAME	Required	Name of the LEZ in the local language   Note: If your feature has names in multiple local languages please indicate which is the preferred in each language.	Single Local Language: “Gent Umweltzone” Multiple Local Languages: NAME_DE: “Gent Umweltzone” NAME_NL: “Gent Lage-emissiezone” NAME_FR: “Gand Zone à faibles émissions”
NAME_EN	Recommended	Name of the LEZ in English	“Ghent Low Emission Zone”
URL	Required	URL of the LEZ in the local language   Note: If your feature has URLs in multiple local languages please indicate which is the preferred in each language.	Single URL: https://stad.gent/de/umweltzone-gent  Multiple URLs: URL_DE: https://stad.gent/de/umweltzone-gent  URL_NL: https://stad.gent/nl/mobiliteit-openbare-werken/lage-emissiezone  URL_FR: https://stad.gent/fr/zone-de-basses-emissions-gand
URL_EN	Recommended	English URL of the LEZ	https://stad.gent/en/mobility-ghent/low-emission-zone-ghent
DESCR	Recommended	Description of the LEZ in the local language   Note: If your feature has descriptions in multiple local languages please indicate which is the preferred in each language.	Single Description: Nur Fahrzeuge, die den Zulassungsbedingungen entsprechen, dürfen in die Umweltzone einfahren. Registrieren Sie ihr Fahrzeug vor Ihrer Ankunft in Gent, um ein Bußgeld zu vermeiden. Multiple Descriptions: DESCR_DE: “Nur Fahrzeuge, die den Zulassungsbedingungen entsprechen, dürfen in die Umweltzone einfahren. Registrieren Sie ihr Fahrzeug vor Ihrer Ankunft in Gent, um ein Bußgeld zu vermeiden.” DESCR_NL: “Om de zone in te rijden moet je auto aan de minimumvoorwaarde voldoen. Benzine en gas: Euro 2 en Diesel: Euro 5. Check je auto voor je de zone inrijdt.” DESCR_FR: “Seuls les véhicules respectant les conditions d’accès ont accès à cette zone. Enregistrez votre véhicule avant de venir à Gand pour éviter une amende.”
DESCR_EN	Recommended	English descriptions of the LEZ	“Only vehicles that meet entry requirements will be allowed into this zone. Register your vehicle before coming to Ghent to avoid a fine.”
RESTR	Required	The restriction particulars of the LEZ	“The emission standards are as follows: - Euro 4 for petrol vehicles - Euro 6 for diesel vehicles - Euro 4 for heavy duty petrol vehicles such as buses/coaches and HGVs - Euro 6 for heavy duty diesel vehicles such as buses/coaches and HGVs”
ID	Supplemental	A unique and stable (alphanumeric string) identifier for the road segment	"AX232514"

New housing developments

New housing development example files

New Housing Development Example

Data requirements:

• Preferred file formats: Shapefile (preferred), CSV, or KML/KMZ 
  • Shapefile uploads must include .SHP, .PRJ, .SHX, and .DBF files
• Geometry type: 
  • Roads: linestring features (no polygon, multipolygon, or point features)
  • Sales Office: Go through the Google Business Profile to create your sales office(s)
  • Community Boundaries: polygon or multipolygon (no points or linestring features)
  • Parcels: polygon or multipolygon (no points or linestring features)
  • Geocodes: point features (no linestring, polygon, multipolygon features)
• Attributes:
  • Road centerlines with street names (see Roads, trails, and pedestrian paths section for more info).
  • Address points should be centered on the structures or parcels they occupy. Street number and street name are required, but include all address components if possible (Address points (Geocodes) section for more info).

Partner steps to verify before uploading:

• You can upload one zip file that includes all road centerlines, addresses, boundaries, and parcels. We can process these as a package.
• To learn how to prepare the data into a compatible format, review the Digitizing Plat Maps article.
• Community sales office names must be included in the POI shapefiles attribute table
• Public opening date should be included. This is the month and year that public routing through the housing development will be made available

• For the full list of geocodes (address) information and requirements: see the Address points (geocodes) section above
• For the full list of POI information and requirements: see the Points of interest (POIs) section above
• For the full list of roads information and requirements: see the Roads, trails, and pedestrian paths section above
• For the full list of road closures information and requirements: see the Road closures section below 

Important to Note:

Parcels are accepted but not actively added to the map

Parks, protected areas, and parking features

Parks, protected areas, and parking features example files

Park Example

Data requirements:

• Preferred file formats: Shapefile, KML/KMZ, or GeoJSON
  • A shapefile should include .shp, shx, .dbf and .prj to ensure alignment
  • KML/KMZ files must not contain z-coordinates, only latitude and longitude
• Geometry type: polygon, or multipolygon (no point features)

Accepted park categories:

• Standard Parks (which include State, National, Provisions, etc)
• Forests (which include State, National)
• Recreation and Sport Fields/Areas
• Nature Preserves and Reserves 
• Green spaces that are:
  • Safely accessible
  • Open to the public
  • A destination for users

Park categories not accepted:

• Road medians that are solely covered in foliage
• Small plots of green urban areas 
• Green spaces that are:
  • Unsafe to access
  • Closed to the public

If no name (or no usable name) is provided: we will process your feature as either:

• A “green space” and the result will be a green polygon that will render on the map.
• A “generic parking lot” and the result will be a grey-hashed polygon that will render on the map.
• A “generic parking garage” and the result will be a grey polygon that will render on the map.

Partner steps to verify before uploading:

• If you have a park that is in two sections, include the park in one polygon
• We recommend a scale of 1:25,000 or larger for the geometry 

A field for the classification of the park with an MTFCC column (Type). Use the latest MTFCC park code provided from the US Census MAF/TIGER Feature Class Code Definitions. Include a data dictionary describing the types.

Parking Spots and Lots

• We do not currently accept single parking spaces
• If you want us to model your parking feature you need to submit your data as a part of a “Parks” dataset, as well as include:
  • A point to represent the feature on Google Maps
  • A polygon to represent the boundaries of your parking feature
  • The type of parking feature (lot, garage, disabled accessible parking lot, etc)

Park fields/attributes

The following fields are listed as either Required, Recommended, or Supplemental for parks datasets. Failure to include the required information could result in processing delays or rejection.

Field	Requirement Level	Description	Example
TYPE	Required	Type of park/protected area	“Park” “State Forest”
NAME	Recommended	Name of the park/protected area you want to appear on the map	“Wallace Falls State Park” “Mt. Baker-Snoqualmie National Forest”
ID	Supplemental	A unique and stable (alphanumeric string) identifier for the road segment	"AX232514"

Parking fields/attributes

The following fields are listed as either Required, Preferred, or Optional for parking feature datasets.  

Field	Requirement Level	Description	Example
TYPE	Required	Type of parking feature	“Lot" "Garage”
NAME	Recommended	Name of the parking feature you want to appear on the map	“Seattle Center 5th Ave. N. Garage”
ATTR	Recommended	Extra attributes associated with the feature	“has_parking_street_paid“
ID	Supplemental	A unique and stable (alphanumeric string) identifier for the road segment	"AX232514"

Parking attributes accepted:

Extra attributes associated with the feature
has_electric_vehicle_charging️	has_parking_lot️	has_wheelchair_accessible_elevator️
has_parking_garage️	has_parking_lot_free️	has_wheelchair_accessible_entrance️
has_parking_garage_free️	has_parking_lot_paid️	has_wheelchair_accessible_parking️
has_parking_garage_paid️	has_parking_reservable️	is_wheelchair_accessible️

Road closures

Contribution channels:

• Share a feed: you can connect your road closure management system to both Waze for Cities and Google Maps by sharing a feed through the Waze Partner Hub. Sharing a feed is best for high volume, recurring, or highly automated updates, which will be reflected on both Google Maps and Waze in a timely manner. Learn more about sharing a feed in this video.
• Upload a specific closure: if you want to make or correct specific closures on Google Maps (or if your Waze for Cities feed isn't impacting Google Maps as expected), you can upload specific road closures to Google Maps Content Partners (GMCP).

Provide a data feed for road closure updates

Share your data feed to the Waze Partner Hub:

• Follow the instructions at  Keep local drivers informed with the Partner feed from the Waze Partners Help Center.
• Initial processing is usually done within several days, but full implementation may be longer depending on content and schema compatibility, specific feature types, and geography.
• Updates and new reports are typically reflected on Waze within minutes.
• Closures provided to Waze through data feeds are propagated to Google Maps.
  • New incidents should be visible on Google Maps approximately 15-25 minutes after being added to a feed.
  • Updates to existing feed closures are not instantaneous and may currently take up to 1-2 hours to reflect on the map. For example, if a partner edits their feed at 7:29 PM to change the re-open time for a road from 9 PM to 7:30 PM, it will still take  an hour or more for the road to re-open on Google Maps.

Important to Note: 

• If your feed is published in your Open Data Portal, we may be able to also support it.
• Most closures can be processed successfully, but some may not be. If a particular closure doesn't appear on Google Maps, or if you want to be certain in advance that it will, follow the procedure below to submit specific closures.

Upload a specific road closure

You can submit specific road closures to Google Maps as uploads to GMCP.

GeoJSON, JSON, or XML files

Data requirements:

• Each road closure or restriction is required to have:

  • A type field detailing the specific type of restriction/closure
  • A polyline field that correlates to the road segment affected by the restriction/closure
  • A start_time and end_time field that correlates to the road segment affected by the restriction/closure
  • A direction field detailing the direction of the restriction/closure

Partner steps to verify before uploading:

• Ensure that your data is structured properly as per the file format you have submitted. See the examples above for a reference on how you can structure your data files.
• For GeoJSON/JSON files: OGC [GeoJSON] guidelines 
• For GML/XML files:  OGC [GML] or W3C [GML] [XML] guidelines

Road closure/restriction fields/attributes:

The following fields are listed as either Required, Preferred, or Optional for road closure datasets. Failure to include the required information could result in processing delays or rejection.

Field	Required	Description	Example
TYPE	Required	Each incident must include a type field clearly identifying the incident as a full closure, lane closure, or another incident type. Incident types supported: INCIDENT_ROAD_CLOSED: The road/bridge/ramp is completely closed or blocked and can't be traveled. INCIDENT_LANE_CLOSURE: The road is not fully closed, some lanes are still open. INCIDENT_CONSTRUCTION: Road construction, maintenance, paving, other types of road work.	INCIDENT_ROAD_CLOSED
POLYLINE	Required	We require polyline geometry following the direction of travel affected by the incident with accuracy within 10m of the centerline of the affected road, with each point using WGS84 coordinates. The draw order of a polyline corresponds to the direction of travel.	“42.1601432984533 -119.3525208937842 42.1781676611244 -119.35679623266”
DIRECTION	Required	The direction field is required to indicate whether the incident applies to one or both directions on the road (e.g., “one way”, “both directions”).	BOTH_DIRECTIONS
START_TIME	Required	Each incident must include clear start time and end time fields that indicate the incident schedule, using ISO8601 format with granularity of minutes and include time zone (e.g., 2016-04-07T00:00:00+01:00).	2017-06-05T00:01:00-04:00
END_TIME	Required	See above.	2017-11-22T15:30:00-05:00
ID	Optional	A unique identifier for the incident, stable over the incident duration.	3f4r45ff233
BEARING	Optional	An optional bearing field (e.g., 90) may be included to describe the precise direction of travel impacted by the incident.	90
ROAD_NAME	Optional	The name of the road where the incident has occurred.	N Liberty St
DESCRIPTION	Optional	A description of the road incident.	Complete road closure due to road works
SOURCE	Optional	The authority or reporter of the incident, for feeds containing data originating from multiple authorities or reporters.	Municipal DOT XYZ

Other file types

Data requirements

• Each road closure or restriction is required to have:
  • The starting and ending location (lat/long, cross road, intersection)
  • The starting and ending time
  • The starting and ending day
  • The type of vehicles that are impacted
  • The type of restriction applied

Partner steps to verify before uploading:

• If uploading a shapefile or KML/KMZ, it is highly encouraged to include required and optional fields/attributes of the roads, trails, and pedestrian paths fields/attributes list, as well as the fields/attributes listed here. 
• Include as much detail as possible in the provided format. Ensure that your attribute table has the equivalent fields to the template

Road closure/restriction fields/attributes:

The following fields are listed as either Required, Preferred, or Optional for road closure datasets. Failure to include the required information could result in processing delays or rejection.

 

Field	Required	Description	Example
FROM_LAT	Required	The latitude of the starting point of the segment that the turn restriction applies to (relative to its geometry).	47.8618
FROM_LON	Required	The longitude of the starting point of the segment that the turn restriction applies to (relative to its geometry).	-121.8151
TO_LAT	Required	The latitude of the ending point of the segment that the turn restriction applies to (relative to its geometry).	47.8501
TO_LON	Required	The longitude of the ending point of the segment that the turn restriction applies to (relative to its geometry).	-121.8146
FROM_END	Preferred	The start of the segment the turn restriction applies to relative to its geometry.	Example_1: From Alder St. & Main St. Example_2: From US 2 MP-10
TO_END	Preferred	The end of the segment the turn restriction applies to relative to its geometry	Example_1: To Alder St. & 8th St. Example_2: To US 2 MP-20
MODE	Required	The mode of transportation the limitation applies to.	One of: ALL PEDESTRIAN CAR TRUCK BUS NON-HOV
START_TM	Required	The start time of the turn restriction, in 24-hour notation. Leave this and END_TM blank for permanent restriction	06:00
END_TM	Required	The end time of the turn restriction, in 24-hour notation. Leave this and START_TM blank for permanent restriction	10:00
STRT_DATE	Required	The start date of the turn restriction.	01/02/2023
END_DATE	Required	The end date of the turn restriction. Leave this blank for permanent restriction	03/03/2023
TURN_RESTR	Required  - if there is a turn restriction	Type of turn restriction	One of:  NO LEFT TURN NO RIGHT TURN NO U-TURN

Ski lifts and runs (or trails)

Ski lifts and runs example - Coming soon

Data requirements:

• File Format: Shapefile, Keyhole Markup File (.kml/ .kmz), GeoJSON, GeoPDF
  • KML/KMZ files must not contain z-coordinates, only latitude and longitude
  • A shapefile should include .shp, shx, .dbf and .prj to ensure alignment
  • If the file contains multiple features, each feature must be named distinctly (more details on this below)
• Geometry type: linestring features (no polygon, multipolygon, or point features)

PDF or JPG Maps: We can also accept maps in these formats as long as:

• There is a clear legend
• The map contains all the required attributes detailed below
• The map comes from the official resort
• The map contains the most recent version of the resort 

Critical Note: For new ski resorts you must send both ski lifts and ski trails - we cannot process one without the other.

• If the ski resort's lift and trails already exist you are permitted to send only trails or only lifts

Ski lifts

Accepted ski lift types: The following are the ski lift types that we currently accept
 

 

We are not accepting other lift types (such as tubelines) at this time

Ski lifts fields/attributes

The following fields are listed as either Required, Recommended, or Supplemental for ski lift datasets. Failure to include the required information could result in processing delays or rejection.

Field	Requirement Level	Description	Example
LIFT_CATEGORY	Recommended	The parent category of the ski lift -the defaulted category is TYPE_AERIAL	One of: TYPE_AERIAL TYPE_SURFACE
LIFT_TYPE	Recommended	The specific type of the lift - the defaulted type is TYPE_CHAIR	One of: TYPE_AERIAL: TYPE_GONDOLA TYPE_CHAIR TYPE_TRAM TYPE_SURFACE: TYPE_T_BAR TYPE_J_BAR TYPE_ROPE_TOW TYPE_CARPET TYPE_POMA TYPE_FUNICULAR
LIFT_NAME	Required	The full lift name which will added to the ski lift polyline	"Skyline Express"
LIFT_SUBTYPE	Supplemental	The subtype of the lift	”Fixed-grip”
LIFT_CAP	Supplemental	The capacity of the lift / chair	“2 person”
RESORT_NAME	Supplemental	The full legal name of the resort that can be searched in Google Map	"Stevens Pass"
RESORT_URL	Supplemental	The URL of the ski resort’s website	https://www.stevenspass.com/
ID	Supplemental	A unique and stable (alphanumeric string) identifier for the road segment	"AX232514"

Ski runs (or trail)

Ski run difficulties: Set the ski run difficulty based on permitted Ski Resort Site information only. Furthermore, Google uses the following difficulty colour schemas based on the region of the ski resort:

Americas + NZ, AU:

• TYPE_EASIEST - Double Green
• TYPE_EASY - Green
• TYPE_INTERMEDIATE - Blue
• TYPE_ADVANCED_INTERMEDIATE - Double Blue / Blue Black
• TYPE_DIFFICULT - Black
• TYPE_ADVANCED_DIFFICULT - Double Black

Europe, Asia, Russia:

• TYPE_EASIEST - Green
• TYPE_EASY - Blue
• TYPE_INTERMEDIATE - Red
• TYPE_DIFFICULT - Black
• TYPE_ADVANCED_DIFFICULT - Yellow

Ski runs fields/attributes

The following fields are listed as either Required, Recommended, or Supplemental for ski run datasets. Failure to include the required information could result in processing delays or rejection.

Field	Requirement Level	Description	Example
RUN_TYPE	Supplemental	The specific type of the run - the defaulted to TYPE_TRAIL	One of: TYPE_TRAIL TYPE_GLADE TYPE_RACE_COURSE TYPE_BOWL
RUN_NAME	Required	The full name of the run that will be added to the map	”Timberline" Notes: If you have upper and lower of the trail make sure to add them to the name too - ”Upper Exhibition” and “Lower Exhibition” Same as numbers: “Run 1”, “Run 2”
RUN_DIFFICULTY (SAFETY)	Required	The difficulty of the run	One of: Americas + NZ, AU: TYPE_EASIEST - Double Green  TYPE_EASY - Green TYPE_INTERMEDIATE - Blue TYPE_ADVANCED_INTERMEDIATE - Double Blue / Blue Black TYPE_DIFFICULT - Black TYPE_ADVANCED_DIFFICULT - Double Black Europe, Asia, Russia: TYPE_EASIEST - Green TYPE_EASY - Blue TYPE_INTERMEDIATE - Red TYPE_DIFFICULT - Black TYPE_ADVANCED_DIFFICULT - Yellow
RESORT_NAME	Supplemental	The full legal name of the resort that can be searched in Google Map	"Stevens Pass"
RESORT_URL	Supplemental	The URL of the ski resort’s website	https://www.stevenspass.com/
ID	Supplemental	A unique and stable (alphanumeric string) identifier for the road segment	"AX232514"

Speed limits

Speed limits example - Coming soon 

Data requirements:

• Preferred file formats: Shapefile, KML/KMZ, or GeoJSON
  • A shapefile should include .shp, shx, .dbf and .prj to ensure alignment
  • KML/KMZ files must not contain z-coordinates, only latitude and longitude
• Geometry type: linestring features (no polygon, multipolygon, or point features)
• If possible, include only the attributes you want updated (e.g. street names, surface, directionality, etc.)

Speed limits fields/attributes

The following fields are listed as either Required, Recommended, or Supplemental for speed limit datasets. Failure to include the required information could result in processing delays or rejection.

Field	Requirement Level	Description	Example
SPEED_LM	Required (unless you provide both the forward and reverse speed limits)	(Bi-directional) Speed limit in MPH or KPH	"20mph" "32 km/h"
FOWARD_SL	Required (unless you provided the bi-directional speed limit)	(Forward) Speed limit in MPH or KPH
REVERSE_SL	Required (unless you provided the bi-directional speed limit)	(Reverse) Speed limit in MPH or KPH
CAR_SL	Supplemental	Car-based conditional speed limit in MPH or KPH
TRUCK_SL	Supplemental	Truck-based conditional speed limit in MPH or KPH
MOTORCYCLE_SL	Supplemental	Motorcycle-based conditional speed limit in MPH or KPH
BUS_SL	Supplemental	Bus-based conditional speed limit in MPH or KPH
SUMMER_SL	Supplemental	Summer-based conditional speed limit in MPH or KPH
WINTER_SL	Supplemental	Winter-based conditional speed limit in MPH or KPH
TIME_SL	Supplemental	Time-based conditional speed limit in MPH or KPH
START_TIME	Supplemental (unless you provided a TIME_SL in which case it is required)	Start of the time-based conditional speed limit	“09:00“
END_TIME	Supplemental (unless you provided a TIME_SL in which case it is required)	End of the time-based conditional speed limit	“17:00“
ST_NAME	Supplemental	Street Name and Type (the words Street, Avenue can be abbreviated)	"208th St. SE"
ID	Supplemental	A unique and stable (alphanumeric string) identifier for the road segment	"AX232514"

Transit

Important to Note:

Bus stops or bus lines/routes need to be routed via the GTFS pipeline. See About Google Transit for more information.

Transit station footprints

Data requirements:

• Preferred file formats: Shapefile, CSV, or KML/KMZ 
  • Shapefile uploads must include .SHP, .PRJ, .SHX, and .DBF files
  • Geodatabase, AutoCAD file, MrSID, or MapInfo TAB are not accepted
• Geometry type: polygon or multipolygon (preferred), point features (are accepted, but not recommended) -no linestring features

Transit station footprints fields/attributes

The following fields are listed as either Required, Recommended, or Supplemental for transit footprint datasets. Failure to include the required information could result in processing delays or rejection.

Field	Requirement Level	Description	Example
STN_NAME	Required	Name of station	"Zurich HB"
LAT	Required	Latitude coordinates of the stop	"40.763"
LONG	Required	Longitude coordinates of the stop	"-74.001"
AGENCY	Required	Entity that owns or operates transit system	"ITO"
STN_TYPE	Supplemental	Type of vehicle services	"Train"
ID	Supplemental	A unique and stable (alphanumeric string) identifier for the road segment	"AX232514"

Transit logos

Data requirements:

File format: SVG files only

Partner steps to verify before uploading:

Ensure the associated agency name is included in your data submission.

Trucking restrictions

Trucking restriction example - Coming soon

Important to Note: 

• Google currently supports the following type of trucking restrictions
  • Height-based restriction
  • Width-based restriction
  • Length-based restriction
  • Weight-based restriction
  • Trailer count-based restriction
  • Axel count-based restriction
  • Hazardous goods restriction
  • Generic “no trucks / tractor-trailer” restriction
• At this time, trucking restrictions do not appear on the map 
• A single road can have multiple restrictions applied to them

Data requirements:

• Preferred file formats: Shapefile, KML/KMZ, or GeoJSON
  • A shapefile should include .shp, shx, .dbf and .prj to ensure alignment
  • KML/KMZ files must not contain z-coordinates, only latitude and longitude
• Geometry type: linestring features (no polygon, multipolygon, or point features)

Partner steps to verify before uploading:

• Ensure that if your road has multiple restrictions applied, all restrictions are listed on a single line.
• Height-, width-, length-, and weight-based restrictions require a dimension comparison (e.g. >), a value (e.g. 30), and a unit (e.g. feet)
• Trailer and axle count-based restrictions require a dimension comparison (e.g.. >), a value (e.g. 3)

Trucking restrictions fields/attributes

The following fields are listed as either Required, Recommended, or Supplemental for trucking restriction datasets. Failure to include the required information could result in processing delays or rejection.

Field	Requirement Level	Description	Example
RESTR	Required (unless parsed out)	Complete restriction explanation written out	“Trucks longer than 36ft. And taller than 15 feet are not permitted”  “No truck tractors with trailers longer than 48 feet”
RESTR_TYPE	Recommended	Restriction type that is associated with the restriction	One of: Height Width Length Weight Trailer count Axel count Hazardous goods Generic “no trucks / tractor-trailer”
DIM	Recommended	Dimension comparison that is associated with the restriction	One of: > >=
Value	Recommended	Value that is associated with the restriction	“3.5”
UNIT	Recommended	Unit that is associated with the restriction	“Metric tonne”
HAZ_TYPE	Required (for hazardous goods restrictions)		One of: Unspecified Explosives Gases Flammable Combustible Organic Poison Radioactive Corrosive Aspiration Hazard Environmental Hazard Other
ST_NAME	Recommended	Street Name and Type (the words Street, Avenue can be abbreviated)	"Powell St"
RT_Name	Recommended	Route Name	"Southeast 52nd Street"
ID	Supplemental	A unique and stable (alphanumeric string) identifier for the road segment	"AX232514"

Water bodies

Water bodies example

Water bodies example

Data requirements:

• Preferred file formats: Shapefile, KML/KMZ, or GeoJSON
  • A shapefile should include .shp, shx, .dbf and .prj to ensure alignment
  • KML/KMZ files must not contain z-coordinates, only latitude and longitude
• Geometry type: linestring features, polygon, or multipolygon (no point features)
  • Polygons representing bodies of water
  • Lines are accepted to indicate rivers

Important to Note:

Water bodies are added to the map on a best effort basis, we cannot provide detailed timelines for when they will be added at this time.

Water body fields/attributes

The following fields are listed as either Required, Recommended, or Supplemental for water body datasets. Failure to include the required information could result in processing delays or rejection.

Field	Requirement Level	Description	Example
TYPE	Required	Type of water body	“River” “Lake”
NAME	Recommended	Name of the water body you want to appear on the map	“Skykomish River” “Lake Isabel”
ID	Supplemental	A unique and stable (alphanumeric string) identifier for the road segment	"AX232514"

You can navigate back to this Content requirements help page by clicking Accepted Data Layers and Formats in the Help card.

 

Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.

Last updated 2022-01-11 UTC.