Content requirements: specifications for sharing data

How to format and structure data to share in Maps Content Partners

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

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

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

Important to Note:

We don’t accept Geodatabase, AutoCAD files, MrSID or MapInfo TAB. Most software has an option to convert to SHP or CSV so you can export into an accepted format.
GMCP can only accept map data in raw, unaltered form, and cannot accept data via 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.
There are no file size limits except for Drone Imagery submissions, which have a maximum file size of 1.99GB.

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)

Geocodes example files

Geocode Example

Data requirements

Address point data is accepted in geospatial formats of either a shapefile or KML/KMZ.
Include full address information required for a valid address (street number, street name, administrative areas, postal codes) or we may be unable to process your request for updates
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.

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	REQUIRED	DESCRIPTION	EXAMPLE
ST_NUM	Required	Street Number (i.e. house number, address number, etc)	125
APT_NUM	Optional	Apartment Number	#101
BLDGNAME	Optional	Building Name	BLDG D
ST_NAME	Required	Street Name and Type (Street, Avenue, etc., can be abbreviated but expansion of abbreviations is preferred)	Powell St
NEIGHBH	Optional	Neighborhood Name	Union Square
CITY	Required	City Name	San Francisco
STATE	Required	State (Two Letter Abbreviation)	CA
ZIP	Required	5-digit zip code	94108
CNT_NAME	Optional	County Name	San Francisco
CNT_FIPS	Optional	County FIPS 6-4 code (refer to Information Technology Laboratory)	06075f5
ID	PREFERRED	A unique id for the feature	B1, B2, B3, etc

Points of interest (POIs)

Example POI files

POI Example

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
- Not accepted: Geodatabase, AutoCAD files, MrSID, or MapInfo TAB
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.
Please include relevant attributes like wheelchair accessibility, curbside pick-up (see list in the Description and Definitions tab of the template)

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	REQUIRED	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. (i.e. hospital, medical_lab)	historical landmark
LAT	REQUIRED	Contains the latitude that corresponds to the location of the listing.	40.7484
LONG	REQUIRED	Contains the longitude that corresponds to the location of the listing.	-73.9857
FULL_AD	PREFERRED	Contains the full formatted address, including all available details (street number, street name, town/city, state/province/region, country and postal code).	20 W 34th St, Suite 201, New York, NY 10011
ST_NUM	PREFERRED	Parsed out address	20
ST_NAME	PREFERRED		West 34th Street
APT_NUM	PREFERRED		Suite 201
CITY	PREFERRED		New York
STATE	PREFERRED		NY
ZIP	PREFERRED		10011
PHONE	PREFERRED	Contains the main phone number of the business (including country code e.g. +86).	(212) 736-3100
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
ID	PREFERRED		NY_001

Additional POI attributes accepted:

Existence: status of an establishment's operations (open, temporary closed or permanently closed)
serves_dine_in: customers are allowed/not allowed to eat inside
has_takeout: a place allows/doesn't allow patrons to purchase and takeaway food
has_curbside_pickup: customers can/cannot pick up order without going inside
has_delivery: a place offers/doesn't offer delivery to customers
has_in_store_pickup: a place allows/doesn't allow online orders to be picked up in store
has_no_contact_delivery : a place offers/doesn't offer delivery at the customer's door without face-to-face interaction
has_in_store_shopping: a place allows/doesn't allow customers to go inside the shop

Reservations (Tribal Areas)

Note that the preceding list is not exhaustive, and there are additional attributes available.

To claim a business POI please visit Google Business Profile.

Political and postal boundaries

Example political files:

Single feature: Wyoming

Multiple features: Country Multiple Types

Data requirements:

Name of Political Feature (English and local language preferred)
Polygon indicating bounds of the political feature
- Boundaries extend out to the water if coastal
- If a river is the boundary, features should snap to one another
- Mindful of other country boundaries - please align with bordering countries
- Ensure that the data ‘tiles’ with no gaps or overlaps/sliver segments
Type column indicating administrative area, postal code, or border feature
- Multiple feature types separated by Admin layer or Type (example below)

What qualifies as a political feature:

