AddrN scheme

[empty-child]

Zverik, hello I am now in Georgia and opened a hellish problem - inability to map addresses of some buildings due to their position. It is corner buildings with two addresses. It would be cool to have a possibility to add both addresses through the addrN scheme. I know, it is a proposal feature, but current situation with constant data changing is a bit of conflict

[mnalis]

Perhaps it might be best to add two entrance nodes, one on each side, and each with its own address ?

Or, one might help bring that AddrN proposal to fruition (or perhaps in discussion even better solution will emerge?)

As an alternative workaround (if you want to add those only-proposed features in every_door anyway) you can use raw tag editor to add any key=value pair as you want.

[empty-child]

Hello @mnalis About nodes with only addresses: as for me, I don't like this approach due to questions to final implementation, like mobile apps. About proposals: main problem - it is a niche problem. Mostly, it is all about Eastern Europe. And we can argue heatedly for nothing. I am not in the sphere of mapping, I am neither geologist nor statistic. Not a civil engineer. I don't know how it usually works, best practice, etc. For me, map is map. Now, I can't suggest a final solution, alas About manual entering key=value, yes, unfortunately, for now. Not so effective, but...

[mnalis]

About nodes with only addresses: as for me, I don't like this approach due to questions to final implementation, like mobile apps.

Can you clarify what is the (perceived?) issue with mobile apps you are having with that approach (mapping multiple addresses on same building as separate entrance=* nodes with addr:*=*?)

All the ones I use (OsmAnd, Organic maps, StreetComplete, Every Door, Acastus Photon, Vespucci, etc.) have no problem with addresses being mapped as separate nodes instead of on building polygons. (In fact, I would be really surprised if any OSM apps had problems with them, as they are used in about the same proportion as addresses on polygons, so any app using only addresses on building would miss addresses on half of the world!)

Mapping separate entrances with multiple addresses is also the (more precise) approach that EveryDoor supports - click on the :house: (house) icon, and then on the :door: (door) icon to add it. It will snap the address on the correct building.

About proposals [...] we can argue heatedly for nothing. I am not in the sphere of mapping, I am neither geologist nor statistic. Not a civil engineer.

I think Eastern Europe is somewhat bigger than a niche, though. Also practically nobody doing the proposals is geologist or statistics or civil engineers. Just people trying to get something done on OSM. But it does require certain patience and willingness to listen to comments made by others (trying to nullify or ignore what others are saying is what can make it heated :smile:), so I understand people might find it taxing.

I don't know how it usually works, best practice

Neither does anybody else - that is actually the whole point of proposal process - to collect information from various individuals with wildly different use cases; and then try to make a solution that would work for majority of them.

Anyway, it was just a suggestion. I can't speak for project owner, but (in my experience) usually it is common prerequisite that for a functionality to be added in an editor, the tagging firstly needs to be accepted by community (either by vote in proposal process which I suggested, or by de-facto very widespread usage worldwide).

[empty-child]

Can you clarify what is the (perceived?) issue with mobile apps you are having with that approach

It is subjective, but as for me, node upon a building doesn't show a relation to the building at all. It's just a node. And just a building. It would have a meaning if these two entities were in a relation (as a data type). But they aren't.

it does require certain patience and willingness to listen to comments made by others (trying to nullify or ignore what others are saying is what can make it heated 😄)

In IT, we do not accept toxicity. Only direct aggression, yea :)

tagging firstly needs to be accepted by community

take a knife and look at another mapper on the other side of the street (joke) But in total, you are right about non-standardized approaches. Basic things create more and more problems when you begin to disassembling them

[mnalis]

It is subjective, but as for me, node upon a building doesn't show a relation to the building at all. It's just a node. And just a building. It would have a meaning if these two entities were in a relation (as a data type). But they aren't.

Hmm, but they are quite related! Not as a OSM relation data type, but in the same manner as relation consists of nodes, ways, and other relations -- it is the same with way: it consist of many nodes.

Here is random example around here:

https://www.openstreetmap.org/way/976743183 is a building polygon made up of many nodes. Some of nodes that comprise that way are different address nodes, e.g. https://www.openstreetmap.org/node/9038628353 or https://www.openstreetmap.org/node/9038628354

So those nodes are a part of that way - you can't get a stronger connection that they are "related" than that! (even relation OSM data type is arguably weaker). So it is absolutely clear to any data consumer that wants to know that those addresses are part of that exact building polygon.

Or are you thinking of cases where nodes aren't connected to the building polygon, but just with coordinates close it it? I agree that such situation might pose a problem with relating them to the building, but:

• mobile apps that you mention just don't care (they care where that address is, not part of what building it is. In fact, they prefer if the address is a node as it is more precise -- having an address on building can be problematic if building is huge and might be approached from several different streets)
• Every Door "door" functionality will make sure that the entrance is actually part of the building polygon.

[empty-child]

Or are you thinking of cases where nodes aren't connected to the building polygon, but just with coordinates close it it

Yes, I mean exact that case.

So those nodes are a part of that way - you can't get a stronger connection that they are "related" than that! (even relation OSM data type is arguably weaker).

I thought that I understood duck typing earlier. I was wrong :))

[smirnov-e]

@mnalis

Mapping separate entrances with multiple addresses is also the (more precise)

In some countries all addresses apply to the whole building, so putting several entrance nodes with different addresses is wrong. That's the reason why AddrN is a standard de-facto with country-specific approvals and, as always in OSM, nobody cares that some wiki pages states it as draft.

[mnalis]

That's the reason why AddrN is a standard de-facto with country-specific approvals and,

I'd advise someone who uses that AddrN schema and cares about it to at least go and document its actual usage on the wiki (if they are not interested in improving it). The fact that its status is "in use" or "de facto" instead of "approved" is (as you correctly note) of lesser importance. But its usage should at least be properly documented, if one expects that data consumers (like editors) should support it.

In my small part of south-eastern europe each entrance has a housenumber, so it is how we map them, even if such differently numbered entrances may lead to same staircase; so I don't use AddrN tagging schema myself. But sure, if it works for you, I certainly won't be stopping you - ATYL.

as always in OSM, nobody cares that some wiki pages states it as draft.

Well, you may not care, sure. But it you compare which data consumers use addr:housenumber vs. e.g. addr2:housenumber, you'll notice that "nobody cares" is likely not really correct.