3dshapes import Leiden

Ik heb geen idee of ik hier aan het goede adres ben maar ik heb het volgende probleem:

In de wijk waar ik woon (http://www.openstreetmap.org/?lat=52.143848&lon=4.471783&zoom=18&layers=M) heb ik aardig wat werk gestoken in het mappen van het parkje en andere groen gebieden (evenals huisnummers en POI dat terzijde). Tot mijn enigsinds onaangename verrassing zijn veel van mijn multipolygons weggegooid en is er een import van 3dshapes overheen gezet, die naar mijn mening van slechtere kwaliteit is.

Mijn vraag is nu dus eigenlijk wat moet ik doen? Ik ben niet echt van plan om weeeer alles in te gaan tekenen enz. Is er een manier om de import ongedaan te maken of iig mijn toevoegingen terug te halen en de 3dshapes import weer te verwijderen?

Sowieso zijn gewiste objecten weer terug te halen, dus opnieuw tekenen hoef je niet te doen.

Op wat voor manier is het slechter? Is er veel veranderd de afgelopen jaren?

Hoi, ik ben ervoor verantwoordelijk geweest dat hier 3dShapes is geïmporteerd, en later heb ik een opschoningsslag gedaan. In het algemeen is de 3dShapes data van betere kwaliteit dan de bestaande landuse, welke veelal op AND is gebaseerd. De opschoningsslag vindt mede plaats om te voorkomen dat er dubbele data aanwezig is, en om te voorkomen dat er wordt gezegd dat imports alleen maar bakken met data uitstrooien, zonder enige kwaliteitscontrole.

Je zou kunnen stellen dat opschoning, e.d. aan de mappers in het desbetreffende gebied overgelaten moet worden, maar wat als de realiteit is dat er in grote delen van Nederland geen actieve mappers zijn, of degenen die er zijn bekommeren zich niet om landuse, of vindt het niet “hun” probleem? Imports zijn dus per definitie tricky.

Van de situatie voor de import (en wanneer alleen 3dShapes is toegevoegd) heb ik een backup. Ik denk niet dat je zomaar kunt stellen dat 3dShapes van “slechtere kwaliteit” is, maar dat dit een kwestie van smaak is. Een belangrijk verschil met jouw werk is dat vlakken in 3dShapes ophouden waar ze ook in realiteit ophouden, dus waar de verharding begint. In jouw geval laat je vlakken doorlopen tot de hartlijn van de weg zelf. Natuurlijk heeft een straat in realiteit een bepaalde breedte.

Een ander issue wat ik in de buurt van Leiden tegenkwam is dat er veel relaties van landgebruik-vlakken (bijv. gras) gemaakt zijn die uit tientallen members bestaan. Dat is in JOSM lastig te onderhouden, maar in Potlatch is het helemaal ondoenlijk. (Trouwens, ook als landgebruikvlakken verkleefd zijn aan wegen.) De vlakken zijn helemaal topologisch opgebouwd (puur op basis van de grenzen, gevormd door ways). Dat is mooi in een ideale situatie, maar onwerkbaar in de praktijk, waar de gemiddelde gebruiker veel moeite heeft om dit goed te kunnen doen.

Nadat ik een vergelijking heb gedaan, kom ik tot de conclusie dat er in ieder geval geen data verloren is geraakt. De changeset van de opschoningsslag heb ik onder mijn eigen account gedaan: http://www.openstreetmap.org/browse/changeset/7045195. Op basis van de verwijderde relaties is te zien dat er slechts 2 niet-AND relaties (die een laag ID hebben) verwijderd. Dat zou ik niet “veel” willen noemen.

Waar misschien een ander probleem zit, is dat de import “onverwacht” overkwam. Het had misschien in de optiek van sommigen beter gecommuniceerd kunnen worden, maar Nederland is al voor ca. 2/3 bedekt met 3dShapes, dus is te verwachten dat de rest ook gauw aan bod komt. Verder zijn er tot op heden nauwelijks problemen geweest, ook toen ik voor een kleiner gebied (bijv. de omgeving Utrecht) de import afkondigde. Op mijn laatste voortgangs-post op de blog is totaal geen respons gekomen, behalve een track-back van het daarop volgende weekbulletin. Het is te allen tijde mogelijk om ons van feedback te voorzien.

Ik hoop dat je iets aan dit antwoord hebt en dat je onze kant van het verhaal begrijpt. Je kunt ervan uitgaan dat de kwaliteit van de kaart voorop staat. (Het is dus niet zo dat per definitie 3dShapes altijd het beste is: in nieuwbouwwijken handhaaf ik de bestaande situatie.) Vanwege de schaal van het werk is het soms mogelijk dat we de mist ingaan, maar we proberen dat uiteraard te voorkomen. Situaties waarin ons inzicht verschilt van die van de lokale mapper, zoals hier, zijn niet altijd te voorkomen. Hier is meestal wel een weg uit te vinden.

Groeten,

Frank

Hoi Frank,

Ik ben het met je eens dat 3dshapes over het algemeen beter is dan de bestaande landuse en ben me er ook zeker van bewust dat als je zulke grote hoeveelheden data importeerd dat je keuzes moet maken over welke data je neemt. Hierbij zal iemand moeten beoordelen wat de beste data is en dat is natuurlijk een kwestie van smaak en kennis van het gebied. Zoals ik al aangaf was de data die er stond naar mijn mening op sommige plaatsen beter, inderdaad een kwestie van smaak.

Ook wat betreft het gebruik van relaties en/of gebieden op de weg aan horen te sluiten zijn er verschillende meningen en zijn al menig forum threads over geschreven maar dit is een compleet andere discussie. Ook in de wijk iets verder westelijk (Stevenshof heet het geloof ik) zijn veel relaties gebruikt om groen gebieden en water gebieden aan te geven en dat is de reden dat ik daar ook mee begonnen ben.

De import kwam voor mij niet onverwacht. Ik ben absoluut niet op de hoogte van jou blog maar het is natuurlijk aannemelijk dat er op een gegeven moment 3dshapes data geimporteerd wordt. Ik had iig gedacht dat degene die de 3dshapes zou importeren zou zien dat er recentelijk gewerkt is aan het gebied en iig even zou wachten tot deze lokale mapper misschien het zelf opschoonde of dat ik een berichtje zou krijgen met de vraag of ik het op wilde schonen. Toen er in Bolsward (friesland) een 3dshapes import kwam is mij gevraagd of ik dat op wilde schonen omdat ik per definitie het gebied beter zou kennen, ik heb dat toen gedaan en scheelt ook de gene die de import verricht een beetje werk.

In dit opzicht vond ik het wel onverwacht om ineens te zien dat een paar uur werk van iemand die daar practisch elke dag langsloopt en op uit kijkt vervangen wordt door data die 3-6 jaar oud is. Ik had liever gezien dat ik de 3dshapes data en de data die al bestond had kunnen combineren waardoor de best mogelijk map gemaakt kan worden. Nogmaals ik snap dat als je met grote hoeveelheden data werkt dat je soms de mist in gaat maar vind dat er altijd gekeken moet worden of en gebied actief bewerkt wordt. Dat je de lokale mapper dan niet een berichtje stuurt omdat dit veel tijd zou kosten kan ik begrijpen, maar als je 2 weken wacht voordat je dingen gaat verwijderen is waarschijnlijk veel data al voor je opgeschoond.

Groeten,

Bartjan

Voor de multipolygonen in de Stevenshof ben ik verantwoordelijk. Die komen uit de tijd dat ik me een beetje heb laten gaan met multipolygonen, aangezien ik het een schone manier van mappen vond. (Geen overlap, alles sluit aan, etc.) Maar ik ben daar om verschillende redenen een beetje van teruggekomen. Nu gebruik ik ze alleen nog voor echte landuse. De Stevenshof wil ik langzamerhand weer omwerken naar een iets meer “standaard”-gebied.

Beste datalogg,

in Leiden waren ook mijn eerste multipolygons, ook om eens te kijken hoe het werkt. Achteraf denk ik dat areas misschien beter werken en het lijkt ook dat mensen dit het meeste gebruiken. Dat neemt niet weg dat data direct als kwalitatief slechter beschouwd moet worden omdat het een multipolygon is. De Stevenshof ziet er trouwens wel mooi uit :wink:

Groeten,

Bartjan

Hoi Bartjan en datalogg,

Theun had toevallig gisteren verteld dat jij (Bartjan) voor hem data had opgeschoond rond Bolsward. Misschien zijn jullie bereid om dit beide rond Leiden te doen, aangezien jullie uiteraard beter op de hoogte zijn dan ik. Zouden jullie hieraan willen meewerken. Ik verwacht in de loop van deze week, of anders komend weekend de data geïmporteerd te hebben. Opschoonwerk beperk ik tot het landelijk gebied. Laat me s.v.p. ook weten of jullie dit op je wilt nemen in plaatsen rond Leiden, zoals Leiderdorp, Oegstgeest, etc.

Ik had trouwens niet door dat je de data recent had toegevoegd. Soms is het 2 weken geleden dat iemand bezig was, soms 2 jaar. Aan de ID’s is het niet altijd te zien (vooral van latere versies niet). In bijv. Gouda heb ik wel een lokale mapper (Reinout) gevraagd om de data op te schonen. Een andere reden dat ik het in Leiden niet in de gaten had, is dat ik nog maar een klein stukje had meegepakt.

V.w.b. multipolygons: op zich is daar niks mis mee, omdat dat de enige manier om een vlak met een gat weer te geven. Het voert m.i. te ver om de ringen (outer en inner) erg gefragmenteerd op te nemen. Voor landuse is het het beste om ze een stuk van de weg af te leggen, of anders een dubbele way te gebruiken. Voor de database-opslag hoef je dat niet te laten: het verschil is verwaarloosbaar t.o.v. de groei van OSM zelf. Ik vind bijv. ook de manier waarop busroutes in de database opgenomen zijn niet praktisch. Als je straten edit waarover veel routes lopen is het erg oppassen gebladen.

By the way, blog.openstreetmap.nl is zoals je misschien gemerkt hebt niet een blog die ik alleen beheer, maar dat gebeurt ook door een aantal anderen van de NL community. Ik kan me wel voorstellen dat je ermee onbekend bent, aangezien er zoveel communicatiekanalen zijn (blog, maillijst, forum, irc, wiki).

Frank

Ja hoor, daar kan ik wel een paar uurtjes voor vrijmaken. Ik ben redelijk bekend in het gebied ten westen (Wassenaar, Katwijk, Valkenburg, Noordwijk) en zuiden (Voorschoten, Leidschendam) van Leiden. Ik wacht al een tijd op die import, dus vind ik het geen probleem om me daarvoor nuttig te maken. Wat houdt het werk precies in en hoeveel tijd kost het?

Het opschonen bestaat uit het evalueren van de bestaande landuse, en kijken of dit beter wordt weergegeven door 3dShapes landuse (evt. a.d.h.v. Bing). Het doel is voorkomen van dubbele data. In veel gevallen is 3dShapes nauwkeuriger, maar niet altijd. 3dShapes is in de meeste gevallen beter dan landuse data die vanuit de AND import komt (te herkennen aan bepaalde tags, als ze niet zijn verwijderd). Uiteraard is in nieuwbouwgebieden 3dShapes lang niet altijd goed (bijv. farm/grass waar al bebouwing staat).

Ik zal in de plaatsen die je noemt alleen data opschonen buiten stedelijke gebieden. Dit is bijv. het toevoegen van waterlopen (river/canal of stream/drain) over de 3dShapes heen, o.b.v. de oude waterlopen die als vlak zijn getekend. Dit is al de normale werkwijze voor rivieren. In het verleden kende ik de naam van de oude waterlopen toe aan 3dShapes, maar dat zorgde soms voor een wolk aan namen, en was ook erg arbeidsintensief. De aangepaste werkwijze zal ook makkelijker zijn voor navigatie op het water. Ik doe het (nog?) alleen voor waterlopen die een naam hebben, omdat het hoofddoel het voorkomen van dubbele data is, maar dan wil ik de naam wel bewaren. V.w.b. hoofdwaterlopen zal ik dit ook doen door de plaatsen die je noemt. Als iemand anders dit al heeft gedaan, laat ik zijn waterloop staan, of vul ik het aan.

In Leidschendam en Voorschoten ben ik trouwens al klaar. Ik doe het opschonen z.s.m. na de import, omdat je later er niet meer aan toekomt. Het wordt dan teveel werk…

Mijn uitleg over de waterlopen, etc. is omslachtig. Wat ik bedoelde is dit: http://wiki.openstreetmap.org/wiki/Tag:waterway%3Driverbank. Ik gebruik het ook voor kanalen, beken en sloten.

Beste Frank,

ik woon pas sinds 3,5 maand in leiden maar ben zeker bereid te helpen met het opschonen van data in/rond leiden. In Friesland ben ik bekender maar ja verhuisd is verhuisd en dit zou zeker een goed projectje zijn om leiden iets beter te leren kennen :wink: Ik download regelmaatig gebieden in en om leiden om daar te kijken of alles klopt en of ik het kan verbeteren, is dit genoeg of wil je dat ik specifiek naar bepaalde gebeiden ga kijken?

Groeten,

Bartjan

@datalogg, nou, dan heb ik een leuk plekje voor je in Wassenaar om orde op zaken te stellen: http://www.openstreetmap.org/?lat=52.12946&lon=4.384265&zoom=18&layers=M
Naar aanleiding van mijn fietstochtje van vandaag kwam ik tot het intekenen van een stuk fietspad langs de Rust en Vreugdlaan. Dat nieuwe stukje begint bij de Backershagenlaan. Langs deze laan loopt aan weerszijden een fietspad. Weg plus fietspaden lopen allemaal westelijk van het water (Zijlwatering). Sinds de 3dShape import loopt het fietspad aan de oostkant nu door het water. Het kan natuurlijk zo zijn dat de Backershagenlaan niet goed is ingetekend - en die indruk krijg ik als ik naar andere kaarten kijk - of de Zijlwatering klopt niet, of misschien kloppen beiden niet. Op de OpenFietsMap van 21-01-2011 ligt de Zijlwatering met fietspaden nog aan de goede kant. Ik kom in Wassenaar overigens op meerdere plaatsen ‘vreemde’ 3dShapes tegen…

Mijn dilemma is dus: ga je wegen aanpassen aan de 3dShapes import, of als je zeker weet dat de weg goed loopt (b.v. gps-track), pas je dan de shapes (in dit geval het water) aan? @datalogg, ik laat het even aan jou over in Wassenaar omdat je je daaraan gecommiteerd hebt… Hulde.

@bikepc: bij het opruimwerk na de import stelde ik me het verwijderen van overlappende landuse voor, niet het helemaal kloppend maken van het betreffende gebied. Dat is een klus die iedereen op zich kan nemen en die ook niet in een paar uurtjes te klaren is. Zo zijn er wel meer plaatsen waar iets niet klopt. Volgens mij ligt de Backershagenlaan om te beginnen al niet goed. Bij mij rees wel de vraag waarom je het fietspad (way 96831587, enige edit de jouwe) door het water hebt gelegd. Heb je dat zo gemeten? Je track van die dag loopt niet over dat fietspad.

Mijn modus operandi voor het behalen van enige nauwkeurigheid is op dit moment: meerdere GPS-tracks maken op verschillende dagen, de punten filteren op HDOP/aantal satellieten, die gebruiken als meetbasis voor de Bing luchtfoto’s, de foto verschuiven indien nodig, en dan uitgaan van de foto. Met wat goede orthogonale GPS-tracks kan je daarmee een nauwkeurigheid van een meter of twee halen, schat ik. Hier is het wat lastiger omdat het fietspad door bomen aan het zicht worden onttrokken. Het hangt er dan helemaal vanaf wat er aangepast gaat worden. Zowel de wegen als de 3d-shapes kloppen soms van geen kant, dus daar komt enige kennis van de situatie ter plaatse bij kijken.

De beide fietspaden langs de Backershagenlaan sloten direct aan op de Rust en Vreugdlaan. Die situatie moest aangepast worden vanwege het nieuwe stukje fiestpad langs de Rust en Vreugdlaan. Het fietspad aan de oostkant van de Backershagenlaan heeft daardoor mijn naam opgeplakt gekregen, maar ik heb dat fietspad verder - voor zover ik weet - onberoerd gelaten. Voordat ik ging wijzigen liep dat fietspad al door het water. Vandaar mijn vragen dus.
Puur practisch, omdat het nu dus niet klopt, ga ik het laatste stuk van de Backershagenlaan een stukje opschuiven naar het westen zodat die weer correspondeert met de feitelijke situatie (klopt nu niet). Indien nodig ook het water van deZijlwatering wat smaller en/of iets naar het oosten zodat het fietspad langs de Backershagenlaan niet meer door het water loopt (ik hou niet van natte voeten…). Het nauwkeurig(er) maken van de situatie komt dan later misschien nog wel eens. Het stoort mij als fietser niet echt als het niet 100% correct is. Dat is op heel veel plaatsen het geval zoals @datalogg ook al opmerkt. Genoeg te doen dus…

V.w.b. het water rond Wassenaar, het viel mij ook op dat dit niet overal goed matcht t.o.v. de wegen. Het is het beste om dit met Bing en eigen GPS tracks te matchen. De meeste wegen in NL zijn geïmportered met de AND import in 2007. Het is een bekend gegeven dat de ligging hiervan niet erg nauwkeurig is. Toen viel het niet op, aangezien er weinig referentiedata is. Nu is er veel meer referentiedata (3dShapes, Bing).

Ik ben nu begonnen met de import rond Leiden. Ik zal het buitengebied opschonen alsmede de hoofdwaterwegen. Hopelijk kom ik morgen ook aan Katwijk, Rijnsburg, Voorhout, Sassenheim, etc. aan toe. Ik geef wel een seintje als ik klaar ben.

Ik heb het gebied rond Leiden voorzien van 3dShapes. In de bebouwde kom van Leiden, Leiderdorp en Oegstgeest heb ik alleen de waterwegen die een naam hebben aangepast. Dit is inclusief de grachten. In de overige plaatsen waren er geen tot beperkt wijzigingen aan landuse data.

NB: over de kustlijn ben ik nog niet tevreden. Deze heb ik wel aangepast, maar ik heb sterk de indruk dat het 3dShapes strand het gebied tussen gem. hoogwater en laagwater is. Op Bing zijn delen overstroomd. Dit geldt ook voor de pieren in de havenmonding van Katwijk: de buitenste stukken zijn niet zichtbaar / onder water in Bing! Ik ga hier nog naar kijken en evt de zaak gedeeltelijk reverten. Bijv. de oude scheiding strand/duin gebruiken. Daarom is het strand nu deels dubbel.

Nog een opmerking: de duinen zijn niet zichtbaar in de kaart, maar wel getagd. Misschien moeten ze deels worden omgetagd naar heide/zand, of moet hiervoor een aparte stijl in Mapnik komen.

Ziet er goed uit, ik ga er binnenkort naar kijken. (Op het moment ben ik bezig met een ander projectje, de wijk Leidschenveen in Den Haag.) Dat het water in Wassenaar niet optimaal is was me ook al opgevallen, ik heb ooit aan de hand van de Yahoo-foto’s het een en ander geprobeerd te corrigeren, maar met de Bing-foto’s is nu een betere correctie mogelijk. Een aparte tag voor natural=dune en/of een aparte stijl in Mapnik is wat mij betreft welkom, de bestaande tags voldoen niet helemaal, al komt natural=heath voor mijn gevoel in de buurt voor het landschap direct achter de zeereep. Was er geen speciale manier van taggen van hoog- en laagwatercontouren?

Vwb het gebied tussen de hoog- en laagwaterlijnen: deze zouden als natural=wetland;wetland=tidalflat getagd kunnen worden. Nadeel van de natural-tag is dat je niet kunt aangeven dat dit strand is, of wat anders. Ik moet hier nog beter induiken. Op IRC hebben we eergisteren dit al even aangesneden. Het ging over hoogveen, wat ook wetland is.