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

Add rendering for cycleway areas #3342

Closed
Tomasz-W opened this issue Aug 13, 2018 · 25 comments
Closed

Add rendering for cycleway areas #3342

Tomasz-W opened this issue Aug 13, 2018 · 25 comments

Comments

@Tomasz-W
Copy link

Tomasz-W commented Aug 13, 2018

Combination of highway=cycleway + area=yes is currently not rendered at all. As we render areas of:

  • highway=footway
  • highway=pedestrian
  • highway=path

I think cycleway areas should be included too. At least with the same filling as the ones from list above. Another options are to render them with some red filling like in this visualisation:
http://osmapa.pl/w/area/?lat=51.09433&lon=17.0173&zoom=19&ol=Qq
or with a little bit darker gray shade than footway areas.

Edit: add rendering for area:highway=cycleway is also good solution for me, I just want a complete rendering of one of these tagging schemes.

@kocio-pl kocio-pl added the roads label Aug 13, 2018
@kocio-pl kocio-pl added this to the New features milestone Aug 13, 2018
@dieterdreist
Copy link

dieterdreist commented Aug 13, 2018 via email

@mboeringa
Copy link

I agree with @dieterdreist , it should be area:highway=*, as is also used in the Polish renderer you reference via the link.

@kocio-pl
Copy link
Collaborator

