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

Rendering of area:highway #180

Closed
scaidermern opened this issue Sep 20, 2013 · 66 comments
Closed

Rendering of area:highway #180

scaidermern opened this issue Sep 20, 2013 · 66 comments
Labels

Comments

@scaidermern
Copy link

It would be nice to see a rendering of the area:highway key. The rendering rules are similar to the regular highway key, including the highway class, except that this key applies to areas only (and should not be used for routing).

@dieterdreist
Copy link

if this should be rendered, there should be no casing (because of arbitrary intersecting lines coming from closing the polygons). Or use the area relation for this (type=area)

@theonlytruth
Copy link

area:highway is just a proposed feature. In my opinion the right solution is highway=* + area=yes

So from my side I would wish no rendering of this beta status key.

@dieterdreist
Copy link

2013/9/20 theonlytruth [email protected]

highway=* + area=yes

no, it is (more or less) agreed that this has different semantics: it is a
non-directional traffic space, accessibile by vehicles (unless highway is
pedestrian) but not a (directional) road. The intention of area:highway was
actually to avoid misinterpretations and to allow clear distinction between
a square and a road drawn as area.

@pnorman
Copy link
Collaborator

pnorman commented Sep 20, 2013

area:highway is just a proposed feature

That's not a particularly important consideration.

I support adding it because it should help reduce misuse of highway=* + area=yes, but the problem is how to go about adding it on the osm2pgsql side. Thoughts?

@dieterdreist
Copy link

Thoughts?

on the German tile server everything is hstore now with a very reduced style for columns, not sure if this performance wise could be an option for the main tile server as well, you surely gain a lot of flexibility

@pnorman
Copy link
Collaborator

pnorman commented Sep 20, 2013

I've been thinking about that - the obvious issue is that even though you can use a view to get a table identical to the current ones, you want to rewrite any query pulling from the hstore to be more efficient.

Something new like this would be 3.0+, so we've got some time to consider.

@scaidermern
Copy link
Author

I support adding it because it should help reduce misuse of highway=* + area=yes

Thats the main reason why I created this issue.

@matthijsmelissen
Copy link
Collaborator

Is there support for this to be implemented? Should it be rendered the same as highway=XXX area=yes?

@matthijsmelissen matthijsmelissen added this to the 3.x - Needs upgrade to mapnik or openstreetmap-carto.style milestone May 26, 2014
@dieterdreist
Copy link

This is a hard question, because given that the mapnik rendering is defacto
determining how people map, implementing this could result in people being
satisfied with only an area mapped (and rendered), therefor breaking our
routing in the long run.

On the other hand it seems reasonable and logical to map highways also as
areas, given the level of detail our map has reached in certain areas (why
should everything "extended" be mapped as area except streets?).

@matkoniecz
Copy link
Contributor

It probably would not look well on lower zooms. Anyway, note that selecting any tagging scheme to be rendered means that only this will be used.

@floscher
Copy link
Contributor

@dieterdreist wrote:
This is a hard question, because given that the mapnik rendering is defacto determining how people map, implementing this could result in people being satisfied with only an area mapped (and rendered), therefor breaking our routing in the long run.

If area:highway is only rendered at high zoomlevels, this would not be a big problem, as the lower zoomlevels would still depend on the linear highways.

@daganzdaanda
Copy link

I think sooner or later we will need rendering for highway areas. It's just a logical next step. Already, aerial images are good enough in lots of places.
It should only be visible in z19, and not be used for drawing anything at 18 or less. Then, people will not forget to put in the regular highways :)

What the best tagging is, I don't know. What are the alternatives?
area:highway or maybe landcover=something or...? IMHO area=yes is better only used for pedestrian areas, or maybe not at all if there are better alternatives.

@kocio-pl
Copy link
Collaborator

kocio-pl commented Feb 9, 2015

I think this proposal:

https://wiki.openstreetmap.org/wiki/Proposed_features/Street_area

is interesting to deploy, since it's more developed at the general level, however it may lack some tagging. In the (mostly duplicate) #1298 ticket I gave the link to demo rendering script for Maperitive:

https://github.com/javnik36/highway-area-style

and additional proposition:

"I have also the idea to drop colouring by street type then (on highest zoom only) and start rendering them by surface type - I think that plus the real width and geometry would be more useful in micro scale."

@kocio-pl
Copy link
Collaborator

I know that we still wait for database update, but there are some real data rendering examples added lately and we could get some ideas how should we render such areas.

@Marekkleciak
Copy link

We have for today 62418 area:highway in the map.
We have enough test cases for further discussion. Check cites Szczecin and Wrocław e.g. here:
http://osmapa.pl/w/area/?lat=51.08998&lon=17.01772&zoom=17&ol=QqEFBAG

@kocio-pl
Copy link
Collaborator

kocio-pl commented Sep 3, 2016

Starting with basics, I like general colors used on osmapa.pl, related to physical features:

  • dark grey pattern for roads
  • red for cycling paths
  • white-and-grey pattern for footways/pedestrian area
  • light grey for traffic islands.

Any other ideas?

@Ircama
Copy link
Contributor

Ircama commented Sep 3, 2016

  • red for cycling paths

One think I would invite to consider (or at least to avoid precluding) is a future possibility to accommodate the representation of signed walking routes together with the already implemented rendering for highways. Being able to get over this challenge will provide new exceptional value to the map for many users. This is currently a default representation in traditional topographic outdoor maps targeted to hiking and mountain biking, where signed routes are generally represented with some kind of vivid or cardinal red color
(e.g., http://www.cicloweb.net/iti1gardavr.jpg or
http://3.bp.blogspot.com/-rChlsq-Mb1M/VoZlBPNdFqI/AAAAAAAAFDk/CUzXh5xomY0/s1600/Boccaor-Val%2Bd%2527Archeset-Val%2Bdelle%2BMure.jpg).

Related tags to be processed are here http://wiki.openstreetmap.org/wiki/Hiking and here http://wiki.openstreetmap.org/wiki/Walking_Routes. Namely, osmc:symbol, ref, symbol, operator, network in case of highway=track or highway=path, which should generate red routes with optional road shield and related refs text.

So, providing space for such color within routes (including cycling paths) would be really good IMHO.

@kocio-pl
Copy link
Collaborator

kocio-pl commented Sep 3, 2016

I think that cycling paths can be also orange. But first I'd like to know if we plan to render any routes - I guess universal style is not about searching and guiding, rather explaining the space.

I think we have public transport and cycling layers on OSM.org exactly because of this, we need probably another layer just for hiking there. In the meantime there are some independent specialized maps like Hike&Bike or OpenTopoMap.

@Ircama
Copy link
Contributor

Ircama commented Sep 11, 2016

In the meantime there are some independent specialized maps like Hike&Bike or OpenTopoMap.

Yes I know. I really admire the achievements of those specialized maps.

@mboeringa
Copy link

Please note that implementing area:highway is only really useful if this includes proper rendering according to the layer=x tag. If this tag is not respected in the rendering, many complex highway junctions with multiple flyovers will become illegible random stackings of highway areas.

Additionally, it is likely man_made=bridge must be rendered according to layer=x as well.

Both of these can be a major challenge to implement. I have succeeded in adding this functionality to my ArcGIS Renderer, and this was quite a job, but I don't know what the consequences are for the carto style...

@d1g
Copy link

d1g commented Sep 29, 2016

@pnorman, I would say more if area:higway=* will get support in openstreetmap-carto I would expect drop in area=yes together together with highway=*.

area:higway was never supported by openstreetmap-carto, right?

@ZLima12
Copy link

ZLima12 commented Jun 8, 2020

This seems to have been forgotten about. I don't think that the average user would consider this to be too much detail, especially if it is only rendered at the highest zoom level. In some public parks, for example, this could add a nice level of detail.

@imagico
Copy link
Collaborator

imagico commented Feb 4, 2021

One option to address this (kind of) would be to render area:highway polygons in a uniform styling in (or immediately above) the landcover layer. That would be a bit like #3872 (which we gave up on highway polygons) but with uniform styling and only for the area:highway polygons.

This way we would be able to provide visual feedback on the mapping but without running into the various problems mentioned above.

@jeisenbe
Copy link
Collaborator

jeisenbe commented Feb 4, 2021

without running into the various problems mentioned above.

Would there be no casing? How would we handle situations where multiple layers of area:highway= are mapped on top of each other, e.g. where there are bridges or tunnels?

@dieterdreist
Copy link

dieterdreist commented Feb 4, 2021 via email

@dieterdreist
Copy link

dieterdreist commented Feb 4, 2021 via email

@imagico
Copy link
Collaborator

imagico commented Feb 4, 2021

Would there be no casing? How would we handle situations where multiple layers of area:highway= are mapped on top of each other, e.g. where there are bridges or tunnels?

It would all be flatly rendered in uniform color in or directly above the landcover layer so there would be no layering issues, artefacts due to interference with linear highway mapping or added complexity in the already complex roads layers.

An overall outset casing would be possible but IMO probably not desirable - it would hardly provide additional feedback, would add noise and could be prone to confusion and ugly interference with line feature rendering like barriers.

The idea would be to acknowledge and provide basic feedback on the data that is being entered but equally acknowledge and not try to ignore that neither consistency in established mapping conventions nor our technical constraints here in combination with our goals allow more specific rendering.

@dieterdreist
Copy link

dieterdreist commented Feb 4, 2021 via email

@Marekkleciak
Copy link

We could use color table with different grey colors for area:highway= and layer =< n>
For instance:
image
If somebody her could try the look in one complicated situation?

@imagico
Copy link
Collaborator

imagico commented Feb 4, 2021

in lower zoom levels these would usually be covered by the linear highways, but in levels like 18 I imagine artefacts due to linear highways covering partly or almost the road areas, you would have tiny bits visible here and there below the highways and their casing.

That depends on the highway type and latitude. For footways/tracks the polygon rendering would be visible fairly early already - like in case of the example mentioned in #4316. In case of larger roads it would be visible starting at z16-z18 depending on latitude. It would not be more of an artefact than with existing landcover rendering where it is not mapped up to the road center so it shows as negative space.

@matkoniecz
Copy link
Contributor

We could use color table with different grey colors for area:highway= and layer =< n>

This is problematic as layer tag is solely about relative layer of object at the same location. This would unilaterally redefine this tag to have different semantics.

@ZLima12
Copy link

ZLima12 commented Apr 2, 2021

If anyone needs a good test case for this, see this park that I mapped. I think it would look great here.

@krolinventions
Copy link

@pnorman Sorry for creating a new issue, I though the others which are years/decades old would perhaps be outdated.

What would the next steps for me be if I would want to pursue this (and put some effort in)?

Would you accept a PR? I would not mind giving it a try even if it turns out that it would have to be declined (for example, because it turns into a mess).

Would I have to find consensus on the way this is mapped or are we fine in this regard?

Is there another place I should go to discuss this?

@imagico
Copy link
Collaborator

imagico commented Apr 15, 2024

What would the next steps for me be if I would want to pursue this (and put some effort in)?

To bring forward any new arguments on the matter here without reiterating discussions we already had. In addition to the discussion above there is significant further context to consider, a summary of some of it can be found in #172 (comment). Other aspects are mentioned in #4948 (comment)

Generally speaking the OSM-Carto road rendering system is complicated - but despite this complexity has numerous limitations. A discussion of most of this can be found in https://imagico.de/blog/en/navigating-the-maze-part-1/.

Would you accept a PR?

I would strongly suggest to discuss whatever concept you have for rendering before investing into a concrete implementation. Various arguments regarding various ideas have already been discussed so make sure you take them into consideration.

Would I have to find consensus on the way this is mapped or are we fine in this regard?

Is there another place I should go to discuss this?

A renewed look what the de facto semantics and use patterns of these tags would definitely be helpful, not only for OSM-Carto. Documentation on the OSM wiki is largely consisting of prescriptive ideas on tagging rather than documentation on how tags are actually used. Last time i looked a lot of area:highway essentially implemented manual buffering of constant width roads while there does not seem any consensus (or attempts to build consensus) on if that is a suitable way of mapping or not. In terms of aggregated use numbers all area:highway tags together are currently used 268k times. Compared to that the width tag on highway=* (which we don't render either) is used 2.75M times.

By far the most commonly tagged value of area:highway is footway - which bears the question of the semantic delineation between area:highway=footway and highway=footway on polygons (which we render - with the constraints of our current handling of road polygons). This is especially the case since many of the area:highway=footway polygons in the database contain junctions.

Discussions on how things should be tagged and mapped should go to different places, ideally where a broad range of mappers can be reached.

@krolinventions
Copy link

@imagico Thank you! I've read those links and I'm not discouraged yet.

I would try the simplest possible solution. The area should be drawn just before (below) the road. I would not mind the way of the road showing over top of the road area. For cycle paths and footpaths this is completely fine and this will even make the map easier to read. A future enhancement could be to detect if there is road area and use a less obtrusive way of drawing the way itself.

I've tested highway=footway area=yes. Those don't show up for me. The only thing I can get to show up is highway=pedestrian area=yes. See https://www.openstreetmap.org/changeset/150052388#map=19/52.16667/4.47920 for an experiment with area highways.

I've done some initial research in some cities on the area=yes and the area:highway using overpass, and the vast majority of the area=yes usage is pedestrian zones. Which isn't surprising as there is consensus over those. This means that for all other highway types the area:highway is much more common.

It looks like that for half of Manhattan all the sidewalks are mapped as highway=pedestrian area=yes so maybe I should just use that for now and see if I get complaints. Changing the tags on an area isn't that much work anyway if the consensus shifts.

I'll report back if this works well enough for me or if I really need cycle paths and traffic islands to show up. Leaving the road itself as a void works fine for me, I don't care too much about cars anyway.

@dieterdreist
Copy link

dieterdreist commented Apr 15, 2024 via email

@imagico
Copy link
Collaborator

imagico commented Apr 15, 2024

I would try the simplest possible solution. The area should be drawn just before (below) the road.

Rendering all area:highway=* polygons flatly below all roads (essentially like a landuse=road mapping) has already been discussed - see #180 (comment).

I've tested highway=footway area=yes. Those don't show up for me.

It quite clearly does:

https://imagico.de/map/styleinfo/#style=osmcarto&section=tags&key=highway&value=footway&ftype=polygon
https://www.openstreetmap.org/way/436187783

@krolinventions
Copy link

@imagico I see you mentioned it, but I don't see what problems with it were discovered? The replies to it look positive to me.

I wonder what went wrong with highway=footway area=yes for me. I probably just tagged it wrong.

@dieterdreist I know it's not the same - but it's not too wrong and at least it shows up. GraphHopper seems to route along the edges sometimes but that's not too distracting. Actually on a sidewalk you can walk wherever you want anyway. If Carto gets support for area:highway I'd definitely switch to that.

@imagico
Copy link
Collaborator

imagico commented Apr 16, 2024

I see you mentioned it, but I don't see what problems with it were discovered?

No one has so far made a compelling case how this would be beneficial for the goals of this project. It was brought up as a potential way to avoid the various technical problems mentioned while still formally adding rendering support for the tags. That does not mean it is a good idea.

The most important question you would need to answer is probably: What existing consistent mapping practice is the rendering supposed to support and is it realistic for the suggested design to actually do that?

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

No branches or pull requests