gravitystorm / openstreetmap-carto

A general-purpose OpenStreetMap mapnik style, in CartoCSS
Other
1.53k stars 819 forks source link

Ugly rendering of addr:flats #4160

Open sanderd17 opened 4 years ago

sanderd17 commented 4 years ago

Expected behavior

The addr:flats tag is used to encode apartment numbers into OSM. Big apartments will usually have a big number of flats, and thus a long list under the addr:flats tag.

In contrast to addr:unit (which is meant to address a single unit), addr:flats is usually a list of apartments. These apartments are usually also on top of each other.

It's geographical info that can be used for address completion/verification, but IMO is very unsuited for rendering on a 2D map.

Actual behavior

Ugly long lists of numbers which makes it almost impossible to find the housenumbers.

Links and screenshots illustrating the problem

afbeelding

afbeelding

Solution

Revert #3988 and display only addr:unit for separate addressed building units.

Adamant36 commented 4 years ago

The Wiki says (and I'm pretty sure that the discuss said to) that it's suppose to be used for a range of numbers. So, your example is probably miss-tagging. Doing a quick glance at TagInfo it seems like values aren't that way. You should take it as an opportunity improve tagging, like would be done in any other similar situation. It's not like the name, ref, or any other similar tags don't have the same problem to some degree.

sanderd17 commented 4 years ago

Here are the links to the shown screenshot locations. Please tell me which ones aren't correctly mapped according to you.

If anything, the default rendering here seems to suggest we need to delete this valid data, or invent yet another tag (addr:flat-list, addr:subhousenumbers, ...)

https://www.openstreetmap.org/#map=19/50.94107/3.06177 https://www.openstreetmap.org/#map=19/50.87525/4.69097

Adamant36 commented 4 years ago

Personally, both links look like junk tagging to me. At least as far as the definition of the tag goes. Its easy to find a edge cases to cherry pick to support whatever perspective, you can do it for every tag. But like I said 99% of the values are used correctly. So its not worth reverting IMO. As far as the suggestion of a flat list tag, this isnt the place for tagging discussions. Maybe message the person that made used the tag wrong though to see if they will fix it or tell you how though. That's what id do. A huge part of OSM is improving tagging in situations where we can. So, dont treat me like its a bad suggestion ;)

sanderd17 commented 4 years ago

I was one of those taggers, tagged long before it was rendered. But I veryfied my tagging with someone elses tagging, and it matches what I did.

According to the wiki, our tagging is conform, the wiki even has such a long list as example:

If there is gap in numeration, mark numbers and intervals with semicolon: addr:flats=3-7;10;14;16-18.

I don't know where you get the number of 99% good tagging. If I look around, I see at least 60% long lists.

sanderd17 commented 4 years ago

I extracted a list of all values used in the city of Ghent (a region where I don't map, and which I didn't check before).

Most of the short examples are wrong tagging: either it lists the number of flats, which should be under building:flats, or it lists a single flat number, which should be under addr:unit.

If you filter those single values out, the vast majority seems rather inconvenient to render.

Note: searched via overpass, and processed the JSON to get only the values out: http://overpass-turbo.eu/s/V3y

``` 1;101 1-14 1;101 1 1-8 1-8 1 1 1 1-6;10;20;30;32;34;42-45;48-50;53-54;57-58;60-62;70-77;42A-42F 101-102;201-206;301-308 1-2;11-19;21-29;31-39 1-2;11-12 1-2;11-12;21-22 1-2;11-12;21-22 11;21 1-4;101 1;101;201;301 1;101;201 1;101-102;201-202 1;101;201;301 1;101;201 1-2 1-2;101-103;201-203;301-303 1;101 1;101;201 1;101;201 1;101 1-2;101-102;201-202 1-2;101;201;301 1;101;201 1;201;301 1-8 1-8 1-8 1-8 1;101;102 1;101-103 1;101-103;201-203;301-302 1-2;101-102;201-202 1;101 1-3;101-102;201-202;301-304;401-406 1;101-102;201 1-2;101-102;201-202;301-302;401-402;501-503;601-602;701 1-2;101-102;201-202;301-302;401-402;501-503;601-602;701 1-2;101-102;201-202;301-302;401-402;501-503;601-602;701 1;101;201-202 101;201 101-104;201-204 1;101;301 1;101;201 1-6;101-107;201-207;301-307 1;101-102 1;101;201;301 1;101-102;201-202;301-302 1;101-102;201-202;301-302;401 1;101-103;201-203;301-303 1;101;201 1-2;101;201 201 1;101 1;101;201 1-2;101-102 1-3;101-103;201-203 1;101;201 1;101;201 101 1;101;201 101-104;201-204 101;201 1;101-102;201-202;301 201-202 101-102;201-202;301 2 1-3;101-104;201-204;301-304 101 1;101-102;201-202;301-302 1;101;201;301 1-3;101-104;201-204;301-304 1-3;101-104;201-204;301-304 1-3;101-104;201-204;301-304 1-3;101-104;201-204;301-304 101-103;201-203;301-303;401-403 1;101;201 1-3;101-102 1;101;201 1-2;101-106;201;301-303 1;101;201;301 1;101;201 1-4;101-102;201-202;301;401-402;501 1;101;201 1;101-102;201-202 1;101 1;301;401 1-2;101-102;201-202;301 101;301 1;101-102;201-202;301 1;101-102;201-202;301 1;101;201;301 1-2;101 1;101;201;301 1;101-102;201-202;301 101 1-4;101-105;201-204;301-302 1;101-102;201 1-2;101-102;201-202 1;101;201 1;101-102;201-202;301 1-2;101;201;301 1-3;101-102;201-203;301 1-3;101;201 1-2;101-102;201-202;301-302;401-402 1 1;101;201 101-102 1-4;101-102;201-203 1;101 101-102;201-202;301-302 1;101;201-202 1;101;201;301 1;101;201;301 1;101;201 101-102;201-202;301-302 1-4 101-103;201-203;301-302 1-3;101;201;301-302 1;101-102;201-202;301 1;101;201 1;101;201;301 1;101 1;101-102;201-202;301-302;401-402 1;101;201 101-106;201-202 1;201;301 1;101;201 1;101;201-202;301-302 1-2;101-102 1;101-102;201;301 1-7;101-109;201-209;301-309 1;101-102;201-202;301-302 101-106;201-202 1;101-102;201-202;301-302 1;101;201;301 1;101-102 1;101;201 1;101;201 1;101-102;201-202;301 1-4;101-103 1;101-103;201-203;301-304 1;101;201 1;101;201 1;101;201 1;101-102;201-202;301-302 1-2;101-103;201-203;301-302 1;101 1;101-102;201-202;301 1-2;101;201-202;301 1;101-102;201;301 101;201 1;101 1;101 1;101;201 101 1-2 1-2;201;301 1;101;201 1-2;101-102;201-202;301 1;101-102;201-202;301-302 1;101;201 1;101-102;201-202;301-302;401-402 1;101-102;201-202;301-302;401-402 1;101-102;201-202;301-302;401-402 1;101;201;301 1-2;101-103;201-203;301 1;101;201 1-2;101;201;301 1-5;101-105;201-205;301-303 101-103;201;301-302 1;101;201 1;101;201;301 1;101;201 1;101 1;201;301 1-2;101-103;201-203;301-303;401-402 1;5;101;201;301-302;601;701;801;1001;1101 1;101;201;301 1;101;201 1 1;101;201;301 1;101;201;301;401;501;601;701 1-2;101;201 1;101;201 1-6;101-111;201-210;301-313;401-406;501-510;601-606;701-702;801-803;901-903;1000 1-8;101-105;201-205;301-305;401-405 1;101-102;201-202 1;101-102;201 1-2;101-102;201-202;301-302;401 1-2;101-102;201-202;301-302;401 1;101;201;301 1-2;101-102;201-202;301-302 1;101 1;101;201 1;201 101;201 1;101 1-2;101-103 3-14;16-35 1-2;101;201-202 1-2;101;201-202 1;101;201;301 1;201 1;101 101;201;301 101;201 1 101 1-2;101;201-202 101-102 101-102;201-202;301 1;101-103;201-202 1;101;201;301 202 1;101;201 101-102;201-202;301 1-106 1-106 101;201;301 1 1-2;4;101-104;201-204;401-404;501-502 101;201 101-102;201-202;301 1;101;201;301 1;101;201;301 101-102;201-202;301-302 1-2;101-103;201;301 1;101-104;201-204;301 1;101;201 101;201;301 1;101;201;301 1;101;201;301 1;101;201;301 1-2;101-103;201-203 1;101;201-202 1-2;101;201 1;101;201;301 101;201;301 101 1-2;101-102;201 101;201 201;301;401 1;201;301 1;101-102;201-202 101;201;301 101;201 101;201-202 101;201;301 101;201 1;101;201 1;201 1-2;101;201;301 1-2;101-103;201-202 1;101;201;301 1-3;101-103;201-203;301-302 1;101;201-202;301-302 101;301 1;101;201 1;201;301 1;201;301 1;101;201 1;101;201 1 1;101;201 1-4;101-105;201-205;301-302 101-103;201-202 1;101;201 1-2;101;201-202;301 1-3;101;201-202 1;101;201;301 1;101;201;301 1-2;101-102;201 1;101;201 1;201;301 1;101;201;301 1 1;101;201;301 1;201;301 101-102;201;301 1;101;201;301 101;201;301 1;101;201;301 101-102;201-202 1-4;101-102;201-202;301-302 1;101;201;301 101;201;301 101;201;301 1-2;43;101-104;201-204;301-304;401-404;501-504;601-604;701-704;801-804;901-904;1001-1004;1101-1104;1201-1204 1-3;101-105;201-205;301-305 1;101;201 1;101 1 1-3;101-104;201-203;301 1-2;101-102;201;301 1-2;101-102;201;301 1;101;201 1 101-102;201-202;301-302;401-402 312 1;101;201;301 1-2;101;201;301 1-39 1;101;201;301 1;101;201;301 101-103;201-203;301-303;401-403;501-503 101;201;301 1;101-102;201-202;301 1;201 1;101-104;201-204 1;101;201;301 1;101;201;301;401 1;201 1-60 1;101;201 1;101;201 103 1-2;101;201;301 1;101;201;301 1-2;101-102;201-202;301-302;401-402;501-502;601-602;701-702;801 1;101;201;301 1;101-102;201-203;301-303;401-402;501-502;601-602;701-702;801-802 101;201;301 1;101 101-102;201;301-302;401-402;501;601-602;701-702;801 101-102;201;301-302;401-402;501;601-602;701-702;801 1;101;201;301 1;101;201 1-2;101;201;301 1-2;101;201 1;101 1;101;201;301 101 1-2;101;201;301 101;201-202;301-302;401-402 1;101;201;301 1;101;201;301;401 1;101-102;201-202;301;401 1;101;201;301 1;101;201;301 1;101;201;301 1;101;201;301;401 101-102;201-202;301-302 1;101;201 1;101 1;101;201;301 201-202;301-302;401 1-2;101;201;301;401 101;201 1;101;201 101-103;201-203;301-303;401-403;501 101-102;201-202;301-302;401-402;501 1;101;201;301 1;101;201;301 1;101;201 1;101;201;301 1;101;201;301 101;201;301;401 1;101;201 101-102;201-202;301-302 101;201;301;401;501 1-2;101-102;201-202;301 1-3;101-102;201-202;301-302 1;101-103;201-203;301-303 1;101;201 101;201;301 101-102;201-202;301-302 301 101;201;301;401 1;101;201;301;401;501 101-102;201-202;301-302;401-402;501 301-302 101;201;301;401 1;101;201;301 101;201 1-3;12;101-103;201-203;301-303;401-402 1;101-102;201-202 1-2;101;201 1;101;201;301 1-3 1-2;101-102;201;301 1;101;201;301 1;101;201 31 1;101;201;301;401 101-102;201-202;301-303 1;101;201;301 1;101 1;101-102;201-202;301-302;401-402 1;101;201 1;101;201-202;301 1;201;301 101 101;201;301 1;101 101;201;301 101;201;301 101-102;201-203;301-303;401-403 1-4;101-104;201-204;301-304;401-403 1;101-102;201-202 101-102;201-202;301-302;401 1;101;201 1-2;101-104;201-204;301-304 1-5;101-105;201-204;301-306 1;101;201 1;101-102;201-202;301-302 1;101 1-2;101;201 1;101-102;201-202;301-302;401 101-102;201-202;301 1-7;101-102;201-202;301-302 101-102;201-202;301 1-2;101-102;201-202;301-302 1-7;101-102;201-202;301-302 1;101-102;201-202;301-302;401 1-3;101;201;301 1;101;201 1;101;201 1-2;101-103;201;301-302 101-102;201-202;301-302;401-402 1;101;201 1;101;201-202 1;101;201 1-2;101;201 2 1;101;201 1;101;201;301 1-2;101;201;301 1;101;201;301 1;101;201 1;101;201;301 101;201 1;101;201 101;201 1-2;101-102;201-202;301-302 1-3;101-102;201-203;301-303;401 1;101 1;101;201 1;101;201 1;101;201 1;101;201;401 1;101-102 101;301 1;101;301 1;101;201 1;101;201 101;201 1;101;201;301 1-2;101;201 1-3;101-103;201-203;301-302 101-102;201-202 1;101 1-2;101;201;301-302 1;101;201-203;401;501;601 1;101 1-3;101-103;201-203;301-303 1-3;101-103;201-203;301-303 1;101;201;301 1-2;101-102;201-202 1;101;201;301 1;101-103;201-203;301-303;401-403 1-2 1-12 1;201 1;101-102;201-202;301-302 1;101-102;201-202;301-302 1;101;201 1;101;201-202;301-302 1-2;101-102;201-202 1-2;101-102;201-202 101-103;201-203;301-303;401-403;501-503;601-602;701 1;101-102;201-202;301-302;401-402;501;601;701;801 1;101;201;301 1-12 1;101 1;101 1;201;301 1;101;201 1;101;201;301 1;101-102;201-202;301 1-2;101-102;201-202;301-302;401 1;101;201 101;201;301;401 101;201;301;401 1;101;201;301 1;101;201 1-3;101-103;201-203;301-302;401-402 1-3;101-103;201-203;301-302;401-402 1;101;201 1-3;101-103;201-203;301-302;401-402 1;101;301 1;101-102;201-202;301-302;401-402 1;101-102;201;301 1;101;201;301 1 1;101;201;301 201;301 201;301 101-104;201-204;301-304;401-402 101-104;201-204;301-304;401-402 1;101;201-202;301;401 1-2;101-102;201-202 1;101;201 1;101-102;201-202 101;201 1;101;201 1;101;201;301 1;101;201 1;101;201-202;301 1;101;201;301;401 1;201;301 1;101;201 1;101;201 1;101;201 1;101;201 1;101;201;301 1;101;201;301 1 1-3;101-104;201-203;301-303;401-402 1-3;101-104;201-203;301-303;401-402 101-103;201 1-3;101-104;201-203;301-303;401-402 1-2;101-102;201-202;301-302;401-402 1;101;201;301 1;101;201;301 1-2;101;201;301 101;201 1-2;101;201;301 1;101;201 101;201;301 1;101 1-2;101;201 1-2;101;201 1;101-102 1;101;201;301 101;201;301 1;101;201 1;101;201 1;101;201;301;401 1;101;201;301;401 1;101;201 1;101;201;301 1;101-102 1;101;201 1-2;101-103;201-203;301-302 1-2;4;101-104;201-204;401-404;501-502 1-2;11-12;21-22 1-2;101-102;201;301 1;101;201 101;201 1;101;201-202;301-302 1;101-102;201-202;301-302 1;101;201;301 1;101;201-202 1-2;101-102;201-202;301-302;401 1;101-102;201-202;301-302 101;201;301 1;101-102;201-202;301 1;101;201 1;101;201;301 1;201 1-2;101-102 1-2;101-102 101-103 1;101 1;101-102;201-202 1;101-102;201-202 2 1-2;101;201 1 1-2;101-102 101 1;101 1;101;201 101;201 1-2 1-2;11-12;21-22 1-2;11-12;21-22 1-2;11-12;21-22 1;11 1-2;11-12 11;21 11;21 1-2;101;201 1-2;11-19;21-29;31-39 1;11 1;11 1;11 1;11-12;21-22 11 1;11;21 11;21 11-12 1-3;11-12;21-23 1;11;21;31 11-12 11;21;31 1-2;11-12;21 1;11 1;11 1-3;11-13 1;11 11 1;11 11 1;11;21 1;11;21 1;11;21 11;21;31 1-2 1-3;11-13;21-23;31-33;41-42 1-3;11-13;21-23;31-33;41-42 1 1-2;101-102;201-202;301 1;101;201 1-2;101 2 101;201 1;101 1;101 1;101;201 1;101 1;101;201;301 101-102;201-202;301 1-3;101-102 1-2;101-102;201 1;101;201 1-3;201 1-2 1;101-102 1-5 1-5 1-7;101-109;201-205 1;101 1;101 1;101;201;301 1;101;201 1;201-202 1;101;201 1;101;201 1-2;101;201 1;101 1;101;201 1;101;201 1-3;101-102;201;301 101;201;301 1;101-102;201-202;301-302;401-402 1-2;101-102;201-202;301-302;401-402 1;101-103;201-206;301-302;401-406 1-3;101;201 101;201 1;101 1;101 1;101;201 301 1;101;201;301 101;201;301 101;201-206;301-306;401-406;501-506;601-606;701-703;801-803 1-3;101;201;301 1;101;201 1;101 1;101-102;201-202 1;101-102;201;301 1;101;201;301 1-3;101-102;201-202;301 1;101;201 1;101;201-202 1;101;201 1;101;201 1;101;201;301 1;101-104;201-204;301 1;101;201;301 1;101;201 1;101 1;101;201;301 1;101;201 1;101;201;301 1;101;201 1-2;101-102;201-202;301-302 1;101;201-202 1-2 1;101 101;201;301 101-102;201-202;301-302 101;201 1;101-102;201-202;301-302;401-402 101;201 1;101-102;201;301-302 1;101;201 1;201;301 1;201;301 1-2;101-103;201 1;101;201;301 1;201;301 1;101;201;301 1-2;101-104;201-204;301-304;401-402 1;101-106;201-206;301-302 1;101;201 1;101;201;301 1-2;101;201;301 1;201 101;201 1-3;101-103;201-203;301-302 101-102;201-202;301-302 101 1;101;201;301-302 1;101;201;301 1;101;201;301 1-2;101-102;201 101-102;201-202 1-2;101-103;201-203;301-303 101-102;201-202 1;101;201 1;101;201 101-102;201 1;101;201 1;101 1;101 1;101;201;301 101;201;301 1;101-102;201;301 1-3;101 1;101 1-2;101-103;201-203;301 1;101-102;201-202 1-4 1;101;201 1;101 1;101 201;301;401-402 201;301;401-402 1-2;101;201 1;101 1;101-102;201-202;301 1;201 1;101;201;301 1-2;101-103;201-203;301-302 101-102;301 1-2;101-102;201-202;301-302 1-2;101-103;201-202;301 2-6 1;101;201 1-6;11;13-16;21-26 101 1-2;101-102;201-202 1-2 1-2 1;101 1;101 101-103;201-203 101-103;201-203 1-2;101-102;201-202 101-102;201-202 101-103;202 1-2;101-102;201-202;301-302 1-2;101-102;201-202;301 1 1 101-102;202 1-2 1-3;101-102 101 101;201 101;201 1-2;101-102;201-202;301-302 1-2;101-102;201-202;301-302 1-4;101-102;201-203 1-2;101-102;201 1-2;101-102 1;101;201 1;101-102 1 101;201-204;301-304 1-2;101-104;201-203;301-303 1-6;101-106;201-204 1-4;101-105;201-202 1;2;101;102 1;2;101 1;101-103 1-4;101-105;201-202 1;101 101;201;301 1;101 1-2 1;101 101-103;201-202;301-303;401-402 1;101 1-2 101-105;201-203 101;201 1;101;201 1;101;201 101;201 101;201;301 1-2 1;101;201 1;101;201;301 1-2;101;201 1;101;201 1;101 1;101-102;201-202 1;101 1-3;101;201 1;101;201 1-2 1-2 1;101;201;301 1-4 1-6 1-2;101-103;201-203;301-303 101-106;201-206;301-306;401-406 1-2;101-102;201-202 1-2;101-102;201-202 1-2;101-102;201-202 1-2;101-102;201-202 1-2;101-103;201-203 1;101-102;201-202 1-5 1-3;101-102;201 1;101;201 1;101;201 1;101;201;301 1;101-103;201-203;301-303 1;101-102;201-202 1;101-103 1;101;201 1;101-102;201 1-2;101-102 1;101;201 1;101;201 1-2;101-102;201-202 1-2;101-102;201-202;301-302 1-2;101-102;201-202 1-3;101-103;201-203 1-2;101-102;201-202 1-2;101-102 0001;0002;0003;0101;0102;0103;0201;0202;0203 0001;0002;0003;0101;0102;0103;0201;0202;0203 0001;0002;0003;0101;0102;0103;0201;0202;0203 0001;0002;0003;0101;0102;0103;0201;0202;0203 1-2;101-102;201-202;301-302 1-2;101-102;201-202;301-302 101;201 101;201;301 1;101 101-102;201 1;101 1-2;101-102;201-202 101;201-202 101;301 1;101 1;101;201 1;101;201 1;101 101;201 1;101;201-202;301-302 1;101 1;101 101-102 1;101-103;201-202;301-302 1;101 101 1-2;101;201;301 1;101 1;101 1;101 101;201;301-302;401 101 1-2 1;101;201 101;201;301-302 1-2;201 1;101-103;201 1;101 101;201 1-3 1-2;101-102;201 1-2;101-102;201-202 1;101 1;101;201 1-2;101-102 101-104;201-204 1;101-103;201 1;101;201;301;401 1;101 1;101;201-202;301-302 1-2;101-102;201-202;301-302 101-105;201-205 1-2;101-102;201-202 1-2;101-102;201-202;301-302 1-2;101-102;201-202;301 1-2;101-104;201 1;101 1;101;201 1-3;101-105;201-205;301-305 1-3;101-104;201-204;301-303 1;101 1;101 1;101 1;101;301 101 1;101-102;201 1;101;201-203 1-13 101-103;201-203;301-303;401-402;501-502 1;101 1;101 1;101;201 101;201 101-102;201 1;101-102;201-202;301 1;101;201 1;101 1;101 1-2;101-102;201-202;301 1;101;201;301 1-2;101-103;201 101-102;201-202;301-302 1;101 1;101;201 1;101 1;101 1;101;201 1;101 1;101 101-102 1;101;201 101;201-202 1;101;201 101;201 101;201 1-2;101-102;201-202 1 1;101;201;301 2 1;101;201 1;101;201;301;401 1;201;301 1;101 1-2;101;201 1;101;201;301 1;101 1;101 101-102;201-202;301-302 1-3;101 1;101 1;101-102;201 1;101 1;101;201 1;101 1;101 1-2;101-102;201-202 101;201;301 1-3;101-103;201-203 1-3;101-103;201-203 1-3;101-103;201-203 1-3;101-103;201-203 1-3;101-103;201-203 1-3;101-103;201-203 1-3;101-103;201-203 1-3;101-103;201-203 101-102;201 1-5;101-105;201-204 1;101 1;101;201;301 101;201;301-302 1;101-102;201-202;301-302 1-2;101-102;201-202;301-302 1-3;101-102;201-202 1;101;201 1;101;201 1;101;201 1-2;101 101 1;101;201;301 1;101;201;301 1-2;101;201-202;301-302 1;101 1-3;101-104;201-204;301-304 1;101 1-2;101-102;201 1-4;101-104;201-204 1-4;101-104;201-204 1-2;101-105;201-204;301-302 1-2;101-105;201-204;301-302 1;101 101-103;201-203;301-302 1-5;101-102;201-202 1;101;201 1-3;101-103;201-203 1-5;101-102 1;101-102 101-102;201-202;301-302 1;101-102;201-202;301 1 101;201;301 1-23 1-3;101-102;201-202;301-302 1-6;101-111;201-210;301-313;401-406;501-510;601-606;701-702;801-803;901-903;1000-1001 1;101;201;301 1;101;201 1;101;201;301 1-5;101-103;201-206;301-302 1-2;101-102;201-204;301-304;401-403;501-504 1;101 ```

Some statistics, the average length of such an addr:flats value is 14 characters, with on average 4.3 numbers per value (split by semicolons or dashes).

For me, this means that the average value shouldn't be rendered. Placing a tag like 150 1;11-13;21-23 (which is about average both in length and number of values) on a small apartment building (only 7 flats in total) is very messy.

Adamant36 commented 4 years ago

I don't know where you get the number of 99% good tagging. If I look around, I see at least 60% long lists.

Look through the pages for tags usage on TagInfo. It takes like 4 or pages to get to one like your example when its already in the low usage numbers. Then it rarely comes up. Like the first one that comes up, 1-2;101;201, is 21 pages in and only has 77 uses. After that they are extremely infrequent and the usage is to low to matter. Its like less then 1% of the total. Just the page which doesn't contain the problem your talking about is like 40,000 uses on its own. My guess is the bad ones are a couple hundred at best. Which is less then 1% of the total usage. Even if there are 1,000 it still isn't 1% of the total (it's like 0.005), but I highly doubt it is anywhere near that. 500 or so out of 185,835 isn't anything. You could re-tag them in a weekend, or just ignore them and accept that nothing is perfect.

Adamant36 commented 4 years ago

Maybe your region is an outlier because it doesn't seem to represent the usage of the tag overall, as stated above. Id suggest fixing the wrong ones that you can. I don't see the problem with that. Its possible there was one or two mappers in your area that didnt know what they were doing and it might fairly simple to clean up. Or message them so they can do it.

sanderd17 commented 4 years ago

You could re-tag them in a weekend

Just a question, to what should you retag those values? They are correct according to the wiki.

It's the job of the renderer to give a good visualisation of the map. It's not the job of the mapper to map for the renderer? Or do you claim otherwise?

And yes, it might be a problem in our region. We have many small apartments (just 3 or 4 floors), with a few flats per floor, and usually number them by floor (so you don't get continious ranges). But the main downside of these small apartments is that they only have one entrance. So the addr:housenumber and addr:flats tags belong on the same small object.

There's really no space to render that decently, and at the moment, mapping the addr:flats obscures many other elements (like housenumbers) which are a lot more important.

Adamant36 commented 4 years ago

Just a question, to what should you retag those values?

In your first example since they do seem to be a range of numbers, just with some missing, I'd re-tag it as four separate addr:flats nodes from left to right. Starting with 0.1-0.2, then 1.1-1.3, 2.1-2.2 etc etc. That seems correct to me. Likely it was four separate areas of the building with different flat numbers that the just combined because they were lazy. Which isn't how the tag is meant to be used IMO.

It's the job of the renderer to give a good visualisation of the map. It's not the job of the mapper to map for the renderer? Or do you claim otherwise?

My claim, and I'm pretty sure everyone will agree with me, is that rendering or not rendering something shouldn't be based on an extremely small regional sample of outliers in tagging that can easily be fixed as I've outlined above.

And yes, it might be a problem in our region. We have many small apartments (just 3 or 4 floors), with a few flats per floor, and usually number them by floor

Then it sounds like my suggestion to tag them as separate nodes above is a sound one. Since it sounds like they are different objects. Maybe in conjunction with the level tag if you have that information, or come up with something like a flats:floor tag. I'm sure it would be useful outside of just your examples. Also, you should discuss it with your local community. One of the great things about OSM is the ability to come up with novel ways to deal with exactly these types of situations and there's a lot of grey area between render/don't render something.

There's really no space to render that decently, and at the moment, mapping the addr:flats obscures many other elements (like housenumbers) which are a lot more important.

Your really working backward from own conclusion here. You can't say a tag with 46 thousand uses isn't important and every blocks everything in some situations. Again, it's not an either or thing though. Correct the ones that you can correct how I suggested, discuss it with your local community, find a novel way to remedy it, and then reevaluate things.

Zverik commented 4 years ago

The idea for addr:flats was to be tagged on building entrances — to specify which flats an entrance leads to. This indeed messes things up when rendered on bulidings or other polygons.

Of course that doesn't solve the case of addressed entrances. Lists of numbers on the opening pictures should go into addr:housenumber. This has usually been solved by tagging housenumbers on entrances (see Brussels).

Adamant36 commented 4 years ago

This has usually been solved by tagging housenumbers on entrances

Tagging things that are properties of the whole building on the entrance has seemed really weird to me for some reason. Like nesting tags or something. The address applies to the whole building. Not just the front door. Plus, you have to know where the entrance is in the first place. Maybe I could sorta see it for addr:flats since "flats" isn't a single object to tag it on, but it makes no sense for addr:housenumber IMO. So, I think it could go either way in the first example. Mapping it on the entrance might actually make the rendering worse. I think my suggestion of splitting them up by range is probably the more sound option.

jeisenbe commented 4 years ago

Also see #4155

andrewharvey commented 3 years ago

I agree with @sanderd17 addr:flats should not be rendered as a text label because it'll often be quite long. The wiki which matches current mapping practice says:

Use addr:flats=* for marking range of numbers of flats behind a door, for example, addr:flats=1-20. If there is gap in numeration, mark numbers and intervals with semicolon: addr:flats=3-7;10;14;16-18.

An example is addr:flats=101-103;201-208;301-306;401-405;408-409;501-507;601-605;701-704;801-806;901-904;1001-1005;1101-1108. Too long to render, but 100% correct tagging. I have scenarios where the list exceeds the 255 tag value limit and have to split the values across addr:flats, addr:flats1, addr:flats2 etc.

Here is another example of a real world value at https://www.domain.com.au/building-profile/668-bourke-street-melbourne-vic-3000

1-3;10-12;100-103;110-112;200-203;210-212;300-303;305-312;400-403;405-412;500-503;505-512;600-603;605-612;700-703;705-712;800-803;805-812;900;902-903;905-911;1000;1002-1003;1005-1011;1100;1102-1103;1105-1111;1200;1202-1203;1205-1211;1300;1302-1303;1305-1311;1400;1402-1403;1405-1411;1500;1502-1503;1505-1511;1600;1602-1603;1605-1611;1700;1702-1703;1705-1711;1800;1802-1803;1805-1811;1900;1902-1903;1905-1911;2000;2002-2003;2005-2011;2100;2102-2103;2105-2111;2200;2202-2203;2205-2211;2300;2302-2303;2305-2311;2400;2402-2403;2405-2411;2500;2502-2503;2505-2511;2600;2602-2603;2605;2607;2609-2611;2700;2702-2703;2705;2707;2709-2711;2800;2802-2803;2805;2809-2811;2900;2902-2903;2905;2907;2909-2911;3003;3006;3009;3012-3013

Yep that's a 30 story building where they don't like the number 4, which forces these ranges to be even longer.

According to https://taginfo.openstreetmap.org/keys/addr%3Aflats#combinations 20% (73k) of these tags appear together with building= (so not on the entrance), 50% (181k) appear with entrance= tag (so on a building entrance). So it appears that people are using the tag on buildings.

andrewharvey commented 3 years ago

Then it sounds like my suggestion to tag them as separate nodes above is a sound one. Since it sounds like they are different objects. Maybe in conjunction with the level tag if you have that information, or come up with something like a flats:floor tag. I'm sure it would be useful outside of just your examples. Also, you should discuss it with your local community. One of the great things about OSM is the ability to come up with novel ways to deal with exactly these types of situations and there's a lot of grey area between render/don't render something.

An apartment building with 400 units we shouldn't be having 400 nodes all on top of each other, that would be an editing nightmare. Using addr:flats allows all 400 different units to be recorded in OSM with a single building polygon and address tags.

Adamant36 commented 3 years ago

Yep that's a 30 story building

I imagine you could likely (and it would probably be correct to) add the ranges of flat numbers as an addition to something like building:levels (or whatever the proper tagging for multi-story buildings is) areas. Realistically though no one is going map a thirty story building as thirty different anything though and trying to add every flat number for such buildings is clearly "mapping every blade of grass." Plus, really, no one cares about what flat is where in the building at that point either.

Also, I'm sure we could find a single ridiculous edge case to poopoo any rendering any tag. I don't think it's valid way to approach to this though if there's almost zero chance of such things being mapped in any amount (or at all) IRL. Even your shorter example is extremely unlikely to occur and if it did there's no reason they couldn't just be split into a couple of different nodes. Since doing so wouldn't technically be wrong either. That said, the longest actual example I could find is 1;10;11;12;13;14;15;16;17;18;19;19A;2;20;21;22;23;24;25;26;3;4;5;6;7;8;9. Which could easily be split up somehow. The vast majority are no more then 3 numbers though. Most are 2.

BTW, there's also some longish examples of addr:housenumber. Which are likely really flat numbers that were tagged as addresses for the rendering. Either way, the "long row of digits that look ugly" issue isn't just confined to the addr:flats tag.

andrewharvey commented 3 years ago

I imagine you could likely (and it would probably be correct to) add the ranges of flat numbers as an addition to something like building:level (or whatever the proper tagging for multi-story buildings is) areas.

I don't understand what you mean. The proper tagging for a multi-story building is building=* + building:levels>1.

Realistically though no one is going map a thirty story building as thirty different anything though

If someone was to do indoor mapping they might map each floor, but I'm not talking about that, I'm just talking about mapping the building itself as building=apartments + building:levels=30 + addr:housenumber=N + addr:flats=Y.

And trying to add every flat number for such buildings is clearly "mapping every blade of grass."

I disagree.

Plus, really, no one cares about what flat is where in the building at that point either.

Exactly, which is why I wouldn't and most people wouldn't map each addr:unit= as it's own node within the building, I'd just map addr:flats= as the list of units within the building.

Also, I'm sure we could find a single ridiculous edge case to poopoo any rendering any tag.

It's not a single edge case, it's very common, and it's not ridiculous.

I don't think it's valid way to approach to this though if there's almost zero chance of such things being mapped in any amount (or at all) IRL.

But people are mapping addr:flats this way, so as a style you can't change how people are mapping or tagging in OSM you just have to accommodate.

Even your shorter example is extremely unlikely to occur

I disagree, they are common where you have apartment buildings where the numbers arent just 1-N but per floor. eg units on level 1 would be 101, 102, 103, etc. then on level 2 201, 202 etc. So you need to represent this as 101-103;201-203;etc which for high rise apartments creates a long list.

if it did there's no reason they couldn't just be split into a couple of different nodes. Since doing so wouldn't technically be wrong either.

If they are all at the same building, then they should be as part of the single building and part of the address.

Adamant36 commented 3 years ago

I don't understand what you mean. The proper tagging for a multi-story building is building=* + building:levels>1.

I just didn't have access to the Wiki at the time and I couldn't remember if that was correct tag for building levels or not. Also, I was thinking about 3D mapping. Which I think is the only realistic (although still stretching it) scenario where something like that could be mapped in connection with the flat numbers. Otherwise, the flat numbers are extremely useless.

I'm just talking about mapping the building itself as building=apartments + building:levels=30 + addr:housenumber=N + addr:flats=Y

Let me ask you this, how is having specific flat numbers on a single area at all useful or useable at that point? Like, if the person is looking for flat number whatever in a thirty story building they already know that the thirty story building has that flat somewhere in it. Adding a fifty number string of flat numbers to a thirty story building area doesn't help anyone actually find anything though. Let alone does it convey anything useful. Again, they already know flat "whatever" is in the building somewhere.

I disagree.

See my last response. Really, OSM is suppose to be a map of things that exist on the ground and can be confirmed. Not everything that exists and can be confirmed though. Just useful, actionable things. To me a thirty story building with a bunch of flat numbers attached to a single building area is neither. Just like "mapping every blade of grass" isn't. Just because you can do something, doesn't mean you should.

It's not a single edge case, it's very common, and it's not ridiculous.

You didn't provide a link to a real world example. So I assumed it was either an edge case or didn't exist in the first place. Also, I researched it myself and couldn't find any examples even close to that many numbers. Not to say they don't exist, but seriously doubt it's that many.

Look it at this way, there's 383,992 uses of addr:flats. If there's like 200 examples, which seems a little high to me, then it's still only 0.0001% of the total usage. That's nothing. Literally every tag out there has that many "bad usage" examples. Probably it's more like only 4 or 5 "bad" examples. Say it isn't and there's multiples more, there's really no hard line anyway. Otherwise, nothing would be rendered.

I disagree, they are common where you have apartment buildings where the numbers arent just 1-N but per floor.

So? From what I can tell they aren't being mapped if they do exist. Which should be the important thing, because if your going to argue something shouldn't be rendered because such and such issue, then it should actually be an existing issue at the time or at least somewhat likely to occur. Again though, I doubt they are common or there would be a more then nominal amount of them currently mapped. When there just isn't.

If they are all at the same building, then they should be as part of the single building and part of the address.

I disagree. I see nothing wrong with mapping things as separate nodes if they are on separate floors or whatever. I'm pretty sure that's how things are already done with underground features. As well as places where a shop is on the bottom floor of a multiple story building and the "apartments" above it have different addresses. Otherwise, you'd be adding the address for the apartments to the stores POI. Which would be stupid and isn't possible anyway. There's also plenty of "single building, multiple shop" scenarios like malls where the shops are mapped as different POIs when they occupy the same building. So, what's the difference?

andrewharvey commented 3 years ago

Let me ask you this, how is having specific flat numbers on a single area at all useful or useable at that point?

Why does that matter? As OSM mappers we try to model the real world, it doesn't matter if it's useful to me or not I still map it as one day it might be useful to someone.

For geocoding it provides validation, if I search for a specific flat number at a specific address, with addr:flats OSM will be able to tell me if that flat number exists at the address or not.

Again, they already know flat "whatever" is in the building somewhere.

How do they know it exists or not if it's not mapped? Maybe someone wants to generate a list of all addresses at the building, to do this they need addr:flats.

Or maybe that 30 story building is actually comprised of two towers each with the same address, or maybe it's one tower but half the units are from one entrance and the other from another entrance. You need to list out all the units for each entrance.

You didn't provide a link to a real world example. So I assumed it was either an edge case or didn't exist in the first place.

I'm working on an address import at the moment which would import many long addr:flats. See https://gitlab.com/alantgeo/vicmap2osm/#removing-duplicates

From what I can tell they aren't being mapped if they do exist.

Well then I better go outside and start mapping some :wink:

I see nothing wrong with mapping things as separate nodes if they are on separate floors or whatever.

Sure if you want to do full indoor mapping of a building then yes, but as an intermediate step for someone wanting to add more detail to the building without doing indoor mapping, then addr:flats is much easier to manage than just 300 nodes on top of each other in the building centroid.

pnorman commented 3 years ago

We've drifted a long way from discussing how to improve the rendering of addr:flats.

Adamant36 commented 3 years ago

We've drifted a long way from discussing how to improve the rendering of addr:flats.

I don't think so. At least from my side. My comment was aimed at accomplishing a few things, 1. Getting an example from the map of the extremely long string of flat numbers that @andrewharvey says exists 2. Arriving at understanding of how much of a problem such tagging actually is in the real world.

I'd say both are perfectly relevant and on topic. Even if @andrewharvey was unable to aid me in accomplishing either. At the end of the day if he can't then I'd say there's zero reason not to render this. At least not based on the 1-3;10-12;100-103;110-112;200-203;210-212;300-303;305-312;400-403;405-412;500-503;505-512;600-603;605-612;700-703;705-712;800-803;805-812;900;902-903;905-911;1000;1002-1003;1005-1011;1100;1102-1103;1105-1111;1200;1202-1203;1205-1211;1300;1302-1303;1305-1311;1400;1402-1403;1405-1411;1500;1502-1503;1505-1511;1600;1602-1603;1605-1611;1700;1702-1703;1705-1711;1800;1802-1803;1805-1811;1900;1902-1903;1905-1911;2000;2002-2003;2005-2011;2100;2102-2103;2105-2111;2200;2202-2203;2205-2211;2300;2302-2303;2305-2311;2400;2402-2403;2405-2411;2500;2502-2503;2505-2511;2600;2602-2603;2605;2607;2609-2611;2700;2702-2703;2705;2707;2709-2711;2800;2802-2803;2805;2809-2811;2900;2902-2903;2905;2907;2909-2911;3003;3006;3009;3012-3013 example. Especially if his response is to tell me to go map one. Which is pretty milk toast.

As a side to that, I don't personally see the original examples given by @sanderd17 as being that much of a problem. There's some long business names out there and I don't see the examples being that much different then those. There's no hard character limit for things.

imagico commented 3 years ago

I concur with @pnorman - recent discussion is fairly non-productive. As said plenty of times in the past this is not the place to discuss how tags should be used, we need to look at how tags are actually used. It is fairly evident that there are uses of addr:flats where the current display style is counterproductive for map readability. OTOH there are a lot of uses of the tag where rendering it in some form (not necessarily in the current simple concatenation with the housenumber) would be beneficial for both mapper feedback and map usefulness.

But until someone takes a planet file and does an analysis of the length distribution of values of addr:flats any discussion how to address this problem is pretty pointless.

andrewharvey commented 3 years ago

Even if @andrewharvey was unable to aid me in accomplishing either. At the end of the day if he can't then I'd say there's zero reason not to render this.

I went for a short walk this morning intent on adding a bunch of addr:flats tags, many older apartments used sequential numbers 1-N which was easy and short to tag. But newer apartments particularly those marketed to the Chinese had the kinds of values I described, they'd be long even without blacklisting the number 4, but with, one here I checked this morning I had to overflow the 255 tag value limit twice to split the value across addr:flats, addr:flats1, addr:flats2.

Not representative at all for a global database, but just a data point of real world examples of longer values.

https://www.openstreetmap.org/way/466884766 https://www.openstreetmap.org/way/504331827

I think it's very clear from all this that longer values are valid how the tag is documented.

I'm now generating a report from the planet dump to see the length distribution of existing tagged values.

PS. I think we could do with a bit less intimidation in this thread, all it does is drive away contributors and people trying to help.

andrewharvey commented 3 years ago

At the moment in OSM 93% of addr:flats are 10 characters or less, 20k of 310k total tags are > 10 characters.

source code (click to expand) ``` wget -O - 'https://ftp5.gwdg.de/pub/misc/openstreetmap/planet.openstreetmap.org/pbf/planet-latest.osm.pbf' | osmium tags-filter --input-format=pbf --output-format=pbf --omit-referenced - 'addr:flats' > flats.osm.pbf osmium export --output-format=geojson --omit-rs flats.osm.pbf > flats.geojson ogr2ogr -select 'addr:flats' -f CSV flats.csv flats.geojson ``` ``` wc -l flats.csv 309616 flats.csv ``` ```bash #!/bin/bash while read line; do ((histogram[${#line}]++)) done < flats.csv echo "Length Occurrence" for length in "${!histogram[@]}"; do printf "%-6s %s\n" "${length}" "${histogram[$length]}" done ```

2021-06-26_20-34

distribution table (click to expand) ``` Length Occurrence 1 8554 2 2359 3 84223 4 43313 5 88110 6 14716 7 37652 8 1480 9 6360 10 2231 11 1539 12 909 13 3589 14 1511 15 675 16 870 17 1919 18 252 19 989 20 222 21 781 22 294 23 246 24 284 25 1372 26 104 27 117 28 375 29 295 30 57 31 223 32 120 33 296 34 97 35 69 36 78 37 305 38 27 39 37 40 121 41 153 42 39 43 88 44 30 45 88 46 78 47 17 48 30 49 218 50 20 51 45 52 78 53 51 54 21 55 54 56 28 57 66 58 32 59 21 60 25 61 78 62 26 63 14 64 50 65 57 66 15 67 28 68 10 69 27 70 25 71 15 72 16 73 76 74 9 75 14 76 25 77 16 78 14 79 26 80 9 81 35 82 18 83 10 84 10 85 46 86 6 87 8 88 14 89 15 90 8 91 21 92 6 93 21 94 15 95 10 96 7 97 34 98 2 99 12 100 9 101 7 102 6 103 15 104 8 105 15 106 15 107 12 108 5 109 32 110 9 111 12 112 9 113 16 114 7 115 13 116 4 117 9 118 10 119 4 120 3 121 22 122 6 123 7 124 10 125 7 126 8 127 12 128 4 129 10 130 9 131 9 132 5 133 18 134 6 135 4 136 11 137 3 138 5 139 7 140 3 141 7 142 10 143 3 144 4 145 16 147 4 148 12 149 11 150 5 151 20 152 2 153 5 154 9 155 4 156 6 157 11 158 1 159 4 160 6 161 7 162 11 163 5 164 2 165 2 166 5 168 1 169 6 170 3 171 4 172 5 173 5 174 2 175 3 176 3 177 3 178 4 179 3 180 3 181 9 182 3 183 4 184 8 185 2 186 6 187 4 188 1 189 3 190 8 191 2 192 5 193 8 196 2 197 2 198 3 199 3 201 5 202 3 203 2 204 3 205 4 206 2 207 7 208 6 209 1 210 2 211 6 212 1 213 3 214 6 215 1 216 1 217 4 218 4 219 2 220 2 221 1 222 4 223 5 224 3 225 3 227 2 229 1 230 1 231 4 232 6 233 3 235 2 238 7 240 1 241 2 244 1 245 1 246 2 247 1 248 1 249 4 251 2 252 1 253 3 254 1 255 6 256 5 257 1 ```
andrewharvey commented 3 years ago

I'm not sure how feasible it is to implement, but probably the best solution is anything <= 7 characters (7 characters captures something like 101-909) can be rendered, but anything longer should not render. This captures the vast majority of cases which can be rendered, and by not showing longer values it lessens the impact of people deleting still valid tags just because it makes the map rendering ugly.

andrewharvey commented 3 years ago

Completely untested but proposed fix at #4430

imagico commented 3 years ago

Thanks, that is very useful.

My suggestion would be to try:

I don't think just dropping rendering of longer values is a good idea - that is potentially confusing for mappers.

andrewharvey commented 3 years ago

separating the rendering of addr:flats and addr:unit from addr:housenumber in rendering and prioritizing addr:housenumber

partly related to #3568, but in Australia the addr:unit and addr:housenumber would go together as {addr:unit}/{addr:housenumber}.

addr:unit shouldn't be used together with addr:flats, so if there is addr:flats instead then {addr:flats}/{addr:housenumber} works too.

distinguish rendering of addr:flats and addr:unit from addr:housenumber in text styling (it is currently ambiguous which tags are actually rendered)

Again I can only comment on the Australian localisation, but this should be unit/number, no need for different styles. For my region the current number space unit is very confusing.

apply some shortening to longer addr:flats values

I guess we could do that. At first it might be confusing to mappers, if you see "..." then you think that was a literal tag value and might mean the tag needs fixing only to find it was just a rendering style.

If the tag value is long then really there's not much benefit in showing the first 7 characters as they probably aren't as useful as if the tag value was <= 7 chars.

A;B;C;D;E

I don't think we should try to cater for this, since the wiki specifically says you can use a range to compress the values eg A-E which would fit within the 7 characters.

I don't think just dropping rendering of longer values is a good idea - that is potentially confusing for mappers.

Yes, but also rendering them or trimming with ... is also potentially confusing to mappers. So I think dropping the values from display is probably the best compromise.

imagico commented 3 years ago

Keep in mind that we are creating an international map style that means to show mapping under different cultural conventions with equal determination. And we also aim to render incomplete mapping (some address components being mapped while others are missing) in a transparent and non-confusing fashion.

If abbreviating address tags with an ellipsis could be misinterpreted as being literally tagged as such using a vertical/midline ellipsis can probably help - see https://en.wikipedia.org/wiki/Ellipsis#Computer_representations.