Nou, ik blijf dat leuk vinden om te doen, Willem1; zoveel zal al wel duidelijk zijn door het lezen van mijn eerste post. Ik ben wel blij dat de imports heel voorzichtig gaan en ik denk dat een upload van water/landuse niet zomaar zal worden gestart. Dat een en ander op aanvraag kan, vind ik een goede optie en misschien is dat wel de enige juiste.
Ik heb nog eens goed gekeken naar de details in de shapes en die zijn een stuk groter dan in mijn polderranden en eilandjes. Eigenlijk dus mooier. ('t Zal wel een flinke bult extra nodes in de db tot gevolg hebben, als dat erin staat…). Mocht het ooit voorgesteld worden om te gaan importeren, dan zal ik zo’n verbetering niet in de weg gaan staan, maar dat weerhoudt me nu nog niet om af en toe eens een bomen- of waterrandje uit Yahoo mee te pikken.
Ik weet niet of het met andere editors wel kan, maar in Merkaartor kan je een tile server als achtergrondkaart kiezen, bijv osm mapnik, maar ook de 3dshapes overlays, bijv.
als ik als serveradres instel: overlay.openstreetmap.nl/3dshapes/ kan ik de 3d landuses zien als achtergrondkaart. Lijkt me wel handig voor het juist positioneren van gps getrackte bos- en fietspaden e.d. want de 3dshapes laat daar witte strepen zien waar de bospaden lopen.
Ja dat is handig, en kan ook met de andere editors (JOSM en Potlatch). Je zou inderdaad op basis van de witte stroken paden kunnen gaan tekenen. Wellicht met een extra tag: source=3DShapes o.i.d.? Ik zie overigens op jouw plaatje ook zat paadjes die niet in 3DShapes aangegeven worden maar wel ingetekend zijn (onderin, net iets links van het midden bijvoorbeeld).
De paarse lijn is overigens een nieuw fietspad, dat naast/over de Turfweg heen loopt (ten westen van Soest). De gravelweg ligt er vaak nog naast, vandaar dat ik het fietspad er parallel aan getekend heb en niet ipv.
Ik had eerder al wat bossen en water overgetekend uit 3dshapes door die als slippymap achtergrond in josm te gebruiken.
Maar ik zie dat via het 3dShapes account nu ook landuse + water geimporteerd worden. Betekent dit dat ik beter niets meer kan overtekenen? Ik denk dat een directe import nauwkeuriger zal zijn, en mijn toevoegingen worden dan dus toch weer gewist?
Er wordt inderdaad landuse+water geïmporteerd direct vanaf de 3dshapes data. Ik ben echter zolang met de gebouwen bezig geweest, dat ik het zelf even rustiger aandoe, en de import voornamelijk aan Frank en Theun overlaat. Zijn zijn op dit moment in het oosten (Twente en uitbreidend) resp. noorden (Fryslân) bezig.
Theun en ik zijn nu redelijk op stoom met de import van 3dshapes landuse en water. Ik ben ondertussen Twente al voorbij en heb de laatste paar weken een groot deel van de Achterhoek geïmporteerd. Toevallig stuitte ik vandaag op edits van Wimmel, en Ldp wees me op zijn post.
Laat ik maar gelijk duidelijk zijn: zelf denk ik dat het geen nut heeft om data van 3dShapes zelf over te trekken. De belangrijkste reden is dat het heel lastig om met de import zelf aan te sluiten op shapes die door anderen zijn overgetrokken. Dat is eigenlijk niet te doen, en daarbij blijft van je inspanningen nagenoeg niks over.
Data van Yahoo, etc. overtrekken: dit hangt heel erg van de ouderdom van de Yahoo foto’s af, en dat in vergelijking met 3dShapes. Ik zou het zelf alleen doen als er geen of weinig 3dShapes coverage is. Dit heb ik zelf o.a. in Utrecht (op beperkte schaal) gedaan.
Wat kun je nou wel doen? Genoeg
Je kunt Ldp of iemand anders een OSM bestand sturen met daarin een way die aangeeft waar géén data geïmporteerd moet worden.
Je kunt Ldp vragen of hij ervoor kan zorgen dat ergens data wél wordt geïmporteerd. Hij zal dan mij of iemand anders vragen om dit te importeren, of zelf als het niet veel moeite kost, aangezien hij het rustiger aan wil doen.
Je kunt zelf gaan beginnen met de import van 3dShapes data. Ik heb enige tijd geleden hierover iets geschreven op de wiki, maar dit ga ik nog aanpassen. Ik pas nu een werkwijze toe waarbij veel minder wachttijd is. Ik laat het hier weten wanneer de beschrijving geüpdate is. Aangezien Ldp de brondata beheert, moet je bij hem zijn voor de data.
V.w.b. de wijzigingen van Wimmel en anderen (bijv. Frankl2009): ik zal bij de import de shapes die zij op basis van 3dShapes hebben toegevoegd verwijderen, om bovengenoemde redenen. Dit komt de kwaliteit van de data ten goede. V.w.b. andere landuse / water data: data met herkomst van AND en/of die slechts ruw de werkelijke situatie aangeven, zal ik in het algemeen verwijderen. Dit geldt vnl. voor bossen, parken, begraafplaatsen en water. Soms verwijder ik ook de residential area van kleine gehuchtjes, die vaak niet op de werkelijke situatie gebaseerd zijn. Als aan een AND shape een naam hangt, ga ik dit omtaggen naar een toponym-tag, met area=yes (t.b.v. correcte rendering van de naam). Dit om de naam te behouden. Als er andere informatie aanhangt (bijv. wood=mixed) denk ik dat ik de natural/landuse tag verwijder, en alleen een area=yes tag toevoeg. Ik heb dit nog niet zo gedaan, maar dit is ook een kwestie van voortschrijdend inzicht
Uiteraard wil ik benadrukken dat het NIET de bedoeling is van de 3dShapes import is om het vele en harde werk van anderen zomaar om zeep te helpen. Zoals hierboven aangegeven is een simpel mailtje genoeg om een gebied af te bakenen (als je er met zorg aan gewerkt hebt), of om zelf de verantwoordelijkheid voor de import van 3dShapes op je te nemen, dus ik wil jullie hierbij van harte uitnodigen om ons mee te helpen. Vele handen maken licht werk
Ik heb er in ieder geval geen probleem mee dat mijn toevoegingen weer verwijderd worden of al verwijderd zijn. Het gaat om een stukje duitsland waar dus geen AND data aanwezig was. De reden is dat ik ze toegevoegd had was dat ik dacht dat landuse voorlopig niet overgenomen zou worden van 3dshapes, en ik wilde volgende week (bij goed weer) ter plekke enkele zaken controleren, en meteen dit meenemen. Dus alleen maar mooi dat de echte data nu geimporteerd is, die is ook vollediger omdat ik alleen de belangrijkste zaken overgenomen had.
Het valt me op dat alle open plekken van de Sallandse Heuvelrug van AND nu veranderd zijn in bossen.
Zie http://www.openstreetmap.org/?lat=52.3308&lon=6.422&zoom=14&layers=B000FTF
De cyclemap toont nog de oude situatie. Zo te zien maakt 3D geen onderscheid tussen bos en heide, wat erg jammer is.
Houd je daar ook rekening mee? Ik zou het liefst die open plekken (=heide) niet opgevuld zien door bos.
Zo te zien ben je er dan met het omtaggen van die buitenste rand naar heide al, aangezien de eilandjes dezelfde constructie hebben als eerder al besproken voor binnentuinen: een ongetagde inner, en een extra way met landuse=forest. Als je de rand omtagt, blijven die eilandjes dus bos.
3dshapes heeft dit allemaal onder ‘natuur’ geschaard (3dshapes:ggmodelk=9). Daarom doen we ook geen enkele poging om naastliggende, maar identieke vlakken te fuseren met elkaar. Nu is het een kwestie van de tagging aanpassen, en als we het samengevoegd hadden, zou dat niet zomaar kunnen.
Ik heb een deel van de vlakken op de Sallandse Heuvelrug omgetagd als heide. Is het zo beter? De aanwezigheid van toponiem-vlakken (die de namen van de Hellendoornse Berg en Holtense Berg bevatten) geven aan wat volgens AND nog bos was. Aan de westkant is de situatie onduidelijker, dus heb ik daar niet aangezeten. Ik beschik nog wel over de originele data, maar het is wel een beetje lastig om door de bomen het bos te zien
Lennard, bevat CLC2000/2006 wel heide? Je was al van plan om dit als “overlay” te gebruiken, dus om 3dShapes vlakken van betere tags te voorzien. Ik denk dat ik het zelf toch alleen bij de import ga houden. Deze nabewerking kan ook door anderen worden uitgevoerd, die de situatie ter plekke beter kennen. Het is immers een stuk makkelijker om een vlak anders te taggen, dan je te verdiepen in de import. Ook zou hiervoor de Landsat imagery gebruikt kunnen worden.
Trouwens, de data van OpenCycleMap is van ca. 2 dagen geleden. Ik heb geen verklaring waarom niet alle “bossen” zijn gerenderd op de Sallandse Heuvelrug. Worden misschien alle multipolygons weggelaten?
