> walker.t.brad...@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 

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 

* 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.

Christoph Hormann 

Tagging mailing list

Reply via email to