[Tagging] Basic cartography features missing, why?

[Anders Torger]

This is great information, I didn't know about your project, very very 
interesting. I have recently come to understand the OSM-Carto technical 
challenges recently. I haven't given it much of a thought as a casual 
mapper for the past two years, just been a bit disappointed with how it 
looks.

I am a programmer in profession though so when taking a deeper look and 
though about it I see these challenges.

However, and this is a big however, I think that the face of 
openstreetmap really need to be a cartographic sound map. It's not right 
that a style seemingly designed mainly for speedy diagnosis should be 
the face of OSM. How many of our mappers are so technical that they 
understand this? And howcome did I not even know about this cartographic 
project of yours? If there are great styles out there but noone knows 
about them that's a problem.

And even if we let the not-so-good-cartography be the first map we see 
on openstreetmap.org (which makes no sense), some of the other layers 
presented there should be one which focus on good cartography, and all 
that are there now have many of the same issues as the main style.

I assume that many, perhaps most, casual mappers use the web editor. I'm 
really impressed with the web editor, it's great and is mostly 
user-friendly, you don't need to be a technical person to map, and that 
is how I think it should be. One thing with the web editor though is 
that unless you are technical enough to turn off caching (which 
essentially means putting the browser in development mode), you won't 
see the rendered results for a long time, even if reloading the page, 
you still get cached data. Thus it wouldn't matter if the rendering 
wasn't updated for a couple of hours or even more, the casual mapper 
won't see it anyway.

I think that direct feedback is desirable of course, but compared to 
other goals I think it's less important, and one can work with the user 
interface in the web editor to mitigate this issue. Perhaps just have a 
way to probe the server so it can deliver some render status. The 
biggest problem today with the web editor regarding feedback is that to 
a casual mapper it may not be obvious that the map needs to be rendered 
at all and that can take time, and together with the web caching and 
different zoom levels it gets even more confusing. Many of us more 
experienced mappers know exactly how OSM works and renders, and we go 
blind for how a new user will experience it.

One way to mitigate this could be to turn on some render info view in 
the web interface to show render status of tiles, maybe even estimated 
time left, and then a way to refresh the tiles without having to resort 
to putting the web browser in development mode with disabled cache.

And now to the most important point, whether one likes it or not, 
OSM-Carto as being the face of OSM and the most commonly used style, is 
the de-facto reference and driver of features and tagging. If OSM-Carto 
doesn't support basic cartography features many mappers won't be 
motivated to tag for that, and then the cartographic styles will have 
less information than they need to make good maps. OSM-Carto due to its 
limited rendering capabilities also make casual mappers tempted to "tag 
for the renderer" just to get results, which for example can mean that 
villages are upped, and thus the cartographic style will get fed with 
incorrect information.

In summary I think there are *very* strong arguments for that the main 
style shown at openstreetmap.org and the main style used for editors 
should be focused on providing great cartography (with the extension 
that it should probably present more features than a usual map, 
alternatively we need to split into several styles, all cartographic 
sound), and we must allow it to be be more computationally expensive and 
come up with smart ways to mitigate that in the tools. We can't 
stubbornly hold on to principles and use the same arguments that held up 
and worked well back in 2004, there are things that need to be revised. 
And one of these things is that we need to understand that good 
cartography needs priority, and good (online) cartography today has much 
tougher competition and therefore expectations than it had back in 2004.

While searching the web for what's happening inside OSM I found this 
blog post from 2018 written by a longtime OSM contributor, where some of 
these issues are discussed:
https://blog.emacsen.net/blog/2018/02/16/osm-is-in-trouble/

but it seems that not much has happened since, which makes me somewhat 
worried about the project's future. I don't think we need a revolution 
or something, but there are some things that need to start moving, and 
for some of these things the old processes no longer work.

/Anders

On 2020-11-07 07:52, Tomas Straupis wrote:
> 2020-11-07, št, 00:41 Anders Torger rašė:
>> However, how important is it that update of the map is immediate for 
>> every database update? <...>
> 
>   OSM-Carto is a style whose purpose is to visualise OSM data to
> MAPPERS, do it quickly (fast feedback is essential). OSM-Carto also
> has a requirement to be easily deployable by almost anybody on any
> hardware. This means that pre-processing of data is impossible as per
> requirements (not a design decision). And without pre-processing it is
> impossible to have a cartographically sound map. So even while the
> OSM-Carto team is doing a terrific job and they do have people with
> good cartographic knowledge (like Christopher), but OSM-Carto does not
> have such a purpose - cartography.
> 
>   We're playing around with a small project striving to comply with
> cartographic rules - topo.openmap.lt - some data is updated daily,
> generalisation is done weekly. But you already get generalised roads,
> buildings, smart lines for waterbody labels as well as text size and
> letter spacing. This should get cartographic simplification for
> waterways this coming spring (not DP or VW, but Wang-Müller). So this
> can be done, but OSM-Carto is not the place to do it.
> 
>   Therefore if you want to have a cartographically sound map - you
> will need a separate project - separate rendering and stuff. You're
> totally right - for general (not mapper) use, minutely update is less
> important than cartographically correct representation. And also not
> everything has to be generalised, some parts could be updated very
> fast, some could be updated weekly or even monthly. Segmentation of
> data could also get more attention (re-calculating only the parts
> which need re-creation). Such tasks could even push forward topics
> which are currently the target of generalisation and multiple
> representation group of International cartographic association - I
> really think OpenStreetMap has people and capabilities to have a say
> there.