[OSM-talk] An open letter to OSMF board members.

[ndrw6]

On 06/06/2022 15:35, Hartmut Holzgraefe wrote:
> On 06.06.22 14:35, ndrw6 wrote:
>> but historically any changes to these tables they were difficult to 
>> deploy
> 
> to get even more off-topic: the "historically" part needs to be stressed 
> here. When you have enough storage space to share you can do an 
> osm2pgsql import using --hstore-all --hstore-only and then add views 
> that present the imported data with "virtual" columns as individual 
> styles expect.

Interesting. I don't know what the specific issue is/was but the OSM 
Carto style is mostly interesting because it is used as a default style 
for osm.org. So this is where styling meets the operations.

> now here things get more interesting ... here some meta data like 
> "population density" (would most likely require an external data source, 
> although some guesses could be made from building and road density?) and 
> "POI / feature density" could be added as an extra data source that 
> could be folded into SQL queries or with a little extra code work even 
> into Mapnik itself?

Some of this is already being done. With two caveats though - style does 
not know anything about the density of objects or their geographical 
relations, and the number of tags that could be used for inferring 
prominence is very limited. Also, in practice it is a very subjective 
topic - it is the user who decides what is prominent in a given 
situation. Sometimes it will be transport routes, sometimes PoIs, 
addresses etc. The same user will have different needs in the middle of 
a town center and in the countryside.

> And no, I don't have a clear concept or plan for this, just 
> brainstorming for now ...
> 

One way of relaxing these constraints would be by having multiple 
overlapping layers, selectable by the user. For example: a base map, 
base map annotations (in different languages), public transport, 
amenities (in different languages, potentially also split by amenity 
type). This would probably require some kind of vector tiles. 
Technically this could also be done with raster tiles + alpha blending 
as well but I don't know if the resulting quality would be satisfactory 
and if elements would not visually collide with each other.

As for the styling solution, neither SQL nor CSS is particularly well 
suited. SQL is far more difficult to develop with and to maintain, CSS 
is operating on a single element at the time and is not aware of its 
surroundings and context. Anything that is not resolved is passed to 
Mapnik, which makes very crude decisions on what gets displayed based on 
size of the labels etc. We would be better served by a language that 
combines ease of use and maintenance of CSS and query power of SQL. Any 
ideas?


-ndrw