"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
both sources 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.
The river-shape was re-digitized thoroughly in QGis, but afterwards some of the linear referenced buildings had 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 the referenced linestring-features are deleted/filtered or if the Reference-Layer is inaccessible, or even removed from project 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
The above function requires "Start_fraction" less than "end_fraction", else NULL is returned for invalid arguments. Nevertheless the plugin allows the storage of "reverse"-stationed measurments, because of a complex expression in the virtual-Show-Layer-query. But this can lead to problems, if these values are used in less complex virtual-layer-query or externally, f.e. inside a PostGIS-View.
"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
Nevertheless the plugin does not store fractions, but real measured distances, because these ar better understandable for humans. Additionally, all referenced features on a reference-line would relocate, if the line-length should change. (Note: The virtual-layer-query created by this plugin internally calculates the required fractions using measurement/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) are possible.
- Show- and Reference-Layer have the same projection.
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.