Draft: place: Store OSM tags and compute properties from them

James Westman requested to merge jwestman/gnome-maps:place-store-updates into main

Several changes to the way we store places.


  • Removed unused PlaceStore columns: icon, name, language
  • Fix a bug where the current location place would sometimes make its way into the store
  • Make our Place class derive from GObject rather than GeocodeGLib.Place. We didn't use any of its functionality, and it'll be easier to make further changes this way.
  • Switch place properties to camelCase. Now that they're not GObject properties we can't use camelCase and snake_case interchangably, and the rest of the codebase is mostly using camelCase.
  • Store all OSM tags for a place.

Place properties

Place properties are now mostly computed from OSM tags. Properties that are shown prominently in the UI (name, address, etc.) are loaded from the stored JSON as a fallback, but for most of them, there is no migration path. Instead, we consider places with no osmTags as stale and refetch them.

One effect of this is that we now localize a place's name on retrieval rather than on storage, so we can remove the language column of the place store.


Older versions of Maps will not load the place store if a new field is present in a place's JSON, so this is not a forward compatible change.

Next steps

Now that most of the place store columns are gone, the next step is to port to ListModel, which is just a list of objects. Type and Added will need to become Place properties.

The vector tile schema we're using (OpenMapTiles) doesn't always use the same tags as OSM, so we'll probably add a separate omtTags property. Vector tiles also don't contain OSM IDs (they could, for a ~10% size increase), so we'll probably want to do fuzzy matching instead of relying on the uniqueID property.

Edited by James Westman

Merge request reports