Missing street

[pietervdvn]

Location

https://dev.mapcomplete.org/rainbow_crossings.html?z=15.5&lat=50.831537559289785&lon=4.65924188029669

Missing segments:

https://www.openstreetmap.org/way/283107405
Screenshots

Required information

• Browser: LibreWolf (Firefox), Chromium; Ubuntu
• Renderer version: MapLibre GL JS 4.1.1
• Tileset version and source: Protomaps hosted, 14/08/2024
• Style JSON or NPM version: MapComplete/Protomaps Sunny, Protomaps Light

[nvkelso]

Hey @pietervdvn great to see StreetComplete using Protomaps and the Tilezen schema providing you some continuity in that migration :)

I wonder if this was a data issue for some period of time until about 3 months ago? The history of that way shows it was tagged highway=construction, construction=tertiary for a few months. Right now we block pass thru of construction and other "not drivable" elements, maybe that should be revisited. Certainly kind=construction is present in mainline Tilezen docs indicating we're not yet at feature parity for this element in Protomaps.

In the meantime, @bdon I see the tileset being reported as Protomaps hosted, 14/08/2024 in this issue description – but this smells like a data issue where the planet was actually 3 to 8 months old even though the tile cut Planetiler schema code might be prod from 2024-08-14?

[pietervdvn]

Hi,

This is MapComplete, not StreetComplete.

I noticed the issue today and thought that the hosted protomaps does daily updates?

[wipfli]

https://maps.protomaps.com/#map=16.27/50.831308/4.660011&theme=light&tiles=https://build.protomaps.com/20240814.pmtiles has the road.

[nvkelso]

@pietervdvn Doh, my mistake! So many good projects out there, including yours :)

@wipfli thanks for the debug link, very helpful!

So the question is why is the map style not configured with the correct tile build...

I see https://dev.mapcomplete.org/assets/sunny.json points at

tiles": [
        "https://api.protomaps.com/tiles/v3/{z}/{x}/{y}.mvt?key=2af8b969a9e8b692"
      ],

@bdon Perhaps this is an issue with the public API not using tiles from that day's PMTiles build either from a config or other caching problem?

[bdon]

Correct, the public API does not use the daily build as of right now, it's updated intermittently.

One main benefit of the public API vs. daily build is more frequent cache hits, which demands a longer cache TTL. What would be the ideal update cadence?

[nvkelso]

There are two axis on release cadence I think about:

• Code changes
• Data changes

For data freshness, monthly is good default if on a chron job. Quarterly if p50 latency cost/benefit is not good otherwise. (Year is too long, week is too quick for a free service, and even for most paid services it takes 3 to 7 days to see your p50 stabilize globally across timezones for a mix of daily, weekly, and monthly active users after a release in my experience.)

But I wonder if cache bust should also be part of code release strategy? What's the moire pattern between releases and chron?

Looking at https://github.com/protomaps/basemaps/commits/main/CHANGELOG.md history we're releasing new code every 1 to 6 months without enough regularity to have a statistically significant median. (Note: the upstream OSM data is changing at least daily even if the code isn't changing.)

A proposal:

• Monthly data builds on a chron
• Weekly chron that looks for new code release tag and if new also promotes a relevant PMTiles daily "staging" build to prod X/x/y tiles endpoint

Reasoning as follow:

If there's a major version code release I'd expect the cache to be busted for that same day or within a week.

If a minor version, then within a week.

If a bug fix patch version, then within a month during the next data update monthly chron.

Note: we should probably get more delivery about tagging during release process...

A week is generally as long as someone who's impatient for code or data changes to wait before the reward feedback loop is broken and they move on.

[pietervdvn]

As a (free) data user, a monthly update cycle is definitively fast enough; a weekly would be even better. But then again, I'm a free user so I can't complain.

However, it would be nice that the update (non)frequency would be documented somewhere in the FAQ.