In de 3dShapes-data in (voornamelijk) bossen hebben de makers voor ieder pad een soort “gat” in het bos gemaakt. Zie deze link.
De conventie is altijd geweest om landuse en wegen te scheiden in OSM, en dus het bos gewoon door te tekenen (zoals het nu hier gedaan is).
Wat moeten we nu doen? Zo laten staan, met de hand de “gaten” eruit halen of kan dat op de een of andere manier automatisch?
Overigens geldt dit ook voor andere 3dShapes-elementen, zoals de elementen die in OSM met landuse=farm zijn getagd, waarbij ieder perceel als een aparte way wordt aangegeven. Ik zou er zelf voorstander van zijn om deze allemaal samen te voegen.
En ik om dat pertinent niet te doen. Je stelt nu gewoon voor om perfect goede informatie om zeep te helpen, omdat jij denkt dat er een conventie is om massieve vlakken te tekenen. Die conventie is er niet. Het is meer een macht der gewoonte, omdat het minder werk is voor een mapper, zeker in het geval er geen hogeresolutieluchtfoto’s beschikbaar zijn. In dit geval staat de data er al, dus is dat argument ook niet geldig.
Overigens ken ik iemand anders die ook al wat landbouwpercelen aan elkaar heeft geplakt, nadat deze persoon de perceelgrenzen heeft voorzien van een sloot. Het is puur zonde om dat te doen. Als een perceel van bestemming verandert, bv akker naar weide, en je ziet dat toevallig als je langskomt, kun je makkelijk een tag omgooien. Als je alles gaat lopen mergen, kan dat helemaal niet meer.
Ik ken echter ook iemand die handmatig landuse gemapt heeft op deze manier, waarbij de paden mooi vrij zijn gehouden. Die zal ook niet blij zijn als een ander dat behulpzaam aan elkaar gaat plakken. Zelf heb ik dat ook op plekken gedaan (ook buiten NL).
Nog een voordeel van die ‘gaten’: je ziet perfect waar er nog paden missen. Dat is heel leuke informatie voor velen om er eens op uit te gaan om die te gaan mappen. Is dat pad er nog, is die opengesteld of heeft die restricties, wat is de oppervlakte van pad, etc etc.
IK ben zo’n laatste ‘lijp’ die ieder paadje in het bos nu wel lopen.
Overigens merkte ik de eerste keer dat deze open stukken niet op mijn Oregon 450 zichtbaar zijn met de kaart van Lambertus.
Klopt dat of was ik weer te snel met de downloaden en is dat nu wel het geval?
Dat is niet helemaal waar. Kijk eens naar de 3dShapes-data voor het Limbrichterbos (zie deze link). De paden zoals die er staan, kloppen bijna exact (ik heb ze zelf afgelopen winter ingetekend). Vergelijk dit met de 3dShapes-data en het blijkt dat 3dShapes ook niet perfect nauwkeurig is. Dit zie ik ook op andere plaatsen. Wat moet ik nu doen als de 3dShapes-dataset geïmporteerd is? Moet ik zelf de bos-polygon aanpassen aan de ware ligging van de paden?
Bovendien, als er een beginnende mapper komt die een nieuw pad in wil tekenen, moet hij dan alle landuse ook gaan splitsen? En wat als er een nieuw stukje bos bij wordt geplant?
Ik zou het natuurlijk mooi vinden als bij ieder pad inderdaad de breedte (enz.) op deze manier kan worden aangegeven - de kaart wordt er immers preciezer door. Ik denk echter dat dit voor een kaart gebaseerd op vrijwilligers moeilijk te onderhouden is. Het feit dat de ervaren mappers precies weten hoe je zo’n “gat in het bos” kunt maken, betekent niet dat iemand die OpenStreetMap net tegenkomt dit ook weet.
Dat misschien niet, maar mappers moeten wel weten dat ze die bossen moeten aanpassen. Bovendien schrikt het denk ik af. Toen ik lang geleden voor het eerst een edit deed (in Potlatch, dat toen nog wel wat ongebruiksvriendelijker was), toen vond ik het al best moeilijk om mijn eerste bospad toe te voegen, dus om alleen één simpele way toe te voegen.
Als de meerderheid overigens voor behoud van de 3dShapes is, dan vind ik dat natuurlijk ook niet erg; ik wil alleen graag dat er overeenstemming is over wat we doen met de 3dShapes-data.
Dat mag je uiteraard helemaal zelf weten voor data die je zelf invoert. In je voorbeeld van het Limbrichterbos zou je de ‘gaten’ voor de paden die er niet meer zijn kunnen dichten. (Is er echt niks meer te vinden van een pad?) En op de paden die jij hebt afgelegd die niet in 3dshapes zijn te vinden als gat, hoef je echt niet een gat te creeren.
Ik argumenteer eigenlijk vooral dat je zulke dingen niet lichtzinnig moet gaan doen op plekken waar je geen goed beeld van hebt, door het ontbreken van lokale bekendheid. Je eerste post zou aan mensen het idee kunnen geven dat mergen altijd prima is, en iemand op een regenachtige zondagmiddag zou dan kunnen besluiten om heel NL door te gaan om te mergen wat er te mergen valt. Daarom ging ik er ook met gestrekt been in, om dat eventuele beeld te ontkrachten.
Kortweg: als je, zoals Peter-almere-nl, een beter beeld hebt van de situatie ter plekke, dat niet overeenkomt met wat er in OSM staat: pas gerust aan, op jouw manier. De ene zal een groot vlak eronder tekenen, en een ander kan besluiten om de paden vrij te houden. Echter, zonder de breedte van de paden te meten, of zonder steun van geschikte luchtfoto’s, is dat ook niet zomaar te doen.
Nee; ten minste, ik ben er niet gisteren opnieuw geweest, maar ik geloof dat ik vorige winter wel alles had gehad dat enigszins op een pad leek. Daarom snap ik ook niet dat hij er op 3dShapes wel ligt. Overigens liggen er rondom het bos wel meerdere paden die ik niet heb gehad en die wel in 3dShapes te zien zijn. Sommige daarvan liggen echter op privégrond.
Daar ben ik het mee eens; “mergen om het mergen” is inderdaad niet nuttig en ik kan me een leukere vrijetijdsbesteding voorstellen
Overigens, ik neem aan dat je bestaande residential-gebieden wel mag mergen met de 3dShapes? (Zie hier, waar een residential-area gedeeltelijk overlapt met 3dShapes en gedeeltelijk stukken “open” laat.)
Het kan zijn dat de paden er enige jaren geleden wel waren en nu niet meer. De 3dShapes-data is ook niet van gisteren.
Dit is natuurlijk het verschil tussen macro en micro. De wereld draait door en op lokale schaal zullen er dus her en der nieuwe ontwikkelingen zijn die de data die we nu hebben verouderen. Op landelijke schaal zal de correctheidsfactor, lijkt mij, wel in de hoge 90% zitten.
Gelijktrekken van de oude/grove residential op 3dShapes lijkt me in jouw voorbeeld prima te doen, zeker op stukken waar het maar meters scheelt.
Edit: tijdens de import van 3dShapes wordt de nieuwe data neergezet. Bestaande data wordt i.h.a. niet door ons rechtgetrokken op de nieuwe data.
Wijs die persoon eens op de manier waarop ik dat rond Lexmond heb gedaan / aan het doen ben. Met multipolygon relaties heb je op de plaats van de sloot niet drie ways overelkaar, maar nog wel voor ieder perceel apart iets in de database.
