3dshapes import Leiden

datalogg · 2011-01-23T12:47:39.000Z

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.

Computerfreaked · 2011-01-23T14:58:31.000Z

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

Groeten,

Bartjan

fsteggink · 2011-01-23T15:24:56.000Z

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

datalogg · 2011-01-23T16:50:25.000Z

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?

fsteggink · 2011-01-23T19:10:29.000Z

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…

fsteggink · 2011-01-23T19:53:03.000Z

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.

Computerfreaked · 2011-01-23T22:05:28.000Z

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 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

BikePC · 2011-01-26T20:11:26.000Z

datalogg:

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?

@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.

datalogg · 2011-01-27T10:22:20.000Z

@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.

BikePC · 2011-01-27T10:53:34.000Z

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…

fsteggink · 2011-01-29T08:52:39.000Z

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).

fsteggink · 2011-01-29T18:56:09.000Z

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.

fsteggink · 2011-01-30T21:14:40.000Z

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.

fsteggink · 2011-01-30T21:16:10.000Z

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.

datalogg · 2011-01-31T13:59:24.000Z

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?

fsteggink · 2011-01-31T21:53:07.000Z

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.

Computerfreaked · 2011-02-01T09:25:34.000Z

Ik ben gister en vandaag een beetje bezig geweest 3dshapes op te schonen. Nou kom ik op een aantal plaatsen een waterway=canal tegen wat door (in dit geval een 3dshape) natural=water ligt. Is het beter om die canal te verwijderen of geeft deze tag aan dat hier door boten gevaren kan worden oid?

ligfietser · 2011-02-01T10:38:55.000Z

fsteggink:

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.

Alleen wanneer er echt sprake is van heide. Omtaggen naar heide omdat het geel zo leuk staat op de mapnik kaart? Dan worden de duinen op mijn kaart paars! We gaan toch niet taggen voor de renderer?

Michiel_Faber · 2011-02-01T10:59:02.000Z

fsteggink:

Het ging over hoogveen, wat ook wetland is.

Ik zou dat niet al te snel roepen. Wellicht dat je een levend hoogveen als wetland kunt beschouwen, maar daar houdt het dan ook mee op.
Veel veengebieden (hoog- of laagveen) zou ik niet als een wetland quantificeren. In elk geval niet in NL.

Nog maar een edit van mij. Na het lezen van (bijna) de hele irc log, ben ik het zeker eens dat het tagging schema van natural/landuse/(landcover) op de schop kan. Zo ook met gebouwen (amnetiy/man_made) en leisure. Maar nogmaals, er moet een keer een werkgroep komen die eens iets belsist. Een groot nadeel van ‘tag what you want’ is dat er ook echt 1001 (x1000) verschillende dingen zijn die je kunt taggen. Zoveel tags ondersteunen is gewoon niet te doen. Groeperen/classificeren is dan de oplossing. Het probleem wordt dan weer de classificatie…

ZMWandelaar · 2011-02-01T15:29:33.000Z

Michiel … doe nou niet … komen al onze vrijgevochtenindoelekkerwatikzelfgoeddunk collega’s weer in het geweer.
Renderers moeten niet alles op de kaart zetten. Ook zij moeten gewoon lekker er uit pikken wat ze lekker vinden.
En willen ze toch profiteren van ALLE data van OSM … Tjaa … dan ondersteunen ze gewoon alle 1.001.000 verschillende tags.
Toch?