[Tagging] Extremely long Amtrak route relations / coastline v. water
osm at imagico.de
Tue Nov 24 15:12:05 UTC 2020
> walker.t.bradley at gmail.com hat am 24.11.2020 12:19 geschrieben:
> Is there a wiki page with a "wish-list" of things, with approximate costs where developers could post? There is likely a disconnect between those willing to pay, and those who could actually scrounge up the money. Thus, once consensus on what changes are needed has been achieved, we can scrounge for money?
There is certainly a deficit in comprehensive communication of the big tasks that are currently not being addressed in and around OSM-Carto. Part of the reason for that is that most OSM-Carto maintainers are doing their work there as a hobby and are not very interested in paid OSM-Carto work specifically. That also means someone paying a developer for implementing something for OSM-Carto does not guarantee you that this will make it into OSM-Carto. The maintainers still reserve the right to review changes for their suitability for the project. See also
where i previously discussed this being an issue for financing of OSM-Carto work.
But lets not beat around the bush too much - here from the top of my head a quick list of tasks that could be beneficial for improving the quality of the style:
* data preprocessing for low zoom level rendering of waterbodies and landcover. I have done some work on that, some of it was already in production use on openstreetmapdata.com, not all of it is currently open source but there is extensive writeup on my blog and website.
* importance rating features based on their context. This includes the widely discussed bay and strait rendering matter but also things like airports, populated places, peaks etc.
* boundary relation preprocessing. This includes things like topologically consistent line simplification, topological simplification, unification of different forms of coastal boundary representation.
* aggregation and importance rating of highway and railway networks based on connectivity functions for higher quality low zoom rendering. There is quite a lot of pre-existing work on the aggregation part but much of this does not scale or is robust enough for use on a global level of course.
* redesigning the POI and label layers of OSM-Carto for consistent prioritization. There are multiple different levels of radicalism at which this could be approached. This is the most important technical todo within OSM-Carto IMO that does not have direct use also beyond that style.
Regarding the volume of work required for these - that depends a lot on how you'd define the scope of work in each of the cases. In those cases where no or very little pre-existing work exists it is probably wise to start with a proof-of-concept development before actually planning and working on a production ready implementation.
More information about the Tagging