[WIP] Proposal: a "satellite" schema for cartographic properties

[jonahadkins]

The Proposal

We are proposing the creation of a "satellite" schema -- separate from the main Overture schema -- that defines a set of cartographic properties that will structure Overture datasets for cartographic display. This satellite schema is a crucial step toward achieving OMF's goal of "enabling the best map" in 2025.

This pull request introduces a new taxonomy of cartographic display properties that can be applied across Overture datasets. The schema definitions included in this PR describe nine display themes and ~100 display categories that map to key/value pairs in places. This logic could be extended to map to properties in Overture's buildings and base datasets, for example:

display_theme	display_category	places: categories property	buildings: class property	base: class property
health and safety	hospital	primary:hospital	hospital	hospital
transit	airport	primary:airport		airport

Property definitions

display_theme: a cartographic property that describes the top level display theme a business can be classified under. This is especially useful when displaying labels / icons for places or buildings in a thematic manner. For example, we might use blue for transit labels.

• arts and culture
• education
• food and drink
• parks and recreation (sub themes: sports, outdoor, indoor, water)
• transportation
• personal services. (sub themes: public, lifestyle, lodging)
• shopping
• health and safety

display_category: a cartographic property that describes the specific category a feature can be classified under. This is an extended classification under display_theme. For example, a fork & knife for restaurants or a bus for bus stops. Too many to list initially, but as implemented at Meta:

User needs and expectations

What we are describing here is a common categorization taxonomy (see below for examples from other major map vendors) that will help mapmakers easily convey the breadth of data offered by Overture in their maps. This will lighten the burden of discerning the 2000+ categories currently available, which has been called out as a pain point from Esri. cc @skmoore.

At Meta, we use a defined palette for our place iconography. We also use similar colors for college campuses, buildings, and icons to highlight their unique space on the map.

At Apple, they use a similar design language. They include a similar hue for medical campuses, buildings, and icons.

That design language also guides users when searching for places:

And of course, something similar at Google:

References

• https://lf-overturemaps.atlassian.net/wiki/x/cQf2
• https://lf-overturemaps.atlassian.net/wiki/x/2oE0AQ

Testing

Brief description of the testing done for this change showing why you are confident it works as expected and does not introduce regressions. Provide sample output data where appropriate.

TODO.

Checklist

Checklist of tasks commonly-associated with schema pull requests. Please review the relevant checklists and ensure you do all the tasks that are required for the change you made.

1. Add relevant examples.
2. Add relevant counterexamples.
3. Update any counterexamples that became obsolete. For example, if a counterexample uses property A but is not intended to test property A's validity, and you made a schema change that invalidates property A in that counterexample, fix the counterexample to align it with your schema change.
4. Update in-schema documentation using plain English written in complete sentences, if an update is required.
5. Update Docusaurus documentation, if an update is required.
6. Review change with Overture technical writer to ensure any advanced documentation needs will be taken care of, unless the change is trivial and would not affect the documentation.

Documentation Website

Update the hyperlink below to put the pull request number in.

Docs preview for this PR.

[vcschapp]

Some comments from 2024-08-21 schema meeting:

• Clearly valuable.
• Questionable whether we would call it "cartographic" or "core data" or "derived data".
  • Maybe what makes it "cartographic" is how heavily curated it is? Down to 8-10 categories.
• Like the normalization between buildings and places.
• Is it "core"?
• Would be beneficial for adoption.
• Could be (a) directly in data; (b) data sidecar; (c) shipped as code that derives from the data....

Nothing conclusive yet.

[vcschapp]

Conclusions: Let's review this and try to figure out what the final schema looks like, e.g. naming/placement. Also whether data is ready to go for buildings & places. This process should help resolve the "is it core?" and "is it a sidecar?" questions.

[jonahadkins]

@vcschapp cool - whats the best way to move fwd given uncertainty:

• should i proceed as if its part of the places schema?
• a file that contains the place category mappings to the cartographic ones?

[vcschapp]

This proposal as updated by Jonah in the last week or so makes a lot of sense to me. IMO we should try to move ahead with it without allowing Schema TF to be a blocker.

The only thing we should work on together with Schema TF IMO is linking features and avoiding redundancy, but I don't think those conversations should block just getting started. We have to start somewhere!