Google Maps Content Partners Accepted Data Layers and Formats

How to Format and Structure Your Data

Sending data using the file types, schema, format and templates we provide in this section will ease the processing. Submitting data outside of these requirements will cause delays.

Preferred 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 & longitude coordinates) are required.

.KML/.KMZ (Keyhole Markup Language): Represent the data as SchemaData and SimpleFields (preferred) or ExtendedData. .kml/.kmz files must have address fields. KML/KMZ files can be created with Google Earth - To view more information on this, click this link

Important to Note:

• We don’t accept Geodatabase, AutoCAD file, 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.

 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 clean geometry with:

• No Dangling lines
• No Undershoots
• No Overlapping lines or nearly overlapping lines
• No Polylines for polygonal features such as political boundaries or parcels
• No Overlapping polygons 
• No Cul-De-Sac geometry or Driveways
• Features with the same name or containing the same feature represented by a single polygon rather than multiple polygons
• We accept Inner loops/donuts
  • E.g., to exclude lakes from a park, or an island from a water feature
• Polygons should have correct windings, and they must not self-intersect
  • Our preferred order is clockwise for both internal and external polygons

Acceptable Data Types 

Below is a list of data types we accept on this site. 

• Political administrative areas
• Points of Interest (POIs) including businesses and services 
• Address Points/Geocodes
• Road network updates, including:
  • Road-related travel restrictions (e.g., checkpoints, border restrictions) 
  • New and existing road changes (e.g., geometry, names, directionality) 
  • Bike and pedestrian paths 
• Other map updates, including:
  • New Housing Developments (road centerline, geocoded addresses, sales office POI)
  • Compounds (building footprint or grounds outline are accepted but imported at best effort only)
  • Parks (green spaces)
  • Overhead imagery
  • Water boundaries
  • EV Charging Stations

If the data type you would like to submit to Google is not listed here, please visit Get on Google.

Data Type Detailed Properties

Political Boundaries

Example Political Files: 

Single Feature: Wyoming

Multiple Features: Country Multiple Types

Basic 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 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 Classifies 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 political operators, no guarantee of edits is made.
• 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

 

Points of Interest (POIs)

Example POI Files

POI Example