Postal codes
- Postal prefix and suffix
- Post towns
Administrative areas (state, province, county)
Municipal features (cities and subdistricts)
Neighborhood boundaries
Colloquial areas (Bay Area, Acadiana, etc.)
School districts
Reservations (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 to point features but we also accept point features for Municipal features or smaller.
We accept shapefiles and KML/KMZ. PDFs are not accepted for political features.

Political Fields/Attribute Requirements:

FIELD	REQUIRED	DESCRIPTION	EXAMPLE
NAME	REQUIRED	Official Name of the Feature	Seattle
TYPE	REQUIRED	Administrative Level	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
- Not accepted: Geodatabase, AutoCAD file, MrSID, or MapInfo TAB
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.
The street format is similar in many ways to the address format detailed above, except for the different street number format.
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.

Address Range Example

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

For trucking restrictions: see the Trucking restrictions section below
For low-emission zone (LEZ) restrictions: see the Low-emission zones section below <add link>
For road closures: see the Road closures section below

Roads, trails, and pedestrian paths fields/attributes

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

FIELD	REQUIRED	DESCRIPTION	EXAMPLE
ID	Optional	A unique and stable identifier for the road segment	Any alphanumeric string (e.g. "14232514")
ST_NAME	Preferred	Street Name and Type (the words Street, Avenue can be abbreviated)	Powell St
RT_Name	Preferred	Route name	Southeast 52nd Street
BIKE_RT	Preferred	Bike route name	Burke-Gilman Trail or Cheshiahud Lake Union Loop
ST_NM_A1	Optional	Alternative name 1	U.S. 101
ST_NM_A2	Optional	Alternative name 2	RT 101
NEIGHBH	Optional	Neighborhood name	Union Square
CITY	Preferred	City name	San Francisco
ADMIN	Preferred	Highest level of administrative area	WA, New South Wales, County Cork, etc
POSTAL	Preferred	Zip code/postal code	94103
AR_RT_FR	Optional	The starting address range value on the right-hand side, relative to geometry	2
AR_RT_TO	Optional	The ending address range value on the right-hand side, relative to geometry	98
AR_LT_FR	Optional	The starting address range value on the left-hand side, relative to geometry	1
AR_LT_TO	Optional	The ending address range value on the left-hand side, relative to geometry	99
SURFACE	Optional	Road surface	Paved or Unpaved
SPEED_LM	Optional	Speed limit in MPH or KPH	20mph, 32 KPH, etc
BIKE	Required	Whether the segment allows bikes, and if so, what route type it is	One of: Non-traffic Trail, Separate Trail, Bike Friendly Pedestrian Path, Shared Road, Shared Road with Pedestrian Path, Bike Lane, Bike Lane with Pedestrian Path, Disallowed, Non-applicable
CAR_RESTR	Optional - unless a restriction is known	Whether the segment allows cars and trucks	One of: Disallowed, Allowed
PED_RESTR	Optional - unless a restriction is known	Whether the segment allows pedestrian use	One of: Disallowed, Allowed
DIR	Preferred	Identifies the direction of travel	One of: Bi-Directional, Forward, Reverse
BIKE SAFETY	Optional - unless the route is known to have potential safety concerns.	Are there any known safety concerns with this bicycle route	One of: RECOMMENDED: No safety concerns, this is an established route (most common) NEUTRAL: No known safety concerns, bikes can travel along this route CAUTION: Bikes are allowed on this route, but it is not recommended, this could be due to lack of signage or deprioritization of bikes. ILLEGAL - Bikes are not allowed on the route/path
SEPARATE	Optional	The road segment is separated by a barrier in the middle	Y/N
TURN_R	Optional	Turn restrictions (below you’ll find the exact format)	Freeform text
ELEV	Optional	If the road is elevated, or a bridge or a tunnel	One of: bridge, tunnel, overpass, underpass

Other types of data

Bicycle facilities

Bicycle facilities examples

Bicycle Facilities Example

Data requirements:

Bike data is preferred as a shapefile or KML/.KMZ
Use a segment-based representation: a segment is part of a road/trail between two intersections. We can’t accept roads/trails that have multiple intersections attached to them.

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.
Due to high demand, cycling imports are being processed on a best-effort basis only (no timeline commitments can be made). We still encourage you to upload to signal your interest and data availability; this will help prioritize cycling improvements in your area.
The Google Maps bike mode layer has not been launched yet in every city or country; however, biking directions will still be available.

Bicycle facility definitions

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	Required	Description	Example
BIKE	Required	Whether the segment allows bikes, and if so, what route type it is	One of: Non-traffic Trail, Separate Trail, Bike Friendly Pedestrian Path, Shared Road, Shared Road with Pedestrian Path, Bike Lane, Bike Lane with Pedestrian Path, Disallowed, Non-applicable
ID	Optional	A unique and stable identifier for the road segment	Any alphanumeric string (e.g. "14232514")
ST_NAME	Preferred	Street Name and Type (the words Street, Avenue can be abbreviated)	Stone Way N.
RT_Name	Preferred	Route Name	Southeast 52nd Street
BIKE_RT	Preferred	Bike Route Name	Burke-Gilman Trail or Cheshiahud Lake Union Loop
NEIGHBH	Optional	Neighborhood Name	Wallingford
CITY	Preferred	City Name	Seattle
ADMIN	Preferred	Highest level of administrative area	WA, New South Wales, County Cork, etc
POSTAL	Preferred	Zip code / postal code	98103
SURFACE	Optional	Road Surface	Paved or Unpaved
SPEED_LM	Optional	Speed limit in MPH or KPH	20mph, 32 KPH, etc
CAR_RESTR	Optional - unless a restriction is known	Whether the segment allows cars and trucks	One of: Disallowed, Allowed
PED_RESTR	Optional - unless a restriction is known	Whether the segment allows pedestrian use	One of: Disallowed, Allowed
DIR	Preferred	Identifies the direction of travel	One of: Bi-Directional, Forward, Reverse
BIKE SAFETY	Optional - unless the route is known to have potential safety concerns.	Are there any known safety concerns with this bicycle route	One of: RECOMMENDED: No safety concerns, this is an established route (most common) NEUTRAL: No known safety concerns, bikes can travel along this route CAUTION: Bikes are allowed on this route, but it is not recommended, this could be due to lack of signage or deprioritization of bikes. ILLEGAL - Bikes are not allowed on the route/path

Building footprints, property boundaries, and parcels

Data requirements:

Polygon of building or grounds extent
Name of building or grounds (if applicable)
APN or unique identifying number (parcels only)
Full address information
Should include the category (residential, business)

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.

Building footprints, property boundaries, and parcels fields/attributes

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

Field	Required	Description	Example
APN	Required for parcel datasets	Property’s parcel number	00594100700700
ID	Optional	A unique and stable identifier for the road segment	Any alphanumeric string (e.g. "14232514")
NAME	Preferred	Contains the building name	Empire State Building
TYPE	Preferred	Contains the type boundary data	One of: Building Footprint Property Boundaries Parcel
CATEG	Preferred	Contains the category of boundary data	Examples: Residential Business Mixed Use
LAT	Preferred	Contains the latitude that corresponds to the location of the listing	40.7484
LONG	Preferred	Contains the longitude that corresponds to the location of the listing	-73.9857
FULL_AD	Preferred	Contains the full formatted address, including all available details (street number, street name, town/city, state/province/region, country and postal code)	20 W 34th St, Suite 201, New York, NY 10011
ST_NUM	Preferred	Parsed out address	20
ST_NAME	Preferred		West 34th Street
APT_NUM	Preferred		Suite 201
CITY	Preferred		New York
STATE	Preferred		NY
ZIP	Preferred		10011

Environmental Insights Explorer (EIE) custom boundaries

EIE example

EIE Example

Data requirements:

File Format: Keyhole Markup File (.kml/ .kmz), Shapefile, GeoJSON
- KML/KMZ files must not contain z-coordinates, only latitude and longitude
- A shapefile must include a PRJ (.prj) file if the data is not in a latitude/longitude projection (as do all the other standard files: .shp, .shx, .dbf)
- If the file contains multiple features, each feature must be named distinctly (more details on this below)
Geometry type: polygon or multipolygon (no points or linestring features)

Partner steps to verify before uploading:

If the data contains multiple polygon or multipolygon features, you are required to state whether the polygons are a part of a larger union, or if the polygons are independent entities
For polygons that are to be unioned together, a unique name for the union is required, along with at least a unique ID for the features that are to be merged
For independent polygons, a unique ID is not required---only a unique name

The data you submit must be viewable in Google Earth Pro. Submitting your data files as per the above Data Requirements should be sufficient, but we encourage you to verify before submitting your data. For more information on Google Earth Pro, see General Help Page , Installation of Google Earth Pro Help Page.

Additional Metadata should be provided as outlined below. See example.

EIE fields/attributes

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

FIELD	REQUIRED	DESCRIPTION	EXAMPLES
RELATION	REQUIRED	Whether the feature is an independent feature, or is to be unioned with other features	UNION INDEPENDENT
UNION_NAME	REQUIRED*	Name of the unioned feature	Greater Manchester Town Centres Glasgow Transport Strategy City Centre Grand Paris Seine Ouest
IND_Name	REQUIRED*	Name of the independent feature	Amsterdam Zuid Berlin Spandau Berkeley
TYPE	PREFERRED	Type of boundary conventionally used	Regional Zone Neighborhood Commuter Belt Borough
ID	PREFERRED	Unique ID for the feature (not required)	A1 B1, B2, B3

Note:

Failure to provide accurate metadata or correctly formatted image files could result in publication delays.
Features do not need both a UNION_NAME and an IND_NAME, they only require one or the other depending on whether the features are a part of a larger union, or should be treated independently.

Additional resources:

EV charging stations

Important to Note:

Thank you for uploading your EV charging station data, and for your interest in partnering with Google. Unfortunately, we’re pausing processing of EV charging station data through GMCP as we’re making changes to our processes and infrastructure to have a better experience for our users. We will be parking your upload to process at a later date. No further action is required at this point on your part.

We will notify you when we resume processing your data by changing the status of this upload to ‘Under review’. When processing is complete and your data has been implemented into Google Maps, the upload status will change to ‘In use’.

If you have any questions, please feel free to reach out anytime in this message panel. Our sincere apologies for this inconvenience, and we appreciate your understanding.

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.

Currently we accept two formats for EVCS data:

Open Charge Point Interface (OCPI)

Google EV Location Feed Specification (GELFS)

GELFS Example

The Google EV Location Feed Specification (GELFS) defines a common format for electric vehicle (EV) charging locations and associated information. GELFS enables EV charging networks to publish this data to be consumed by a variety of applications including Google Maps.

Key to this format is the ability to provide:

Information to accurately represent the location of the charging station (address and a hosting business, if relevant),
The connectors and power characteristics of the charging station,
Possible Real time usage availability,
Future planned availability, such as reservation queues, or out of service maintenance periods.
Accepted formats (Json)

GELFS update types

Questions:

Are you the direct CPO?
Is your data /business growing and you will need to update it frequently?
- Would you like to share your Endpoint so your data can be frequently updated?
- Can you provide us a sample data
Do you have real-time data for your EVCS?
- Would you like to share your Endpoint so your data can be frequently updated?
- Can you provide us a sample data
Do you have payments and authentication for your feed?
- Would you like to share your Endpoint so your data can be frequently updated?
- Can you provide us a sample data

If you are able to share your endpoint:

If you are regularly updating your data you don’t have to upload it every time. We can offer you three types of update:

A full feed containing all charging locations and associated data
A real-time availability feed update, containing port status to enable low latency, high frequency publication of changes in port status (such as busy, reserved, available)
A payments and authentication feed, containing authorization modes that allow charging through charging ports.

Keep in mind if your data is not getting updated we still can accept your request if it meets the Gelfs Data Levels Required Fields

GELFS’ standardized endpoints and Feed Authentication

While GELFS doesn’t require or specify a single feed access authentication, we recommend using a static authorization token for accessing and fetching GELFS feeds from partner servers over https. This token specifically would be sent to the partner server via the Authorization HTTP header. (e.g. Authorization: Token StaticToken1234).

Full feed:
- Example: https://servername.com/gelfs/locations (will be fetched every day)
Real-time availability feeds:
- Example: https://servername.com/gelfs/realtime (will be fetched every x minutes)
Payments and authentication:
- Example: https://servername.com/gelfs/auth (will be fetched every day)

Note: You can share your OCPI formatted data via “Full Feed” static data as well

Encoding

GELFS Data Levels Required Fields:

There is a minimum requirement your (Json formatted) data should meet. These fields are necessary and your data can not be accepted if it’s missing any of this information:

gelfs_version: "0.96"

Locations:

Id(string)
network_brand_name(string)
network_name(string)
contact(Contact)
- Operator_phone
- operator_website
coordinates (Address)
- Latitude
- longitude
address(string)
- address_string
- Street_number
- Street_name
- Locality
- Admin_area
- Postal_code
- Country_code
- language_code
stations(string)
Access_restriction

Station

Id
Coordinates
- Latitude
- longitude
ports

Port

Id
connector_type
power_kw
Charging_mechanism
last_updated
Authentications
- authentication_id

Status (if real-time data is available)

Note:

If your feed getting updated frequently and you have real-time and payment network availability for your stations:

Check this document to see if you can provide the Standard format and set up your Endpoints:
- GELFS PDF Document
Provide us a sample of your feed
We will contact and lead you through the on-boarding process

GELFS Top-Level Object

The top-level object for GELFS contains a set of location objects as well as the gelfs_version the feed is implementing. See examples below.

Field	Type	Requirement Status	Comments
gelfs_version	string	Required	Version number of GELFS spec.
locations	Location	Required (Array)	An array of Location Objects.

Field

Type

Requirement Status

Comments

gelfs_version

string

Required

Version number of GELFS spec.

locations

Location

Required

(Array)

An array of Location Objects.

Location

A Location object denotes a physical location such as a physical address at a specific location for a single network provider. The Location object is synonymous with a POI; for example, if there are 20 charging stations within a parking lot, this is represented via a single Location object.

Location objects are specified as elements inside the gelfs_data array.

Field Variables	Requirement Status	Comments
Field: id Type: String	Required	A unique string identifier for each semantic location. Identifiers must be the same across feed versions Location ID must not change unless the location is moved to an entirely new location). Identifiers MUST NOT contain spaces (e.g. ABC123)
Field: network_brand_name Type: string	Required	Official name of the network that gets displayed on the Map. No symbols such as trademark, copyright, or others are permitted. Example: WonderCharge This must correspond to driver visible branding at the location, if any exists If the location does not belong to any charging network, this field can carry the name “Non-Networked”. If this field is missing, the stations are assumed to be Non-networked and will carry a generic title “EV Charging Station” (or similar)
Field: network_name Type: String	Required	Official name of the charging network that owns the charging stations. This may or may not be the external-facing brand name.
Field: contact Type: String	Required	Contact information for the location/charging provider. Refer to Contact object.
Field: coordinates Type: Coordinates	Required	Geographic coordinates of the location. Refer to Coordinates object.
Field: address Type: Address	Required	Structured address of the location. Refer to Address object.
Field: location_hint Type: string	Optional	Description to help locate the stations Example: Near the elevators, on the 4th level of the parking garage.
Field: opening_hours Type: Opening Hours	Optional (Array)	Operational hours for this charging location.
Field: access_restriction Type: Access Restriction Enum	Required	Restrictions to enter and/or charge at this charging location (See section below for access restrictions). Most restrictive category implied by parking and the charging station Over all times throughout the week.
Field: host Type: Host	Optional	Individual business, entity or organization directly hosting this location Example, Whole Foods Market Note: “host” should not be attributed to larger business holdings, city/community councils, etc, but rather to an individual entity that is visually identifiable at the EV charging station.
Field: stations Type: Station	Required (Array)	Information for one or more stations at this location. Refer to Station object.
Field: onstreet_location Type: boolean	Optional	Whether the location is on-street or off-street. Note: If the same location has both on-street and off-street stations, create separate location objects for each group.
Field: opening_date Type: string	Optional	Opening date for this location, YYYY-mm-dd format. For upcoming locations, this field can specify a future opening date. Note: If the exact future opening date is not available, supply the nearest possible month in YYYY-mm format.
Field: language_code Type: string	Optional	2-letter ISO language code, indicating the language code for the address components
Field: last_updated Type: String	Required	Timestamp when the status was last updated. This must be provided via the ISO 8601 standard string, in the form: YYYY-MM-DDThh:mm:ssTZD (eg 2019-04-12T01:02:03+0000)

AccessRestrictionEnum

Field	Enum Value	Comments
access_restriction	PUBLIC	Open to the public; no restrictions
	CUSTOMERS_ONLY	Open to customers of an organization or business entity, such as a restaurant or cafe
	GUESTS_ONLY	Open to guests of an establishment only, such as a hotel
	EMPLOYEES_ONLY	Open to employees of an organization or business entity
	STUDENTS_ONLY	Open to students attending an educational institution
	RESIDENTS_ONLY	Open to residents or tenants of a housing location
	HOME_CHARGER	Chargers located at someone's private residence. These are restricted from showing on Google Maps.
	UNKNOWN	Restriction unknown. Note: The chargers with this restriction might not surface on Google Maps.

Opening hours

Field Variables	Requirement Status	Comments
Field: weekday_begin Type: Integer	Optional	Beginning day of operation, indicated as ISO week day (Monday = 1, Tuesday = 2 , etc)
Field: weekday_end Type: Integer	Optional	End day of weekly operation. If absent, it is assumed the location is open week-round.
Field: hour_begin Type: String	Optional	Beginning hour of operation in 24 hour format (00:00). If absent, 00:00 is assumed
Field: hour_end Type: String	Optional	End hour of operation in 24 hour format. If absent, 24:00 is assumed.

Contact

Field Variables

Requirement Status

Comments

Field: operator_phone

Type: String

Required

The operator_phone field contains a single voice telephone number for either:
1. The specified charge point operator; or
2. The host business in the case of an un-networked Station.
This field presents the telephone number as is typical for the agency's service area.
It can and should contain punctuation marks to group the digits of the number.

Field: operator_website

Type: String

Optional

This value may be to a specific website representing this Location, or a general website for the operator.

The value must be a fully qualified URL that includes http:// or https://
Any special characters in the URL must be correctly escaped.
Please review this link for a description of how to create fully qualified URL values.

Coordinates

Address

Field Variables	Requirement Status	Comments
Field: address_string Type: String	Optional	A single string representing the street address of the Location. Other structured address fields can be provided along with this string for better interpretation of the address. Where possible avoid using this field and instead use other components in this Address object. For countries without suitable addressing scheme (e.g. Japan, India), please provide this field in combination with the language code and country code.
Field: street_number Type: String	Optional	Street number, containing either numbers or a combination of numbers, letters, and punctuation islands (e.g. 123, 1A, 1-A. etc)
Field: street_name Type: String	Optional	Street name for the location
Field: locality Type: String	Optional	City/locality name
Field: admin_area Type: String	Optional	State, Province name or other administrative area name
Field: postal_code Type: String	Optional	Postal Code
Field: country_code Type: String	Required	2-letter ISO country code
Field: language_code Type: String	Optional	2-letter ISO language code, indicating the language code for the address components

Host

Station

Field Variables	Requirement Status	Comments
Field: id Type: String	Required	Unique identifier for the charging station. Identifiers must be identical across feed versions. Identifiers MUST NOT contain spaces (e.g. ABC123) and must be universally unique.
Field: label Type: String	Optional	A distinctive marker associated with the station, such as something that a user sees on the physical station unit.
Field: coordinates Type: Coordinates	Required	Geo coordinates indicating the exact location of the station.
Field: ports Type: Ports	Required (array)	One or more charging ports associated with this charging station.
Field: notes Type: String	Optional	Any additional text field describing the station.
Field: url Type: String Optional	Optional	Fully-formed URL representing the station, allowing potential deep-linking to that station on a network operator’s website.

Port

Field Variables	Requirement Status	Comments
Field: id Type: String	Required	Unique identifier for the port. Port numbers need to be unique within the stations they are grouped under. Identifiers MUST NOT contain spaces (e.g. ABC123).
Field: connector_type Type: ConnectorTypeEnum	Required
Field: power_kw Type: Float	Required	Maximum power output in kilowatts
Field: charging_mechanism Type: ChargingMechanismEnum	Required	Cable or socket
Field: port_status Type: PortStatus	Optional	A repeated set of PortStatus objects indicating a port status and its start/end times. See PortStatus object as well as the example feed below
Field: last_updated Type: String	Required	Timestamp when the status was last updated. This must be provided via the ISO 8601 standard string, in the format: YYYY-MM-DDThh:mm:ssTZD (eg 2019-04-12T00:09:22+0000)
Field: authentications Type: Authentication	Required (array)	Authentication and payment methods for this port.
Field: notes Type: String	Optional	Any optional text related to this port.
Field: reservable Type: boolean	Optional	Whether this port is reservable.
Field: wheelchair_access_only Type: boolean	Optional	Whether this port is reserved as an wheelchair-accessible spot.
Field: dedicated_parking Type: boolean	Optional	Whether this station has dedicated parking space(s) for the purpose of charging.

