The neutral way to look at things like this is to consider which approach

• provides the most information
• is most intuitive and convenient for the mapper

The first point would call for approach two plus splitting the link into sections ‘connected’, ‘theoretically separated’ and ‘physically separated’. Because approach three would not record information on the beginning of lane separation (which you would for example also need for precise routing) it would contain significantly less useful information.

The second point would in particular speak against the ‘45 degree angle’ concept of your approach three which creates a purely abstract geometry element with no verifiability on the ground. You call this “balance between the needs of renderers and routers” (or in other words: combined tagging for the renderer and router) - i would call it codified mediocrity in both rendering and routing.

Have you looked at what approaches are actually most widely used in OSM - like some statistics on the angle between motorway and motorway_link at motorway_junction? You can bet that if you start fixing these to a 45 degree angle in a country where 2/3 of the junctions are mapped with a smaller angle you will rightfully get significant opposition to such edits. Looking at a few places around Europe it seems pretty clear that your 45 degree concept does not have much popularity.

I just wanted to point out that the description of the historic development in OSM-Carto by kocio is not quite right. The problem with low zoom waterbody rendering has been discussed and fully analyzed many years ago - i linked to some parts of the discussion in the blog entry above - others are referenced from there. I also discussed the topic a bit more than year ago here from a somewhat different perspective (the rendering side) which was also referenced from the style development here.

The ‘solution’ now introduced is an approach that has been well known in rendering of OSM based maps and used in many maps, in particular ones without a mapper feedback mandate/function and commercial maps where cost efficiency is the primary goal for many years with similar low quality results. This approach has been rejected several times in the past in OSM-Carto (see in particular here and here).

I agree that the OSM-Carto issue tracker would be a better place for discussing the problem but a productive discussion would require all participants being fully aware of the previous state of discussion and a common understanding of the cartographic goals. At the moment i can see neither of these here. The problem is that while it is easy to recognize the issues with the current approach (as i pointed out in this diary) the cartographic and technical context is complicated and it is tempting to try ignoring parts of this context in the attempt to facilitate understanding. Ideas like “just stopped rendering water haze of sub-pixel size” are an example of such over-simplification. If you want to make it really simple it is best to accept that way_area filtering for filled polygon rendering just does not serve any positive goal, it is purely a method of reducing rendering costs at the expense of quality. This obviously is an over-simplification too but not a harmful one like the other way round.

Grayscale rendering and other color processing with Leaflet - using canvas/CSS and not WebGL:

http://humangeo.github.io/leaflet-tilefilter/demo.html

You should however add that this is just the normal raster tiles from the osm.org tile servers rendered with WebGL. It is not a vector tiles based version of the standard style like what Rory/Geofabrik have showed some time ago:

https://github.com/geofabrik/openstreetmap-carto-vector-tiles

Any post processing like for colors or rotation or other coordinate system transforms come with the usual problems of posterization/sampling artefacts etc.

Openlayers/Leaflet IIRC also offer b&w conversion, rotation etc.

Your description of the latitude problem is correct - if you design your styling to appear 4m wide in Scotland (because the typical hedge is 4m wide) it will be rendered 8m wide at the equator.

You might not consider this to be a problem but you will always optimize for a certain latitude and in a way discriminate other latitudes with that by being less optimized there.

I see your point about the visual weight.

The key to getting it working was to ensure that the width of lines used at high zooms mostly matched the real width of the feature on the map

The problem with that is that in Mercator it works reasonably well for a small area map like of Britain but it does not on a global map over a wider range of latitudes. There this kind of thing is much more complicated - see

https://github.com/gravitystorm/openstreetmap-carto/pull/1853

Design wise i am not sure if a crossable barrier like a cattle grid being rendered much stronger than a non-crossable barrier like a fence or hedge is very intuitive. You can certainly get used to it but it still looks kind of strange.

@Alan - I think that is a misunderstanding of the “One feature, one OSM element” rule in two separate ways.

First the riverbank polygons do not represent the river, they represent the water covered area of the river. This area can be split in mapping just like landuse mapping can be split. The river itself is represented by the linear ways with waterway=river and potentially a waterway relation collecting those ways.

Second i think “One feature, one OSM element” does not mean you need to merge all features that are part of a larger scale concepts into one OSM element (like all natural=wood areas that are part of the Amazon rain forest into one giant multipolygon). In case of a river mappers standing in Hamburg are mapping the Elbe locally as a way waterway=river, name=Elbe - like here:

osm.org/way/4264804

Mappers in Lovosice will map their river locally with waterway=river, name=Labe:

osm.org/way/514836877

This is not in violation of “One feature, one OSM element” because to the local mappers this is not the same feature obviously. The larger scale concept of a river as a global feature is represented as a waterway relation in addition but that is a concept separate from the river as a local feature.

