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.

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

Problems with rendering "highway=track; area=yes" (and to a lesser extent other highway types) #1967

Closed
SomeoneElseOSM opened this issue Nov 10, 2015 · 19 comments · Fixed by #4096
Labels

Comments

@SomeoneElseOSM
Copy link
Contributor

Essentially, the problem is this:

"highway=blah; area=yes" is rendered by OSM carto, and "area:highway=blah" is not. The former is intended for "true" highway areas (pedestrian plazas etc.); the latter for adding the "width" of linear highways (a bit like "waterway=riverbank" is on "waterway=river"). The problem is, as discussed on #180 and the links from there such as #1504 , area:highway can't be supported yet, so people are using "highway=blah; area=yes" on linear features.

In some cases (pedestrian plazas) it's perfectly valid; in others (track, cycleway) it surely isn't. Here's an example I found today:

http://www.openstreetmap.org/#map=17/53.23152/-0.48302

(for completeness I tried to explain the problem on https://www.openstreetmap.org/changeset/35066497 ).

It's a similar logic to used at #1280 (comment) - if OSM Carto renders something, it is in some sense a "seal of approval"; we all see that mappers shouldn't "tag for the renderer" but we all know that many tag specifically for OSM Carto, and a specific goal of CARTOGRAPHY.md is to provide a "feedback mechanism for mappers to validate their edits".

So, which of the "current highway area values" (which I suspect is the list at

'highway_' || (CASE WHEN highway IN ('residential', 'unclassified', 'pedestrian', 'service', 'footway', 'cycleway', 'track', 'path', 'platform') THEN highway ELSE NULL END)),
) are really valid?

I'd suggest 'residential', 'unclassified', 'pedestrian', 'service', 'platform' only; can anyone point to a real-world feature that's validly mapped as an area=yes highway (i.e. is not primarily a linear feature) that is 'footway', 'cycleway', 'track', or 'path'?

@jojo4u
Copy link

jojo4u commented Nov 10, 2015

I'd remove residential und and unclassified as well. I never considered area=yes valid for these. What's the difference in area mapping between unclassified and tertiary?

@pnorman
Copy link
Collaborator

pnorman commented Nov 11, 2015

I'd also agree with removing footway, cycleway, track, and path area rendering.

@dieterdreist
Copy link

2015-11-11 10:30 GMT+01:00 Paul Norman notifications@github.com:

I'd also agree with removing footway, cycleway, track, and path area
rendering.

me too. For footway and path there isn't actually a difference to
pedestrian areas (and what applies to tracks and cycleways applies also to
them), and track and cycleway areas aren't by definition tracks or
cycleways, they are areas of some kind. To map them as areas the tag is
area:highway, not highway.

@HolgerJeromin
Copy link
Contributor

http://www.openstreetmap.org/way/33197964#map=19/50.78979/6.07294 and
http://www.openstreetmap.org/way/24729133#map=19/50.78581/6.08194 (image)
these are footway areas around viewpoints. Usable only via foot and iirc surface=compacted.
Adding a second linear footway seems like mapping for osm-carto.
Replacing with a linear footway is loosing data.
retagging as a highway=pedestrian area does not fit the definition very good:
"Typical in shopping areas, town centres, places with tourism attractions and recreation/civic areas, where wide expanses of hard surface are provided for pedestrians to walk."

@jojo4u
Copy link

jojo4u commented Nov 11, 2015

highway=* + area=yes should only be supported for highway types which often are not linear. If a highway can be somehow represented by a linear way, it's better to use area:highway=* for the area representation instead. It's a proposal but it's gaining support with 35.000 occurences as of now.

From http://wiki.openstreetmap.org/wiki/Proposed_features/Street_area#Note_on_area.3Dyes

Don't use area:highway=* for plazas and similiar features. These are described by highway=* combined with area=yes, while area:highway=* combined with area=yes is incorrect. Use area:highway=* only to add an area representation for linear highways where a way tagged highway=* without area=yes exists. This applies mostly but not exclusively to highway=pedestrian and highway=footway.

@dieterdreist
Copy link

2015-11-11 10:47 GMT+01:00 Holger Jeromin notifications@github.com:

retagging as a highway=pedestrian area does not fit the definition very
good:
"Typical in shopping areas, town centres, places with tourism attractions
and recreation/civic areas, where wide expanses of hard surface are
provided for pedestrians to walk."

maybe this wiki definition could be improved. A pedestrian area can occur
wherever, no need to restrict it to shopping areas and town centres. On the
other hand, "tourism attraction" seems to fit on your case.

I also wouldn't insist on "hard surface" for pedestrian areas (there are
some with soft surfaces, e.g. rubber, wood chips) but again, it would fit
on your "compacted surface".

@matkoniecz
Copy link
Contributor

I noticed highway=footway + area=yes used for smaller squares - I also added some.

Maybe it may be treated as a tagging mistake.

See for example http://www.openstreetmap.org/way/25463980#map=19/50.05699/19.93507

selection_001

According to taginfo it is used 28 690 times.

@BalooUriza
Copy link

On Wed, Nov 11, 2015 at 3:30 AM, Paul Norman notifications@github.com
wrote:

I'd remove residential und and unclassified as well. I never considered

area=yes valid for these.

I'd also agree with removing footway, cycleway, track, and path area

rendering.

What about the case of free-flowing plazas with no traffic control? These
are often a traffic calming feature on minor (tertiary and smaller, and
even some cycleway cases) ways. https://en.wikipedia.org/wiki/Shared_space

