> 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 <[EMAIL PROTECTED]>: > 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 [EMAIL PROTECTED] ## N49°00'09" E008°23'33" > >
_______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
