Closed basvanbemmel closed 5 months ago
Heeft op zich niet heel prio, maar wel handig als toch duidelijk wordt waarom dit zo is
Goeie observatie, het gaat hier om een multilinestring bestand, dat door de GeoDMS geinterpreteerd wordt als (niet multi) linestring, aka arc, dus een sequentie van 2d punten, wat vervolgens een lijn van het eindpunt van de eerste linestring (door heel de flevopolder) naar het beginpunt van de 2e linestring laat tekenen:
Het interpreteren van een multilinestring gdal type als sequence of points (aka arc) hebben we onlangs experimenteel door laten gaan en werkt nog niet goed voor linestrings met werkelijke multilinestring structuren zoals het geval wat jij terecht hebt geobserveerd. Voorheen interpreteerden we multilinestrings als WKT string geometrie.
Daarmee kan het gebruik van multilinestring bestanden op dit moment nog leiden tot ongewenste geometrie resultaten. We hebben naar aanleiding van dit issue maar ook naar aanleiding van discussies over multilinestrings eerder dit jaar een implementatie route uitgedacht waarmee geodms multilinestrings volledig zal ondersteunen:
In lijn met (multi)polygons willen we multilinestrings encoderen als een sequentie van punten. Een van de redenen om dit zo te doen is performance, maar daarnaast ook het gebruik van een simpel datamodel: sequentie van punten ten opzichte van een hiërarchische structuur van afhankelijke geometrieën.
Technisch zal een multilinestring als een serie linestrings geëncodeerd worden als 1 sequentie van punten met null als separator tussen het einde van een linestring en het begin van een volgende linestring.
De implementatie zal beslaan:
En daarnaast het implementeren en/decodering multilinestrings in:
Note that dyna_point and dyna_segment can be made to work on the current results of arc2segm by filtering out segments with !IsDefined(point) || !IsDefined(nextpoint).
Tot we hier aan toe zijn gekomen geven we vanaf nu een warning uit wanneer gebruikers toch een multilinestring bestand willen inlezen:
if (layer_geometry_type == OGRwkbGeometryType::wkbMultiLineString)
reportF(SeverityTypeID::ST_Warning, "gdal.vect", "storage [[%s]] has geometry type wkbMultiLineString, which is reinterpreted to plain linestring, possibly resulting in incorrect geometries.", storageHolder->GetFullName());
New implementation (v14.17.0):
@basvanbemmel na @MaartenHilferink zijn laatste commit leest je bestand goed in:
Daarmee hebben we een grote stap gezet om in GeoDMS multilinestrings volledig te ondersteunen. Zie lijst in dit comment welke delen van GeoDMS nog geen multilinestrings ondersteunen.
Zie geselecteerde kruizing:
bg_buffer creates an extra line part, see:
Code to reproduce:
unit<uint32> test_multi_linestring
: StorageName="C:/Users/Cicada/Downloads/vw_nl_netlijnen_2023_v4_5_december.gpkg"
, StorageType="gdal.vect"
, StorageReadOnly="True"
{
attribute<dpoint> geometry (arc);
attribute<dpoint> arc_buffer (poly) := bg_buffer_linestring(geometry, 10.0, 16b);
}
Extra verbindingslijnstuk komt niet meer voor na laatste commit:
Dump of manually labelled encoded (undefined separated) multi linestring in GeoDMS:
B {509191.388, 165254.648
{null, null
B {509191.388, 165254.648
{509241.121, 165299.823
{509354.452, 165405.457
A {509429.009, 165419.062
{null, null
B {509191.388, 165254.648
{509269.796, 165269.13
{509383.148, 165374.752
A {509429.009, 165419.062
{null, null}
A {509429.009, 165419.062}
{509818.334, 165320.043}
}
See implementation of simplify multi linestring:
Implemented as simplification per linestring.
Extra warning for dyna_point:
Er worden extra lijnen getekend in dit gpkg bestand o.a. tussen Muiden en Lelystad. Onduidelijk waarom het is niet het geval in ArcMAP en QGIS
vw_nl_netlijnen_2023_v4_5_december.zip
GeoDMS 14.14.0
QGIS 3.34.2