@dieterdreist
Copy link

2015-11-11 11:45 GMT+01:00 BalooUriza notifications@github.com:

What about the case of free-flowing plazas with no traffic control? These
are often a traffic calming feature on minor (tertiary and smaller, and
even some cycleway cases) ways. https://en.wikipedia.org/wiki/Shared_space

looking at the pictures, they don't seem to be very "free" flow, cars all
lined up to the right. Any Italian city has more free flow without
explicitly stating it ;-)

Seriously, if these areas abandon the idea that vehicles have to keep on
the right (or left in the "odd" countries) and you can go in whatever
direction I agree that area=yes on a road tag makes sense.

Cheers,
Martin

@jojo4u
Copy link

jojo4u commented Nov 11, 2015

Highway=pedestrian is not synonym to every "footway area". The tag refers to pedestrian zones and I added the Wikipedia link and the more verbose introduction from wikipedia in the wiki. The examples from HolgerJeromin don't fit highway=pedestrian.

@kocio-pl
Copy link
Collaborator

I would be cautious with dropping pedestrian and footways with area=yes, because many times (much more than in case of vehicle highways) they have complicated forms and routing traces are just a second guess looking at the shape. I like to ultimately adopt area:highway notation, but I also think it's better to make a smooth transition than just drop things.

First thing I would like to know before making such changes is when we could have database reload, but currently we have no slightest idea about it.

@HolgerJeromin
Copy link
Contributor

shared spaces are IMO perfectly modeled as an pedestrian area and a normal linear car highway (as the cars are mostly using the space linear).

@BalooUriza
Copy link

On Wed, Nov 11, 2015 at 5:19 AM, dieterdreist notifications@github.com
wrote:

2015-11-11 11:45 GMT+01:00 BalooUriza notifications@github.com:

What about the case of free-flowing plazas with no traffic control? These
are often a traffic calming feature on minor (tertiary and smaller, and
even some cycleway cases) ways.
https://en.wikipedia.org/wiki/Shared_space

looking at the pictures, they don't seem to be very "free" flow, cars all
lined up to the right. Any Italian city has more free flow without
explicitly stating it ;-)

Seriously, if these areas abandon the idea that vehicles have to keep on
the right (or left in the "odd" countries) and you can go in whatever
direction I agree that area=yes on a road tag makes sense.

That would be the case for a few odd cycleway examples in the Tulsa area
(of which I'm not sure if I've mapped to that level yet). Usually the
approach would be a sign indicating SLOW and a rumble strip followed by a
free flow area, with traffic control resuming on the other end of the plaza
with another rumble strip. These can be quite chaotic on busy days.

@matthijsmelissen
Copy link
Collaborator

I suppose this could qualify as highway=cycleway, area=yes: http://www.dichtbij.nl/content/images/Large/13500345_635683343096757352.jpg
The blue sign says 'Fietspad' which means 'Bike path'.

@dieterdreist
Copy link

2016-03-07 23:25 GMT+01:00 math1985 notifications@github.com:

I suppose this could qualify as highway=cycleway, area=yes:
http://www.dichtbij.nl/content/images/Large/13500345_635683343096757352.jpg
The blue sign says 'Fietspad' which means 'Bike path'.

Isn't the usage of the word "path" a clear indication that this isn't an
"area" but rather a linear object? Are you allowed to drive in any
direction or do you have to remain in a certain space (e.g., can you pass
on the left of another cyclist that goes in the opposite direction as you?).

@matkoniecz
Copy link
Contributor

In some cases (pedestrian plazas) it's perfectly valid; in others (track, cycleway) it surely isn't.

I encountered places where highway=track + area=yes would be correct rendering. For example large areas where logging equipment was moving, stored, used to unload/load wood etc. Second case would be places similar to pedestrian squares in function but on highway=track in the forest.

Both are rare but it certainly happens.

@matkoniecz
Copy link
Contributor

Isn't the usage of the word "path" a clear indication that this isn't an "area" but rather a linear object?

Most likely "bike path" is legal term.

Are you allowed to drive in any direction or do you have to remain in a certain space (e.g., can you pass on the left of another cyclist that goes in the opposite direction as you?).

I am not sure what would lawyer say but in Poland in similar cases "drive in any direction" is true (these places are not tagged highway=cycleway + area=yes as these are pedestrian areas with allowed cycling, or in some cases cycling is in theory forbidden).

@dieterdreist
Copy link

sent from a phone

Il giorno 08 giu 2016, alle ore 22:09, Mateusz Konieczny notifications@github.com ha scritto:

I encountered places where highway=track + area=yes would be correct rendering. For example large areas where logging equipment was moving, stored, used to unload/load wood etc.

I'm sure there is a better tag (to develop) for facilities like this, rather than track area

@jeisenbe
Copy link
Collaborator

places where highway=track + area=yes would be correct rendering. For example large areas where logging equipment was moving, stored, used to unload/load wood etc.

These are temporary features, usually only in use for a few months while logging operations are in progress. They are more like a parking lot or industrial area. The current highway=track +area=yes rendering does not work well, because tracks are rendered as a thin brown line, usually dashed, and this does not make much sense when it suddenly widens to large brown area with track-color casing and #cdbea0 fill.

I am in favor of removing this rendering.

For the highway=footway areas, generally highway=pedestrian is more appropriate - a footway should be too narrow for a 2-track motor vehicle to comfortably travel.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
10 participants