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 · 59 comments
Closed

Rendering of area:highway #180

scaidermern opened this issue Sep 20, 2013 · 59 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 notifications@github.com

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...

@Marekkleciak
Copy link

Marekkleciak commented Sep 19, 2016

congratulations! It looks really good. I like it.

@pnorman
Copy link
Collaborator

pnorman commented Sep 26, 2016

We talked about this at the SOTM hack day and decided to close the issue

  • Implementing this change by rendering all objects of all types by layer tag is out of scope of this issue, and not an option for technical reasons. It is not practical, even if it is desirable.
  • If we were to implement this change, it would be a simple rendering, probably just rendering the area in the colour corresponding to fills. None of the examples fit well with the rest of the OpenStreetMap Carto style.
  • Making a map is about what data not to include as much as what to include.
  • Rendering highways mapped as areas obscures the bridge and other topological information. Transparency is not an option.

@mboeringa
Copy link

mboeringa commented Sep 26, 2016

I appreciate the difficulties of implementing something like this, probably as few others, having developed and implemented area:highway renderer in my own ArcGIS renderer. It was only after some careful deliberation, that I realized my models could probably be adapted to do this.

Nonetheless, I wonder what PR you are referencing? I think this issue was just about exploring the potential for it. I don't see any concrete PR, just ideas and some (mock-up) examples, including my own.

@Marekkleciak
Copy link

  1. "Implementing this change by rendering all objects of all types by layer tag is out of scope of this issue, and not an option for technical reasons. It is not practical, even if it is desirable."

-> Exactly. And it is not necessarily. We need only one color value with outline for the following elements: street as general, footway, cycleway, bus stop, taxi stop, "emergency" or "dashed" areas.

  1. "If we were to implement this change, it would be a simple rendering, probably just rendering the area in the colour corresponding to fills. None of the examples fit well with the rest of the OpenStreetMap Carto style."

-> Yes, we should implement as the first step a simple rendering of area in the colour corresponing to fills. Examples:

https://wiki.openstreetmap.org/wiki/File:MockupAreaHighwayWithStreetMidlines.jpg
https://wiki.openstreetmap.org/wiki/File:MockupAreaHighwayWithStreetMidlinesBright.jpg

  1. "Making a map is about what data not to include as much as what to include." Yes, we speak only about the highest zoom level. There is an important aspect: We don´t show turn:lanes as well. The polish rendering, let´s say here: http://osmapa.pl/w/area/?lat=51.76106&lon=19.48626&zoom=18&ol=Qq show that. You should go in the left corner down and use all options except the last both.
  2. "Rendering highways mapped as areas obscures the bridge and other topological information. Transparency is not an option."
    -> This is the problem we have always, when we render a map. See e.g. here:
    http://www.openstreetmap.org/#map=19/22.28453/114.19181
    I suggest use of area:highway rendering for the highest zoom level only.

@d1g
Copy link

d1g commented Sep 29, 2016

@pnorman, Paul, even without colours we would be happy to see area:highways=* rendered (even most popular subset of it's classes)

If we were to implement this change, it would be a simple rendering, probably just rendering the area in the colour corresponding to fills.

That would be great to have, why decline it?

I would happy to see just outlines of such areas (without fills, without coloured fills)
Similar to kerbs/berriers and other infrastructure #180 (comment)

@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.

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