@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.
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?
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?
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…
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?
Ik denk dat het een illusie is om te denken dat je een werkgroepje kunt krijgen die overal uitkomt. Om maar te zwijgen dat de uitkomsten (zeker geen beslissingen, dat schept onrust) door iedereen verwelkomd zullen worden.
Maar goed, ik denk dat er natuurlijk verbetering mogelijk en ook nodig is. Maar het tagging schema zal altijd wel terugkerend onderwerp zijn/blijven van discussies.
Het idee van de waterways is om zaken zoals namen, vaarroutes, etc. weer te geven. De vlakken geven de ware grootte aan. Waterwegen zijn lineaire elementen, dus om die informatie naar de vlakken over te zetten is niet zo’n goed idee. Vaarroutes zou ik zeker lineair houden, i.v.m. een mogelijke waterrouteplanner. (Volgens een collega, die o.a. OSM op z’n vaartochten gebruikt, is hier een grote behoefte aan.) Ook is het veel makkelijker te onderhouden, als namen aan waterways gekoppeld zijn dan aan vlakken. Zie bijv. ook het gebruik van deze mix bij waterway=riverbank, alhoewel ik hier wil aantekenen dat ik absoluut geen fan ben van de riverbank tag, omdat dat verwarrend is. Zie bijv. de recente thread over de Nieuwe Waterweg en de waterwegen rond Dordrecht.
In het verleden heb ik wel namen aan vlakken gekoppeld, maar daar ben ik later van afgestapt. Dit deed ik overigens vooral met het AND-water. Resultaat, sommige waterwegen kun je goed zien door de aaneenschakelingvannamen. Tegenwoordig koppel ik een naam alleen voor meren, plassen, etc. aan vlakken.
Nadeel van deze werkwijze is wel dat het dubbel lijkt, maar ik vind de nadelen aan het alles aan de vlakken koppelen (een serie vlakjes met boat=yes, wtf?) zodanig groot worden dat het gebruik van waterway in combinatie met natural=water toch mijn voorkeur heeft. Op dit moment kan ik geen beter alternatief verzinnen. De shapes mergen wil ik ook niet. In veel gevallen (bijv. de kleinere waterlopen in veenweidegebieden) is het zelfs onmogelijk.
Het enige vervelende van ‘waterway=canal’ dat op sommige plaatsen, waar de 3dShapes erg smal is (bijvoorbeeld bij bruggen en sluizen), de waterway breder getekend wordt dan deze in werkelijkheid is.
Is hier misschien met width=* als extra tag op de waterway iets aan te doen?
Die laatste opmerking begrijp ik niet. Het is toch juist de bedoelding de ways te laten staan, zodat een eventuele waterroute planner hier gebruik van kan maken? Een multipolygon veranderd hier niets aan…
.
