- Products ProductsLocation Services
Solve complex location problems from geofencing to custom routing
PlatformCloud environments for location-centric solution development, data exchange and visualization
Tracking & PositioningFast and accurate tracking and positioning of people and devices, indoors or outdoors
APIs & SDKsEasy to use, scaleable and flexible tools to get going quickly
Developer EcosystemsAccess Location Services on your favorite developer platform ecosystem
- Documentation DocumentationOverview OverviewServices ServicesApplications ApplicationsDevelopment Enablers Development EnablersContent ContentHERE Studio HERE StudioHERE Workspace HERE WorkspaceHERE Marketplace HERE MarketplacePlatform Foundation and Policy Documents Platform Foundation and Policy Documents
- Pricing
- Resources ResourcesTutorials TutorialsExamples ExamplesBlog & Release Announcements Blog & Release AnnouncementsChangelog ChangelogDeveloper Newsletter Developer NewsletterKnowledge Base Knowledge BaseFeature List Feature ListSupport Plans Support PlansSystem Status System StatusLocation Services Coverage Information Location Services Coverage InformationSample Map Data for Students Sample Map Data for Students
- Help
Marketplace Object Model
Within the GeoJSON "properties", the Marketplace Object Model can be logically categorized into the following sections:
- Metadata – such as timestamps, type, and version information (mandatory).
- Feature-specific payload - such as road segment properties (mandatory).
- System-specific extensions – such as extended Carto properties (optional).
All features that are part of the Markeplace Object Model can, in theory, reference any other feature in order to ensure maximum flexibility. Only when relations are essential for the feature definition are the references specifically spelled out.
References may be represented:
- In "short notation" (Layer name + feature Type + ID).
- As "fully qualified" with uri for the layer.
- In their "resolved form", as in with the referenced object embedded in the parent object.
The "resolved form" representation enables the design principle that every object will be de-normalized and self-contained as much as possible.
Common metadata
Independent from the payload specific to each feature type, a set of properties carrying metadata is common to all objects found within the HERE Map Layers collection of catalogs.
General
| Attribute | Value | Description |
|---|---|---|
| id | Object identifier. | |
| box | An optional bounding box. | |
| geometry | The object geometry. This may be null for non-spatial features. | |
| Type | "Feature" | Clients may be able to handle the type "FeatureCollection,” but this is out of scope of the objects. |
- category specifies a generic "free text" subcategory description for the feature. To be used for display only.
- featureType, such as Place, Roadsegment, and Building.
- isoCountryCode identifies the ISO-3166 Alpha-3 code of the country. This is included for all countries. For more information about ISO-3166 Alpha-3 codes, refer to the International Organization for Standardization.
- Map Objects metadata ("properties"."@ns:com:here:mom:meta"):
- hashPayload - this is a SHA1 checksum over the payload of the object. Metadata is excluded from the calculation.
- createdTS - Timestamp of the initial creation of the object using the RFC-822 time zone.
- lastUpdatedTS - Timestamp of the last modification of the object.
- lastReviewedTS – Timestamp of the last review of feature.
- lastUpdatedBy – An optional token identifying the user who last modified the object.
- modelVersion – Identifies the Marketplace Object Model version.
- sourceId – Source of the data.
- layerId – Identification of the data layer the feature is published in.
- All metadata is optional and is not published if unknown.
Feature dependencies
The following figure provides a global overview of the defined features that are part of the feature dependencies map.
