Version 0.6.3:

**Highlights**

* **Performance**: merging an editing session is much faster on long
roads: only the managed objects
which may be impacted by the modifications are updated, for example
0.4 s instead of 13 s for a new crossroad
* **Fixes**: more precise cumulative distances (to the centimeter),
and the managed lines are no longer
shortened by 1 cm at each merge

**Upgrade notes**

* Run the algorithm `Upgrade database structure` to upgrade the
database (migration 42).
It calculates again the references of all the edges, which can take a
few minutes on a large road graph
* Optionally, run the algorithm `Update managed objects from the road
graph` on each managed table
to correct their cumulative distances


* **SQL**: faster merge of the editing sessions: only the managed
objects which may be impacted
by the modifications are updated (near the modified edges, downstream
of them if the road geometry has changed,
or near a modified marker), instead of all the objects of the modified
roads.
For example on a road of 118 km with 1,250 objects: 0.4 s instead of
13 s for a new crossroad,
and 5 s instead of 13 s for a realigned edge (migration
`upgrade_to_42.sql`)


* **SQL**: the cumulative distances greater than 10 km were rounded to
10 cm (1 m above 100 km),
for the edges and the managed objects. The migration calculates again
the references of all the edges
(about 17 s for the 7,809 edges of the demo data). The managed objects
are corrected when they are updated,
or with the algorithm `Update managed objects from the road graph`
* **SQL**: the managed lines with the update policy `geometry` were
shortened by 1 cm at each merge
* **SQL**: a managed object whose geometry cannot be calculated from
its references no longer cancels the merge:
it is not updated, and a warning is displayed
* **SQL**: the list of the last updated managed objects
(`last_updated_objects_ids`) is emptied
when a merge does not update any object: it still contained the
objects of the previous merge
* **Tools panel**: the references displayed on click or on hover now
show the marker `0`, and the abscissa,
offset or cumulative distance `0`, instead of an empty field

Version 0.6.2:

**Highlights**

* **Performance**: editing long roads is much faster, for example
adding an edge crossing a road
of 135 edges takes about 0.6 s instead of 8 to 13 s
* **Docs**: new explanation of the impacts of the modifications on the
references, with a diagram

**Upgrade notes**

* Run the algorithm `Upgrade database structure` to upgrade the
database (migration 41)


* **SQL**: faster editing of long roads: the references of a road are
no longer calculated several times
for one modification, and splitting an edge only calculates the
references of its two parts.
For example on a road of 135 edges, adding a crossing edge takes about
0.6 s instead of 8 to 13 s
(migration `upgrade_to_41.sql`)
* **Docs**: in the page `Road graph editing`, explain the impacts of
the modifications of the edges and markers
on the references, upstream and downstream, with a diagram
* **Docs**: in the page `Road graph editing`, warn against editing
directly the production schema `road_graph`,
and explain how to correct the whole road graph after a first import
with an editing session covering all the data

Version 0.6.1:

**Highlights**

* **GPS tracks**: new Processing algorithm to get the road sections
followed by the lines of a layer,
for example GPS tracks, with their start and end references
* **Performance**: modifying a field of the edges is much faster

**Upgrade notes**

* Run the algorithm `Upgrade database structure` to upgrade the
database (migration 40)


* **Processing**: new algorithm `Get road sections from a line (GPS
track)` in the group `Linear referencing`,
which snaps the lines of a layer, for example GPS tracks, on the road
graph,
and creates a layer with the sections of the roads they follow, with
their start and end references


* **SQL**: performance of the edges updates: the references of an
updated edge are not calculated anymore
by the trigger `before_edge_insert_or_update` when they are calculated
again just after
for the whole road, or when only another field of the edge has been
modified.
For example, modifying a field of all the edges of a road is a few
hundred times faster (migration `upgrade_to_40.sql`)
* **SQL**: new function `road_graph.get_or_create_edge_node`, used by
the trigger `before_edge_insert_or_update`
to get or create the start and end nodes of an edge, instead of
duplicated code


* **SQL**: the search of the next edge of an edge could fail if two
edges of the same road started at the same node

None