"Referenced-Geometry-Problem"
Linear-referenced features have some special characteristics in
contrast to "normal" vector-layers, which can lead to unexpected
effects.
The most important and the clue of linear
referencing: The geometries ar calculated from different sources, a
geometry-less data-layer and a referenced linestring-layer.
Any change of the linestring-geometry will propagate to the linear
referenced geometries, which can lead to unexpected side-effects:
Imagine a river with some linear-referenced technical buildings.
There is a renaturation-project on that river, the watercourse
gets extended, more place for meandering, very useful and welcome.
Afterwards the river-shape was adjusted thoroughly, but some of
the linear referenced buildings have been inexplicably relocated
in QGis.
Workaround for that problem:
- restore the previous positions by manual adjusting of the
stationing
- let this be done by some magic database-trigger (provided
data-layer and reference-layer stored in the same database)
- Use LinestringM with calibrated measurements (not supported
by this plugin, see PostGis Linear_Referencing)
- avoid river-renaturation ;-)
"Join-Problem"
Another problem using two data-sources is the join between two
layers:
Linear-referenced-features suddenly appear in a completely different place, if
the reference-id changes, or they vanish, if linestring-features
are deleted/filtered or if the reference layer was removed by mistake.
Digitize-Direction:
The direction of digitization must be considered in two places:
- Reference-Layer:
The stationing always refers to
the starting point of the referenced line, therfore
all lines in the reference-layer must be digitized in the
same direction.
Note: in the above examples, a
river-network, the usual direction is against flow
direction, from mouth to source
- LoL-Stationing:
The internal used SpatiaLite-function "ST_Line_Substring"
requires two numerical values: ST_Line_Substring( line Curve , start_fraction Double precision , end_fraction Double precision )
Return a Linestring being a substring of the input one starting and ending at the given fractions of total 2d length.
Second and third arguments are expected to be in the range between 0.0 and 1.0.
NULL is returned for invalid arguments
Not mentioned in the
documentations: "start_fraction" < "end_fraction",
but:
This plugin does not check this and allows the
storage of "reverse"-stationed segements, because the complex
expression in the virtual-show-layer-query uses
min(from,to)/max(from,to) to select the right order.
"fraction vs. stationing":
The internal used
SpatiaLite-functions
"ST_Line_Interpolate_Point" and "ST_Line_Substring" require values
in range 0..1:
ST_Line_Interpolate_Point( line Curve , fraction Double precision )
return a point interpolated along a line.
Second argument (between 0.0 and 1.0) representing fraction of total length of linestring the point has to be located.
NULL is returned for invalid arguments
ST_Line_Substring( line Curve , start_fraction Double precision , end_fraction Double precision )
Return a Linestring being a substring of the input one starting and ending at the given fractions of total 2d length.
Second and third arguments are expected to be in the range between 0.0 and 1.0.
NULL is returned for invalid arguments
Although, the plugin does not store fractions, but the real
measured distances, because these ar better understandable for
humans. Also all referenced features on a reference-line would
relocate, if the line-length should change. The virtual-layer-query
calculates the required fractions using
measured_distance/length_of_referenced_line.
Projections and measurements:
The projection for the displayed values of the cursor- and
snap-coordinates is the current selected project-CRS.
The
measurements are calculated, displayed and stored in the projection of
reference-layer. Geographic CRS (lat/lon, f.e. WGS 84/EPSG 4326) is
possible (...but presumably rarely used for measuring, imagine a
segment with length 2°32'12" and offset -5"...)
Snapping
QGis built-in snapping-mechanism is an indispensable help for
stationing-measurement. Therefore, the following snap-settings are
automatically applied to the configured reference-layer:
- "Advanced configuration"
- "snap to segment and line-endpoints"
- "10px tolerance"
Note: These snap-settings are
maintained/restored/reapplied on configuration-change or
plugin-unload.
Multi-Linestring-Support
Only single-type-features are supported by this plugin, because the
measurement-to-geometry-calculation is indefinite on
multi-linestring-geometries.
Actually, the plugin accepts
linestring-layers in shape-format, which allways is
multi-type (does not distinguish between single- and
multi-part-shapes), but only supports their single-part shapes.
LinestringM-Support
Conventional linestring-layer store their vertices with x- and
y-coordinates. Linestring
M-layer store an additional
m-value, which contains the measured distance to the start-point of
the linestring. Linestring
Z-layer store an additional
z-value, which is the geodesic height of this vertex. Linestring
MZ-layer
store both additional vertex-coordinates.
The plugin accepts
these types, but the m-values are ignored for the
geometry-by-measurement-calculation, because the internally used
SpatiaLite-Functions (ST_Line_Substring, ST_Line_Interpolate_Point)
do not support m-values. See
SpatiaLite "SQL functions supporting Linear
Referencing".
Note:
PostGis offers possibilities to calculate
points/segments on linestring-m-geometries with calibrated
m-values (compressed/stretched/not starting at 0)
See
PostGis Linear_Referencing.