Talk:Relationships

Explicit and Implicit Relationships

There are relationships which can be expressed by geography. For example, a post code area will usually have a defined geographical area. It is not that the postal service assigns a post code to streets and houses at random. Instead, they design an (usually closed) area and say "anything herein is post code so-and-so".

Such implicit relationships should not be made explicit, I believe.

The fact that a certain house has the post code XYZ is *not* a property of that one house; if I move the house to a different location then the post code will change. If I place a new house in an existing post code area, it will automatically have the post code of that area; no need to say that.

The same is usually true for most of the "is-in" relationships that we think about. They are not properties of individual objects, but functions of their location. A village that "is-in" Germany will, if the border of Germany changes, perhaps be in France; being in Germany is not a characteristic of the village.

There are exceptions, for example the German embassy in Paris could be viewed as being part of Germany even though it is not inside the German border polygon.

Examples for "explicit" relationships are turn restrictions, or "belongs-to" relationships where the relationship is not based on the location.

I don't have a packaged solution for that, I just want to encourage people to make this distinction in their heads between relationships that somehow just "fall into place" if the locations of everything are known, and those that must in any case be made explicit.

--Frederik Ramm 23:47, 7 July 2007 (BST)

is_in

I find the is_in tag quite useful and could be used to much greater potential. They can be used to produce polygon lines of where hamlet, village, town, suburb, city, council, region, state, country and continent boundaries are. You shouldn't need to have to specify all of these properties for every item. You only need to specify the next item up in the hierarchy. Eventually a tree of all items should be able to be produced, with the ability to programatically choose the appropriate tags for some items that are missing the is_in tag.

These boundaries are fairly static and are unlikely to change. However only specifying the next boundary up, would it easier if there were boundary changes. Smsm1 01:30, 9 July 2007 (BST)

Sorry I do not understand how you can generate polygon from the is_in hierarchy? For example council can hardly be generated in this way. (BTW: I agree with that is only necessary and good to specify next item in hierarchy). --Gorn 18:18, 15 July 2007 (BST)

Changing Turn Restriction

Just an idea: i thing that in case of changing turn restriction of other restrictions which does not follow any simple algorithm we can treat them as traffic lights. (Until there is an good way to change them online of course ... imagine map with all traffic lights changing in synchro with reality ;-) ) --Gorn 16:52, 15 July 2007 (BST)

Turn Priority

I think it is good to add Turn Priorities to the page. It helps the navigation very much. Without this the navigation should unnecessarily give instructions on many obvious places. I am using TomTom navigator which would not give you any instruction if you should just follow the priority road. I find this very convenient. --Gorn 19:03, 16 July 2007 (BST)

Relation Category

Just an idea: category tag for relation to distinguish between category=visual ((renderers needs to deal with them, like multipolygons, bridges of tunnels) and category=meta (usualy for routing or generaly for non visual relations, like turn_restriction ) --Dido 14:14, 27 October 2007 (BST)