[OSM-talk] OpenStreetMap Carto design

Daniel Koć daniel at xn--ko-wla.pl
Fri Jun 29 15:04:34 UTC 2018


W dniu 29.06.2018 o 11:06, Christoph Hormann pisze:

> I did not make any assumptions on avant-garde being a positive thing
> here.  In fact for a long time i have clearly said that i think that 
> OSM map design should become more pluralistic.  

It is now and it does not go away, so I still see no crossroad - just
more or less active.

> But historically 
> OSM-Carto has been and has meant to be avant-garde, in particular also 
> to justify being rendered on OSMF infrastructure.

It's very interesting, could you tell more about it? I'm not aware of
such comments and I'm not sure what "avant-garde" meant in this context.

I suspect it could be map richness, which is rather simple, but might be
seen as avant-garde. Also the act of collective design in itself might
be seen as ground breaking. But I wouldn't call it like that.

> You are making the wrong assumption here that code complexity and 
> cartographic sophistication always need to go together.  But they 
> don't.  There are plenty of examples of cartographic sophistication 
> being implemented without additional code complexity as well as code 
> complexity being added which was cartographically a step back.  

You're right, I used simplification. We deployed some simple code for
borders simplification for example and I was happy with that. Here I
talk only about avant-garde which currently requires workarounds.

> You are 
> also making the wrong implicit assumption that code complexity is the 
> only major factor that negatively affects developers' ability to 
> implement changes.

What are other factors then?

> about this.  And the unpaved roads rendering is not the problem here, 
> the problem is the complexity of roads rendering in general.

In my opinion there are two problems which add up - current road
complexity and surface code being Mapnik workaround too.

> Right now OSM-Carto is in the position of a quasi-monopoly in what it 
> does.  A potential competitor would need to mobilize a tile serving 
> infrastructure at least roughly on the same level as that of the OSMF 
> to seriously challenge it.  And this is quite a big hurdle.  This 
> creates a pretty stable comfort zone where OSM-Carto can rest idly even 
> if the world of digital cartography is progressing around it.

What do you define as the "serious competitor"? How do you measure it,
because there are a lot of styles using OSM data - including Wikimedia
maps style. Are they serious for you?

For me it's not the main problem, rather internal complexity which is
hard to avoid. No matter if the competitor exists or not, we're bound by
the tools and environment we're using, for example:

- https://github.com/gravitystorm/openstreetmap-carto/issues/2452 -
problem with lack of variables in YAML and/or CartoCSS parsing big lists
in SQL queries

- https://github.com/mapnik/mapnik/issues/3763 - lack of em measure in
Mapnik

- https://github.com/openstreetmap/chef/issues/155 - smarter label
placement has been implemented in mainstream Mapnik after I talked with
developers, but it's still not deployed on OSMF servers

...and so on.

The competitor would have to reimplement all of it or find better
toolchain, but OSM Carto could also use them if available, so it's still
the same problem.

But for rich map I see no such ready tools. Do you know any of them?

-- 
"My method is uncertain/ It's a mess but it's working" [F. Apple]





More information about the talk mailing list