circular cliffs are not rendered #268
Comments
|
The natural=cliff wiki page allows the usage on areas as well as lines. The common interpretation of such tags (e.g. piers, barriers, city-walls, race-tracks, breakwaters, pt-platforms, dams, runways, etc.) is that they represent areas if their way is closed and are not explicitly marked as being linear by an So, this is really a tagging issue: Should we disallow cliffs to be area-ish (even though they have been mapped as such since years)? Does |
|
Would area=no solve this problem? |
|
No, because it would be tagging for the renderer, and because area=* is used to turn ways into areas, not the other way round. Tyrasd is right in that the wiki is not explicit enough. It seems that natural=cliff for areas was an ancient suggestion that has not really made it to actual use, but the wiki still reflects that concept. It is a pity that the wiki leaves renderer developers in doubt on what natural=cliff on closed ways or on nodes means. Even if it is changed in the Mapnik layer, the others are still left in the dark. Therefore we should run a clarification (wiki cleanup) proposal, similar to my proposal for natural=rock cleanup which has been in RFC state for so long that it's time to proceed with it as well. |
Not necessarily - it depends on how a closed way without area tag should be understood. If closed ways are understood to be areas when tagged with natural=cliff, then adding area=no would not be tagging for the rendering. On the other hand, if such ways are normally understood as linear features, then we should not require area=no, but simply change the rendering. I don't know which of both is the case.
Not according to the wiki: "If the assumption that a closed way together with other tags defines an area is misleading, area=no can be used clarify the situation. E.g., sports=running, area=no is just a closed running way. "
That would be an excellent idea. A clarification is definitely needed. |
|
Since this needs external clarification, I'm closing the ticket in the meantime. |
|
Clarification finished. Ways tagged natural=cliff do now default to area=no. |
|
See #1227 for a follow-up. |
matthijsmelissen
modified the milestones:
3.x - Needs upgrade to openstreetmap-carto.style,
Bugs and improvements
|
Best solved with a new database import. |
This allows the decision whether an object is treated as polygon or linestring to be set in the style.lua file. In particular, it treats man_made=embankment and natural=cliff as linestring, and highway=services as polygon. Including this in the default style.lua file has the following advantages: * It serves as an easy-to-extend example of how the polygon/linestring decision can be made based on key. * It provides sane defaults - it can be expeced that most users of the style want to treat man_made=embankment and natural=cliff as linestring, and highway=services as polygon. This resolves the following downstream bugs in openstreetmap-carto: * gravitystorm/openstreetmap-carto#892 * gravitystorm/openstreetmap-carto#268 * gravitystorm/openstreetmap-carto#137 This builds on osm2pgsql-dev#345, and thus assumes osm2pgsql-dev#345 is merged first.
This allows the decision whether an object is treated as polygon or linestring to be set in the style.lua file. In particular, it treats man_made=embankment and natural=cliff as linestring, and highway=services as polygon. Including this in the default style.lua file has the following advantages: * It serves as an easy-to-extend example of how the polygon/linestring decision can be made based on key. * It provides sane defaults - it can be expected that most users of the style want to treat man_made=embankment and natural=cliff as linestring, and highway=services as polygon. This resolves the following downstream bugs in openstreetmap-carto: * gravitystorm/openstreetmap-carto#892 * gravitystorm/openstreetmap-carto#268 * gravitystorm/openstreetmap-carto#137 This builds on osm2pgsql-dev#345, and thus assumes osm2pgsql-dev#345 is merged first.
This allows the decision whether an object is treated as polygon or linestring to be set in the style.lua file. In particular, it treats man_made=embankment and natural=cliff as linestring, and highway=services as polygon. Including this in the default style.lua file has the following advantages: * It serves as an easy-to-extend example of how the polygon/linestring decision can be made based on key. * It provides sane defaults - it can be expected that most users of the style want to treat man_made=embankment and natural=cliff as linestring, and highway=services as polygon. This resolves the following downstream bugs in openstreetmap-carto: * gravitystorm/openstreetmap-carto#892 * gravitystorm/openstreetmap-carto#268 * gravitystorm/openstreetmap-carto#137 This builds on osm2pgsql-dev#345, and thus assumes osm2pgsql-dev#345 is merged first.
This allows the decision whether an object is treated as polygon or linestring to be set in the style.lua file. In particular, it treats man_made=embankment and natural=cliff as linestring, and highway=services as polygon. Including this in the default style.lua file has the following advantages: * It serves as an easy-to-extend example of how the polygon/linestring decision can be made based on key. * It provides sane defaults - it can be expected that most users of the style want to treat man_made=embankment and natural=cliff as linestring, and highway=services as polygon. This resolves the following downstream bugs in openstreetmap-carto: * gravitystorm/openstreetmap-carto#892 * gravitystorm/openstreetmap-carto#268 * gravitystorm/openstreetmap-carto#137 This builds on osm2pgsql-dev#345, and thus assumes osm2pgsql-dev#345 is merged first.
This allows the decision whether an object is treated as polygon or linestring to be set in the style.lua file. In particular, it treats man_made=embankment and natural=cliff as linestring, and highway=services as polygon. Including this in the default style.lua file has the following advantages: * It serves as an easy-to-extend example of how the polygon/linestring decision can be made based on key. * It provides sane defaults - it can be expected that most users of the style want to treat man_made=embankment and natural=cliff as linestring, and highway=services as polygon. This resolves the following downstream bugs in openstreetmap-carto: * gravitystorm/openstreetmap-carto#892 * gravitystorm/openstreetmap-carto#268 * gravitystorm/openstreetmap-carto#137 This builds on osm2pgsql-dev#345, and thus assumes osm2pgsql-dev#345 is merged first.
This PR proposes a database-reload. It changes the documentation on the use of osm2pgsql, and adds a .lua file for preprocessing. This database import aims to be backwards compatible with older versions of the style. This resolves (at least part of) gravitystorm#1504. Adding the hstore option to osm2pgsql allows the database to use all keys. This PR proposes using hstore for new keys, and using traditional columns for old keys. This allows us to stay compatible with old versions of the style. According to [@pnorman's benchmarks](http://www.paulnorman.ca/blog/2014/03/osm2pgsql-and-hstore/), using hstore without dropping columns would lead to a 9% size increase and a 0.38% speed decrease. Given the benefits of having all columns available, I would consider this acceptable. This is based on the following unmerged PR to osm2pgsql: osm2pgsql-dev/osm2pgsql#346 It makes the polygon/linestring decision based on the tag value, in addition to the tag key. In particular, highway=services and junction=yes are now treated as polygon, while leisure=track, man_made=embankment, man_made=breakwater, man_made=groyne, natural=cliff, natural=tree_row, historic=citywalls, waterway=derelict_canal, waterway=ditch, waterway=drain, waterway=river, waterway=stream, waterway=wadi, waterway=weir, power=line, and power=minor_line are now treated as linestring. This resolves gravitystorm#1362, resolves gravitystorm#137, resolves gravitystorm#268, and resolves gravitystorm#892. The new .lua file creates a osmcarto_z_order value in the database, which stores the rendering order we use. This will allow us to simplify the road queries. This resolves gravitystorm#59. This resolves gravitystorm#101. The .lua file drops some more meta-information from imports that is of no need for rendering. This is based on the following unmerged PR to osm2pgsql: * osm2pgsql-dev/osm2pgsql#532
This PR proposes a database-reload. It changes the documentation on the use of osm2pgsql, and adds a .lua file for preprocessing. This database import aims to be backwards compatible with older versions of the style. This resolves (at least part of) gravitystorm#1504. #Hstore Adding the hstore option to osm2pgsql allows the database to use all keys. This PR proposes using hstore for new keys, and using traditional columns for old keys. This allows us to stay compatible with old versions of the style. According to [@pnorman's benchmarks](http://www.paulnorman.ca/blog/2014/03/osm2pgsql-and-hstore/), using hstore without dropping columns would lead to a 9% size increase and a 0.38% speed decrease. Given the benefits of having all columns available, I would consider this acceptable. # Make polygon/linestring decision based on value This is based on the following unmerged PR to osm2pgsql: osm2pgsql-dev/osm2pgsql#346 It makes the polygon/linestring decision based on the tag value, in addition to the tag key. In particular, highway=services and junction=yes are now treated as polygon, while leisure=track, man_made=embankment, man_made=breakwater, man_made=groyne, natural=cliff, natural=tree_row, historic=citywalls, waterway=derelict_canal, waterway=ditch, waterway=drain, waterway=river, waterway=stream, waterway=wadi, waterway=weir, power=line, and power=minor_line are now treated as linestring. This resolves gravitystorm#1362, resolves gravitystorm#137, resolves gravitystorm#268, and resolves gravitystorm#892. # Rendering order The new .lua file creates a osmcarto_z_order value in the database, which stores the rendering order we use. This will allow us to simplify the road queries. # Recommend -G flag for multipolygons This resolves gravitystorm#59. # Import ele on buildings This resolves gravitystorm#101. # Delete more meta-tags from imports The .lua file drops some more meta-information from imports that is of no need for rendering. This is based on the following unmerged PR to osm2pgsql: * osm2pgsql-dev/osm2pgsql#532
|
Probably related to #892. |
Cliffs that are closed ways (i.e. start node = end node) are not rendered. They should be rendered in the same style as open-way cliffs, with ticks on the right side. Interpreting them as areas by default makes no sense, because areal cliffs are of historical interest at best. For areas with rock surface, the tag natural=bare_rock has been approved by voting.
See https://trac.openstreetmap.org/ticket/3294 for the history of this bug. It is annoying not only that is has not been fixed for 3 years, but also that the ticket wasn't migrated to the new bug tracking system.
The text was updated successfully, but these errors were encountered: