[WIP] Proposal: Cartographic Display Categories for Places + Buildings

[jonahadkins]

Description

A common use case when using Places data in a base map is displaying thematic icons to quickly convey the type of place it is. While the specific design of icons and colors that are used can be specific to cartographic preference, a common categorization can help map makers easily convey the breadth of Places data offered by Overture in their maps.

For instance at Meta we use blue for transit, red for medical, teal for entertainment, and so on.

At Apple, they use a similar design language.

That design language also guides users when searching for places.

And of course, something similar at Google.

The Proposal

This pull request would introduce display_theme and display_category as optional cartographic properties. This PR, when complete, would introduce 11 themes and 160 categories that map to the taxonomy linked here. This should lighten the burden of discerning the 2000+ categories currently available, which has been called out as a pain point from Esri. cc @skmoore

display_theme: An attribute that describes the top level 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, blue for transit labels.

Acceptable Values:

• aquatic
• civic
• education
• entertainment
• food
• medical
• other
• recreation
• retail
• service
• transit

display_category: An attribute that describes the specific category a business can be classified under. This is an extended classification under display_theme. When displaying labels / icons for places or buildings in a thematic manner, this attribute can help when displaying a specific icon. For example, a fork & knife for restaurants or a bus for bus stops.

Acceptable Values:

• beach
• office_public
• landmark
• stop_rail
• seafood
• casino
• park_dog
• and many more...

These new thematic categorizations would serve as the starting point for, and if adopted, can be adjusted as needed from member / user feedback.

TODO.

Reference

List of relevant links to GitHub issues, PRs, and other documentation.

1. TODO.

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?