We render other types of highway=* + area=yes and nobody has called it an error. On the other hand rendering of area:highway=* was rejected (#180) and there were strong opinions on avoiding duplicate tagging schemes (lately in #2548).

That's inconsistency either way. I prefer rendering only area:highway=* (which means dropping highway=* + area=yes for all of these cases) as a proper solution.

@dieterdreist
Copy link

dieterdreist commented Aug 14, 2018 via email

@kocio-pl
Copy link
Collaborator

Yes. And what do you think about it?

@dieterdreist
Copy link

dieterdreist commented Aug 14, 2018 via email

@Tomasz-W
Copy link
Author

Tomasz-W commented Aug 14, 2018

@dieterdreist @mboeringa @kocio-pl
I started a discussion about area:highway=* for footways etc. on TL some time ago, and there have been voices that using combination of highway=* + area=yes is not a tagging error. There was an argument that adding area=yes tag for objects which could also be linear (eg. barrier=hedge) is a common agreed method of tagging them.

See: https://lists.openstreetmap.org/pipermail/talk/2018-August/081102.html

As we render footway/ pedestrian/ path areas, cycleway is an illlogical "gap" here, but like @kocio-pl said, we should avoid duplicating tagging schemes, so we should choose the proper one and drop the second.

Dropping of combinations and render a:h=* is also good solution for me, I just want us to establish one propper tagging scheme supported by default style.

@dieterdreist
Copy link

dieterdreist commented Aug 14, 2018 via email

@mboeringa
Copy link

mboeringa commented Aug 14, 2018

I agree hedges may be different, still what I wrote about the different meaning is established interpretation at least in Italy.

I don't think this is just in Italy, this is the more general interpretation in many countries, including I think in Poland based on the tagging applied there.

A highway=pedestrian + area=yes can in fact be subdived in many small areas of area:highway=pedestrain + surface=x.

E.g. imagine a big plaza tagged with highway=pedestrian + area=yes + name="OUR_PLAZA" to mark out the entire extent of the plaza. This plaza could have several different areas with a different surface.

E.g.:

  • The northern part of the plaza functions as an exclusive pedestrian area and has cobblestones:
    area:highway=pedestrain + surface=cobblestone
  • The southern part of the plaza doubles as a parking place and has paving stones:
    area:highway=pedestrain ( / possible alternative - area:highway=service) + surface=paving_stones + amenity=parking
  • The north-western part has a small recreational area where people play boules and again has distinct surface:
    area:highway=pedestrain + surface=fine_gravel + leisure=recreation_ground + sport=boules

As you can see, in most cases, it is highly advisable to add the surface=x tag when using area:highway.

Also note that each feature is distinct here. The highway=pedestrian + area=yes + name="OUR_PLAZA" feature is not equivalent to any of the area:highway=x features.

@Tomasz-W
Copy link
Author

Tomasz-W commented Aug 14, 2018

@mboeringa @kocio-pl Can you join to ML discussion from link above and present your arguments for area:highway=* scheme? There is not so much people strictly decided on combination scheme, so I think we can make it for a:h=*.

@polarbearing
Copy link
Contributor

@Tomasz-W - do you have a real-world example which is tagged cycleway + area=yes that is dedicated to omnidirectional cycle traffic?

I haven't seen such a case so far. People on foot have a slower mode of locomotion, thus an omnidirectional area makes sense: as a pedestrian area to stroll from shop to shop, or as a widened areal in the middle of a park. On a service way, area=yes is often used in industrial estates where you have large areas for trucks to manoeuvre.

I mean, we don't need to code a case that is just a theoretical combination of keys.

@Tomasz-W
Copy link
Author

Tomasz-W commented Aug 14, 2018

@polarbearing You seem to don't understand the idea. Way's direction, its access, wheelchair access, lit or no-lit, etc. is tagged in highway=* way (which correctly mapped is "flowing" through area middle), and area:highay=* area is just for visual area shape representation, so way's direction doesn't matter to area tagging.

@kocio-pl
Copy link
Collaborator

kocio-pl commented Aug 14, 2018

I'm not ready to discuss it outside this ticket yet. The arguments given here are interesting and I have to think about them more:

  • if a:h is really different than h=c + a=y?
  • if h=c + a=y is rarely used it may indicate that something is wrong with this scheme (or just that nobody cares, for example because it's not rendered)

On the other hand if h=c + a=y is not wrong, I want to have it included to cover complete highway solution. I don't like adding rendering case by case without thinking about the whole system, I think this is old bad habit.

@polarbearing
Copy link
Contributor

area:highay=* area is just for visual area shape representation

Correct, but your original issue was to render area=yes.

if h=c + a=y is rarely used it may indicate that something is wrong with this scheme

No it just indicates that this feature does not exist in the real world for cycleways, otherwise please point to an example of such feature.

if a:h is really different than h=c + a=y?

Yes. the first is the shapes regardless of traffic, the second describes omnidirectional traffic.

@Tomasz-W Tomasz-W changed the title Add rendering for highway=cycleway areas Add rendering for cycleway areas Aug 15, 2018
@Tomasz-W
Copy link
Author

@matkoniecz You have been quite active on this topic (OSM edits converting area=yes to a:h=*, forum posts), so I'm tagging you as you may be interested in ;)

@kocio-pl
Copy link
Collaborator

kocio-pl commented Aug 24, 2018

Yes. the first is the shapes regardless of traffic, the second describes omnidirectional traffic.

I don't think so looking at numbers:

https://taginfo.openstreetmap.org/tags/area=yes#combinations

30.55% | highway=*
13.90% | highway=pedestrian
4.65% | highway=footway
4.21% | highway=service
2.28% | highway=residential

It looks like ~21% (2/3) is about omnidirectional traffic, but I guess residential or unclassified are not.

So this tag seems to be used for different uses and I guess rendering some of them makes the bias toward omnidirectional traffic, but it's still just 2:1.

@polarbearing
Copy link
Contributor

Trying to understand what you mean. Taginfo shows that area=yes is used in a lot of unnecessary combinations, it makes no sense e.g. on natural=bare_rock as that is an area by definition. This might come from bad imports.

area=yes on a highway is supposed to describe the omnidirectional traffic.
area=yes is not shown by taginfo in combination with highway=cycleway (i.e. <1000), and we have not been pointed to a single real-world example where that would be needed.

thus I think we can close the issue.

@dieterdreist
Copy link

dieterdreist commented Aug 26, 2018 via email

@Tomasz-W
Copy link
Author

I think that rename the issue to "Add rendering for area:highway=cycleway" would be better.

@polarbearing
Copy link
Contributor

That's a completely different thing and a dup of #180.

@Tomasz-W
Copy link
Author

That ticket was about adding rendering for whole area:highway=* key, and this one is for area:highway=cycleway only, so it's not a duplicate.

@polarbearing
Copy link
Contributor

Well but I'd not start rendering area:highway=cycleway as an exception without deciding about area:highway=* as a whole.

@geostonemarten
Copy link

area:highway=* is a micromapping and is totally an other strategy
it can be a parallele to linear schema and twice representation is in my sens not compliant.
This solution is for me a replacement of linear with specific scale and this is possible for a 19 20 zoom level
But in replacement of existing polylines

noboby area:highway have a representation a moment.

There is an other problem with overlapped same data one line and one closed line with area = yes

for exemple :
https://www.openstreetmap.org/search?query=montpellier#map=19/43.60377/3.91730

@jeisenbe
Copy link
Collaborator

jeisenbe commented Sep 5, 2019

The combination highway=cycleway + area=yes is only used 179 times on ways and relations, according to the linked overpass-turbo search. Discussion about rendering area:highway=cycleway can continue at #180, if desired.

@jeisenbe jeisenbe closed this as completed Sep 5, 2019
@dieterdreist
Copy link

dieterdreist commented Sep 5, 2019 via email

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

No branches or pull requests

8 participants