failed display of closed way, unclosed way works (multiple affected tags) #1362
Labels
Milestone
Comments
matkoniecz
changed the title
|
A closed-way waterway=dam could make sense in some circumstances. One example that comes to mind is the dam around some tailings ponds, which are often completely man-made and enclose the pond in a closed loop. I'll see if I can find one that has been mapped in OSM. |
|
power=line and power=minor_line might also make sense as closed loop, if there is redundancy built in the network. As opposed to rivers, power lines are not directional. |
|
Example for power=line: www.openstreetmap.org/way/239134263 Waterway=dam is fixed by #991. |
matthijsmelissen
changed the title
|
Also closed ways tagged with highway=raceway & sport=motor are not shown... |
@pnorman Would using hstore and dropping sport fro the tag list be a solution to that? |
matthijsmelissen
modified the milestones:
Bugs and improvements,
3.x - Needs upgrade to Mapnik
|
See also osm2pgsql-dev/osm2pgsql#346 (comment). |
Closed
matthijsmelissen
added a commit
to matthijsmelissen/openstreetmap-carto
that referenced
this issue
May 16, 2016
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
Closed
matthijsmelissen
added a commit
to matthijsmelissen/openstreetmap-carto
that referenced
this issue
May 16, 2016
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
Merged
pnorman
modified the milestones:
3.x - Needs upgrade to openstreetmap-carto.style,
3.x - Needs upgrade to Mapnik
5 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
It affects:
historic=citywalls
man_made=breakwater
man_made=embankment (also #892)
man_made=groyne
natural=cliff (also #268)
natural=tree_row
waterway=derelict_canal
waterway=ditch
it affects also this tags, but in such cases closed way is tagging that makes no sense:
waterway=dam
waterway=drain
waterway=river
waterway=stream
waterway=wadi
waterway=weir
power=line
power=minor_line
This list should contain all affected primary tags, but it is possible that additionally also some tag combinations are affected. Already reported:
Administrative boundaries not being rendered for closed ways #713
The boundary=national_park tag is not rendered when tagged on a closed way (not a relation) #1141
The text was updated successfully, but these errors were encountered: