Hi, I am fairly new to map edits and I have searched quite a bit on the matter but did not find a definite guideline.
I am wondering how to define addresses so that they are accurate and useful to users but without falling into redundancies. Here are some examples:
Building with multiple addresses and parking garage:
The way I edited these so far (just a couple of buildings) are by adding the address to the building object with the numbers separated by commas. On top of that, point addresses where the doors are (useful for mail or delivery platforms) and, on top of that, also define the address and numbers for the entrance(s) of the parking garage (for residents that want to be navigated to the garage entrance when driving and not to the door). I am wondering if I am doing this correctly or if all this is too redundant and might cause more problems than bring solutions.
Building with one address:
So far, I only introduced the address in the building object but I wonder if defining where the entrance to the building is on top of that would be useful for some users. Also, if yes, would you use the “Address” class or the “Entrance/Exit” to define the point where the door is?
There are not very many buildings with multiple addresses in the areas I have mapped so I will leave that for others to comment on. I will focus on a building with one address.
For me the main reason for adding address information is for navigation and deliveries so I want to map the address in a way that increases the chances that the visitor or parcel delivery person get to the correct place. Usually having the address on the building is all you need.
But there are exceptions. I have seen buildings, usually detached houses, that are set back on the land parcel so far that the building is physically closer to another street. In those cases a navigation app may direct the visitor to the wrong side of the building. And the building might not even be accessible from that point due to walls, steep hills, or other obstacles. For those cases, which are fortunately rare in my area, I may put the address on an entrance node or even just put an address only node at an appropriate place on the correct street.
I think the smarter navigation apps can figure out about driveways, so another way to deal with this edge case is to add the driveway(s) for the building. My hope when doing this is that the building end of the driveway will be the closest road and will be picked by the navigation app for its destination.
Generally there should be one feature to one element so the same address should generally not be recorded twice unless to document that a particular address really is used by multiple separately mapped businesses in the same building or some part of the address is different (like unit or flat number).
If you are mapping addresses on entrance nodes then it is generally not recommended to also put it on the way and vice versa.
You can use standalone nodes for such addresses, but don’t add the address on the building outline. You can also add the entrances. This is where you can choose whether to keep the address as a separate point or merge it with the entrance. Generally speaking if one address has 2 or more entrances, keep it as a separate node. Otherwise you can choose either option.
In cases where a building has only one address, adding the entrance(s) is quite useful but duplicating the address is not a good idea. It’s better to keep the address on the building outline. See OpenStreetMap for such example.
Your linked examples were really useful to understand the situation you were trying to describe. But the topic is still not 100% clear to me.
I think @dieterdreist just pinpointed the core of my confusion. These addresses are object properties unless, of course, we use the point feature “address”. OSM should be kind of a map information database right? The richer, the better. And then the tools/software that use the information in this database should know which information is interesting for their needs. The one feature one element applies when you have a university or a sports campus and you should not use that feature for the area and the buildings of the area. But in this case, the addresses are properties of the features.
In the example from Champex-Lac the building has the name of the street even though the name of the street is also in the entrances. In the example from Sofia this is not the case. The same way we could argue that the building could also contain the group of door numbers that belong to it.
I was referring to something like this example which includes the garage entrance. There are three interesting uses for this information:
Delivery
If I have a software for some delivery service I want the user to be guided to the entrance/exit where the package can be delivered.
Average driver
I want the user to be asked if they want to go to the garage, in this example situated on the south side of the building, or the actual address, in case they do not want to enter the garage. Sometimes the garage is accessed from the back of the building and the route to it is quite different.
Building
For this is more difficult to find an example but let’s suppose some kind of scenario in which the addresses that belong to a certain building are the information we need and not how many entrances there are or where they are.
By eliminating property information from either the building, entrance or garage entrance we are truncating the possible uses for the information in OSM, aren’t we? On the other hand, I also understand that this may overcomplicate things for OSM users because their information queries have to be much more precise.
A fourth issue with the example I linked above would be the POIs on the eastern side of the building. They share the address with the flats above them but they are situated on the opposite side of the building.
If the parking entrance and human entrance are on the same way then it should be possible for software to give the option to use the one suitable to the mode of transport even if just tagged on one entrance or interior node. Not sure if anything does right now but we don’t strive to avoid all preprocessing by downstream users.
