Version 0.6.4:

**Highlights**

* **Managed objects**: the split and merge of lines in Lizmap now give
the right references, even for lines
drawn in the opposite direction of the road, and the lines connected
to an edited line stay connected
* **Security**: the `SECURITY DEFINER` functions set their
`search_path`, and the read-only functions
work even if the `search_path` of the caller does not contain `public`



* **SQL**: new trigger function
`update_managed_object_linked_geometries`: when the geometry of a
managed line
is updated, the lines of the same table and road which were connected
to its start or end are shortened
or extended to stay connected. Their references, and cumulative
distances, follow the new references
of the line, and their geometry is calculated again from them. The
function `add_managed_objects_triggers`
creates this trigger `trg_update_managed_object_linked_geometries` on
the line tables,
and now returns one line per trigger with its name (migration
`upgrade_to_43.sql`)


* **Lizmap**: in the form `Create the geometry from references` of the
editing panel, the fields `Offset` and `Side`
are hidden by default: click on `Offset` to display them
* **Lizmap**: the button `Merge two lines` of the popup no longer
requires the right to delete features,
but the rights to create features and modify the geometry. The editing
rights needed to display the buttons
`Split a line at a point` and `Merge two lines` can be changed with
the new constants
`ROAD_SPLIT_NEEDED_RIGHTS` and `ROAD_MERGE_NEEDED_RIGHTS` of the
script `road_network.js`
* **SQL**: merge of two managed object lines (Lizmap action
`merge_selected_lines`): the merged feature
is now the feature chosen first, with its field values, instead of the
feature with the lowest start references.
Its references, and its cumulative distances if the table has these
fields, are calculated from the merged line
in the direction of the road, even if the table has no trigger
calculating them (migration `upgrade_to_43.sql`)
* **SQL**: the functions called from outside the plugin which only
read data (`get_reference_from_point`,
`get_road_point_from_reference`, `get_road_substring_from_references`,
`get_managed_object_geometry_from_references`,
`get_snapped_line_from_track`, `get_road_sections_from_snapped_line`,
`get_spatial_road`)
and the trigger function `calculate_managed_object_references` now set
their `search_path` to `public`:
they work even if the `search_path` of the caller does not contain the
schema `public`, where PostGIS is installed
(migration `upgrade_to_43.sql`)
* **SQL**: security: the `SECURITY DEFINER` functions
`copy_data_to_editing_session`, `drop_editing_session`
and `toggle_foreign_key_constraints` now set their `search_path` to
`public, pg_temp`,
and `merge_editing_session_data` prefixes the objects of the
production schema (migration `upgrade_to_43.sql`)


* **SQL**: split of a managed object line by a point (Lizmap action
`split_line_by_point`): for a line drawn
in the opposite direction of the road, each part could get the
references of the other part,
or start after its end. The two parts now follow the direction of the
road, like the geometries
calculated from the references, and their four references, and their
cumulative distances
if the table has these fields, are calculated in the direction of the
road (migration `upgrade_to_43.sql`)
* **SQL**: the trigger calculating the references of the managed
objects (`trg_calculate_managed_object_references`)
gave a start reference greater than the end reference for a line drawn
in the opposite direction of the road.
They are now inverted, like in the algorithm `Update managed objects
from the road graph`
* **Lizmap**: in the form `Create the geometry from references` of the
editing panel, the start and end references
of a line drawn in the opposite direction of the road were displayed
in the drawing order.
They are now ordered in the direction of the road, like the geometry
created from them

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

None