Definitely. So far iD is taking a few approaches that differ from Potlatch:
- Instead of storing undo data in a separate undo stack, we're creating a 'persistent datastucture' style graph that preserves every version of data while trying to keep memory usage low. This means that operations, undo, and (I think) changeset creation can be implemented fairly simply, but things like 'showing the 'elastic band' for drawing ways isn't straightforward, and more important stuff like how to merge in new data downloaded from the API - without having this data removed by undo operations - isn't really solved yet. - Right now the main structure is in 'Graph' and is a Javascript object of 'prefixed id' -> node/way/relation mappings. Prefixed ids are n1 for nodes, w1 for ways, r1 for relations, and so on. Asked around and this approach has been taken before. Since these ids are stored as keys in an object, they're stored as strings internally anyway, so there should be no performance difference. But, Potlatch 2 and JOSM have a stronger concept of a graph - elements in iD currently have references as ids, so a way will have nodes: [n1, n2 ... nk] and these are 'resolved' by a graph.fetch method. But this probably needs to be actually represented in the code, to make things like 'finding all nodes without way parents' faster - a serious bottleneck right now. Should this be a separate 'tree' concept or should the graph be nested itself and only contain parent-free elements at its root? - Is it worthwhile to consider circular relations in an editor? For reference, implementations: * Graph: https://github.com/systemed/iD/blob/master/js/iD/graph/Graph.js * Operations: https://github.com/systemed/iD/blob/master/js/iD/actions/operations.js Thanks for the knowledge as always! -Tom On Tue, Nov 6, 2012 at 9:54 AM, Andy Allan <gravityst...@gmail.com> wrote: > On 5 November 2012 18:11, Alex Barth <a...@mapbox.com> wrote: > > > > Notes here: > > > > https://github.com/systemed/iD/wiki/Check-in-Nov-05-2012 > > From the notes: > > @tmcw: "I would love anyone else to look at this and try fixing / > proofing some of the work" (RichardF, Allan, JOSM team) > > Can you / Tom elaborate on this? > > Cheers, > Andy > > _______________________________________________ > dev mailing list > dev@openstreetmap.org > http://lists.openstreetmap.org/listinfo/dev >
_______________________________________________ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