All of this has nothing to do with the subject at hand: The problematic mapping incentives created by using way_area filtering on riverbank polygons in the standard style. Even if you want to interpret “One feature, one OSM element” differently and create thousands of new giant MPs extending in some cases across whole continents to represent the water covered areas of rivers as global concepts the right way to do that is to discuss this with the mapping community and achieve consensus on that matter, not to push this from a prominent map style for convenience of the map designers.

@nebulon42 - i understand your point and normally if it had just been a loss of quality in the map this is about i would not have said anything - hoping that even if those making the changes won’t listen to me they will over time recognize the problems and either fix them or ask for and accept help to do better. But this is going to have a massive effect on mapping pushing mappers strongly in a certain direction so i think it is important to bring this up. And as you noticed i discussed this matter on many occasions in the map styling context so arguing the same point yet again in style development after my views on the matter have already been ignored there many times did not seem a very productive course of action.

I have considered resigning my position as maintainer but as long as OSM-Carto is prominently featured on the OSMF infrastructure i don’t think this is the responsible thing to do. So i will continue providing critical feedback and provide alternative styling ideas to whoever will listen. I am grateful if there is a possibility to do that in style development but if not i will also do so in other places like here.

Mapping for the renderer means mapping against established conventions to achieve a certain rendering result. Splitting riverbank polygons into small parts has always been documented practice and it universally used by mappers as you can now see in the standard style.

You probably did not notice my mapping tip to create a MP for thousands of lakes together was ironic. It is meant to illustrate that even if you are fine with the standard map style pushing mappers to a certain style of mapping against established practice and common sense this would still lead to completely ridiculous incentives in this case.

Just to avoid misunderstandings - the 2.9562 exhausted votes are from people who have had only 1 or 2 people on their ballot so after Heather was elected and David eliminated they did not have any vote left to make a difference. So if those who had Heather/David on 1/2 or the other way round or only one of them and an empty ballot otherwise they could have, if they had added Joost to the bottom of their list, made a difference in the final results.

@naoliv - there was a recommendation by Nakaner to vote Paul-Joost-David(-Heather) - see http://blog.openstreetmap.de/blog/2017/12/wahlen-zum-vorstand-der-openstreetmap-foundation-2017-teil-2/

Since there were four candidates there are only 4*3=12 possible combinations (not counting empty positions) for first and second so 10 percent of the voters choosing one of them is not in any way strange.

This indicates Heather was the most polarizing candidate (which most voters either voted on top of the list or as last/not at all) while Joost was the most broadly accepted candidate (which most voters put on one of the upper places of their list).

The really interesting information would of course be the geographic distribution of the votes. Unfortunately this is not possible to determine of course.

Let me take the opportunity to thank you for your work. From what is visible from the outside you contributed quite a lot to a better transparency of the OSMF work during the past years which - independent of the help you provide within the the OSMF - is of direct benefit for the whole OSM community.

I imagine being the first person in the role of an administrative assistant on the OSMF can be both a blessing and a curse and for sure is not always easy and pleasant.

Ok - since we have the board elections these days and you list one of the candidates it is important to be as clear as possible not to lead to misunderstandings among the voters. Thanks.

For clarification: It seems the people listed have not actually actively contributed to the document shown in the sense they endorse it. It would be great if you could specifically clarify that.

Checking with other Czech mappers and the data provider is a good idea - free-to-use services do not generally mean they are free for data extraction like tracing in OSM.

Otherwise nice example of the usefulness of relief data for mapping.

Are you sure it is allowed to use this for mapping in OSM? Neither the WMS nor the info on the data set on

http://geoportal.cuzk.cz/(S(lhmhzafvgs5vuq3qgjkbphev))/Default.aspx?lng=EN&mode=TextMeta&side=vyskopis&metadataID=CZ-CUZK-DMR5G-V&head_tab=sekce-02-gp&menu=302

indicate this is available under a free license compatible to OSM.

Nice.

But don’t make the mistake to just map forests just because it is one of the pet landcovers that are shown earlier than the rest in OSM-Carto.

Some interesting observations can be made from these diagrams but i also find two things somewhat misleading.

First Graph 1 looks wrong since the x-axis looks like a time axis but in fact is not - as i understand this it is a combination of separate diagrams for every year with the x-axis indicating the month after first contribution.

Second considering the days of participation a measure of activity is problematic. In particular the very active weekend mapper mapping a lot during the whole day on weekends will have a lot less days of participation than the casual end-of-day mapper who maps a few things every evening to relax.

Is it just my impression or does Graph 4a indicate that contributions from veteran mappers (who started mapping several years ago) has increased quite a bit in 2017?

Good example for the usefulness of open data imagery for mapping in OSM.

The limiting factor in this area by the way is not the recording frequency - both Sentinel-2 and Landsat have newer images available than from September 7. But cloud cover during summer leads to most of the images not being useful.

And care should be taken to process the data into images well readable by the mappers so they can correctly interpret what they see. Here a rendering of the same image that probably better resembles the on-the-ground impression:

@RobJN - I think we can only agree to disagree. Everyone else can form their own opinion.