Reduce label clutter on entrances #2932
Conversation
|
IMHO it would be better to show the z18 (new) labels already in z17, and
agree that this is more readable than z17/18 (old). Z17 new on the other
hand is too scarse.
|
|
In general - make PR with smallest possible change. With separate PRs changing A, B, C one may quickly merge A, discuss B and merge it later and reject C. With the same A, B, C changes in one PR it would end just rejected. Can you make PR again with changes split? For example in this PR my initial reactions are:
Looks fine, I will only need to test rendering and check whatever it is a standard tagging.
:( Please, please make separate PR for separate changes. This is not 100% clear.
:( Please, please make separate PR for separate changes. I am not sure about this. |
|
And thank you for a PR! And for helping me discover addr:unit, I was unaware about it (and used ref tags). |
tpikonen
force-pushed
the
entrance_addresses
branch
from
b49c0f1 to
cccf369
Compare
|
Ok, I removed the second commit with the addr:unit separator fix. |
|
What about entrance=* tagged with addr:housenumber ? It exists over 400k times - see https://taginfo.openstreetmap.org/keys/entrance#combinations. This PR will cause them to appear later - and only about 4k address tags on entrance have addr:unit. entrance=* with addr:housename exists just 3k times so it may be safe to ignore. |
|
See also https://wiki.openstreetmap.org/wiki/Key:entrance#Entrances_and_addresses
I checked entrance=* tagged with addr:housenumber in my city, what I found seems to be a tagging mistake. But it seems to be widely used (where?) and correct tagging method, so maybe only addr:unit (without addr:housename, addr:housenumber) on entrances should be displayed later? |
|
I think we should obviously encourage people to add full addressing info to entrances, that way there is a change that some day search engines such as nominatim will point to the correct node, when given an address with addr:unit (it does not currently support them though). About entrances with only addr:housenumber disappearing, I have a PR in the works which renders all entrances with small markers at z>=17. Here's a preview from the same location as before: I think this is superior to the situation now, where entrances without address info are not visible at all. The house number is usually a property of the building, so rendering it on the entrance is IMHO useless repetition in correctly tagged cases. |
|
if you hide the details at z17 people will have to zoom to z18 in order to
make use of the map (visually), because there are many buildings with the
same housenumber. Showing symbols for the entrances doesn't solve this.
|
see https://wiki.openstreetmap.org/wiki/Key:entrance#Entrances_and_addresses with
Wide usage (400k+ entries) suggests that it is really used, so I am not convinced that dropping rendering is OK. If that it is really wrong and unused tagging - in that case wiki should be fixed. But note that with 400k cases one would need to check that it is really 400k of duplicates (for start one may try asking tagging ml or run overpass queries in various regions to find these 400k cases). I guess that one of countries has addresses assigned not to the building, but to the entrance ("If address is related not to whole building, but to individual staircases/entrances"). |
Do you think that https://user-images.githubusercontent.com/3215/32441408-2efe4d10-c300-11e7-9a06-6e0affedf311.png is readable? |
|
The tagging instructions for Key:entrance in the wiki are correct, but I don't think there are many cases where the entrance has a different housenumber than the building it is on, that's why I see rendering it as repetition. I think Dieters point was that if we drop the housenumber from entrances, the readability improves enough that entrance labels can also be rendered at z=17. |
Then rendering should handle this. It should be fairly simple, instead of
How you checked this? AFAIK some countries have addresses assigned not to the building, but to the entrance (I tried using http://overpass-turbo.eu/s/sNm to find something but for now I failed). |
I'm not sure what kind of entrance labels this would result in. Do you mean that we should render only either addr:housenumber or addr:unit on entrances, and prefer addr:unit if it's defined?
Admittedly I have not. Finding these cases would probably make an interesting overpass query :) |
That was based on my mistake (I somehow missed that entrances also have addr:housenumber tagged). Now again: maybe render later only if addr:unit is present (and ignore entrance tag)? Is it correct to assume that main address will not have addr:unit and secondary addresses will have both addr:unit and addr:housenumber? |
The main reason for disabling entrance label rendering at z=17 is that they sometimes (although rarely) block the housenumber on the building from being rendered, because of overlaps. IMO building addresses should have priority over entrance addresses. The problem of many buildings being visible with same housenumber can be solved by tagging addr:unit range on the building, like here, for example. This matches what is at least the local convention for naming separate buildings on the same lot, but has the problem that a unit range is (obviously) never used as a postal address. |
I'm afraid I don't see what you mean here.
I'm not sure what you mean by main and secondary addresses, but there are at least buildings with addr:housenumber and addr:unit tags both on the building and on its entrances. This is arguably even correct, as I explained in the previous reply to Dieter. |
now - all rendered normally: entrance=yes + addr:housenumber=13 PR: rendered later (because entrance is present): entrance=yes + addr:housenumber=13 rendered normally (because entrance is not present): addr:housenumber=13 proposed: rendered later (because addr:unit is present): entrance=yes + addr:unit=12 + addr:housenumber=13 rendered normally (because addr:unit is not present): entrance=yes + addr:housenumber=13 |
|
Maybe I missed something but what we want is to render less importnat addresses (with addr:unit) as less important and we do not want to make addresses from
rendered as less important. Note also that vast majority of addr:unit are not tagged on entrances: https://taginfo.openstreetmap.org/keys/addr%3Aunit#combinations |
|
If by rendered later you mean at higher zoom levels, then your proposed rendering would result in some buildings having a housenumber label at e.g. z=17 and other buildings having no label, even if they have a housenumber (+unit). There is almost always space for one label inside a building at z=17, so the clutter argument IMO does not work here. |
Can you give an example of correctly tagged building where all labels have addr:unit tag? Or description of such tagging? Because I was not expecting it as a valid tagging. |
|
Well, here's a building which is part of a four building group all with addr:housenumber=12 and entrances running from A to Y, divided among the four buildings. The building polygons are tagged (well, 3/4 are) with an addr:unit range, like "F-K" and they also have entrance nodes with addr:unit tagging. The staircase or unit range is a common way to identify buildings in such building groups around here. In addition there also groups of one-family houses with identical housenumbers, differentiated by a unit letter. Rendering labels for these only on higher zoom levels would look funny. |
|
sent from a phone
On 6. Nov 2017, at 16:02, Mateusz Konieczny ***@***.***> wrote:
I guess that one of countries has addresses assigned not to the building, but the the entrance ("If address is related not to whole building, but to individual staircases/entrances").
in Italy housenumbers typically apply to entrances, in Germany it can happen (is not decided on the national level)
|
|
So both
are correctly tagged main address for a building that should not be displayed later. So we have situations where with tag-based rules at least one problem will happen:
I am not sure is it fixable by simple rules. One may try some more complex ideas like checking whatever given address on entrance has matching nearby addr:housenumber - but it would be quite complex. |
|
I was not aware that entrances can have a separate housenumber, but indeed that seems to be the case.
Personally, I would leave the situation as it is now, i.e. live with the clutter. The elegant solution is easy to state: Every correct entrance node is part of a building, so check whether the housenumber of the entrance differs from its building and render the housenumber only then. Otherwise render the unit, if it exists. Coding this in CartoCSS is another matter. For example, is there any way to access the tags of a polygons member nodes? |
|
sent from a phone
On 7. Nov 2017, at 20:34, tpikonen ***@***.***> wrote:
The elegant solution is easy to state: Every correct entrance node is part of a building, so check whether the housenumber of the entrance differs from its building and render the housenumber only then.
every entrance to a building is part of the building, but there are also entrances to sites/lots, which are typically part of a wall or fence (or even nothing, when there’s no perimeter barrier), e.g. barrier=gate etc.
|
For example http://www.openstreetmap.org/node/3523331951#map=19/41.72506/12.29651 appears to be a correct address. So thanks to wide variety of addresses it seems currently to not be possible with simple tag filtering :( So, it seems that unfortunately this PR should be closed as (again) complexity of the world was larger than expected.
Hm, it seems that turning circles code is relatively complex because it requires access to information how parent way is tagged - see Line 2064 in 5aef1d5 Addresses are even worse as address may be on the building polygon or on node within building polygon. |
Actually, rendering building entrances differently when their housenumbers are identical to their building is probably doable, but requires a more complicated SQL query. I don't have the time to work on this right now, but maybe soon. But, if you want to close this PR, I can open another one. |
tpikonen
force-pushed
the
entrance_addresses
branch
from
cccf369 to
0ca006f
Compare
|
Ok, I updated the PR to render only addr:unit for entrances which have the same addr:housenumber as the buildings they are attached to. This leaves non-building entrances as they were and reduces the clutter in building entrance address labels, as in the original PR. |
|
In Russia addr:unit is not used. The most common and popular tagging scheme for appartament houses is this: 1. at home address:street and addr:housenumber; 2. a few entrance=staircase with ref and addr:flats. |
|
Any more comments here? If all the problems are resolved and there's no need to make additional changes, I could test the rendering. |
|
This PR is ready, as far as I'm concerned. |
|
Test rendering showed that the only change comparing to original version is that z17 is rendered the same as z18. Since the discussion was very detailed and I got lost - @matkoniecz what do you think of the current code? |
|
@matkoniecz ping? (see my last question) |
|
I am trying to understand what this PR is doing, since at various stages I read:
Still, addr:unit is used in the code? In Germany I have not seen cases of using addr:unit so far. In Berlin/Brandenburg at least, the addr:housenumber is officially the plot number, and if the plot is split, numbers as 8, 8A, 8B etc are squeezed in. Would these be affected? How is this now working as the entrances are rendered as icons? |
Set it to value 'unit-only' for entrance nodes which have the same addr:housenumber as an overlapping building.
Render addr:unit and addr:housename even if addr:housenumber is missing. Render only addr:unit, when render = "unit-only" has been set in SQL, i.e. render only addr:unit on entrances which have the same addr:housenumber as the building they overlap with.
This PR does have a rather convoluted comment track already, but the point is to reduce label clutter on buildings with many entrances with full address tags (addr:housenumber + addr:unit), so that only the unit is rendered, when the building has the same housenumber as the entrance. In its current state this code renders entrance labels like shown in the first message, except that z=17 looks the same now as z=18 and the non-building entrances are handled better. If your region does not use addr:unit, then nothing should change in the rendering. If it does it's probably a bug. Entrance icons are not visible below even a single letter label, but I think it's obvious that a label on the border of a building (or other feature) marks an entrance. Moving the label below the icon when the icon is rendered is of course possible, if it's found to be useful. |
tpikonen
force-pushed
the
entrance_addresses
branch
from
0ca006f to
05510be
Compare
|
Could we please have entrance's |
|
Please open new ticket for this, as refs are not rendered here by default (it's mostly names, but refs are for example shown at roads), so it's much wider problem than just "reducing clutter". Also it's interesting which way of tagging is proper, wrong or neutral. |
|
This seems to be quite complex topic, especially with situations differing from country to country.
For this reason, I agree it's probably best to leave the situation as is. I will therefore close the PR. @tpikonen thanks a lot for trying though! |
Currently correctly address-tagged building entrances have labels showing addr:housenumber + addr:unit. At z=17 this creates quite a bit of text on regions with large apartment buildings, like here:
This PR removes address labels from entrances at z=17 and makes them to have just the addr:unit text at higher zoom levels. At z=17:
and at z=18:
Edit: Removed fix related to addr:housenumber and addr:unit rendering on buildings.