ConnectorTypeEnum

Field	Enum Value	Comments
connector_type	WALL_OUTLET	All wall outlets requiring the user to bring their own EVSE must be denoted using this type. A 110V wall outlet, or a 3 phase wall outlet is an example of such a connector that must be represented by WALL_OUTLET
	J_1772
	MENNEKES
	CHADEMO
	CCS_TYPE_1	CCS Combo, Type 1
	CCS_TYPE_2	CCS Combo, Type 2
	TESLA	Tesla Connector, indicating a Destination Charger or Supercharger
	GBT

ChargingMechanismEnum

PortStatus

Field Variables

Requirement Status

Comments

Field: status

Type: PortStatusEnum

Required

Status of the port at the current moment.

Field: start_time

Type: time

Optional

Timestamp when the current port status is expected begin.
This field could be used in cases where a port has been reserved for a certain time and the start time is available to populate.
This must be provided via the ISO 8601 standard string, in the fom: YYYY-MM-DDThh:mm:ssTZD

(e.g. 2020-10-01T19:20:30+01:00)

Field: end_time

Type: time

Optional

Timestamp when the current port status is expected to end in the future, if available.
This field could be used in cases where a port has been reserved for a certain time and the end time is available to populate.
This must be provided via the ISO 8601 standard string, in the fom: YYYY-MM-DDThh:mm:ssTZD
(eg 2020-10-01T19:20:30+01:00)

Authentication

Field Variables

Requirement Status

Comments

Field: authentication_id

Type: AuthenticationMethod.ID

Required

Unique identifier for the authentication method.

Field: payment_required

Type: Boolean

Optional

Specifies whether this method costs money or not.

Note: it's possible for charging to have no cost, but still require authentication.

Field: authentication_urls

Type: AuthenticationUrl

Optional

A set of objects containing URL strings that enables deep-linking to the partner app/website, where a user may be able to view pricing details, and complete their authorization and payment for charging their EV.
These are presented as most specific (charging at a specific port) to the least specific (charging at a station or location).

AuthenticationUrl

Field Variables	Requirement Status	Comments
Field: port_auth_url Type: String	Optional	Object containing authentication URL for this port.
Field: station_auth_url Type: String	Optional	Object containing authentication URL for the station.
Field: location_auth_url Type: String	Optional	Object containing authentication URL for the location.

Field Variables

Requirement Status

Comments

