From 71a77393c009fe303076014d2479d553e2ded025 Mon Sep 17 00:00:00 2001 From: Gabor Hodi Date: Tue, 19 Jul 2022 11:16:04 +0200 Subject: [PATCH] Remove double spaces and fix links in Architecture.md (#8996) --- ARCHITECTURE.md | 58 ++++++++++++++++++++++++------------------------- 1 file changed, 29 insertions(+), 29 deletions(-) diff --git a/ARCHITECTURE.md b/ARCHITECTURE.md index aa2757e81..f647bfe3d 100644 --- a/ARCHITECTURE.md +++ b/ARCHITECTURE.md @@ -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. -![](http://farm9.staticflickr.com/8087/8508309757_ccf5b6f09b_o.png) +![](https://farm9.staticflickr.com/8087/8508309757_ccf5b6f09b_o.png) 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: ![Mode buttons](docs/img/modes.png) @@ -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