Thanks. Yes, there is a plan to figure it out. Do you have some measured time, how long it takes to regenerated osm-lakeline on your use case?

I have started doing a run from a planet.osm.pbf-loaded database on AWS (m5.24xlarge, 96 cores) and also on local machine (AMD Ryzen9 3950x, 12 cores) to get some numbers. Will post them when they are done.

The AWS instance finished generating the centerlines (36370 of them in total) in 132 minutes. Will check the local machine tomorrow.

The local machine finished in 155 minutes with 37544 centerlines (planet.osm.pbf is 2 months newer than AWS instance's).
For reference the AWS instance needed 8 days to run quickstart.sh down to zoom level 14, and the local machine needed 31 days.

@ache051 ideally we should NOT use the lakeline centerlines like we do now. My long term hope was to get rid of it entirely, and instead use the usual PostGIS functions to compute it, possibly generating a materialized view if needed for performance reasons. The current implementation adds significant complexity to the project's ecosystem.

@nyurik I agree with you 100%. Exporting to shapefile then generate lines is cumbersome. At the time being though it is a stop gap solution for my project. If anybody thinks there is merit, then I will look at if ST_ApproximateMedialAxis can do the trick.
I have posted the centerlines generated from last night's run for your amusement.

@ache051 this looks like a perfect path as far as I'm concerned! Will gladly review/discuss/merge any PR work in that direction, and I'm sure @TomPohys will agree with me on this :)

Great! I will dive in a bit more seriously, but here are the results from my crude attempt with PostGIS internal functions (green is from last night's run, red is from PostGIS). A lot of work to be done with voronois...

LOL, the last one is just priceless... I keep thinking what kind of an animal it reminds me of... some dinosaur I suspect :D But the last image does highlight the broken nature of the PostGIS algo it seem? The docs say that ST_ApproximateMedialAxis will use ST_StraightSkeleton if SFCGAL is not available - was that the case in your examples?

Hah! It looks like my 2 years old's drawing!
You are right about the SFCGAL part. I didn't want to modify the postgis installation so adapted some of the codes from this stackexchange post. I am going to look at the code closer tomorrow.

Is the SFCGAL extension problem? There are some licence blockers? Some comments in openmaptiles/openmaptiles#1150 (comment)

Anyway, thanks for looking at it!

Not much that it is a problem. It's just that I already have a planet-loaded database and didn't want to fiddle around with it. But if there are other components that need SFCGAL, then I am happy to build a docker image and try it out.

@TomPohys I noted in openmaptiles/openmaptiles#1150 (comment) with link to the original source documentation, that there is no issue with using the SFCGAL extension from a license perspective. Also, it is the same licensing as PostGIS itself, so if PostGIS is OK, then so is SFCGAL :)

@ache051, it would be very useful if we had the SFCGAL extensions available. The lack of this extension is a blocker for #1150 and #380.

No problem to add SFCGAL into openmaptiles-tools/postgis docker. PR is welcome.

I have been chipping it away slowly. ST_StraightSkeleton ST_ApproximateMedialAxis (edited) does a better job than my initial effort. But in order to replicate what Lukas and Ungarj did (routing between the furthest nodes in a network built by Voronois with maximum angle of turns defined), we will also need pgrouting enable as well. I have built a modified openmaptiles-tools/postgis with pgrouting enabled and will try to implement Ungarj's inside Postgis. To be honest I have no idea whether it is the best method to construct centerlines, I just replicate 😛 Comments welcome.

@klokan might know the most about the actual math needed for this

My opinion on the overall approach -- it is better to have a "good enough" solution for lake centerlines as part of the OMT SQL than to have a "perfect" solution that uses a complex external processing outside of the project. The SQL can be incrementally improved in subsequent pull requests, whereas the external project is essentially frozen, as it requires far more work to make any changes.