Field: port_auth_url

Type: String

Optional

Object containing authentication URL for this port.

Field: station_auth_url

Type: String

Optional

Object containing authentication URL for the station.

Field: location_auth_url

Type: String

Optional

Object containing authentication URL for the location.

Authentication and Payment

Authentication objects describe aspects of authentication methods linked to each charging port. This enables adding multiple, granular authentication methods per charging port.

As such, authentication describes how the user asserts that they have an identity, which in turn can be used by the network to determine appropriate access to the resource. For example, a physical membership card, an app or a credit card. Each authentication method is specified as a separate object, and these objects are referred to by their IDs inside the Port objects.

For each authentication method, whether a payment is required can be specified. Here are the objects required as part of supplying authentication information.

Authorization

The top-level object for GELFS auth/payment contains a gelfs_version string field, along with an ev_data wrapper object containing AuthenticationMethod objects. See examples below.

Field Variables

Requirement Status

Comments

Field: gelfs_version

Type: String

Optional

Version number of GELFS spec.

Field: authentication_methods

Type: AuthenticationMethod

Required (Array)

An array of AuthenticationMethod objects.

AuthenticationMethod

Field Variables

Requirement Status

Comments

Field: id

Type: String

Required

Unique identifier for the authentication method.

Field: authentication_method

Type: AuthenticationMethod Enum

Required

Authentication method used

Field: description

Type: String

Optional

The commonly recognized name of the authentication method. For example, “Mastercard” or “Zappity”.

Note: that this is user facing and must be a meaningful name that users can identify/recognize.

AuthenticationMethodEnum

Field	Enum Value	Comments
authentication_method	UNKNOWN
	NONE	No authentication is required. Drivers can use the port without presenting any form of authentication.
	CREDIT_CARD	Credit card activates the port, either by swipe, chip or NFC
	DEBIT_CARD	Debit card activates the port, either by swipe, chip or NFC
	MEMBERSHIP_CARD	A network operator’s membership card activates the port.
	MEMBERSHIP_APP	A network operator’s mobile phone app.
	QR_CODE	Scanning a QR code activates the port.
	OTHER	The authentication method is known (i.e., not “UNKNOWN”), but doesn’t fit any of the above methods.

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 example file.
Additional metadata should be provided as outlined below, see 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, Preferred, or Optional for drone imagery datasets. Failure to include the required information could result in processing delays or rejection.

Field	Required	Description	Example
CRS	REQUIRED	WGS 84 or another local coordinate reference system for placing the data in the right geolocation.	WGS84
Location	REQUIRED	Include the lat/long location for the center of your Aerial Imagery asset	37.421863, -122.079659
Capture date	REQUIRED	The earliest data the imagery was captured in Month/Day/Year format. If the imagery was captured between 6/23/2022 and 7/02/2022 then use 6/23/2022.	6/23/2022
Resolution (GSD)	PREFERRED	The resolution or ground sample distance of your data in px/cm.	10 cm/px
Method of Capture	PREFERRED	How was the imagery captured? Satellite, Airplane, Drone, ect.	Drone
Name	PREFERRED	Basic Description of the Data	2D orthophoto of downtown Mountain View California
Area Size	PREFERRED	Area in sqkm the data covers	10 sqkm
City	PREFERRED	City Name	Mountain View
State	PREFERRED	State Name	California
Country	PREFERRED	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 the output (red, bolded sections) is similar to the example file.
Additional metadata should be provided as outlined below, see example.

Overhead imagery fields/attributes

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

Field	Required	Description	Example
CRS	REQUIRED	WGS 84 or another local coordinate reference system for placing the data in the right geolocation.	WGS84
Location	REQUIRED	Include the lat/long location for the center of your Aerial Imagery asset	37.421863, -122.079659
Capture date	REQUIRED	The earliest data the imagery was captured in Month/Day/Year format. If the imagery was captured between 6/23/2022 and 7/02/2022 then use 6/23/2022.	6/23/2022
Resolution (GSD)	PREFERRED	The resolution or ground sample distance of your data in px/cm.	10 cm/px
Method of Capture	PREFERRED	How was the imagery captured? Satellite, Airplane, Drone, ect.	Aircraft
Name	PREFERRED	Basic Description of the Data	2D orthophoto of downtown Mountain View California
Area Size	PREFERRED	Area in sqkm the data covers	10 sqkm
City	PREFERRED	City Name	Mountain View
State	PREFERRED	State Name	California
Country	PREFERRED	Country Name	USA

Images

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)

Data requirements

LEZs require the following, at a minimum:

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

LEZ fields/attributes

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

Field	Required	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	Preferred	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	Preferred	English URL of the LEZ	https://stad.gent/en/mobility-ghent/low-emission-zone-ghent
DESCR	Preferred - Highly Encouraged	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	Preferred	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”

