broken basemaps

[carlhiggs]

I updated the basemaps in an attempt to get broader study region coverage, use updated data, and better document the approach ... but they ended up looking quite wrong. Not exactly sure why.

E.g. instead of city labels and general good representation, looks like this:

I attempted to use most up to date build and perhaps this was an error. The most up to date on https://maps.protomaps.com/builds/ was 2024-10-21 (today) and uses v4.0.1 spec; previously I used 2023-10-12 or so and that was v3.x.x spec. In fact, if I understand things rightly, v3 is the current support spec... so perhaps that is why things aren't working, because the format has changed and the library for reading and understanding the data (e.g. https://www.npmjs.com/package/pmtiles ) is still on v3? I don't know if that's the right way of thinking about this, but might explain why things don't appear right.

In any case, things are not right hence this issue.

I'll try rolling back to a v3 version --- last date of which was 2024-08-12 and see if that does the trick.

[carlhiggs]

This is as I thought above, and directly discussed in this thread:
protomaps/PMTiles#463
I haven't yet fixed this though (despite attempting to roll back to 2024-08-12 that was still v3...). More work to do.

[carlhiggs]

Unclear why, but the styling appears to have spontaneously regressed... Has CloudFront cache-ing reset? It is very strange. This issue appeared resolved about 24 hours ago, and now it is not, again.

[carlhiggs]

So the issue here in a sense was one of caching, but more deeply its one of need for better naming conventions: I have been calling the basemap layer naively 'jibe_basemaps.pmtiles' --- but this doesn't provide important information: date of OpenStreetMap used in construction (e.g. 20231012, or 20241012), or specification of PMTiles that also varies over this period (v3.xx or v4.xx). The latter is crucial as it requires different style definition files. I initially opened this issue after updating basemaps and inadvertently advancing the map data to v4 while style definitions lagged on v3. I then updated the map styles, however due to caching these hadn't kicked into effect. I backtracked the data to v3 and all appeared well, I thought, but caching was out of sync still --- ended up with v4 styles on v3 data and a failure all round for it work. (that is the gist of what happened, anyway)

Need to use both date and pmtiles schema in convention moving forwards, particularly for basemaps that rely on the stock layer style that matches the specification.

I will leave this issue open until at least the basemaps have their naming convention improved to include both date and specification version, and have confirmed that the configured style matches these.