Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

man_made=embankment is not rendered if it's a closed way #892

Closed
kocio-pl opened this issue Aug 18, 2014 · 3 comments
Closed

man_made=embankment is not rendered if it's a closed way #892

kocio-pl opened this issue Aug 18, 2014 · 3 comments
Labels
landcover
Milestone
Database layout c...

Comments

@kocio-pl
Copy link
Collaborator

man_made=embankment is rendered only when it's an open way, but not if it's a closed way. I think it should be visible in both cases, since sometimes embankment can be seen from all sides, not only as left/right edges - it also may be used to indicate there is a big "hole" in the ground.
@pnorman
Copy link
Collaborator

pnorman commented Aug 18, 2014

I believe osm2pgsql will put man_made=embankment into the polygon table. We could still pull it from there and transform it to a linestring if necessary, but that might be messy.

@ghost ghost mentioned this issue Aug 18, 2014
Closed
@matthijsmelissen matthijsmelissen modified the milestones: 3.x - Needs upgrade to openstreetmap-carto.style, Bugs and improvements Feb 16, 2015
@matthijsmelissen
Copy link
Collaborator

Best solved with osm2pgsql lua file. Moved to corresponding milestone.

@matkoniecz matkoniecz mentioned this issue Mar 10, 2015
Closed
matthijsmelissen added a commit to matthijsmelissen/osm2pgsql that referenced this issue Apr 28, 2015
@matthijsmelissen
Allow polygon/linestring decision to be set by value in lua
926d32c 
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.
matthijsmelissen added a commit to matthijsmelissen/osm2pgsql that referenced this issue Apr 28, 2015
@matthijsmelissen
Allow polygon/linestring decision to be set by value in lua
60a53c9 
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 was referenced Apr 28, 2015
Closed
Closed
matthijsmelissen added a commit to matthijsmelissen/osm2pgsql that referenced this issue Apr 28, 2015
@matthijsmelissen
Allow polygon/linestring decision to be set by value in lua
09fed4e 
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.
matthijsmelissen added a commit to matthijsmelissen/osm2pgsql that referenced this issue Feb 21, 2016
@matthijsmelissen
Allow polygon/linestring decision to be set by value in lua
6e70881 
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.
matthijsmelissen added a commit to matthijsmelissen/osm2pgsql that referenced this issue Apr 3, 2016
@matthijsmelissen
Allow polygon/linestring decision to be set by value in lua
bc7a0cd 
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.
@matthijsmelissen matthijsmelissen mentioned this issue Apr 3, 2016
Closed
matthijsmelissen added a commit to matthijsmelissen/openstreetmap-carto that referenced this issue May 16, 2016
@matthijsmelissen
**This is a pull-request against the lua branch**
6427fc8 
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
@matthijsmelissen matthijsmelissen mentioned this issue May 16, 2016
Closed
matthijsmelissen added a commit to matthijsmelissen/openstreetmap-carto that referenced this issue May 16, 2016
@matthijsmelissen
**This is a pull-request against the lua branch**
d767022 
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
@matthijsmelissen matthijsmelissen mentioned this issue May 16, 2016
Merged
@kocio-pl
Copy link
Collaborator Author

Simple solution for now was adding area=no:

http://www.openstreetmap.org/way/296610960

The idea came from this object:

http://www.openstreetmap.org/way/219234636

@kocio-pl kocio-pl mentioned this issue Dec 15, 2016
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
landcover
Projects
None yet
Milestone
Database layout change
Development

Successfully merging a pull request may close this issue.

Database-reload matthijsmelissen/openstreetmap-carto
3 participants
@pnorman @matthijsmelissen @kocio-pl