highway=services is an area #137

al-- · 2013-08-28T15:12:10Z

highway=services implicitely defines an area.

Please render it as an area (but not pink, if possible...).

pnorman · 2013-09-04T11:08:28Z

Just to be clear, is the issue solely one of a default assumption about what is/is not an area?

al-- · 2013-09-04T12:55:12Z

Currently it is not rendered as an area, for instance:

http://www.openstreetmap.org/browse/way/187691678

dieterdreist · 2013-09-04T13:06:22Z

2013/9/4 al-- notifications@github.com

Currently it is not rendered as an area, for instance:

http://www.openstreetmap.org/browse/way/187691678https://f.cloud.github.com/assets/1458456/1080291/216f3a52-1561-11e3-9ce1-9685bf8e1a50.png

you have to add explicitly area=yes to specify it is an area. Current
osm2pgsql doesn't allow for k/v-tags to be defined as area default (only at
key-level). All highway tags are considered non-areas as long as they don't
have an area=yes tag.

gravitystorm · 2013-09-04T13:44:14Z

That's a bug in osm2pgsql then. If highway = services is always an area in openstreetmap, then mappers shouldn't be forced into adding an additional tag just because a particular piece of software can't handle it.

Of course, we can also work around it with a carefully constructed SQL statement, so we might not need any changes to osm2pgsql. But please don't ask mappers to add unnecessary tags!

dieterdreist · 2013-09-04T13:55:00Z

2013/9/4 Andy Allan notifications@github.com

That's a bug in osm2pgsql then. If highway = services is always an area in
openstreetmap, then mappers shouldn't be forced into adding an additional
tag just because a particular piece of software can't handle it.

Of course, we can also work around it with a carefully constructed SQL
statement, so we might not need any changes to osm2pgsql. But please don't
ask mappers to add unnecessary tags!

you are right, but this is a well known limitation of osm2pgsql for years,
there are also other frequently used tags involved, e.g. leisure=track
(this time the other way round). AFAIK it isn't resolved by adding a
tag-level config file to osm2pgsql because devs are hoping for a dedicated
area data type in the next API version. This would also solve situations
(require to better structure them) where people are using the same object
as linear and as polygon feature (e.g. landuse=*, barrier=fence).

pnorman · 2013-09-04T19:55:47Z

Of course, we can also work around it with a carefully constructed SQL statement, so we might not need any changes to osm2pgsql. But please don't ask mappers to add unnecessary tags!

Do we want to be taking this on in osm-carto? If so I can do so, I've written similar statements for addressmerge that do so efficiently

matthijsmelissen · 2014-05-17T17:59:33Z

devs are hoping for a dedicated area data type in the next API version

Has any progress been made with respect to this issue?

gravitystorm · 2014-05-21T10:59:28Z

Has any progress been made with respect to this issue?

I wouldn't hold my breath - if it happens, it'll be 6+ months away.

matthijsmelissen · 2014-07-20T23:57:26Z

@pnorman If you have time, I would be interested to see how the SQL would look like, yes.

matthijsmelissen · 2015-02-16T01:05:36Z

Best done with osm2pgsql on 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.

joakimfors · 2015-04-28T21:10:57Z

Found this in osm2pgsql-dev/osm2pgsql#346

Why should a closed highway=service automatically be treated as area when no other highway= is? I know of a lot of places where service is mapped as closed ways but aren't areas IRL.

HolgerJeromin · 2015-04-28T21:36:05Z

We talk about highway=services not highway=service here :-)

matthijsmelissen · 2015-04-28T22:40:21Z

http://wiki.openstreetmap.org/wiki/Tag:highway%3Dservices

Very confusing, I admit.

joakimfors · 2015-04-29T10:46:25Z

Ah, sorry. I shouldn't comment on issues in the middle of the night. ;)

jojo4u · 2015-07-25T22:11:46Z

Please also treat highway=rest_area as area, it's the small cousin of services (http://wiki.openstreetmap.org/wiki/Tag:highway%3Drest_area).

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.

@pnorman

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

@pnorman

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 added the roads label Apr 14, 2014

23cpo mentioned this issue Jul 14, 2014

Rendering of highway=services got damaged #730

Closed

polarbearing mentioned this issue Sep 2, 2014

render names of highway=services and rest_area #918

Closed

matthijsmelissen added this to the Bugs and improvements milestone Sep 26, 2014

matthijsmelissen modified the milestones: 3.x - Needs upgrade to openstreetmap-carto.style, Bugs and improvements Feb 16, 2015

This was referenced Apr 28, 2015

Set polygon/linestring differently for some key values differently than the key in default style.lua osm2pgsql-dev/osm2pgsql#346

Closed

Plan database re-import #1504

Closed

matthijsmelissen mentioned this issue Apr 3, 2016

Database-reload #2105

Closed

matthijsmelissen mentioned this issue May 16, 2016

Database-reload #2127

Closed

matthijsmelissen mentioned this issue May 16, 2016

Database-reload #2128

Merged

pnorman closed this as completed in d48106e May 10, 2017

naoliv mentioned this issue Jul 31, 2017

Not recognizing highway=services openstreetmap/iD#4194

Closed

openstreetmap-trac mentioned this issue Jul 23, 2021

Wrong rendering of highway=services openstreetmap/trac-tickets#4835

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

highway=services is an area #137

highway=services is an area #137

al-- commented Aug 28, 2013

pnorman commented Sep 4, 2013

al-- commented Sep 4, 2013

dieterdreist commented Sep 4, 2013

gravitystorm commented Sep 4, 2013

dieterdreist commented Sep 4, 2013

pnorman commented Sep 4, 2013

matthijsmelissen commented May 17, 2014

gravitystorm commented May 21, 2014

matthijsmelissen commented Jul 20, 2014

matthijsmelissen commented Feb 16, 2015

joakimfors commented Apr 28, 2015

HolgerJeromin commented Apr 28, 2015

matthijsmelissen commented Apr 28, 2015

joakimfors commented Apr 29, 2015

jojo4u commented Jul 25, 2015

highway=services is an area #137

highway=services is an area #137

Comments

al-- commented Aug 28, 2013

pnorman commented Sep 4, 2013

al-- commented Sep 4, 2013

dieterdreist commented Sep 4, 2013

gravitystorm commented Sep 4, 2013

dieterdreist commented Sep 4, 2013

pnorman commented Sep 4, 2013

matthijsmelissen commented May 17, 2014

gravitystorm commented May 21, 2014

matthijsmelissen commented Jul 20, 2014

matthijsmelissen commented Feb 16, 2015

joakimfors commented Apr 28, 2015

HolgerJeromin commented Apr 28, 2015

matthijsmelissen commented Apr 28, 2015

joakimfors commented Apr 29, 2015

jojo4u commented Jul 25, 2015