Dave Stubbs wrote: > On Fri, Oct 31, 2008 at 11:02 AM, Stefan de Konink <[EMAIL PROTECTED]> wrote: >> On Fri, 31 Oct 2008, Frederik Ramm wrote: >> >>> Any comments? >> You are now basically working around the actual problem. Allowing partial >> ways in the editors for the current bbox. I think hacking and breaking >> ways is bad, duplicate information, missing tags upon edit etc. I think >> storing ways with their tags per 'new segment' is bad too; hence the >> reason I proposed to use an ordered relation to represent ways. > > > With 40k nodes in a way it takes the API about 30 seconds just to > generate and serve the XML for the way, /without/ the nodes. > The .osm file with no node data goes upto about 100kb. (With node data > that's 5-6MB) > To make a modification to the way, ie: add a tag, you have to reupload > that 100kb of XML, and sit back, probably make a cup of coffee to pass > the time.
Fix the API. (and the implementation if it takes you that long ;) > I don't think having a single object of this size ends up helping > anybody. With relations we can add indirection to handle extremely > large objects, but with small API units. It just makes everything more > flexible than dealing with megalithic monoliths. Imagine a way as a relation. Where every difference in way is represented as a subtree under it. In that case common tags are equal and managed at top level. In case of a partial checkout you would only fetch the subtrees (relations) that are in your bbox and their parent. Because you now know it is a partial checkout, and you have a partial subtree, based on the changes you make (the way is a connected line) every change will just be an insertion, translation or deletion of this ordered segments, hence the only thing you download. The only thing you block is the change of nodes at cut points. In this case I address all your and my problems; - common tags are not duplicated - partial ways are smaller - relations become in essence ordered linestrings, with the possibility to add tags Stefan _______________________________________________ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
