Remove double spaces and fix links in Architecture.md (openstreetmap#…

…8996)

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