The HERE UniMap Content Factory- What it means for private map making and Geo-enabled products

In recent weeks, we at HERE have been talking a lot about UniMap. As a basic concept, it makes a lot sense: build a framework that unifies HERE’s content catalog into an integrated referenceable dataset, that is a near real-time digital representation of the world (ergo a map); but how is this achieved and what does this mean to the day-to-day Geo-developer or geospatial practitioner?  

This blog post and the below video serve as a basic primer to demystify the core concepts of UniMap by explaining how it is an enabler to create, update and use maps, as well as Geo-enable and enrich custom products. 

Map Making Challenges  

To build off the video, it is worth noting some of the fundamental challenges of map making that UniMap aims to solve:  

• Data sources are heterogenous: Varying by accuracy, coverage, semantics, structure, update frequency, business terms and usage intentions 
• Country-level data has unique specifications 
• Not just building maps but also keeping them up to date, factors such as backwards compatibility and difficulties making updates/changes 
• Automation is correlated to the need for faster update cycles 
• Global coverage necessitates managing huge data lakes 
• Autonomous driving use cases require higher accuracy and additional map features 
• Escaping content silos: all features must be spatially aligned and released at the same frequency to lessen these challenges

Enter The Content Factory 

The video points out that what we have built in UniMap is a content factory where automation powers the need for faster updates while focusing on reducing latency and the overall friction by aligning datasets in the pipeline. UniMap is enabled by interoperability, and in the context of map making and Geo-enablement, both allow the creation of timely (real-time is the standard), and accurate geospatial assets. Technological advancements are allowing us to integrate data from many sources to create maps, apps, APIs and other geocentric outputs that transcend industry. 

For private map making and “BYO” workflows (like data!) practitioners want and need to be able to seamlessly integrate multiple datasets and systems during the creation of accurate and detailed maps, apps, and solutions. Traditional data sources are often not homogenous and the video highlights what we all know about making maps: there is variability in the accuracy, coverage, semantics, structure, and update frequency of data. 

UniMap acknowledges that the world and its data is not consistent. Building a map? Not a problem. Keeping it current, well that can be a challenge. When it comes to the need for backwards compatibility, things can get a little sticky. Automation is the means for quicker updates in a worldwide coverage paradigm. By leveraging various tools and resources--including interoperability--we can streamline these workflows and achieve greater efficiency while enhancing the quality and value of the final product. 

More on how it works 

UniMap as a highly automated process merges and aligns millions of sensor data in a way that can be constantly updated. Each content domain acts as a source of truth for its features, for example, HERE Imagery and Topography or the HERE HD Live Map. When we detect a change in physical space, that change becomes visible on the map within 24 hours. As a content factory fueled by ingesting and conflating diverse types and sources of data, we need a data model. This is where interoperability comes in.

The video gives a great overview of the format agnostic data model called The HERE Map Object Model (MOM) and how it represents map data in a hierarchical data structure. Interoperability in this context means that the same stack of tools, automation, validations, and pipelines can now be used for all products. Therefore, MOM is an enabler for UniMap, while UniMap extends MOM to serve more use cases. 

Diving deeper into the Map Object Model (MOM) 

To get in the weeds for a moment, MOM uses an in-house generated modeling language called “SHIFT” where the semantic model is captured. This content is typically represented in GeoJSON format, and unlike with previous content management, content is no longer stored in different repositories, but rather is organized by layers all within the same physical location. As the word “object” in MOM indicates, it is an object-oriented model, meaning that attributes are not dispersed into multiple interlinked tables but are instead stored with a particular object, using a hierarchical data structure. This has pros and cons, but dramatically helps with flexibility, scale, and performance, especially considering large datasets.  

Note: A data model is not the same thing as Data Specifications. We have a clear process in place on how to derive Data Specifications from Product Requirements. While the model needs to physically support all features described by the Data Specifications, the latter also provides information on inclusion rules, accuracy, defaults, and mandatory fields to be filled. Bottom-line, the Data Model follows Data Specifications which again follow Product Requirements. 

In the end, MOM provides a consistent and unified representation of the real world and stores and manages various features and attributes of a map, such as roads, buildings, and points of interest. That is, the data in our unified map (UniMap) is modeled in the Map Object Model (MOM). MOM is also used to support HERE's mapping and location-based services and provides builders access to unified map data in a single build environment where everyone can choose it, augment it, and extend map products and services (even with their own privately held data) easily while predicting quality to create new products. 

This also means conflating your own data and apps with HERE data to be delivered via platform services. All of this is anchored by fresh data that is authoritative, accurate, and semantically consistent (combines SD, HD, ADAS). Flexibility in map making is essential and BYOD further will enable mixing & matching with private data to build custom solutions. 

Tying it together

If you have made it this far, we can broadly summarize the objectives of UniMap as follows: 

• Provides a unified and standardized format for data (see MOM) and semantic map consistency
• It provides quicker map updates and spatially aligns vast amounts of data for maximum accuracy
• Reduce latency through feedback loops
• Supports multiple data formats with more being added
• Aligns product release frequency 

UniMap seeks to redefine “map making” through: 

• Scaling the cost of making maps with the ability to optimize your data by conflating or enhancing attributes (enrichment)
• Harnessing vast amounts of data sources and AI/ML algorithms 
• Support change management with near real-time product updates
• Reducing the complexity of managing and updating maps 

MOM (Map Object Model) aims to: 

• Be an enabler for UniMap by adding common semantics to a standard GeoJSON structure (aligning disparate data and version) in a "live" map bound by data specifications 
• Be an enabler for your use cases and content making them available in our tools and services 
• Interoperability as a single source of truth for content products with version stability, a standard for “BYO” use cases 
• Creates a rules based-Unique ID’s for spatial objects, the relationship of those objects and their attributes 

Lastly, you can explore the visualization shown in the video below, and keep an eye out for future blog posts on the evolution of UniMap!