Dank alle reacties!
Lastig een conclusie te geven voor dit topic. Ik denk nog steeds dat “cijfers achter komma” niet het enige probleem is. Het gaat, in praktisch gebruik, ook om de parameters van een “curve expansie functie”. Een terugmelding zoals ik eerder voor BGT heb gedaan, kan verworpen worden in dat grijze gebied.
Als afnemers moeten we pragmatisch zijn dus maar “repareren” ipv “NOT ST_IsValid()” uitsluiten. Er is zelfs een stuk wetenschap hiervoor, door, en met literatuurverwijzingen naar, niet de minste auteurs: Tidying feature geometries with sf …
‘Pragmatisch repareren’ is wat we momenteel in NLExtract doen, als onderdeel BGT Lean SQL script.
In de laatste commit wordt gezorgd dat alle vlak-geometrie na expansie valide is, en er geen geometrie, of deel daarvan, uit origineel (BGT met Curves), verloren gaat. Ik heb dit nu best-effort gedaan. Wie weet willen ontwikkelaars onder ons nog eens licht daarop schijnen. Bij voorkeur reacties geven op betreffend NLExtract issue en/of PRs.