[Tagging] Feature Proposal - RFC - addrN:*

Markus Lindholm markus.lindholm at gmail.com
Wed Jan 21 07:28:44 UTC 2015


On 21 January 2015 at 07:59, Friedrich Volkmann <bsd at volki.at> wrote:
> On 19.01.2015 12:37, Markus Lindholm wrote:
>> Treating addresses as attributes might be fast and convenient but that
>> kind of scheme
>> becomes incoherent as there is no one-to-one relationship between
>> addresses and other features.
>> E.g.
>> - There are MULTIPLE POIs that all relate to ONE address
>> - There are MULTIPLE addresses that all relate to ONE building
>> So you would end up with a database where the address information is
>> stored "all over the place" and no coherent way to process it. Better
>> to have bare address nodes and when necessary use a relation to create
>> an association between the address and other features.
>
> We already have zillions of POIs (e.g. shop nodes) with address attributes.
> If you wanted to keep address information separate, you would need to add
> just as many address nodes and relations. You would even need to separate
> all addresses from buildings. So your vision is not only incompatible with
> the addrN scheme, it is incompatible with how addresses are used in OSM
> altogether.
>
> You apparently wish to implement a relational database concept for address
> information, but this is just impossible because OSM is not a relational
> database. All data in OSM directly or indirectly contains geographical
> information. When you use a relation to connect a shop node (which has
> geographical coordinates) to an address node (which as geographical
> coordinates), you have two conflicting sets of geographical coordinates. So
> if you are looking for normalisation, you need to get rid of the address
> nodes altogether and set the adress tags on the relation directly.

Before we get carried away by a zillion relations I think we have to
answer the questions as to what purpose do we want to explicitly
associate an address with a POI or a building.

Is it so that the data consumer can find her way to a POI? That's
obviously superfluous as the POI already has a geographical location
given. The only purpose I can think of is to facilitate for the data
consumer to send a physical letter to the POI and that is a bit of a
fringe use case. With buildings is even murkier as to what the purpose
would be. Is there any country where the address would be part of the
ID for the building in the cadastre? Seems unlikely as a building can
have many addresses.

So I'm not advocating that a zillion relation be created, just that if
you REALLY need an EXPLICIT association between an address and a
POI/building then you should use a relation. And that addresses would
be stored in the database in a coherent manner.



More information about the Tagging mailing list