We hadden laatst een korte discussie over 3dShapes.
Ik kwam toevallig een “mooi” voorbeeld tegen van 3dShapes:
Je kunt goed zien dat zo’n beetje alles, behalve de BAG-panden, verkeerd ligt. De kwaliteit van deze data is matig tot slecht.
De vraag was vorige week of het redelijk is om alles goed te gaan leggen, op de hele camping.
Mijn plan is om
Hoe denken jullie daarover?
Wat mij betreft geen bezwaar; 3dshapes is sowieso stokoud. Of destijds de kwaliteit goed was is nu slecht te checken natuurlijk.
Landuse, zeker agrarisch, is voor een zeer groot deel niet actueel.
Maar de huidige hires luchtfoto biedt voldoende aanknopingspunten om nauwkeurig te mappen. BGT kan je ook redelijk goed gebruiken om wegen uit te lijnen; pas echter op met paden in bossen: hier zit de BGT er soms tientallen meters naast; hillshades biedt dan meer houvast.
Eventueel de 3dshapes landuses samenvoegen ? Heb je direct de witruimtes weg en nog een beetje een versie historie overeind…
PS. Ik ben zeer actief in deze regio dus kan ook een en ander oppakken of vragen beantwoorden mochten die er zijn.
Ik zie graag 3dShapes vervangen worden door data die we zelf maken. Kogacarlo’s voorstel hier vind ik goed.
Een probleem dat ik zelf tegen ben gekomen is dat de landuse=orchard van 3dShapes vaker onnauwkeurig is dan overige geïmporteerde objecten. Veelal gaat het bij de landuse=orchard om een ander landgebruik of om grote privétuinen met veel bomen. Is misschien eens handig om met Overpass op te jagen.
Er waren in de 3dShapes maar een beperkt aantal smaken. Dus boomkwekerijen staan ook als Orchard en zullen dus omgetagd kunnen worden. gras was altijd landuse=grass. We weten nu ook wel beter.
Dat geldt ook voor stukken bos die heide zijn. En al die bossen in de steden zijn vaak ook geen bossen in de zin van. Werk genoeg aan de winkel.
Toch waren we wat in onze nopjes met de kaart na die import. Daarvoor was alles zo’n beetje wit.
Ik ben in het voorbeeld van 3dShapes ook voorstander van verwijderen.
Zorg dan wel dat je niet te grote gebieden verwijderd, waardoor multi poligoon (relaties) half verwijderd dreigen te worden.
Draag ook zorg voor lege relaties die ook verwijderd dienen te worden.
Het bewaren van de historie heeft veelal geen toegevoegde waarde. Dit omdat het een import betrof in de begintijd van OSM.
Mits een enthousiaste mapper het gebied al onder handen heeft gehad. Wellicht is het dan netjes om hem/haar even in te lichten.
Dat is heel begrijpelijk. Nederland ziet er mooi uit op de kaart. Je moet alleen niet te ver in willen zoomen op plekken waar de 3dShapes vlakken nog niet bijgeschaafd zijn. Gelukkig werken we daaraan 
Veel boomkwekerijen zijn ondertussen in mijn omgeving gerooid.
De meeste boomgaarden uit de 3dshapes import in Noord Limburg waren in werkelijkheid boomkwekerijen.
Goed, punt 2. de wegen goed leggen, hier praten we dan ook over de lijn way visualisatie.
Slecht, punt 1. en 3.
Verlies van detail. Dat gaat in tegen de OSM methodiek.
Dit verhaal komt overeen met dit topic Wat ik categoriseer als “DWG waardig”.
Het argument van witvlakte moet op een andere manier worden opgelost, door intekening, wat het is, een weg, geen bomen en rendering, waar ook AnkEric mee aan de gang ging, topic.
Topics met dezelfde problematiek.
Dat het niet goed op de plaats ligt, dat was in die tijd zo, hoe konden wij toen uitlijnen. ten opzichte van, hoe kon men het landschap vertalen naar 3Dshapes (object vision)
Met JOSM CTRL-W, kan je behoorlijk snel zaken goed leggen, doe je dit met een pentablet dan gaat het nog sneller.
met alt=x snel polygonen knippen.
Helaas hebben we Openstreetmap NL Kiaatix deels verloren, zijn cut out polygon tool zouden ook landuse=highway en area:highway kunnen bevatten, waarbij je heel snel een groter grover vlak over kon tekenen en dan met die andere polygonen (uitknippen) dat vlak goed kon aansluiten. CTRL-W goed leggen.
Wil je goed intekenen in JOSM dan doe je dat al gauw op zoomniveau 21-23, ga je op 18 -19 intekenen, en je zoomt later in dan ligt het al gauw niet zo goed.
Tegen het bezwaar tegen het punt 1 en 3 wil ik toch wel enige nuance inbrengen:
Een fout of verouderd 3dshapes-detail is geen detail (meer); OSM is niet om (historische?) kavelgrenzen te mappen. Daar hebben we het kadaster voor, die houdt dat ook bij.
En een smalle highway-feature as path, cycleway, service of unclassified mag wat mij betreft gerust over de landuse heen getrokken worden. Die discussie is geweest, daar was geen concensus maar persoonlijke voorkeuren.
Dan heb je niet begrepen hoe 3Dshapes ontstaan is, je haalt er kadastrale kavelgrenzen bij, wat niet de basis is van de dataset.
Nu gescheiden percelen over de weg samenvoegen tot 1 perceel is verlies van detail.
Er groeien geen bomen op de weg net zo min gras en farmland over de weg heen verbinden is net zo slecht, er is altijd nog een berm, hoe klein dan ook.
Dat iets je persoonlijke wens is, ik ga uit van hoe OSM zich heeft ontwikkeld. Welke voorwaarden er gesteld worden aan het bijdragen en verbeteren van de data.
Wat nu gescheiden getekend is mag je dan niet samenvoegen, tenzij het in de werkelijkheid zo is en dat is bij een weg nooit het geval. Je het recht nemen om samen te voegen gaat in tegen de OSM werkwijze.
En verlies van detail is een belangrijk punt.
Deze wens is ingegeven door een kaart, het witvlak, het over de weg heen tekenen is duidelijk een geval van tekenen voor de render. Wat fout is. De werkelijkheid ziet er zo niet uit.
Wat in houd dat het wegvlak/berm ingetekend moet worden om renders de mogelijkheid te geven het te renderen, dit is wat je ziet.
Dat zal onze OSM survey ogen ook zien. Waarbij we nu BGT en HR luchtfoto kunnen gebruiken om het zo goed mogelijk neerte leggen. Anders kunnen wij het nooit zo goed neer leggen, zelfs niet met onze eigen GPS en hun afwijkingen.
Het maakt niet uit of het van een import komt of door een mapper ingetekend.
Ook zijn delen van die import reeds deels her en der aangepast.
Door met de vraagsteller in te stemmen gaan we de verkeerde kant op.
Dat vind jij. Maar als je de wegberm niet intekent, zoals in 3dshapes en daarmee de ruimte tussen de highway en de landuse, afhankelijk van de zoomfactor, een niet gedefinieerd vacuüm wordt, ben je verder van huis. Bij het niet definiëren van deze ruimte tussen, bijvoorbeeld, agricultural of forest en een highway ben je kwalitatief slechter dan het intekenen van de highway over de landuse, als die links en rechts van de highway gelijk is. Dit is beter dan het niet intekenen van het wegvlak / berm. Ik vind persoonlijk jouw frase “gaan we de verkeerde kant op” nogal pertinent, net als “dan heb je niet begrepen”.
Ik ben bij tijd en wijle bezig met landgebruik in het buitengebied en bij bossen. Ik ben er een voorstander van om zo veel mogelijk recht te leggen en/of voort te borduren op ouder werk.
Ik denk dat de link handhaven met de oude import aardig kan zijn voor de ‘geschiedschrijving’. Je kunt kiezen om een aantal punten recht te leggen, vervolgens de weg te splitsen en van daaruit verder te werken.
Ik ben wel voor het handhaven van uitsparingen in grondgebruik bij wegen e.d. Dat is ook iets wat bij andere vormen van grondgebruik gebeurt (al zijn daar natuurlijk meerdere ‘scholen’ in).
Als ik ga ‘hakken’ in oude 3d-shapespolygonen, dan betekent dat wel minstens twee uur werk om onze plattegrond niet achter te laten met witte vlekken. Dat je iets terugbrengt zonder die uitsparingen is te begrijpen, want het is minder tijdrovend. In gegeven voorbeeld van de Helderse Duinen zou ik dat echter niet doen: sterker nog: het is de vraag of je de privégrond als bosbouw zou willen intekenen. Feitelijk zijn het natuurlijk niet-toegankelijke tuinen.
Verlies van niet kloppend detail.
Het is niet mijn bedoeling de kaart te de-detailleren. De vraag is hoe om te gaan met detail dat niet de werkelijkheid representeert.
Ik kan ook de wegen goed leggen en dan uploaden.
Dan is het wachten tot iemand anders de wegen weer netjes tussen de (foute) 3dShapes legt.
Als jij de wegen zoveel mogelijk netjes legt met AHN, pak ik de landuse wel op!
Dat vind ik dus echt lelijk. Liever highways strak tussen de 3dshapes met een afwijking van een paar meter dan het onooglijk en slordig achter te laten.
Ik denk dat de ironie je even ontgaan is… 
Zou zomaar kunnen.
Anyway, ik zie het regelmatig gebeuren dat er een highway die netjes tussen de 3dshapes ligt wordt rechtgelegd volgens AHN of BGT en de 3dshapes niet overeenkomstig wordt aangepast.
Tsja, hoe meer detail op de kaart komt, hoe vaker je niet op alles kunt focusen wanneer je iets aanpast. Dat betekent niet dat je bepaalde aspecten niet kunt verbeteren terwijl je andere dingen voor anderen laat. Liever 50% fout dan 100% fout, toch? (Voorkeur is natuurlijk 0% fout, maar we zijn mensen). Dus terugleggen naar oude 3dShapes (lees: bewust fouten aanbrengen) lijkt mij onwenselijker dan de landuse laten voor wat het is, zodat iemand anders (of jijzelf een paar dagen later) de overige 50% kan doen.
(Ik doe het zelf soms ook: als ik een weg uitlijn/meer gedetailleerd maak, is mijn focus hoofdweg + fietspad; heb ik tijd over kijk ik naar voetpaden en landuse. Soms vergeet ik ook gewoon dat ik het filter voor landuse aan heb staan)
P.s. heeft iemand toevallig een overpass of mapcss of kaart voor kruisende landuse/highways (zonder gedeelde nodes)? Wellicht helpt dat zulke fouten vinden
CogaCarlo,
Is dat niet een drempel die veel mappers gewoon niet zien, het begint bij de herkomst van de data ?
Maar er is in OSM geen protocol dat gemeten data respecteerd of markeerd, dus staat het iedere mapper vrij om het aan te passen. Zelfs als je er dagen aan meet/veldwerk insteekt is het in deze Open Data community niet veilig voor vandalen of ronduit vandalisme. Onder de vlag van ik weet het beter.
Als alles er al staat blijf ik ervan af, dan kun je je tijd beter elders lopen besteden dan waar alles al gezien is, dubbel werk zogezegd.