New housing developments

Parks and protected areas

Parks and protected areas example files

Park Example

Data requirements:

Polygon geometry of park boundaries is preferred over point geometry. We recommend a scale of 1:25,000 or larger.
If you have a park that is in two sections, include the park in one polygon
Name of park or protected area (in a field called NAME, with alternates in ALT_NM_1, ALT_NM_2).
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.
Optionally, parks can include an address, park operating hours, parking, or facilities. Add the data in fields in the form of X_DESCRIPTION, such as X_USAGE, X_HOURS, X_PARKING.

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

Important to Note:

If no name (or no usable name) is provided, we will process as a “green space” and the result will be a green polygon that will render on the map.

Park fields/attributes

The following fields are listed as either Required, Preferred, or Optional for park/protected area datasets.

Field	Required	Description	Example
ID	Optional	A unique and stable identifier for the road segment	Any alphanumeric string (e.g. "14232514")
NAME	Preferred	Name of the park/protected area you want to appear on the map	Wallace Falls State Park, Mt. Baker-Snoqualmie National Forest
TYPE	Required	Type of park/protected area	Park, State Forest, etc.

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

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

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 (preferred), multipolygon (preferred), or point features (no linestring features)
Required attributes: Agency and station/hub name

Transit station footprints fields/attributes

The following fields are listed as either Required or Optional.

Field	Required	Description	Example
STN_NAME	Required	Name of station	Zurich HB
LAT	Required	Latitude coordinates of the stop	40.76255
LONG	Required	Longitude coordinates of the stop	-74.000969
AGENCY	Required	Entity that owns or operates transit system	ITO
STN_TYPE	Optional	Type of vehicle services	Train

Transit logos

Trucking restrictions

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:

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)
Hazardous goods restrictions require which type of hazardous goods are not allowed:
- Unspecified
- Explosives
- Gases
- Flammable
- Combustible
- Organic
- Poison
- Radioactive
- Corrosive
- Aspiration Hazard
- Environmental Hazard
- Other

Partner steps to verify before uploading:

Ensure that if your road has multiple restrictions applied, all restrictions are listed on a single line.

Trucking restrictions fields/attributes

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

Field	Required	Description	Example
ID	Optional	A unique and stable identifier for the road segment	Any alphanumeric string (e.g. "14232514")
ST_NAME	Preferred - Highly Encouraged	Street Name and Type (the words Street, Avenue can be abbreviated)	Powell St
RT_Name	Preferred	Route Name	Southeast 52nd Street
RESTR	Required - unless parsed out	Complete restriction explanation written out	Example_1: “Trucks longer than 36ft. And taller than 15 feet are not permitted” Example_2: “No truck tractors with trailers longer than 48 feet”
RESTR_TYPE	Preferred - Highly Encouraged	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	Preferred - Highly Encouraged	Dimension comparison that is associated with the restriction	One of: > >= < <= =
Value	Preferred - Highly Encouraged	Value that is associated with the restriction	30
UNIT	Preferred - Highly Encouraged	Unit that is associated with the restriction	feet
HAZ_TYPE	Required - for hazardous goods restrictions		One of: Unspecified Explosives Gases Flammable Combustible Organic Poison Radioactive Corrosive Aspiration Hazard Environmental Hazard Other

Water bodies

Water bodies example

Data requirements:

Be sure to include:
- Name of the water feature if available
- Feature type of the water feature
  - Some examples include (but are not limited to): River, Lake, Reservoir, Pond, Channel
Polygons representing bodies of water
Lines are accepted to indicate rivers
Please do not include point geometry to represent water features.

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, Preferred, or Optional for water body datasets. Failure to include the required information could result in processing delays or rejection.

Field	Required	Description	Example
ID	Optional	A unique and stable identifier for the road segment	Any alphanumeric string (e.g. "14232514")
NAME	Preferred	Name of the water body you want to appear on the map	Skykomish River, Lake Isabel
TYPE	Required	Type of water body	River, Lake, etc.

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.

Choose a section to give feedback on

Was this helpful?

How can we improve it?

Field	Enum Value	Comments
charging_mechanism	CABLE	A charging cable is provided at the charging port. The user can take this cable and plug it into the car directly.
	SOCKET	The charging port is a socket and requires the user to bring their own cable to connect the car to the socket.

Content requirements: specifications for sharing data

Supported file types for Google Maps Content Partners (GMCP)

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

EV charging stations

Imagery

Indoor mapping data format (IMDF)

Restriction zones

New housing developments

Parks and protected areas

Road closures

Transit

Trucking restrictions

Water bodies

Was this helpful?

Need more help?

Try these next steps: