Refocus project goals to show where data is weak / incomplete

[Firefishy]

Expected behaviour

OpenStreetMap Carto should not try smooth over data gaps in OpenStreetMap, but instead hint at the weak data.

Example: highway=* without a surface=* tag should not be rended as normal road, but should be degraded to a simplified road line style.

Goal: Nudge mappers to map increased data depth / quality.

Actual behaviour

OSM Carto currently looks awesome even where data depth is weak. No nudge to improve the data depth / quality.

[Firefishy]

I would suggest a radical departure from what has come before. Eg: Change all highway=motorway/trunk/primary/secondary/tertiary without a surface=* tag to all display as a single simple road line type.

[imagico]

This seems to be primarily a suggestion to change policy and to modify the design goals of this style. Since we can also discuss the matter of road surface rendering and the implicit default assumption of a paved surface in that under the current goals i separated this out into another issue (#4724). It is good to see some interest in discussing our guiding design principles and policies so i welcome you bringing up this idea.

The policy suggestion seems to be on two fronts:

• put more emphasis on the mapper feedback goal and less on the other goals - combined with introducing QA visualization elements (explicitly highlighting faulty/incomplete mapping in a negative way).
• depart from the paradigm to support mappers but not to actively steer them.

So far I am not very fond of either of these ideas, in particular not of the latter. If we'd practically do what you suggest as an example we would try to impose our ideas of what is important for mappers to map and what constitutes incomplete mapping on the mapper community. And i would not want to do that (not to mention that we - the maintainers here - would rarely achieve consensus on that). Why for example do you consider the lack of surface tagging on roads a particularly significant deficit? Isn't the lack of a width tag at least as significant? It decides if i can actually pass through with my truck/SUV while the surface tag merely gives some indication of driving comfort. 😏

Would you also suggest we render all natural=water without water=* in bright red or to hide them to nudge mappers to add this information? Prevalence of water=* on natural=water is currently about 30 percent.

[tjur0]

I think we need to revisit the idea that this style needs to both serve as a mapper verification tool and a general-purpose map. If we make a separate "OSM carto verification style" that has everything that we have now and shows way more secondary tags. Then the OSM website should give it as an option. It would solve a lot of issues with over rendering and could be more fast paced and more experimental.

[imagico]

To make this clear right away - this is not an invitation to brainstorm what kind of style people would like to see on the OSM website - that is not a discussion for this issue tracker.

This issue is for the discussion of the merits of a fairly specific idea to change the design goals of this style. Please keep the discussion on that topic.

[Firefishy]

OSM-Carto is in a unique place in OpenStreetMap, you have the power to influence 1000s+ of new and current mappers to improve tagging quality with little nudges.

The nudge factor is already defined in the policy document "It's an important feedback mechanism for mappers to validate their edits and helps to prevent unfavorable fragmentation of tag use."

OSM-Carto should not become a "QA" / "verification" style, but it should have nudges to improve mapping quality.

My example of degrading the style of roads without surface tags is a completely silly for countries which have 99% paved roads, but in South Africa where I am from, road atlases are careful to distinguish between "paved" / "unpaved" roads. I believe all roads should have a surface tag (even if generic types surface=paved / surface=unpaved). It took me a day to add surface= tags to UK motorways (using aerial imagery). I'd imagine if OSM-Carto degraded road rendering for roads without surface= tags, mappers would VERY QUICKLY map the missing tags.

Would you also suggest we render all natural=water without water=* in bright red or to hide them to nudge mappers to add this information? Prevalence of water=* on natural=water is currently about 30 percent.

Yes, if we believed this was an important enough thing in OSM to map, I would promote you using a nudge. Bright red would likely be a step too far, something more subtle, but enough to get mappers to fix it. ;-)

[imagico]

OSM-Carto is in a unique place in OpenStreetMap, you have the power to influence 1000s+ of new and current mappers to improve tagging quality with little nudges.

The nudge factor is already defined in the policy document "It's an important feedback mechanism for mappers to validate their edits and helps to prevent unfavorable fragmentation of tag use."

The section you cite describes what purposes and functions the style has, not what we as maintainers and developers should and should not do. The fact that we have a lot of power on mappers (which i concur we do) is in no way a mandate to use that power for a certain purpose. On the contrary: Exactly because we have a lot of power we need to be particularly careful to consider the consequences and the moral implications of using that power.

The goals we have - and which are outlined in the next section of that document, support what i have mentioned and what we have in the past on many occasions re-affirmed to be consensus among the maintainers: To support, but not steer, mappers in consistent use of tags.

My example of degrading the style of roads without surface tags is a completely silly for countries which have 99% paved roads, but in South Africa where I am from, road atlases are careful to distinguish between "paved" / "unpaved" roads. I believe all roads should have a surface tag (even if generic types surface=paved / surface=unpaved). It took me a day to add surface= tags to UK motorways (using aerial imagery). I'd imagine if OSM-Carto degraded road rendering for roads without surface= tags, mappers would VERY QUICKLY map the missing tags.

As i have already mentioned i have opened an issue to discuss what can be improved about this particular matter in #4724. I welcome you and everyone else to bring in any ideas how to do that there. I completely agree that rendering the surface tag on roads without an implicit default (i.e. with a differentiation between paved and unknown surface) would be of benefit if we can find a good way to do so (and that in particular means one that does not just generically degrade the display of roads with no tagged surface).

Yes, if we believed this was an important enough thing in OSM to map, I would promote you using a nudge.

But who are we (we as in either you and me or we as the maintainers of this style - but ultimately also of course the OSMF as those who in the end decide on what is shown on osm.org, though that's a different discussion of course) to decide on what is important enough to be mapped in OSM and therefore mandates mappers to be nudged to map this independent of their intrinsic motivation to do so?

This idea IMO goes against the very core principles of OSM as a project where local mappers are free to map what they locally consider to be important and to decide - through bottom-up consensus building processes and equal-level interaction - on how to map it.

Yes, of course we do make decisions on what we show in the map and what we don't - we have to do so to be able to create a useful map. But we (a) base these decisions primarily on what we observe mappers doing by looking at the data (and therefore decidedly not according to what we consider important to map) and (b) we do so - as mentioned - under the paradigm to support, but not steer.

[davidpnewton]

Expected behaviour

OpenStreetMap Carto should not try smooth over data gaps in OpenStreetMap, but instead hint at the weak data.

Example: highway=* without a surface=* tag should not be rended as normal road, but should be degraded to a simplified road line style.

Goal: Nudge mappers to map increased data depth / quality.

Actual behaviour

OSM Carto currently looks awesome even where data depth is weak. No nudge to improve the data depth / quality.

Use QA tools for the job that they are designed for. Stop trying to wreck the most visible styling for the database information that we have got. OSM-Carto's primary job not to show data problems. Its primary job is to render data in the database in widely-useful format.

[mvl22]

I would favour the opposite: a style which specifically just shows errors. Essentially becomes a map-based todo list, a bit like a renderer version of KeepRight but with as many known error types as possible.

[Firefishy]

I would favour the opposite: a style which specifically just shows errors. Essentially becomes a map-based todo list, a bit like a renderer version of KeepRight but with as many known error types as possible.

tile.openstreetmap.org which is the primary user of this osm-carto style is viewed by millions of users across 10,000+ websites. To paraphrase an open source expression: "Many eyes make all bugs shallow". OpenStreetMap has many bugs and is far from "complete".

[woodpeck]

I agree with the idea that OSM-Carto should not pave (ha!) over glaring bugs. For example, if a polygon is broken but repair-able with some clever buffer algorithm or so, I'd prefer the object to not render, so that a mapper will fix it properly. I wouldn't be opposed to objects vanishing from the map if they have, say, a non-parseable opening hours syntax or a glaring omission that makes them useless.

The particular example chosen here, a missing surface tag, doesn't work for me though. I am in a country where most roads are paved. If someone were to add surface=paved to all the roads, I would not view this as improving tagging quality at all - I would view it as a degradation, because it just adds useless information that makes it much harder to spot the five exceptions where a road is indeed unpaved and carries an appropriate tag.

A missing surface tag on a road in my country is not "weak" data, it is OSM concentrating on what matters. The problem is, in my eyes, that we don't have an established way to record and apply country- or region-wide defaults, and the solution to this problem cannot lie in enticing mappers to make useless edits that waste their time, increase the data volume, and confuse mappers who have to read through a dozen "default" tags before they find the one thing that is remarkable about this road.

[imagico]

Thanks for the additional comments.

I like to again urge anyone who wants to discuss specifically improving the unpaved road rendering and to avoid the implicit default of paved and the lack of visual indication if no surface is tagged to provide their ideas and thoughts on #4724. Solving this is not in any way prevented by our policy (codified or otherwise).

@Firefishy - since you commented on the wider context of this matter on openstreetmap/operations#775 i would like to ask you to make clear if your comments here are made by you just in personal capacity as a mapper and individual OSM community member or if you make them in your function as an OSMF sysadmin and employee.

@woodpeck - we have in the past decided against any ideas of regional federation of this style. But this is not a principle that is set in stone or strictly mandated by our policy. What i would however be fairly sceptical of is basing such regional differentiation of style rules on external data that is not under a bottom-up control from the base of the mapper community (and to be clear: Any information extracted from the OSM wiki would also not qualify as such). And as you well know the ability of mapping in OSM to develop and maintain consensus on concepts of larger geographic extent is very limited. I have sketched in the past in a specific case example how such a concept of regional defaults could be designed in a way that maintains local control by mappers. But until such concepts are actually implemented in practical mapping we have nothing to work with here.

@tjur0 - i am sorry if i came across a bit bruskly. The idea of better and more accessible visual QA tools and QA map layers (in particular ones that are broad in thematic scope like this map style and do not focus exclusively on a small subset of features like many existing QA tools) certainly has merit - as would potentially the idea to include them in the map layer selector on osm.org (maybe only for logged in users). But this is off-topic here. So please discuss that elsewhere.

To everyone: Since the discussion here is apparently elsewhere (like on openstreetmap/operations#775) framed in a distorting way i like to emphasize again: This issue is open. Discussion is welcome (but please keep it on topic of the policy matter and move more specific styling discussion to separate issues). I have above in #4723 (comment) presented my current thoughts on what has been suggested and what considerations are behind these thoughts. I explicitly welcome arguments and reasoning that challange these considerations.

[matkoniecz]

Example: highway=* without a surface=* tag should not be rended as normal road, but should be degraded to a simplified road line style.

Goal: Nudge mappers to map increased data depth / quality.

note that it will not nudge users to add correct data

it will result in users guessing surface and adding fake values to "fix" rendering

if we will be lucky people would add surface=yes

if unlucky, people will add surface=paved to everything

[matkoniecz]

OSM Carto currently looks awesome even where data depth is weak. No nudge to improve the data depth / quality.

not really sure about it, see for example https://www.openstreetmap.org/#map=17/24.49830/105.09400 vs https://www.openstreetmap.org/#map=17/51.11076/15.58605

and to surface for example wrong or outdated opening hours it seems that far more powerful and useful would to make this data accessible for mapped POIs on the OSM website, rather than for example render such POIs gray/in red circle etc.

[imagico]

OSM Carto currently looks awesome even where data depth is weak. No nudge to improve the data depth / quality.

There is one important aspect of this i have not commented on - that is the breadth vs. depth matter. We currently render more than 400 primary tags (that is tags we interpret to decide if something is rendered or not) but only less than 200 secondary tags (tags that modify rendering of things, but only in the presence of a primary tag). That is partly of course because primary tags are much more widely used by mappers, but also because

• addition of new primary tags (i.e. newly depicting features that are not shown so far) is often more attractive for developers.
• addition of new primary tags at least superficially often seems more easy design wise because you can try to ignore the design context and just try to add it not regarding if it fits harmonically into the style otherwise. For modifying rendering based on secondary tags this is not possible, you inevitably have to deal with the existing design constraints.

This would be good to change and focus more on modifying styling of features we already render based on either secondary tags or geometric context. This in particular applies for primary tags that are used with a very broad meaning. Roads could be good to look at here (see for example #214, #791) though we already render a lot of secondary tags on those of course. Other examples would be woodland (#1756), farmland/orchard based on crop/trees, buildings (#738, #2475), water features (#3893, #3895, #3896, #4267), wetlands/reefs (some ideas in #4513 (comment)) and sport infrastructure (#844). POIs are also a field for that - though it is often complicated, partly due to the technical limitations we have (see for example #3124, #2431).

This is not meant to deflect from the policy discussion, just trying to pick up one aspect of @Firefishy's suggestion that should not fall under the table IMO.

[Firefishy]

@Firefishy - since you commented on the wider context of this matter on openstreetmap/operations#775 i would like to ask you to make clear if your comments here are made by you just in personal capacity as a mapper and individual OSM community member or if you make them in your function as an OSMF sysadmin and employee.

My request is in my personal capacity as a mapper and user. I want to see OpenStreetMap grow and improve. I am not the first to call for OpenStreetMap's default style to used to nudge mappers, dare I say even Steve Coast made the suggestion in his recent controversial Minds Behind Maps interview.

And yes, I am also part of the OpenStreetMap operations team and I have spend a lot of time over the years keeping tile.openstreetmap.org running and promoting tile.openstreetmap.org to be kept open to allow developers to freely use it. My view is the millions of eyes viewing tile.openstreetmap.org / osm-carto can be nudged into improving OpenStreetMap map data, but we first need need to make conscious decisions setting up. the nudges. Linus's Law: "Many eyes make any bug shallow."

Ops team invest some time in caching behaviour / rendering speed to allow map to update more quickly. There may be some coordination work to ask JOSM / iD etc to also highlight the "nudge" to mappers or to improve presets.

My employee has no relevance or influenced my request.

[zekefarwell]

A missing surface tag on a road in my country is not "weak" data, it is OSM concentrating on what matters.

@woodpeck, is the road paving so homogenous in your country that a specific surface value such as asphalt can be assumed? In most places road paving can include a variety of surfaces such as concrete, sett, unhewn_cobblestone, etc. Whether these distinctions matter or not depends on the use case of course, but a number of data consumers have been quite vocal about encouraging this level of detail so it clearly matters to some.

[imagico]

@zekefarwell - see #4724 (comment) for some info on that.