[OSM-dev] API 0.5 is on the way
michael_j at email.de
Sat Sep 15 20:54:23 BST 2007
>> I'd like to understand the use case behind.
> The possible use case, esoteric as it may seem, is structured tags.
> You can use a relation as a tag container. This gets very theoretical
> but I hope it can be understood:
> Assume you have something that has a set of tags valid weekdays, and
> the same set of tags with completely different values for the weekend.
> I know this example is too simple to be a real use case but I believe
> it at least hints at interesting possibilities.
> So you can have lots of tags on the object:
> opening_times=9-17 weekdays, 10-18 weekends
> entry_fee=10 GBP weekdays, 15 GBP weekends
> entry_fee_weekdays=10 GBP
> entry_fee_weekends=15 GBP
> or you could make the whole thing a *relation* with two members, each
> of them a relation again, one in the role "weekdays" one in the role
> "weekends", and each one of these has the tags
> and the other
> Which rather nicely models the whole thing, especially if you consider
> there might be one entry for each day of the week.
OK. I understand. Intuitively I'd turn the relation around and let the
container point to the weekday etc. Why do you want to do it the other
Everyone creating their Sunday object. It is not the best way to model
it, however it is for free and it does not hurt. We can always delete
them from the database if we need to.
It seems to be something to start modeling new things we have not yet
understood. We will see, how people will use it. We can then react.
As such objects require a very much different user interface, we might
in the future come to the conclusion that we should introduce new object
A similar might exist for Country Names, Area Codes etc.
>> This might lead to "Circular referenced Relations". A set of relations
>> pointing to each other and that have no references to a way or a node.
> Circular references can happen (this has nothing to do with whether a
> way or node is also in it or not); that's why we never, anywhere,
> offer to return a relation with all members recursively retrieved. The
> API does not protect against circular references but it doesn't choke
> on them either. I think that's the best way to deal with them; if
> someone came up with a reson why he would want to use circular
> references somewhere, who am I to judge whether that makes sense ;-)
As "Circular referenced Relations" can not be prevented, the tools need
to be able to safely handle "Circular referenced Relations". :-(
More information about the dev