It’s been mentioned that Streets GL now uses manually-updated vector tiles instead of real-time Overpass queries. However, the option to configure Overpass API endpoints still exists. Is it possible to re-enable their use as a user? Otherwise, are they even used for anything?
As mentioned above, being able to see your changes soon after you make them was a key feature of Streets GL for editors, so it would be great if this functionality is made available one way or another.
Is there a clear overview of supported features? And which parameters are considered for these features?
For example: natural=tree is supported with parameters height, leaf type.
There is no description and val breakdown yet, but they are listed in the file Streets GL | Projects | OpenStreetMap Taginfo https://github.com/StrandedKitty/streets-gl/blob/dev/docs/taginfo.json
The source code is https://github.com/StrandedKitty/streets-gl/tree/dev/src/lib/tile-processing/vector/qualifiers/factories/osm/helpers
I’ve been working on porting a more robust straight skeleton implementation over to Wasm, see GitHub - StrandedKitty/straight-skeleton: Straight skeleton algorithm implementation in TypeScript
This new implementation is already available on streets.gl.
The previous version failed really often on complex polygons, so straight skeleton-dependent roof shapes like hipped, gabled, gambrel, mansard sometimes had to fall back to flat roof shape.
The new version should work fine for almost any kind of building footprint, no matter how complex. The only downside is worse performance, which might be a problem when loading tiles with lots of roofs that need to compute straight skeletons. I’m planning on moving this straight skeleton generation logic over to the tile generator for it to be processed offline, this would be the most optimal solution.
Some screenshots with comparisons:
wow this looks fantastic! thank you for your work 
The map is not updated for some weeks now. It’s a shame because this 3D renderer is really good.
Does anybody know how the process for updates works?
If it would be possible to use “live” data again it would be terrific.
It’s manual if I remember correctly.
Who can do it?
Pretty please, @StrandedKitty , update the tiles. Last update was on August 8 for my area.
Thanks for such a great tool!
Is it still possible to switch of the server cashe and generate the tiles in the browser client?
Could the client upload an actual tile to the server?
What is the limiting factor regarding tile updates? I’m also eagerly waiting for an update. F4Map seems to have them approx. daily, which I think is a good baseline.
Can it be quantified in terms of money/financial support what would be needed that streets.gl could run daily, automatic updates?
(related: Add Button to retrieve and render current data · Issue #143 · StrandedKitty/streets-gl · GitHub)
Have effectively abandoned visiting SGL and returned reviewing new complex building renders on F4 simply because last SGL update interval was like 5-6 weeks and the present has again not updated since Sept.24, a far cry from the 1-2 weeks which was indicated after the tile updating process change.
Such a magic button which “manually” (client-side) reloads data from Overpass would be the silver bullet though, especially for isolated edit/view cycles. I don’t have a first clue about Typescript, but hopefully it will make for a beginner-friendly PR!
When it comes to vector tiles, I don’t think there’s a cheap solution to generating them. It’s either paying $5-10 per update or investing into a powerfull machine which most likely won’t happen.
The old code that handled Overpass API data needs to be ported to the most recent app version so that some feature can be pulled directly from OSM while problematic large features like water bodies, fields, etc. are pulled from vector tiles. I’m not sure when I’ll be able to implement this.
Plus, there are a couple of GPU-related problems that are quite high priority:
I don’t wish to seem I am being negative towards @StrandedKitty, as it’s awesome what we see as fruits of your efforts.
I do, however, believe there IS a solution to “this” (currently bad performance on Apple Silicon). It would be a real analysis of your code stack and some optimizations and/or rewrites for Apple Silicon. That’s a tall order, I know, and many wouldn’t consider it “straightforward” (I’m a former Apple software engineer and it doesn’t seem so, though I don’t know details of your stack). There is a solution, it’s a deep, deep one, given what you are doing now to implement what we see.
So, not insurmountable, though a tall mountain to climb, or a deep chasm to look into and shout an echo.
GPU coding of the sort that is happening here can be tricky stuff, but it is possible to craft code to exploit specific hardware. Possible? Yes. Difficult? Yes.
Fact check:
I generate planet-scale vector tiles twice a day for pennies using an old laptop.
That sound very good! And just as a reference, stronger hardware is able to keep up with minutely updates of vector tiles: Minutely updated map — Jochen Topf
I understand it might be problematic for @StrandedKitty themselves, but if the hardware is the issue, if they issue a call for help, I think there is a high chance that some people might offer some high-bandwidth connected hardware to be used for that purpose.
Implementing this however would solve most problems for people wanting to use streets.gl as QA to check their work and provide fast feedback. I understand that there are other important rendering issues; but I think fixing this regression would make many people very happy.
70 days since. What’s off the boil in the tile cooker?
