Rendering of natural=bay vanishes too early and is too small

[martiensch]

The labels of areas which are tagged with natural=bay do not scale and vanish too early when zooming out.

Example The label is omitted in Z13, but the area is vast and includes also the wetlands surrounding the water. Also the label is quite small compared to the area size.

I would like to see that the label for natural=bay is rendered similarly to natural=wetland which is visible up to Z10 (example).

[imagico]

See also #788, #804.

Currently less than 5 percent of bays are mapped as areas, the merits of mapping bays as areas universally are subject to debate (see also http://wiki.openstreetmap.org/wiki/Tag:natural%3Dbay) and since the coastline is not in the database there is no way to properly assess the size of bays mapped as nodes.

Having size dependent rendering for bays mapped as areas but not for those mapped as nodes would add a huge incentive to mappers to map them as areas which will likely result in a lot of non-verifiable and difficult to maintain area drawing. Ideally mappers should feel free to map as either area or node depending on the situation and not get a particular pressure to choose an area due to the choices in rendering here.

[mboeringa]

This is from my ArcGIS Renderer for OpenStreetMap. It is a 1:100k rendering of a Croatian island which includes natural=bay features, based on simple nodes primarily in this area, because that is how it is tagged here. 1:100k in this local Croatian / Balkan projection is about equivalent to Z12. I actually render the bay features up to 1:250k scale in reality, which would equate to about Z11.

I think it quite acceptable, although it does require a proper knock-out labelling that removes overlapping labels. In fact, there are a quite bit more natural=bay features in this area that had their label being removed in the labelling process. Of course, the removal is completely arbitrary based on a rendering of nodes, so you won't have a hierarchy of large and small bays in this image, although it is likely that large bays won't have any other bay label features near, so are a bit more likely to "naturally" stay in view instead of getting removed.

Anyway, Z10 may be a bit to much for a rendering not able to distinguish between large and small features, but Z12 just encompasses the Dollart ;)

[martiensch]

@imagico Thank you for the references!

I fully understand that the process of mapping a bay is hard and not well defined problem. However, there are lots of situations, where the area is fuzzy. There are large woods and large wetlands where the parts are named after the nearest village, but the border between the parts is vague. In my example the local government opted to use both names for the nature reserve. And this contiguous body of water in my home town has three names but is just 2.5 sq.km. Just one of the parts is well defined since it was excavated.

Mapping nature and the names we give to that nature is elaborate and not as exact as naming streets and buildings, but that is no reason to not render those features. We cannot control nature through a map :-)

( With your line of argumentation I should also stop mapping the Frisian islands, this one moved about 100m in five years (artifacts of coastline rendering are still visible) :-P )

Why is there a problem in having an incentive to draw an area? The information of the area is not just for the renderer, is also for the user/reader. He can assess more easily the size of the bay. Also, the point rendering which is used now just neglects the vast size of some bays. My example - the Dollart - is as big as Manhattan but gets a label which is smaller than the font used for rivers.

(Note: I do not advocate to stop rendering points with natural=bay, as a first step they are still useful)

[imagico]

I am not sure if you are rejecting the concept of Verifiability in general here. Woods, wetlands, bodies of water and islands are generally verifiable features in terms of their geometry. Bays OTOH often are not. Which is one of the reasons why mapping them as nodes is fairly popular.

Why is there a problem in having an incentive to draw an area?

Influencing the mappers' decisions for reasons that lie in specific limitations of a certain map rendering setup is generally a bad idea. Most experienced mappers are pretty good in choosing a reasonable way to represent what they map in terms of features and tags when they are not persuaded to map in a certain way by renderers. Style development should try its best to avoid messing with that.

[martiensch]

@imagico Thank you for pointing me to this part of the wiki :) It is good to remember, rethink and discuss once in a while what the principles of OSM are.

I do not reject the concept of Verifiability, but I feel that it is very rigid. The problem with verifiability of areas is that we have to deal with conventions for naming areas.

We usually adhere to our local government in mapping borders between municipalities. They are well-defined, well-known, and agreed on by many people. It becomes more difficult when one distinct area has multiple names, depending on your point of view (the Dalum-Wietmarscher Moor I showed previously), or, in case of bays, only a part of the border is undisputed.

I am not sure what the best method for mapping a bay is and what the rules for a bay area should be. It's just that I am not satisfied with mapping a point. A point is less informative to me than an area.

PS: there are some official rules on determining the extent of a bay, but they are used for determining internal waters (art. 10)

[imagico]

Discussion here should focus on how to render what is currently mapped, mapping related discussion is better done elsewhere. Not to repeat previous arguments unnecessarily - there was a lengthy discussion on the matter some time ago on:

https://lists.openstreetmap.org/pipermail/tagging/2014-October/019775.html

As already indicated the problem with labeling bays in this style is foremost a technical one. All information necessary for assessing the size of bays and labeling them accordingly is there, even for bays mapped as nodes. It is just not readily accessible in the current setup.

The most relevant question here to me seems if with the planned database reload the coastline ways could be included in the rendering database and if they are if it would be considered using them for bay size assessment. In https://github.com/gravitystorm/openstreetmap-carto/issues/804#issuecomment-53799051 @pnorman indicated in a somewhat different context he considers use of the coastline undesirable but this was for positioning labels and not for size assessment - although both topics are closely related of course.

[pnorman]

I don't see that having coastline linestrings would help much. Yes, if you have a coastline way in the bounding box you can figure out which side is land and which is water, but I suspect label clipping issues are unsolvable if you try to construct bays from coastline linestrings

[imagico]

I intended this purely for size assessment here, anything more fancy would likely be either not very robust, slow or counter-intuitive for mappers.

But i also see that even just that could be prohibitive in terms of performance at the lower zoom levels - the big advantage from the technical side of using way_area is always that it is precalculated. Doing anything like that for nodes without preprocessing is hard - as a preprocessing step it would be fairly strait away.

[pnorman]

The problem is that the coastline linestrings around the bay may not lie in the same metatile as the bay point, so you can't just work with the bounding box. You can't use && with the point and linestring either, since they may not bounding box overlap. you could find st_distance to the nearest coastline linestring, but you'd need very recent versions because KNN on older versions is bounding box based, and I'm not sure if st_distance is useful.

[imagico]

My idea was to select a certain size threshold for every zoom level beyond which everything is considered 'really big' and find all coastline ways within that distance and work with these - that would essentially be bounding box based. I am not familiar with KNN in PostGIS but i would assume this is of little use since the K is arbitrary due to the coastline being split arbitrarily by mappers.

A preprocessing approach would be much nicer, especially since you could use coastline polygons and therefore eliminate small islands which would otherwise mess with the size estimate.

[Tomasz-W]

@kocio-pl Please check example place from the first post or another ones: https://www.openstreetmap.org/relation/8162631#map=10/54.2195/13.6011 https://www.openstreetmap.org/relation/6719627#map=10/54.6007/13.3745

Labels for natural=bay seems to be rendered from z10, so it makes this issue not up to date. Please close it.

[kocio-pl]

Thanks!

Solved by #3144 (only for areas, I see no solution for nodes anyway).