To ensure data is processed quickly, make sure to submit data using the file types, schema, formats, and templates provided in this article.
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)
- Points of interest (POIs)
- Political and postal boundaries
- Roads, trails, and pedestrian paths
Other types of data
- Bicycle facilities
- Building footprints, property boundaries, and parcels
- Environmental Insights Explorer (EIE) custom boundaries
- Imagery (drone, overhead, and other images)
- Indoor mapping data format (IMDF)
- Restriction zones
- New housing developments
- Parks and protected areas
- Road closures
- Transit
- Trucking restrictions
- Water bodies
Common types of data
Address points (geocodes)
Geocodes example files
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.
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 |
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
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://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 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.
Political and postal boundaries
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
- 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:
|
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
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:
|
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)
- 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:
|
CATEG |
Preferred |
Contains the category of boundary data |
Examples:
|
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
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_NAME |
REQUIRED* |
Name of the unioned feature |
|
IND_Name |
REQUIRED* |
Name of the independent feature |
|
TYPE |
PREFERRED |
Type of boundary conventionally used |
|
ID |
PREFERRED |
Unique ID for the feature (not required) |
|
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)
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 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:
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 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:
- 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 |
|
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 |
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 |
|
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. |
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.
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 |
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
Data requirements
File Format: GeoTIFF (.tif, .tiff), PDF, PNG, JPEG
Partner steps to verify before uploading:
- Ensure there is an adequate description that accompanies your image upload
- Ensure that all the required attributes of the data that is included within your image are included - please see the associated content requirements section
- Ensure that the associated content requirements section of the data type you are submitting an image for does not prohibit a PDF/image submission (ex: Political datasets are not allowed to be submitted via a PDF/image)
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. |
|
|
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.” |
|
|
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. |
|
|
Building |
A Building describes a physical building structure associated with a Venue.
|
|
|
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. |
|
|
Fixture |
A Fixture models the presence and approximate physical extent of a moveable or semi-permanent physical asset possessing any of the following characteristics:
|
|
|
Footprint |
A Footprint models the approximate physical extent of one or more referenced Buildings. |
|
|
Geofence |
A Geofence models the extent of a geofence. |
|
|
Kiosk |
A Kiosk models the presence and physical extent of furniture that facilitates the distribution of products and/or services.
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. |
|
|
Level |
A Level models the presence, location and approximate physical extent of a floor area in:
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. |
|
|
Occupant |
An Occupant models the presence and location (via Anchor) of a business entity that trades goods and/or services. |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
Unit |
A Unit models the presence, location and approximate extent of a space. Extent may be characterized by: A barrier, such as a wall
|
|
|
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. |
|
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_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_EN |
Preferred |
English URL of the LEZ |
|
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_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
New housing development example files
Data requirements:
- Preferred file formats: Shapefile (preferred), 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:
- Roads: linestring features (no polygon, multipolygon, or point features)
- Sales Office: point features (no linestring, polygon, multipolygon features)
- Community Boundaries: polygon or multipolygon (no points or linestring features)
- Parcels: polygon or multipolygon (no points or linestring features)
- Geocodes: point features (no linestring, polygon, multipolygon features)
- Attributes:
- Road centerlines with street names (see Roads, trails, and pedestrian paths section for more info).
- Address points should be centered on the structures or parcels they occupy. Street number and street name are required, but include all address components if possible (Address points (Geocodes) section for more info).
Partner steps to verify before uploading:
- You can upload one zip file that includes all road centerlines, addresses, boundaries, and parcels. We can process these as a package.
- To learn how to prepare the data into a compatible format, review the Digitizing Plat Maps article.
- Community sales office names must be included in the POI shapefiles attribute table
- Public opening date should be included. This is the month and year that public routing through the housing development will be made available
Important to Note:
Parcels are accepted but not actively added to the map
Parks and protected areas
Parks and protected areas example files
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
Share your data feed to the Waze Partner Hub:
- Follow the instructions at Keep local drivers informed with the Partner feed from the Waze Partners Help Center.
- Initial processing is usually done within several days, but full implementation may be longer depending on content and schema compatibility, specific feature types, and geography.
- Updates and new reports are typically reflected on Waze within minutes.
- Closures provided to Waze through data feeds are propagated to Google Maps.
- New incidents should be visible on Google Maps approximately 15-25 minutes after being added to a feed.
- Updates to existing feed closures are not instantaneous and may currently take up to 1-2 hours to reflect on the map. For example, if a partner edits their feed at 7:29 PM to change the re-open time for a road from 9 PM to 7:30 PM, it will still take an hour or more for the road to re-open on Google Maps.
Important to Note:
- If your feed is published in your Open Data Portal, we may be able to also support it.
- Most closures can be processed successfully, but some may not be. If a particular closure doesn't appear on Google Maps, or if you want to be certain in advance that it will, follow the procedure below to submit specific closures.
Upload a specific road closure
You can submit specific road closures to Google Maps as uploads to GMCP.
GeoJSON, JSON, or XML files
Data requirements:
-
Each road closure or restriction is required to have:
- A type field detailing the specific type of restriction/closure
- A polyline field that correlates to the road segment affected by the restriction/closure
- A start_time and end_time field that correlates to the road segment affected by the restriction/closure
- A direction field detailing the direction of the restriction/closure
Partner steps to verify before uploading:
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 |
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:
|
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:
|
Transit
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
Data requirements:
File format: SVG files only
Partner steps to verify before uploading:
Ensure the associated agency name is included in your data submission.
Trucking restrictions
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:
|
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:
|
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.