An industrial property with multiple buildings is used by a single operator. The property has one address, and the individual buildings do not have publicly known unit addresses. The boundary of the property is marked with a fence, and it is clear to anyone on the ground what the boundary of the property’s address is.
One could map landuse=industrial; addr:street=Santaradantie; addr:housenumber=7 for the overall site, and map building=warehouse; addr:street=Santaradantie; addr:housenumber=7 for all of the buildings, too.
But now it is not immediately obvious what area the address Santaradantie 7 actually refers to. The buildings would have to be identified to be wholly within the encompassing landuse polygon for one to determine that the landuse polygon defines the space of the address. The addr:*=* tags of the buildings would then only define what building the address is at, not where the boundary of the address itself is.
If addr:*=* was only used for defining where the address is, the only logical place to put address tags on would be the outer polygon. This is obviously not the de facto usage of address, as, for example, business POI nodes often have full address tags despite being wholly within a building that also has these same address tags.
What should addr:*=* actually mean? Is it where the address is, or what address the feature is at? If the full area of the address is obvious on the ground, how would that be mapped?
How do you view the addr:*=* tag?
addr:*=* should only represent what address the tagged feature is at
addr:*=* should only represent where the address actually is
addr:*=* should represent both ideas without a clear distinction
I think that the options that you offer are not clear. Typically, the addr tag is an attribute of the main feature that is tagged by the node. (Some stand-alone addr nodes exist, but that’s a separate issue.) I don’t think that a landuse area is a good place for an addr attribute. It makes more sense to use addr tags with a site relation, a building, a node that represents a business or similar, or an entrance.
Would it then be idiomatic to map each of the buildings in my sample images with the same address values, and to not map the actual boundary of the address? I feel that this is a weaker scheme, since, for example, geocoders can not determine what the address Santarannantie 7 actually encompasses, only singular features it contains.
Where would you map the name of the business at that site, or the operator? I doubt you would map those on the individual buildings - are address tags any different?
More generally, is this issue specific to address tags, or is could it equally be expressed as a more general question about where to tag attributes such as name, operator, website and other contact details…
(Not a rhetorical question, I am genuinely not sure).
This isn’t optimal, though. In real life the address of a fixed feature (almost?) always has a definite location or boundary. If an address is the address of a feature, then it means that this feature is within that definite location or boundary that the address describes. Why shouldn’t we map what the address itself actually refers to, if we know this information?
It seems to vary. For schools, for example, Tag:amenity=school - OpenStreetMap Wiki suggests that the entire school site, not just the building, should be mapped as amenity=school and that this school site boundary should receive the addr:*=* tags. Yet there doesn’t seem to be a proper primary tag for marking an industrial property in this manner.
From a practical point of view, if you navigate to an address, where do you want to arrive?
Usually, this will be an entrance, main gate, office building or POI (e.g. shop). All of this can be tagged appropriately or is inferred by the geocoder.
For an industrial estate, you can e.g. put the address on the compound and tag entrance=main on the main gate (Edit: even better, barrier=gate, routing:entrance=main) on its outline (where there is often a checkpoint or intercom).
There are two ways I know of (lengthy discussion on this in German forum), and both are less than perfect. Option A would be e.g. landuse=industrial, industrial=* (landuse as site area) or B man_made=works (extending the factory building to the area of the site).
I would put the address on the landuse polygon. I would not tag the individual buildings, unless each has a sub-address (e.g. “Santaradantie 7B”).
(Note that in some jurisdictions, an address refers to the point of entry, not the property as a whole. For example, in Italy: There, a property that fronts two different streets may have two entrance nodes with two different addresses)
though you have cases of entire industrial area / hospital / etc being assigned an address, that is specifically for entire area - or at least handled so
adding it only to the most important building or to every building or to node somewhere within area or to entrance or all entrances would be an inferior solution
(in some cases some specific buildings also have own addresses - or names, or codes or…)
Should perhaps a new tag such as addr:boundary=yes be implemented, so that in cases where the boundary of the address can be mapped and when there isn’t an established primary area feature such as amenity=school to receive the address information, it can be directly identified as specifying the extend of the address?
This would retain compatibility with the current practice of tagging individual buildings in a complex with identical addresses, as a new encompassing addr:boundary=yes feature would indicate that those buildings belong to its span.
that is bad when Santaradantie 7 refers to a specific building or location
that is good when Santaradantie 7 does not refer to a specific building or location, but rather to an entire site
addr: can be a property and in this case it indicates (postal?) address of a specific feature
addr: can be standalone object in such case it records that address is more or less at a given location
(in cases where first is enough to express also second, we skip second - for example if building outline has an address tagged there is no need for address node inside it repeating the same)
(also, in cases where first can be inferred from second it can be skipped - if building outline has an address tagged typically there is no real need to replicate the same info for each POI inside)
we have “established primary area feature” for industrial land use, it is landuse=industrial (and man_made=works and some other more specialized are available)
I see no benefit from adding addr:boundary=yes to such objects
Searching for addr:street=Lukupuronrinne AND addr:housenumber=1 AND addr:boundary=yes before searching for only addr:street=Lukupuronrinne AND addr:housenumber=1 could give geocoders a better representation of what an address refers to.
There is no reason why multiple landuses couldn’t exist within one address. Take, for example, a construction site within a residential complex. It could conceivably be tagged with the address of the residential complex it is a part of. If that residential complex were also to be tagged with a landuse tag, then it wouldn’t be clear from tags alone which feature represents the entire address space.
In which case the geocoder falls back to searching for features without addr:boundary. Just as searching for Streetname Housenumber Unit falls back to returning Streetname Housenumber if the specific unit has not been mapped.