To describe POIs, please use guidance and definitions included here. Please upload as a .csv file only. 

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).	[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
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 place an order by the curb
• 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

 

To claim a business POI please visit Google My Business.

Address Points (Geocodes)

Geocodes Example Files

Geocode Example

• Address Point data are accepted in geospatial formats 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
• Center address points on the property or house structure they represent
• 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.

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 List:

The following fields are listed as either Required or Optional for Geocode Addresses.  This format also applies for address fields in Points of Interest or Roads datasets:

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

New Roads and Pedestrian Paths

Roads and Pedestrian Paths Examples

Roads: Roads Example

Pedestrian Paths: Pedestrian Paths Example

• Road and pedestrian path data is preferred as a shapefile or .KML/.KMZ
• 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.
• See separate section below for TRAVEL ROAD RESTRICTIONS

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

Roads and Pedestrian Fields/Attributes List.

The following fields are useful for roads and pedestrian paths. "Required" is specific to Feature Type:

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	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
STATE	Preferred	State (Two Letter Abbreviation)	CA
ZIP	Preferred	5-digit zip code	94108
CNT_NAME	Optional	County Name	San Francisco
AR_RT_FR	Optional	Starting address on the right-hand side, relative to geometry	2
AR_RT_TO	Optional	Ending address on the right-hand side, relative to geometry	98
AR_LT_FR	Optional	Starting address on the left-hand side, relative to geometry	1
AR_LT_TO	Optional	Ending address 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	55
CAR	Required for Road Datasets	Cars are allowed on this segment	Allowed, Small vehicles only (mopeds), None, Disallowed
PEDEST	Required for Pedestrian Walkway Datasets	Segment traffic restricted to pedestrian access	One of: Trail, Walkway, Mall, Sidewalk, Wide Shoulder, None, Disallowed
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

Travel Restrictions for Checkpoints, Road Closures, Border and Road Restrictions

If uploading tabular data for checkpoints, road closures, road restrictions, border restriction, please use of this Travel Restrictions guidance below.

• Include as much detail as possible in the provided format. Ensure that your attribute table has the equivalent fields to the template
• Please note that other formats can be accepted: PDFs, shapefile, public URL, detailed screenshots.

Travel Restrictions Fields/Attributes List: 

If uploading shapefile or .KML/.KMZ, include required and optional fields/attributes of the Roads, Bikes, and Pedestrian Fields/Attributes List and additionally include the following required fields/attributes.

Field	Description	Example
FROM_ID	The ID (find the id column above of a road segment) of the segment where the turn restriction starts	14232514
FROM_END	The start of the segment the turn restriction applies to relative to its geometry.	Either "FROM" or "TO"
TO_ID	The ID (find the id column of a road segment) of the segment where the turn restriction ends	14232599
TO_END	The end of the segment the turn restriction applies to relative to its geometry	Either "FROM" or "TO"
MODE	The mode of transportation the limitation applies to.	Either "ALL", "PEDESTRIAN", "CAR", "TRUCK", "BUS" or "NON-HOV"
START_TM	The start time of the turn restriction, in 24-hour notation. Leave this and END_TM blank for permanent restriction	06:00
END_TM	The end time of the turn restriction, in 24-hour notation. Leave this and START_TM blank for permanent restriction	10:00
STRTDATE	The start date of the turn restriction.	01/02/2023
END_DATE	The end date of the turn restriction. Leave this blank for permanent restriction	03/03/2023
TYPE	Type of turn restriction	Either "NO LEFT TURN", "NO RIGHT TURN" or "NO U-TURN"

 

Transit

Transit Example Files

Transit Examples

Please note that Google has a Transit website for real time feed data. Through GMCP, you can add:

Stops/Stations (Bus Stops)

• Geometry - point or polygon features
• Name of transit station or transit stop
• Latitude and Longitude coordinates of the stop
• Route or Line type  (Not Transit Lines)
• Agency
• Address
• Stop Schedule

Footprints

• Geometry - polygons of footprints, buildings, or bus bay structures
• Station name
• Lat/long
• Agency
• Route type

Stops/Stations Fields/Attributes List:

The following fields are listed as either Required or Optional.

Field	Required	Description	Example
STOP_NAME	Required	Name of station or stop	42 ST
LAT	Required	Latitude coordinates of the stop	40.752619
LONG	Required	Longitude coordinates of the stop	-73.977268
RTE_TYPE	Required	Type of vehicle services	Train
AGENCY	Required	Entity that owns or operates transit system	ITO
ST_NUM	Optional	Street Number	89
ST_NAME	Required for train, subway stations, or transit hubs	Street Name and Type  (Street, Avenue, etc., can be abbreviated but expansion of abbreviations is preferred)	E 42nd ST
NEIGHBH	Optional	Neighborhood Name	Midtown Manhattan
CITY	Required	City Name	New York
STATE	Required	State (Two Letter Abbreviation)	NY
ZIP	Required	5-digit zip code	10017
CNT_NAME	Optional	County name	Manhattan
STOP_TIMES	Optional	Times that transit feature will stop at this location	1:00, 1:30, 2:00, 2:30

Important to Note

 

• Modeling of stations, station buildings or bus bays - upload each station as an individual polygon or point rather than a single polygon as a network
• If you would like to become a Transit Partner please follow this link for more details.

Transit Footprints Fields/Attributes List:

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
RTE_TYPE	Optional	Type of vehicle services	Train

New Housing Development

New Housing Development Example Files

New Housing Development Example

• Shapefiles are preferred. There will be delays in processing any data that is not in shapefile format. PDFs without spatial information will not be accepted.  

• Road centerlines with street names (see roads and addresses 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 (see roads and addresses section for more info).

• Public opening date should be included. This is the month and year that public routing through the housing development will be made available
   
• Community sales office names must be included in the POI shapefiles attribute table
   
• Parcels are accepted but not actively added to the map
   
• 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.

Building Footprints, Property Boundaries and Parcels

• 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 (i.e. a house’s tax parcel) is still accepted, but they are not actively added to the map. 
• Building footprints and Property boundaries (i.e. a boundary of say a hospital) are accepted but imported as best effort only.

Parks and Protected Areas

Parks and Protected Areas Example Files

Park Example

Parks and protected areas should have the following info:

• Polygon geometry of park boundaries is preferred over point geometry. We recommend a scale better than 1:25,000.
• 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.

Overhead Imagery

• 2D nadir (top-down) imagery 
  • Format requirements
    • File format: GeoTIFF, JP2000
    • Data must be orthorectified 
    • Single image or tiled mosaic
       
  • Description of Data (required)
    • Projection
    • Location of Imagery (Lat/Long)
    • Date of Capture
    • Method of Capture (Satellite, Airplane, Balloon, Drone, etc)
    • ​​Approximate Resolution (cm/px)

Note: we do not accept oblique imagery. 

Drone Imagery

• 2D nadir (top-down) imagery 
• Format requirements
  • File format: GeoTIFF, JP2000
  • Data must be orthorectified
  • Single image or tiled mosaic. 
     
• Basic Description of Data (required)
  • Projection
  • Location of Imagery (Lat/Long)
  • Date of Capture
  • Method of Capture (Satellite, Airplane, Balloon, Drone, etc)
  • ​​Approximate Resolution (cm/px)

Note: we do not accept oblique imagery. 

• 3D Models 
  • Format: .zip containing a single OBJ file
    • Includes MTL and Texture files (JPG or PNG) 
    • Approximate maximum vertices: 5 million
       
  • Basic Description of Data
    • Location of Imagery (Lat/Long)
    • Date of Capture
    • Method of Capture (Drone, Car, Helicopter, 360, Handheld, etc)
    • Approximate Resolution (cm/px)

Note: Please ensure the data does not contain personally identifiable information, such as license plates or faces. We cannot publish data that contains PII.

Water Boundaries

Example Water Boundaries Files

Water Sample

• Name of the water feature if available
• Feature Type of the water feature
  • Some examples include (but are not limited too): 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.

EV Charging Stations

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 2 types of format for EVCS data:

• Open Charge Point Interface (OCPI) 
• Google EV Location Feed Specification (GELFS)

Open Charge Point Interface (OCPI)

OCPI Example Files

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 8.3. Object Description in the OCPI document for more details about objects in this format.

Key to use of this format:

• 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?

Google EV Location Feed Specifications (GELFS)

GELFS Example Files

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 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 feed data must be encoded in UTF-8. Feeds outputs may be optionally supplied as zipped or tarred files to reduce file size.

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 one of these informations:

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.

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:  The specified charge point operator; or  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

Field Variables	Requirement Status	Comments
Field: latitude Type: Double	Required	Latitude of geo coordinate. The field value must be a valid WGS 84 latitude.
Field: longitude Type: Double	Required	Longitude of geo coordinate. The field value must be a valid WGS 84 latitude.

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

Field Variables	Requirement Status	Comments
Field: name Type: String	Required	Name of the host organization/business/entity
Field: address Type: Address	Optional	Address components for the host
Field: contact Type: Contact	Optional	Contact information for the 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

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.

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)

PortStatusEnum

Field	Enum Value	Comments
current_status	AVAILABLE	Available for Charging
	IN_USE	Currently being used
	RESERVED	Currently Reserved
	OUT_OF_ORDER	Not working
	UNKNOWN	Status is not known
	UNAVAILABLE	Unavailable due to another port being IN_USE on the same station.

 

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.

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

AuthenticationMethod Enum

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.

 

 

 

 

 

 

Bicycle Routes

Bicycle Route Examples

Bicycle Routes: Bicycle Routes Example

• Bike data is preferred as a shapefile or .KML/.KMZ
• 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.

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.

Biking Type Definitions

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

NON_TRAFFIC_TRAIL: A trail dedicated to bikes, pedestrians, etc; a route where cars and trucks are strictly not allowed. SEPARATE_TRAIL: Roads with a physical barrier separating bikes from cars, with the additional requirement that pedestrians are not allowed on a SEPARATE_TRAIL. BIKE_FRIENDLY_PEDESTRIAN_PATH: A pedestrian path / sidewalk that bicyclists are directed to use instead of riding on the road which is shared with cars and trucks.   BIKE_LANE: Roads with a dedicated painted lanes for bikes. BIKE_LANE_WITH_PEDESTRIAN_PATH: Same definition as Bike Lane, with the addition that bikes are also allowed to travel on the nearby pedestrian path / sidewalk. SHARED_ROAD: Roads where bikes travel on the same path cars also travel. SHARED_ROAD_WITH_PEDESTRIAN_PATH: Same definition as Shared Road, with the addition that bikes are also allowed to travel on the nearby pedestrian path / sidewalk. DISALLOWED: Roads/trails where bikes are strictly prohibited from operating on.

Reference table how to select the Bikes attribute

	Bike-only separate path is present for the road for cars/trucks	A road shared with cars/trucks and cyclists	Bike lane is present for the road for cars/trucks	Pedestrian facility such as sidewalk or pedestrian road is allowed for cycling
NON_TRAFFIC_TRAIL	No	No	No	Yes
SEPARATE_TRAIL	Yes	Yes or No	Yes or No	Yes or No
BIKE_FRIENDLY_PEDESTRIAN_PATH	No	No	No	Yes
BIKE_LANE_WITH_PEDESTRIAN_PATH	No	Yes or No	Yes	Yes
BIKE_LANE	No	Yes or No	Yes	No
SHARED_ROAD_WITH_PEDESTRIAN_PATH	No	Yes	No	Yes
SHARED_ROAD	No	Yes	No	No

Bike Fields/Attributes List

The following fields are useful for bicycle routes. "Required" is specific to Feature Type:

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)	Stone Way N.
RT_Name	Preferred	Bike Route Name	Burke-Gilman Trail or Cheshiahud Lake Union Loop
NEIGHBH	Optional	Neighborhood Name	Wallingford
CITY	Preferred	City Name	Seattle
STATE	Preferred	State (Two Letter Abbreviation)	WA
ZIP	Preferred	5-digit zip code	98103
CNT_NAME	Optional	County Name	King
SURFACE	Optional	Road Surface	Paved or Unpaved
SPEED_LM	Optional	Speed limit in MPH or KPH	55
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

Please Note: 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.

 

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.