Open sanderd17 opened 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.
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
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 ;)
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.
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
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.
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.
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.
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.
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.
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).
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.
Also see #4155
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.
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.
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.
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.
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?
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.
We've drifted a long way from discussing how to improve the rendering of addr:flats.
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.
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.
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.
At the moment in OSM 93% of addr:flats
are 10 characters or less, 20k of 310k total tags are > 10 characters.
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.
Completely untested but proposed fix at #4430
Thanks, that is very useful.
My suggestion would be to try:
A;B;C;D;E
into A...
or A;B...
. Since most longer addr:flats values are either repetitive/overlapping for different neighboring addresses (several appartment blocks with different housenumbers but with same or very similar lists of flats) or roughly consecutive and non-overlapping (different blocks from the same housenumber) such a shortening would provide some useful info to the map reader in compact form without taking a lot of space.I don't think just dropping rendering of longer values is a good idea - that is potentially confusing for mappers.
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.
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.
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 theaddr: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
Solution
Revert #3988 and display only
addr:unit
for separate addressed building units.