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
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
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: |
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
Address Points (Geocodes)
Geocodes Example Files
- 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.
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 |
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
- 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
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:
|
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
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 |
- 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
-
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)
- 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
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)
- Format requirements
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)
- 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)
- Format: .zip containing a single OBJ file
Water Boundaries
Example Water Boundaries Files
- 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)
OCPI Example Files
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
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:
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).
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 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:
- 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 |
|
Field: network_brand_name Type: string
|
Required |
Example: WonderCharge
|
Field: network_name Type: String
|
Required |
|
Field: contact Type: String
|
Required |
|
Field: coordinates Type: Coordinates
|
Required |
|
Field: address Type: Address
|
Required |
|
Field: location_hint Type: string
|
Optional |
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 |
|
Field: host Type: Host
|
Optional |
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) |
|
Field: onstreet_location Type: boolean
|
Optional |
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 |
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 |
|
Field: last_updated Type: String
|
Required |
|
AccessRestrictionEnum
Field |
Enum Value |
Comments |
---|---|---|
access_restriction |
PUBLIC |
|
CUSTOMERS_ONLY |
|
|
GUESTS_ONLY |
|
|
EMPLOYEES_ONLY |
|
|
STUDENTS_ONLY |
|
|
RESIDENTS_ONLY |
|
|
HOME_CHARGER |
|
|
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 |
|
Field: weekday_end Type: Integer |
Optional |
|
Field: hour_begin Type: String |
Optional |
|
Field: hour_end Type: String |
Optional |
|
Contact
Field Variables | Requirement Status | Comments |
---|---|---|
Field: operator_phone Type: String |
Required |
|
Field: operator_website Type: String
|
Optional |
|
Coordinates
Field Variables | Requirement Status | Comments |
---|---|---|
Field: latitude Type: Double |
Required |
|
Field: longitude Type: Double |
Required |
|
Address
Field Variables | Requirement Status | Comments |
---|---|---|
Field: address_string Type: String
|
Optional |
|
Field: street_number Type: String |
Optional |
|
Field: street_name Type: String |
Optional |
|
Field: locality Type: String |
Optional |
|
Field: admin_area Type: String |
Optional |
|
Field: postal_code Type: String |
Optional |
|
Field: country_code Type: String |
Required |
|
Field: language_code Type: String |
Optional |
|
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 |
|
Field: label Type: String |
Optional |
|
Field: coordinates Type: Coordinates |
Required |
|
Field: ports Type: Ports |
Required (array) |
|
Field: notes Type: String |
Optional |
|
Field: url Type: String Optional |
Optional |
|
Port
Field Variables | Requirement Status | Comments |
---|---|---|
Field: id Type: String |
Required |
|
Field: connector_type Type: ConnectorTypeEnum |
Required |
|
Field: power_kw Type: Float |
Required |
|
Field: charging_mechanism Type: ChargingMechanismEnum |
Required |
|
Field: port_status Type: PortStatus |
Optional |
|
Field: last_updated Type: String |
Required |
|
Field: authentications Type: Authentication |
Required (array) |
|
Field: notes Type: String |
Optional |
|
Field: reservable Type: boolean |
Optional |
|
Field: wheelchair_access_only Type: boolean |
Optional |
|
Field: dedicated_parking Type: boolean
|
Optional |
|
ConnectorTypeEnum
Field |
Enum Value |
Comments |
---|---|---|
connector_type |
WALL_OUTLET |
|
J_1772 |
||
MENNEKES |
||
CHADEMO |
||
CCS_TYPE_1 |
|
|
CCS_TYPE_2 |
|
|
TESLA |
|
|
GBT |
ChargingMechanismEnum
Field |
Enum Value |
Comments |
---|---|---|
charging_mechanism |
CABLE |
|
SOCKET |
|
PortStatus
Field Variables | Requirement Status | Comments |
---|---|---|
Field: status Type: PortStatusEnum |
Required |
|
Field: start_time Type: time |
Optional |
(e.g. 2020-10-01T19:20:30+01:00) |
Field: end_time Type: time |
Optional |
|
PortStatusEnum
Field |
Enum Value |
Comments |
---|---|---|
current_status |
AVAILABLE |
|
IN_USE |
|
|
RESERVED |
|
|
OUT_OF_ORDER |
|
|
UNKNOWN |
|
|
UNAVAILABLE |
|
Authentication
Field Variables | Requirement Status | Comments |
---|---|---|
Field: authentication_id Type: AuthenticationMethod.ID |
Required |
|
Field: payment_required Type: Boolean |
Optional |
Note: it's possible for charging to have no cost, but still require authentication. |
Field: authentication_urls Type: AuthenticationUrl |
Optional |
|
AuthenticationUrl
Field Variables | Requirement Status | Comments |
---|---|---|
Field: port_auth_url Type: String |
Optional |
|
Field: station_auth_url Type: String |
Optional |
|
Field: location_auth_url Type: String |
Optional |
|
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 |
|
Field: authentication_methods Type: AuthenticationMethod |
Required (Array) |
|
AuthenticationMethod
Field Variables | Requirement Status | Comments |
---|---|---|
Field: id Type: String |
Required |
|
Field: authentication_method Type: AuthenticationMethod Enum |
Required |
|
Field: description Type: String |
Optional |
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 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
|
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:
|
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.