[OSM-talk] [tagging] Feature Proposal - Voting - architect=*

[Jonathan Bennett]

Tobias Knerr wrote:

> "Relations are not Categories" uses the argument that you can query for
> all objects that carry a tag. This isn't enough, however, if the
> combined information from tags and coordinates doesn't qualify as an
> unique identifier. The situation for architects, imo, resembles the
> route relations (also in that there can be more than one architect),
> thus there is a case for relations.

I disagree. The reason we use relations for routes is that each section
of the route are part of the same "thing" -- a signed route that uses
many different sections of highway. While each individual section may
have some other identity, the route exists as a separate abstract
entity. A route is also a geographic entity.

Buildings designed by the same architect don't form part of some greater
whole -- it's just metadata about the buildings themselves, and the
relationship between them certainly isn't geographical. That's why using
a relation to group them would simply be classification.

There are lots of different ways you could format an architect tag to
ensure unambiguous values:

<surname> "," <firstname> <initials>

Would be a start, and should you find two architects with exactly the
same name (can you name any?) you could add their year of birth:

<surname> "," <firstname> <initials> "(" <year> ")"


The important thing -- something I believe to be part of the OSM way of
doing things -- is to deal with actual cases, rather than theoretical
ones. The reason we have "Any Tags You Like" is because OSM is different
to other GIS systems. We don't have official, authoritative, preordained
ontologies and taxonomies. We make them up as we go along, based on what
we encounter in the real world. We then refine the tags as we get a
better idea of what works and what doesn't.

Trying to fix a problem you haven't encountered yet, particularly by
overusing a technical feature like relations, is overkill and probably
counter-productive. Keep it simple, and we'll get a better map far quicker.




-- 
Jonathan (Jonobennett)