Skip to content
This repository has been archived by the owner on Jul 24, 2021. It is now read-only.

cliffs not rendered #3294

Closed
openstreetmap-trac opened this issue Jul 23, 2021 · 6 comments
Closed

cliffs not rendered #3294

openstreetmap-trac opened this issue Jul 23, 2021 · 6 comments

Comments

@openstreetmap-trac
Copy link

Reporter: fkv
[Submitted to the original trac issue database at 12.46pm, Saturday, 16th October 2010]

  1. Circular cliffs are not rendered, but they should. Many rocks (and even some mountains) are surrounded by steep walls, all the way round. In that case, the cliff is mapped counter-clockwise by convention (top = left side of way). If it is mapped clockwise, it may be a sinkhole. In either case it can be rendered as if it were non-circular.
  2. Single-node cliffs are not rendered either. In my understanding they are for rock spires. One usual symbol for them is a triangle, similar to the peak symbol, but higher than wide. It symbolizes the form of the rock spire. I have also seen a variant with 2 smaller triangles attached, one left and one right, overlapping with the bigger middle triangle.
@openstreetmap-trac
Copy link
Author

Author: katpatuka
[Added to the original trac issue at 7.27am, Sunday, 6th February 2011]

... and still not rendering - see http://www.openstreetmap.org/browse/way/33074515 for example

@openstreetmap-trac
Copy link
Author

Author: Ldp
[Added to the original trac issue at 12.09pm, Sunday, 6th February 2011]

How would we be able to discern between a closed way denoting a circular cliff and a closed way denoting a true area where the cliff is?

Once we render these natural=cliff closed ways, these true area cliffs would come out wrong. Now, we can accept that and expect mappers to not map true areas for cliffs and to clean up this data. Or, we can ask that for these closed ways that could conceivably be explained either way, an area=no tag is added. That would not only help mapnik or other renderers, but would make it equally clear to any data user that you, as a mapper, truely meant a circular cliff.

@openstreetmap-trac
Copy link
Author

Author: Ldp
[Added to the original trac issue at 9.13pm, Sunday, 27th March 2011]

I took the liberty to add area=no to the example way above. It will now render as expected.

@openstreetmap-trac
Copy link
Author

Author: webreg[at]volki.at
[Added to the original trac issue at 6.26pm, Tuesday, 9th August 2011]

Replying to [comment:3 Ldp]:

I took the liberty to add area=no to the example way above. It will now render as expected.

This is tagging for the renderer. area=no seems just wrong, because area=* is used to turn linear things into areas, not the other way round.

The meaning of true area cliffs is not defined in the wiki, so I see no point in considering that the default. It's just as the same as with barrier=fence etc.

Whatever the default is, Mapnik actually does not render closed cliffs without area=*. That means that Mapnik does not handle the default case. It's hard to call this behaviour not a bug.

Part (2) of my initial ticket description has not been adressed at all. Meanwhile, someone opened ticket #3770 on the same issue.

@openstreetmap-trac
Copy link
Author

Author: fkv
[Added to the original trac issue at 11.07am, Sunday, 10th November 2013]

Part (1) is becoming increasingly annoying because it has remained unsolved for 3 years, and missing cliffs may get hikers and mountainbikers into danger, espescially in regions where they rely on the map because all of the cliffs are mapped. Therefore I am changing the priority to "major".

I suggest leaving out the controversial part (2) for now, because there is a dedicated ticket #3770 for that, and instead to just start work on the more critical part (1).

@openstreetmap-trac
Copy link
Author

Author: pnorman
[Added to the original trac issue at 6.13am, Monday, 11th November 2013]

The "mapnik" component in trac is for the old XML-based openstreetmap.xml stylesheets which are not deployed on OpenStreetMap.org. Since June the default style on OpenStreetMap.org has been openstreetmap-carto, which has its own issue tracker at https://github.com/gravitystorm/openstreetmap-carto/issues.

I'm going to go ahead and close this issue as wontfix to avoid people being confused by it and commenting on it instead of somewhere where it will effect the rendering on osm.org. Closing it doesn't mean the issue won't be fixed in openstreetmap-carto, just that this ticket is against old unmaintained software that has been replaced and this ticket has zero chance of being resolved.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant