[OSM-dev] Datamodel relation/member constraints

[Stefan Keller]

> I don't quite understand what you mean: The API will not change one
> millimetre by making relations ordered.
The syntax doesn't change, but the semantics - an the requirements of
internal data structures.
I see the argument for ordering routes. But routing is really an optional
requirement.
This is why I advised againts ordering (it's YAGNI:
http://c2.com/cgi/wiki?YagniAndDatabases)
-- S.

2008/6/1 Frederik Ramm <frederik at remote.org>:

> Hi,
>
> >> Correct. I would be happy though if writers of editors etc. could act as
> >> if the relation members were ordered, and thus upload them in the same
> >> sequence they were downloaded. This gives us the option of switching to
>
> > In APISs/interfaces there's often a dilemma to make 'life' easier for
> > writers or readers.
> > Imposing the "same order" is even more demanding for 'data producers'
> than
> > imposing an ordering.
> > I would not recommend both in order to make APIs simple.
>
> I don't quite understand what you mean: The API will not change one
> millimetre by making relations ordered.
>
> I am relatively sure that we will have ordered relations *some day*
> because they are required for some things, for example a bus route
> relation where the bus uses the same bit of road twice on its route.
>
> If editing software today makes sure that elements are written back
> in the order they are retrieved (even though we don't have ordered
> relations yet), then the software is already prepared for a future
> time when relations might be ordered.
>
> If, on the other hand, the editor throws relation members into a
> container that doesn't guarantee ordering, then the editor will have
> to be changed when ordered relations are introduced.
>
> That's all I wanted to say.
>
> --
> Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00'09" E008°23'33"
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20080601/4bde5f37/attachment.html>