Opened 8 years ago

Closed 5 years ago

#3294 closed enhancement (wontfix)

cliffs not rendered

Reported by: fkv Owned by: mapnik-team@…
Priority: major Milestone:
Component: mapnik Version:
Keywords: cliff Cc: katpatuka

Description

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.

Change History (6)

comment:1 Changed 8 years ago by katpatuka

  • Cc katpatuka added

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

comment:2 Changed 8 years ago by Ldp

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.

comment:3 follow-up: Changed 8 years ago by Ldp

  • Resolution set to wontfix
  • Status changed from new to closed

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

comment:4 in reply to: ↑ 3 Changed 7 years ago by webreg@…

  • Resolution wontfix deleted
  • Status changed from closed to reopened

Replying to 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.

comment:5 Changed 5 years ago by fkv

  • Keywords cliff added
  • Priority changed from minor to major

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).

comment:6 Changed 5 years ago by pnorman

  • Resolution set to wontfix
  • Status changed from reopened to closed
  • Type changed from defect to enhancement

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.

Note: See TracTickets for help on using tickets.