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
Comments
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) |
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. |
2013/9/20 theonlytruth notifications@github.com
no, it is (more or less) agreed that this has different semantics: it is a |
That's not a particularly important consideration. I support adding it because it should help reduce misuse of |
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 |
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. |
Thats the main reason why I created this issue. |
Is there support for this to be implemented? Should it be rendered the same as highway=XXX area=yes? |
This is a hard question, because given that the mapnik rendering is defacto On the other hand it seems reasonable and logical to map highways also as |
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. |
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. |
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. What the best tagging is, I don't know. What are the alternatives? |
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." |
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. |
We have for today 62418 area:highway in the map. |
Starting with basics, I like general colors used on osmapa.pl, related to physical features:
Any other ideas? |
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 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. |
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. |
Yes I know. I really admire the achievements of those specialized maps. |
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... |
congratulations! It looks really good. I like it. |
User Tomasz_W sent me this: He is thinking abour better visualisation of bridges and tunnels from area:highway point of view. |
We talked about this at the SOTM hack day and decided to close the issue
|
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. |
-> 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.
-> 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
|
@pnorman, Paul, even without colours we would be happy to see area:highways=* rendered (even most popular subset of it's classes)
That would be great to have, why decline it? I would happy to see just outlines of such areas (without fills, without coloured fills) |
@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? |
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. |
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. |
Would there be no casing? How would we handle situations where multiple layers of |
sent from a phone
On 4 Feb 2021, at 02:43, Joseph E ***@***.***> wrote:
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?
in architecture, when there are hidden lines which you want to show (and this is important, because all hidden lines would often be too much), you draw them above, but in a dashed style. This style draws tunnels below (necessary because they also have a fill) which leads to situations where they are completely covered.
Christoph’s suggestion would work, but would lead to multiple lines for the same road, which would lead potentially to confusion or ugly rendering in some zoomlevels (appearing as “double casing”)(resulting from (even partial) overlap of highway lines and areas.
Rendering areas between highway fills and labels (including symbols like oneway and stop), and only in highest zoom levels, would IMHO lead to a better looking result, particularly when sidewalks and carriageway are represented with individual areas, or explicit kerbs are drawn. The higher level of detail would overrule the highway centre line display (potential problem could be people refraining from fixing the highway grid because it visually works with areas alone)
|
sent from a phone
On 4 Feb 2021, at 02:43, Joseph E ***@***.***> wrote:
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?
the areas should respect explicit layer tags, as should bridges and buildings ;-)
|
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. |
sent from a phone
On 4 Feb 2021, at 12:57, Christoph Hormann ***@***.***> wrote:
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
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. |
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. |
If anyone needs a good test case for this, see this park that I mapped. I think it would look great here. |
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).
The text was updated successfully, but these errors were encountered: