Render entrances. #2936
Render entrances. #2936
Conversation
|
I think that we might use brown dot for some amenities, so I would try some other shape/color for entrances. |
|
The color is the same or slightly darker or lighter than the building border in order to make the markers as unobtrusive as possible, especially on z=17. On the other hand one could go to the other direction in color coding and make non-permissive entrances the same color as the border and permissive ones progressively lighter, giving an impression of an opening in the building border. |
|
What if we use square border only (without filling)? |
tpikonen
force-pushed
the
render_entrances
branch
from
f32449b to
77c66e2
Compare
Ok, I tried this (branch updated) and it doesn't look that bad. Entrances are now rendered with a hollow square, except main entrances still with a solid one. Service entrances have just a hint of a square with a marker with only corners of a square, and access=no entrances have a diagonal line across the hollow square. Entrances with access=yes|permissive are rendered with a larger contrast (darker marker). Here's some images: Apartments with main and service entrances, z=17-18: School, z=17-18: University buildings with entrance=main's, one with access=permissive, one without and several service entrances, z=17-18: Two entrances, one with access=no, z=18-19: |
|
I like this scheme. However I would render all the entrances at z19 and on z18 maybe main entrances only. |
|
Yes, highlighting which entrance is main is great. |
|
What does it look like for nodes which are tagged as both house numbers and entrances? |
Did you perhaps mean z18 and z17? I think there is enough space to render all entrances at z18 without the map looking too busy. Also, addr:housenumber (+ addr:unit) is rendered at z>=17 also for entrances. |
The marker is not visible below the label. Have a look at the last image of the first comment. |
|
How it looks at entrances tagged on places other than buildings? Especially on nodes where entrance and barrier=gate tag are tagged together? |
|
It seems that code is using catch-all rendering, this is discouraged. For example entrance=yes;staircase should not be rendered. |
tpikonen
force-pushed
the
render_entrances
branch
from
77c66e2 to
ec1c002
Compare
The layers in buildings.mss are rendered early, so an entrance marker is usually not visible if there is another marker on top of it, except in really high zooms. Here's images with barrier=gate at z17-19:
I updated the PR to render just the entrance types which are in the table in the wiki. |
|
I had been hoping entrances would be rendered for a while, but never done anything abou It. I like the unfilled icons, but is it possible to use a rectangle for the icon? I think this would look more like a doorway, if it was something like twice as high as it was wide. This might also distinguish entrances from other generic circular/square icons. |
|
Hi! |
|
do we really need 3 tags?
addr:housenumber
addr:unit
addr:flats
aren’t the flats either housenumbers or unit numbers?
|
|
I think @NetWormKido meant to render both the entrance ref (part of the address, but not included/covered by any address tags) and addr:flats, so as to show where each flat is at a glance |
|
@NetWormKido, take a look at PR #2932 which is about rendering of address labels. This PR is about rendering markers to entrance=* nodes. Personally, I'm not against rendering addr:flats, but it should probably be only at the highest zoom levels (z>=19 or so). Also, I'd first like to finish PR #2932, which is mostly about addr:unit rendering before adding flat numbers. |
|
I erroneously assumed (and was proven wrong) that addr:unit is the European/US way of tagging entrance=staircase's refs, but every time I see examples of usage I get confused again. |
|
@tpikonen, I completely agree that the addr:flats need to render at the highest zoom levels (z>=19). I hope you consider my proposal. |
|
Just a quick remark: Outline only rendering is quite noisy IMO. Otherwise good initiative. |
Sorry, it took me some time to think it over. This is nice feature to have, but I really mean z19+. It's not about the available space, I want to avoid the clutter. Address numbers are used to search places on the street, so they can be shown earlier. Entrances are related to the single buildings and it's easy to guess they are here - most of the time footpath or multiple numbers indicate their existence. Sometimes even the shapes of the lawns are enough to know where is the entrance. The only new thing that this code brings and which can't be guessed is the type of the entrance, but this is really local feature. |
Ok, I'll update the code to do this eventually, but I would also like to remove the outline-only rendering of the markers (i.e. make the markers opaque), as @nebulon42 suggested. I don't know how to do it with the marker-* directives in carto, so this needs some thinking. |
tpikonen
force-pushed
the
render_entrances
branch
from
ec1c002 to
afe4358
Compare
|
Main entrances are now rendered at z>=18 and the rest at z>=19, as requested. Opaque markers with dark borders are apparently not possible (i.e. they would require non-monochrome markers), so the generic entrance markers are still outline only. As far as I'm concerned, this PR is ready. |
|
Thanks, I hope I will check it soon. |
|
I like the outcome and that's what I would merge soon - the only request left is to squash all the commits into one. Although we don't use z20 on OSMF servers currently, it makes sense in this case to extend the definition there, because the differences are sometimes still subtle on z19. I don't want to make it more evident earlier, because such small feature should not be too visible. Showing only main entrances on z18 sounds OK for me - that might help to find the way if the building is big enough.
|
|
There are lots of cases where people put the address label on an entrance node. This is somehow discussed in the first post, however is there a before/after comparison? Maybe the number should be under the icon, not on top? |
New layer "entrances", with entrance and access tags. Render entrance=main nodes starting at z=18 and other entrance types defined in OSM wiki (entrance=yes|home|service|staircase) starting at z=19. Most entrances are rendered with a hollow square marker. Entrances marked as "main" are rendered with a solid square, "service" entrances with corners of a hollow square and entrances with access="no" with a hollow square with a line along a diagonal. The marker brightness reflects the access permissions of the entrance. Entrances with access="yes" and "permissive" have a darker color. Markers with other access tag values have the same color as the building perimeter line. Exits, such as entrance=exit and entrance=emergency are not rendered. Address label text-halo-radius is increased at z>=18 to improve readability of labels on top of entrance markers.
tpikonen
force-pushed
the
render_entrances
branch
from
afe4358 to
7691ea7
Compare
Done. Thanks for the positive review. |
I have another PR (#2932) on labeling of entrances, so this change would probably fit there better. I'll see how it looks like after this PR is merged. |
|
Thanks for all the work on this code, @tpikonen! |
|
While I appreciate rendering entrances in general, I find rendering the value "entrance" = "staircase" problematic. It was not part of the original key proposal, and is badly documented. It is a value where the physical appearance of the entrance conflicts with its function, such as "main" or "emergency". |
|
We can of course change that (or any other) part. Is this the only problem do you see here? |
|
I don't see examples what happens when addr:housenumber is on the entrance node, |
In both cases address label or shop icon will be placed on top of the entrance marker, since the entrances layer is lower than addresses and amenity points and allows overlaps. In practice the entrance marker will not be visible, since its colors are chosen deliberately to be the same as in building borders. |
|
I believe staircase is OK, because in OSM many types are mixed and this one is not cryptic. We can change it in the future if needed, for the moment I'm inclined to stay with it. |
|
Thanks, could we see a preview for the housenumber/shop on an entrance? |
|
I don't get exactly what do you want to see, could you post a link to the example place? |
|
Posted some 5 posts above. |
|
Ok, now I see: |
|
Hm, the entrance icons are not fully covered. They remain visible, in particular under the '7' being so narrow, and in the jewellery ring. The 71 looks a bit like 7.1. They would probably also be bigger than the generic shop dot. Would it be possible to suppress them in the code when there is another icon or label on top? |
|
Please open new ticket for tuning this feature. |
Render entrances starting at z=17. The "main" and "staircase" entrances are rendered with a square marker, the "service" entrance with a circle (starting at z=18) and other entrances with a disc.
Three levels of marker brightness reflect the access permissions of the entrance. Darker color means more permissive access. The "main" entrances are dark by default. The access tag modifies the brightness such that access="yes" and "permissive" set the marker to darkest and access=no to the lightest colour. Entrances with other access tag values have intermediate brightness.
Exits, such as entrance=exit and entrance=emergency are not rendered.
Address label text-halo-radius is increased at z>=18 to improve readability of labels on top of entrance markers.
Examples:
Buildings with "main" and "service" entrances, z=17-18:
School with several entrance="yes" and access="permissive"|"private", z=17-18:
Apartment building with entrance="staircase" tagged with addr:unit, z=17-18:
