[OSM-dev] API 0.5 is on the way

Frederik Ramm frederik at remote.org
Sat Sep 15 19:26:55 BST 2007

Should've gone to dev ;-)


> > Frederik kicked me for this: he suggests that a relation needs either
> > a member or a tag but not both.
> Uups. The documentation is vague on this point too. We should update it 
> with the final resolution.
> A relation without a member?? That is probably hard to retrieve back 
> from the database.

Don't forget that a relation may be a member of something itself. Ways
to retrieve a relation without a member:

* By ID
* Through a search on tag values
* By making a "full" request on the relation containing it

> 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. Of course that's
far a way in the future somewhere, and would require proper editor
support etc., but I am unwilling to introduce restrictions now that
would disallow this kind of use.

> 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 ;-)


Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00.09' E008°23.33'

More information about the dev mailing list