Losse delen bos/gras/etc bij 3dshapes import

Ik zag dat bij de 3dshapes import heel veel losse delen worden geïmporteerd. Dat er bijvoorbeeld twee vlakken gras zijn die met veel nodes aan elkaar grenzen.
Vaak zijn dat nuttige grenzen (er loopt bijvoorbeeld op die grens een pad of een sloot o.i.d.).

Vraag: als er eenmaal dat pad ingetekend is, is het dan handig om de losse delen aan elkaar te zetten? De rand is immers verkend en er ligt dan al een pad/sloot of iets anders. Dus mij lijkt het niet erg nuttig dat gebied in tweeën te splitsen (met nog veel nodes ook).
Voordelen:

  • Makkelijker te editen (het is vaak moeilijk om het pad, het ene veld/bos of het andere veld/bos te selecteren (ten minste, in JOSM is dat vrij lastig).
  • Minder data (hele rijen van nodes hoeven niet meer in de ways te staan)
  • De kaart ziet er beter uit omdat bij losse stukken bos het patroon van bomen verloren gaat.

PS. Die import ziet er goed uit, verder.

En nog iets: wegen die tussen velden doorlopen zijn goed te zien op 3dshapes. Maar de wegen lopen vaak niet gelijk met de velden. Is het dan beter om de wegen gelijk te trekken met 3dshapes? (dus midden door de strook ‘leeg gebied’)

Stukje IRC log:
[17:31] ayke, v.w.b. bosvlakken: je weet dat dit ook heide kan zijn, en we denken ook dat het bos in meerdere vlakken is opgedeeld, omdat het ene stuk loofbos is en het andere stuk naaldbos, of gemengd.
[17:31] Dat geldt uiteraard ook voor stukken waar een pad tussenloopt.
[17:32] We zijn een beetje huiverig om alles rücksichtlos samen te voegen, omdat het achteraf lastiger is om de originele data weer terug te halen.
[17:32] + dat je simpelweg vergeet dat het oorspronkelijke losse vlakken waren
[17:33] fsteggink: dus voorlopig gescheiden houden?
[17:33] v.w.b. het bospatroontje: dat is puur een renderingkwestie. De database is het hoofdproduct van OSM, en niet de kaart. Data aanpassen puur omdat dat mooier uitkomt op de kaart, moet je niet doen.
[17:33] yep
[17:34] totdat we misschien andere inzichten hebben
[17:34] fsteggink: dan zal ik ze gescheiden houden.
[17:34] voorbeeldje waar op het eerste gezicht “onnodige” data bleef staan is bijv. het importance_level van de AND wegen. Deze data is al in 2007 geïmporteerd, en pas een maand geleden hebben we besloten om toch wegen te herclassificeren, omdat er teveel wegen secondary en tertiary zijn.
[17:35] vandaar ook de afwisseling van classificatie van wegdelen; want wegen die door een gebruiker zijn aangeraakt (versie > 1) zijn niet aangepast
[17:35] ok
[17:36] fsteggink: heb me ondertussen verveeld met de bus_stops

[17:36] nu vraag 2: gelijk trekken. Ook daar zijn we niet helemaal over uit. 3dShapes geeft niet de situatie juist weer. Laatst heb ik dit gecheckt n.a.v. een opmerking van pjdebruin.
[17:37] Hier moeten we snel eens over bakkeleien :slight_smile: Misschien wel gelijktrekken als de afwijking < 10m is.
[17:38] ook geeft KeepRight hierom veel fouten.
[17:38] Dit komt gedeeltelijk ook omdat de AND data afwijkingen heeft
[17:39] of we zetten de wegen tussen AND en 3dshapes in…
[17:39] ik zal er voorlopig van af blijven totdat er een uitkomst is
[17:39] dat is lastig te registreren. Als gebruiker #2 langskomt, weet hij niet wat de status is, tenzij hij voor elk stukje de history induikt…
[17:40] vwb de alignment van wegen ben ik van mening dat gelijktrekken gerust kan. Veel tracks van wandel- en fietspaden matchen beter met 3dshapes dan AND data
[17:40] en in mijn optiek wel zo goed dat dit geen toeval is.
[17:41] als ze niet hard verbouwd hebben etc dan is 3dShapes iha stuk beter dan AND
[17:41] natuurlijk zijn er ook zat fiets- en voetpaden die niet netjes liggen. Soms “op gevoel” ingetekend, of met een brakke GPS ontvanger gelogd (bijv. in veel telefoons)
[17:45] of ik met een tomtom
[17:45] uiteindelijk ook niet erg precies. Had er veel meer van verwacht.
[17:46] In de winter zou het beter moeten gaan, omdat je dan geen last van het bladerdek hebt
[17:46] iig voor mijn test in vergelijking met pjdebruin: hij heeft een telefoon gebruikt, en ik een GPS ontvanger, die ik ook voor me heb gehouden.
[17:47] mijn tracks begonnen wel in de buurt van 3dShapes te komen, maar er zijn ook stukken waar 3dShapes niet met de werkelijkheid matcht