CalvinBackup/iD
1
0
Fork 0
mirror of https://github.com/FoggedLens/iD.git synced 2026-02-13 01:02:58 +00:00
Code Issues Packages Projects Releases Wiki Activity

Add a bit about iD.Tree to ARCHITECTURE.md

Browse Source
This commit is contained in:
John Firebaugh
2013-02-25 13:51:54 -08:00
parent 42a662720d
commit 516193d8ea
1 changed files with 20 additions and 14 deletions
Download Patch File Download Diff File Expand all files Collapse all files

34
ARCHITECTURE.md
View File

@@ -20,9 +20,9 @@ which implements map panning and zooming.
## Core
The iD *core* implements the OSM data types, a graph of OSM object's
relationships to each other, and an undo/redo history for changes made during
editing. It aims to be generic enough to be used by other JavaScript-based
tools for OpenStreetMap.
relationships to each other, an undo/redo history for changes made during
editing, and a couple of important auxiliary classes. It aims to be generic
enough to be used by other JavaScript-based tools for OpenStreetMap.
Briefly, the OSM data model includes three basic data types: nodes, ways, and
relations. A _node_ is a point type, having a single geographic coordinate. A
@@ -77,17 +77,23 @@ references to entities that have not changed, keeping memory use to a minimum.
If you are familiar with how git works internally, this persistent data
structure approach is very similar.
The final component of the core is comprised of `iD.History` and
`iD.Difference`, which track the changes made in an editing session and
provide undo/redo capabilities. Here, the immutable nature of the core types
really pays off: the history is a simple stack of graphs, each representing
the state of the data at a particular point in editing. The graph at the top
of the stack is the current state, off which all rendering is based. To undo
the last change, this graph is popped off the stack, and the map is
re-rendered based on the new top of the stack. Contrast this to a mutable
graph as used in JOSM and Potlatch: every command that changes the graph must
implement an equal and opposite undo command that restores the graph to the
previous state.
The last major component of the core is `iD.History`, which tracks the changes
made in an editing session and provide undo/redo capabilities. Here, the
immutable nature of the core types really pays off: the history is a simple
stack of graphs, each representing the state of the data at a particular point
in editing. The graph at the top of the stack is the current state, off which
all rendering is based. To undo the last change, this graph is popped off the
stack, and the map is re-rendered based on the new top of the stack. Contrast
this to a mutable graph as used in JOSM and Potlatch: every command that
changes the graph must implement an equal and opposite undo command that
restores the graph to the previous state.
Finally, we have the auxiliary classes `iD.Difference` and `iD.Tree`. The first
encapsulates the difference between two graphs, and knows how to calculate the
set of entities that were created, modified, or deleted, and need to be redrawn.
The second provides a means of calculating which entities, out of all that have
been downloaded, are currently visible. In order to do this very quickly as you
pan or zoom the map, it uses an [R-tree](http://en.wikipedia.org/wiki/R-tree).
## Actions