mirror of
https://github.com/FoggedLens/iD.git
synced 2026-02-12 16:52:50 +00:00
Remove double spaces and fix links in Architecture.md (#8996)
This commit is contained in:
Gabor Hodi
@@ -1,7 +1,7 @@
|
||||
## iD Architecture
|
||||
|
||||
iD is written in a modular code style using ES6 modules. The modules are bundled
|
||||
with [rollup.js](http://rollupjs.org/). iD eventually aims to be a reusable,
|
||||
iD is written in a modular code style using ES6 modules. The modules are bundled
|
||||
with [rollup.js](http://rollupjs.org/). iD eventually aims to be a reusable,
|
||||
modular library to kickstart other JavaScript-based tools for OpenStreetMap.
|
||||
|
||||
### d3
|
||||
@@ -11,15 +11,15 @@ rendering the map data as well as many sorts of general DOM manipulation tasks
|
||||
for which jQuery would often be used.
|
||||
|
||||
Notable features of d3 that are used by iD include
|
||||
[d3.fetch](https://github.com/d3/d3/blob/develop/API.md#fetches-d3-fetch), which is
|
||||
[d3.fetch](https://github.com/d3/d3/blob/main/API.md#fetches-d3-fetch), which is
|
||||
used to make the API requests to download data from openstreetmap.org and save changes;
|
||||
[d3.dispatch](https://github.com/d3/d3/blob/develop/API.md#dispatches-d3-dispatch),
|
||||
[d3.dispatch](https://github.com/d3/d3/blob/main/API.md#dispatches-d3-dispatch),
|
||||
which provides a callback-based [Observer
|
||||
pattern](http://en.wikipedia.org/wiki/Observer_pattern) between different
|
||||
pattern](https://en.wikipedia.org/wiki/Observer_pattern) between different
|
||||
parts of iD;
|
||||
[d3.geoPath](https://github.com/d3/d3/blob/develop/API.md#paths), which
|
||||
[d3.geoPath](https://github.com/d3/d3/blob/main/API.md#paths), which
|
||||
generates SVG paths for lines and areas; and
|
||||
[d3.zoom](https://github.com/d3/d3/blob/develop/API.md#zooming-d3-zoom),
|
||||
[d3.zoom](https://github.com/d3/d3/blob/main/API.md#zooming-d3-zoom),
|
||||
which implements map panning and zooming.
|
||||
|
||||
|
||||
@@ -37,33 +37,33 @@ browser-based editing:
|
||||
### OSM Module
|
||||
|
||||
The iD *osm* module includes classes which represent the basic OpenStreetMap
|
||||
objects: nodes, ways, and relations.
|
||||
objects: nodes, ways, and relations.
|
||||
|
||||
* `iD.osmNode` - a _node_ is a point type, having a single geographic coordinate
|
||||
* `iD.osmWay` - a _way_ is an ordered list of nodes
|
||||
* `iD.osmRelation` - a _relation_ groups together nodes, ways, and other relations to provide
|
||||
* `iD.osmRelation` - a _relation_ groups together nodes, ways, and other relations to provide
|
||||
free-form higher-level structures.
|
||||
|
||||
Each of these three types has _tags_: an associative array of key-value pairs which
|
||||
Each of these three types has _tags_: an associative array of key-value pairs which
|
||||
describe the object.
|
||||
|
||||
* `iD.osmEntity` - common base class for `iD.osmNode`, `iD.osmWay`, `iD.osmRelation`
|
||||
|
||||
These three classes inherit from a common base, `iD.osmEntity`.
|
||||
This is the only use of classical inheritance in iD, but it's justified
|
||||
by the common functionality of the types. Generically, we refer to a
|
||||
by the common functionality of the types. Generically, we refer to a
|
||||
node, way or relation as an _entity_.
|
||||
|
||||
Every entity has a unique numeric `id`. By convention, positive numbers are
|
||||
Every entity has a unique numeric `id`. By convention, positive numbers are
|
||||
assigned by the OSM database for saved features, and negative numbers are
|
||||
assigned by the iD editor for local newly-created objects.
|
||||
|
||||
`id` values from the OSM database as treated as opaque strings; no
|
||||
[assumptions](http://lists.openstreetmap.org/pipermail/dev/2013-February/026495.html)
|
||||
[assumptions](https://lists.openstreetmap.org/pipermail/dev/2013-February/026495.html)
|
||||
are made of them other than that they can be compared for identity and do not
|
||||
begin with a minus sign (and thus will not conflict with local `id` values).
|
||||
The three types of entities have separate `id` spaces: a node can have the
|
||||
same numeric `id` as a way or a relation. Instead of segregating ways, nodes,
|
||||
The three types of entities have separate `id` spaces: a node can have the
|
||||
same numeric `id` as a way or a relation. Instead of segregating ways, nodes,
|
||||
and other entities into different datastructures, iD internally uses fully-unique
|
||||
`id` values generated by prefixing each OSM ID with the first letter of the entity
|
||||
type. For example, a way with OSM `id` `123456` is represented as `w123456`
|
||||
@@ -76,17 +76,17 @@ entity: if your code has a reference to one, it is safe to store it and use it
|
||||
later, knowing that it cannot have been changed outside of your control. It
|
||||
also makes it possible to implement the entity graph (described below) as an
|
||||
efficient [persistent data
|
||||
structure](http://en.wikipedia.org/wiki/Persistent_data_structure).
|
||||
structure](https://en.wikipedia.org/wiki/Persistent_data_structure).
|
||||
|
||||
Since iD is an editor, it must allow for new versions of entities. The
|
||||
solution is that all edits produce new copies of anything that changes. At the
|
||||
entity level, this takes the form of methods such as `iD.osmNode#move`, which
|
||||
returns a new node object that has the same `id` and `tags` as the original, but a
|
||||
different `loc` coordinate. More generically, `iD.osmEntity#update` returns
|
||||
different `loc` coordinate. More generically, `iD.osmEntity#update` returns
|
||||
a new entity of the same type and `id` as the original but with specified properties
|
||||
such as `nodes`, `tags`, or `members` replaced.
|
||||
|
||||
|
||||
|
||||
|
||||
Entities are related to one another: ways have many nodes and relations have
|
||||
many members.
|
||||
@@ -121,8 +121,8 @@ 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.
|
||||
|
||||
This approach constitutes one of the main differences between iD's approach
|
||||
to data and that of [JOSM](http://josm.openstreetmap.de/) and
|
||||
[Potlatch 2](http://wiki.openstreetmap.org/wiki/Potlatch_2).
|
||||
to data and that of [JOSM](https://josm.openstreetmap.de/) and
|
||||
[Potlatch 2](https://wiki.openstreetmap.org/wiki/Potlatch_2).
|
||||
Instead of changing a single copy of local data and having to implement
|
||||
an 'undo' for each specific action, actions in iD do not need to be aware
|
||||
of history and the undo system.
|
||||
@@ -143,7 +143,7 @@ difference.created();
|
||||
|
||||
`iD.coreTree` calculates the set of downloaded entities that are visible in the
|
||||
current map view. To calculate this quickly during map
|
||||
interaction, it uses an [R-tree](http://en.wikipedia.org/wiki/R-tree).
|
||||
interaction, it uses an [R-tree](https://en.wikipedia.org/wiki/R-tree).
|
||||
|
||||
```js
|
||||
var graph = iD.coreGraph();
|
||||
@@ -193,7 +193,7 @@ significantly reducing the work necessary to create a robust tool.
|
||||
### Modes Module
|
||||
|
||||
With _modes_, we shift gears from abstract data types and algorithms to the
|
||||
parts of the architecture that implement the user interface for iD. Modes are
|
||||
parts of the architecture that implement the user interface for iD. Modes are
|
||||
manifested in the interface by the three buttons at the top left:
|
||||
|
||||
|
||||
@@ -233,7 +233,7 @@ of duplicating the code to implement this behavior in all these modes, we
|
||||
extract it to `iD.behaviorHover`.
|
||||
|
||||
_Behaviors_ take their inspiration from [d3's
|
||||
behaviors](https://github.com/d3/d3/blob/develop/API.md). Like d3's `zoom`
|
||||
behaviors](https://github.com/d3/d3/blob/main/API.md). Like d3's `zoom`
|
||||
and `drag`, each iD behavior is a function that takes as input a d3 selection
|
||||
(assumed to consist of a single element) and installs the DOM event bindings
|
||||
necessary to implement the behavior. The `Hover` behavior, for example,
|
||||
@@ -279,7 +279,7 @@ the history, and then enter the appropriate mode. For example,
|
||||
|
||||
Finally, we get to the parts of iD that actually draw and manipulate the map
|
||||
entities on screen. The rendering is coordinated by `iD.rendererMap`, which
|
||||
takes care of setting up a [Spherical Mercator](http://bl.ocks.org/mbostock/3757132)
|
||||
takes care of setting up a [Spherical Mercator](https://bl.ocks.org/mbostock/3757132)
|
||||
projection and the [zoom
|
||||
behavior](https://github.com/mbostock/d3/wiki/Zoom-Behavior), and provides
|
||||
accessors for such things as the current zoom level and map center.
|
||||
@@ -297,7 +297,7 @@ entity types of the OSM data model:
|
||||
For each of these geometric types, `iD.svg` has a corresponding module:
|
||||
`iD.svgPoints`, `iD.svgVertices`, `iD.svgLines`, and `iD.svgAreas`. To
|
||||
render entities on screen, `iD.rendererMap` delegates to these modules. Internally,
|
||||
they make heavy use of [d3 joins](http://bost.ocks.org/mike/join/) to
|
||||
they make heavy use of [d3 joins](https://bost.ocks.org/mike/join/) to
|
||||
manipulate the SVG elements that visually represent the map entities. When an
|
||||
entity is rendered for the first time, it is part of the _enter_ selection,
|
||||
and the SVG elements needed to represent it are created. When an entity is
|
||||
@@ -334,15 +334,15 @@ the first time you use iD, the map controls, and the tag/preset editor, for exam
|
||||
|
||||
The implementations for all non-map UI components live in the `iD.ui` module.
|
||||
Many of the submodules under the `ui` module follow a pattern for reusable d3
|
||||
components [originally suggested](http://bost.ocks.org/mike/chart/) by Mike
|
||||
Bostock in the context of charts. The entry point to a UI element is a
|
||||
components [originally suggested](https://bost.ocks.org/mike/chart/) by Mike
|
||||
Bostock in the context of charts. The entry point to a UI element is a
|
||||
constructor function, e.g. `iD.uiViewOnOSM()`. The constructor function may
|
||||
require a set of mandatory arguments; for most UI components exactly one
|
||||
argument is required, a `context`.
|
||||
|
||||
The constructor function returns a draw function which accepts a d3 selection.
|
||||
Drawing is then accomplished with
|
||||
[d3.selection#call](https://github.com/d3/d3-selection/blob/develop/README.md#selection_call):
|
||||
[d3.selection#call](https://github.com/d3/d3-selection/blob/main/README.md#selection_call):
|
||||
|
||||
```js
|
||||
footer = footer.enter()
|
||||
@@ -358,7 +358,7 @@ Some components are reconfigurable, and some provide functionality beyond
|
||||
basic rendering. Both reconfiguration and extended functionality are exposed
|
||||
via module functions:
|
||||
|
||||
```
|
||||
```js
|
||||
var inspector = iD.uiInspector();
|
||||
inspector(container); // render the inspector
|
||||
inspector.tags(); // retrieve the current tags
|
||||
|
||||
Reference in New Issue
Block a user