Production stylesheets use staging tiles

[1ec5]

As fo OpenHistoricalMap/map-styles@b501f73deba7cd3837d32da266efaaf3c38401bc, production stylesheets such as Historical and Woodblock are pointing to vector tilesets on vtiles.staging.openhistoricalmap.org.

This is causing some issues that otherwise wouldn’t be noticeable in production. For example, the wiki portal is currently showcasing Palmanova, which appears fine on the main site but blank and watery on the wiki.

Under the hood, requests for tiles at z16 are failing with HTTP error 500. But the same requests on the production tile server work fine.

[danrademacher]

Ah, this goes back to a debate about which tiles we should be using for design development. And the answer is "it depends" (testing new tile attributes needs staging at first, styling best data needs prod)

Ruben's recent improvements to map style deployment means for the website it no longer matters. At the point of deployment, the correct endpoint is inserted.

But the stylesheets remain in use as production end point for other consumers.

I wonder if just need a better way -- like at the point of deployments put some known working copies on S3 at a nice URL and then move away from any live linking to the map-styles repo for production applications.

Or we need a thorough staging and prod flow in the map-styles repo itself

[Rub21]

The script works on the following way 👇

• Read /var/www/public/map-styles/main/main.json and Write in /var/www/app/assets/javascripts/ohm.style.original.js
• Read /var/www/public/map-styles/rail/rail.json and Write in /var/www/app/assets/javascripts/ohm.style.railway.js
• Read /var/www/public/map-styles/woodblock/woodblock.json and Write in /var/www/app/assets/javascripts/ohm.style.woodblock.js
• Read /var/www/public/map-styles/japanese_scroll/ohm-japanese-scroll-map.json and Write in /var/www/app/assets/javascripts/ohm.style.japanese.js

in the process of writing the script updates the endpoint(by default the map-styles has staging endpoint and then the script updates to production) https://github.com/OpenHistoricalMap/ohm-deploy/blob/main/images/web/update_map_styles.py

But i see the those endpoint are still in pointing to staging, Are we somewhere those styles?

• https://www.openhistoricalmap.org/map-styles/main/main.json
• https://www.openhistoricalmap.org/map-styles/rail/rail.json
• https://www.openhistoricalmap.org/map-styles/woodblock/woodblock.json
• https://www.openhistoricalmap.org/map-styles/japanese_scroll/ohm-japanese-scroll-map.json

in case we need those endpoint to production, I can update the script to overwrite the endpoints to production.

[danrademacher]

Ah so if Ruben added to his script to overwrite those as well, then we could move to all external style consumers pulling from real OHM.org URLs.

That sounds ideal to me.

[vknoppkewetzel]

AH my understanding when I made the change "on our end" was that it didn't matter if I used staging or "not staging" as it would ultimately get overwritten in production.

It sounds like Ruben will be updating scripts on his end, so I'll untag myself here, but I can update map-styles to "not staging".

edit: Done ✅

[Rub21]

@vknoppkewetzel , just make sure that you that you are using staging endpoint on styling vtiles.staging.openhistoricalmap.org later the script will update that to production in the deployment process. the script will look for and replace 👇

For production

look for vtiles.staging.openhistoricalmap.org and replace by vtiles.openhistoricalmap.org look for openhistoricalmap.github.io and replace by www.openhistoricalmap.org

For Staging

look for openhistoricalmap.github.io and replace by staging.openhistoricalmap.org https://github.com/OpenHistoricalMap/ohm-deploy/blob/staging/images/web/update_map_styles.py

[vknoppkewetzel]

got it. will revert styles back to staging ✅

Done

[1ec5]

Once this issue is fixed, should both https://openhistoricalmap.github.io/map-styles/main/main.json and https://www.openhistoricalmap.org/map-styles/main/main.json point to the production tiles? We have quite a bit of documentation that points to openhistoricalmap.github.io, but I can update it to www.openhistoricalmap.org if necessary.

[danrademacher]

As of now, we have these files on the OHM website and those will be the most stable style endpoints, always pointing to production:

• https://www.openhistoricalmap.org/map-styles/main/main.json
• https://www.openhistoricalmap.org/map-styles/rail/rail.json
• https://www.openhistoricalmap.org/map-styles/woodblock/woodblock.json
• https://www.openhistoricalmap.org/map-styles/japanese_scroll/ohm-japanese-scroll-map.json

So we need to update docs and tell all consumers that these are the endpoints they should use.

[1ec5]

OK, time to reprise https://github.com/OpenHistoricalMap/issues/issues/792#issuecomment-2151150911:

• [x] OpenHistoricalMap/leaflet-ohm-timeslider-v2#13
• [x] OpenHistoricalMap/ohm-embed-1yr@d8d7f2362bfd87521c4559cf59885a1282e52621
• [x] Overpass Ultra defaults
• [x] OpenStreetMap Wiki
  • [x] Documentation for direct embeds on websites
  • [x] Documentation for Overpass Ultra settings
  • [x] Example Overpass Ultra query
  • [x] Announcement to Web developers
  • [x] Maps gadget (including OHM portal)
• [x] AARoads Wiki maps gadget

Unfortunately, I can’t make further progress on these changes, because www.openhistoricalmap.org is blocking connections from external websites to the map-styles/ path: #829.

[1ec5]

All set.