Grootschalige aanpak landgebruik: hoe te werk te gaan?

De wintermaanden zijn bij uitstek geschikt voor grootschalige projecten aan te pakken. Ik heb al hier en daar in mijn woonomgeving geoefend, maar wil het nu wat groter aanpakken.
De Geul, een kleine rivier in Zuid-Limburg, is de meeste mensen hier wel bekend, maar ze staat eigenlijk net zo op kaart als een lullig beekje van een halve meter breed en dat doet de rivier -naar mijn mening- geen eer aan. De rivier heeft de laatste jaren op verschillende plekken meer ruimte gekregen die een belangrijke rol spelen in het waterbeheer. Dat voor wat betreft mijn motivatie om De Geul een plek te geven in het Limburgse landschap.

Gisteren heb ik mijn eerste wijzigingen in dat kader al aangebracht in het gebied bij Engwegen. Verschillende forumleden zijn daar in die buurt ook al aan de slag geweest en met name bij het uitlijnen op BGT_omtrekgericht, was er door Allroads al het nodige gedaan, de laatste weken.
Omdat ik het gedane werk door mensen zoveel mogelijk wil respecteren, wil ik bij die werkzaamheden zo min mogelijk verwijderen, maar daaraan ontkom ik ook niet. Tot nu werk ik in feite altijd volgens een vast principe:

• Het gebied downloaden en de huidige situatie beoordelen;

• Zaken die te complex worden (of onacceptabel veel tijd in beslag nemen) om te wijzigen, verwijderen;

• Overgebleven landgebruik uitlijnen (daarbij maak ik het ook vaak los om het uit te lijnen op BGT_omtrekgericht). Als de grenzen van het landgebruik zichtbaar zijn bij omtrekgericht, laat ik het in de regel tot aan de weg doorlopen, staat het pad of weg niet in BGT_omtrekgericht, leg ik de weg of het pad over het landgebruik heen. Wegen en fietspaden lijn ik uit op de as van de weg en probeer ik naar de buitenkant van de gedownloade gebieden vloeiend te maken.

• Het nieuwe of gewijzigde landgebruik intekenen, ook met begrenzingen zoals in BGT-omtrekgericht of -bij nieuwe projecten/wijzigingen- what’s on the ground.

Deze werkwijze neemt natuurlijk heel veel tijd in beslag en ik vroeg me eigenlijk af, of er snellere en betere werkwijzen zijn en ook of jullie zoiets als nuttig/ wenselijk achten? :)

Tsja, volledige consensus zullen we nooit krijgen…

Persoonlijk trek ik lijnelementen (highways), tenzij ze erg breed worden (natuurlijk een contradictio in terminis, maar bijvoorbeeld voor autosnelwegen met meerdere banen) door de landuse heen en laat ik de landuse, zo die aan beide zijden van de highway verschillend is, aansluiten aan elkaar. (nooit de landuse vastplakken aan de highway: dit geeft heel veel problemen bij verschuiven van e.e.a. of aanpassen!).
Als de landuse aan beide zijden van de highway verschillend is (bijvoorbeeld grass / farmland) is het arbitrair of je die grens net links of rechts van de highway legt. Aangezien de meeste farmland door een grasstrookje begrensd wordt, dan wel de berm van de weg is het ‘veiliger’ de landusegrens dan aan de farmland-zijde van de highway te leggen.
De redenen waarom ik landuse laat aanlsuiten zijn enerzijds het gemak van tekenen, anderzijds, afhankelijk van de zoomfactor ‘lege ruimte’ (‘vacuüm’) op de kaartweergave.

Oude import van landuse (3dshapes, behoorlijkoud inmiddels) kan imho gerust verwijderd worden en op basis van PDOK-foto’s opnieuw ingetekend wordt en daarbij gelijk gelijke indentieke landuses mergen (samenvloeien). Ik zie geen zin om oude indelingen (van 3 shapes, gebaseerd op topokaart/kadaster?) te handhaven en “grote stappen snel thuis” is het devies. Natuurlijk wel dan bijvoorbeeld bos-perceeltjes in een groot grass-landuse netjes met multipolygoonrelaties mappen.
Het voordeel van oude 3shapes landuse verwijderen is tevens dat, indien van toepassing, de onterecht vastgeplakte highways loskomen van de landuse

Of je een beek als vlak dan wel alleen als slechts een lijnelement (stream) mapt is volledig afhankelijk van de breedte. De Geul verdient het om als area te tekenen in het Nederlandse Geuldal, maar dat had je al gezien.

Martin

Ik heb in Zuid Limburg voornamelijk me bezig gehouden met het op het midden van de rijbaan uitlijnen van de wegen/paden op de wegas, dit op basis van BGT omtrekgericht in combinatie met luchtfoto en Actueel Hoogtebestand Nederland (vooral daar waar bomen staan).
Hierbij heb ik in de buitengebieden wegen en paden bekeken en de doorgaande wegen door de dorpen. De andere wegen in de dorpen heb ik niet aangepast evenals de N278, die ook een update kan gebruiken betreffende de fietspaden en oversteken.
Eigen waarneming, zo ook veel (EOSfoto) mapillary beelden gebruikt, om de access goed te zetten wat op veel plaatsen niet klopte ten opzichte van de bebording. Horse, mofa, moped was vaak niet goed ingevoerd, of helemaal niet. Hierbij heb ik vaak gebruik gemaakt van :forward en :backward, omdat de vertaling van de borden, daar om vraagt. Zo ook het bord vermeld op een stuk van de weg. Om de tagging later te kunnen controleren. En aan te geven wat de basis is van de access tags. Tevens later meer de surface structureel meegenomen. Ook de snelheden aangepast veel moest van 80 naar 60 terug gezet worden. m.a.w. ik heb me nog niet veel bezig gehouden met landgebruik.

Structureel aansluitend door Zuid-Limburg gewerkt.
Ik heb een overpass query gebruikt om mijn aansluitende voortgang te zien.
Let daarbij op dat wanneer je, als voorbeeld, op een kruispunt van 1 weg het gezamelijke punt verandert je gelijk alle wegen op jouw naam komt te staan als laatste edit. Die overige drie wegen heb je dan nog niet bewerkt in zijn geheel.
Ik liet dan ook vaak het kruispunt onbewerkt totdat de laatste weg geheel (tussen nodes) bewerkt was.

Tijdwinst zit ook in de methode van werken.
Voor mij het gebruik van een pen tablet ten opzichte van muis bij het tekenen.
Met pen teken je sneller. Bij muis moet je bij elke node klikken. Pen aanraken, zo ook schuiven en het vasthouden, maakt het verschil.
In combinatie met de improve way accuracy
In combinatie met de CTRL toets. Zoomen deed ik met de muis, die ik nulinks had liggen, zou ook op het toetsenbord kunnen als deze functie er op zit. Om goed te teken moet je best ver inzoomen, voor overzicht zoom je vaak uit
Als zou je een nieuwe weg tekenen dan kan je tekenen van links naar recht of je zet begin en eind node en gebruikt de way accuracy methode.
Voordeel met pen teken je kwalitatief beter, dan wanneer ik met muis teken.
En ben eerder geneigd een bocht op te bouwen met vijf of meer nodes meer vloeiend dan met drie met alleen muis.
Ook het herstellen van een bocht, way accuracy methode.
Dat zie ik ook terug in hoe anderen tekenen

Omdat er veel repeterend werkt in zit, merk ik zelf dat de belasting voor pols, armen, schouder bij pen veel minder is als bij het werken met een muis.
Hogere lichamelijk belasting leidt to kwalitatief minder tekenwerk. En zo verandert werkwijze.

Ik zou de belijning van BGT over gaan nemen, beter kunnen we het haast niet tekenen. Niet met overtekenen, omtrekgericht, dat kost te veel tijd, maar de belijning met copy en paste merge gebruiken. (methode wat nog niet veel wordt gebruikt)

Je zal merken dat je automatisch aansluitend wil gaan werken, eigenlijk pas je dan elke polygon aan.

Wanneer ik het zou gaan doen dan zou ik de wegen met area:highway overnemen, dan is alles aansluitend ingetekend.
Ik heb eerder voordat BGT er was gebruik gemaakt van DTB Digitaal Topografisch Bestand van Rijkswaterstaat bij verkeerspleinen, daar toen de weg niet aansluitend meegenomen en heb daar nu spijt van, want later inpassen kost veel meer tijd.

Voor mij geldt: beter 1 keer goed, dan half, want als de volgende het weer gaat veranderen, besteden we met elkaar er veel meer tijd aan. Zo krijgen we effectief gezien in minder tijd een betere kwalitatieve kaart database voor Nederland.

Ik verschil hier dus van mening met Martin

Dat is zeker niet mijn devies.
Alleen op basis van luchtfoto intekenen, dat deden we vroeger, we hebben nu andere bronnen met op veel punten meer kwaliteit.

Mijn aanpak komt grotendeels overeen met de jouwe. In en rond mijn eigen dorp werk ik nu extra gedetailleerd, een beetje als proef van wat er mogelijk is. Daarna wil ik de wijdere omgeving goed aanpakken met minder detail maar wel nauwkeurig in wat ik doe.
Ik hoef niet beslist de meest efficiënte werkwijze te hanteren. Door het meer handmatige werk ontdek je nog wel eens leuke details in je nabije leefomgeving.

Om maar met de eerste zin te beginnen: de dag dat we hier op het forum een consensus weten te bereiken, trakteer ik op Limburgse vlaai voor de mensen in dat topic.

Als ik aan het werk ga in een gebied, probeer ik het bestaande werk van mensen zoveel mogelijk te respecteren want ik weet inmiddels als geen ander hoe frustrerend het soms is dat wanneer je ergens veel tijd aan besteedt hebt anderen het (verkeerd) aanpassen of erger nog: verwijderen. Een van de redenen waarom ik dit topic geopend heb is ook het feit dat ik het liefst zoveel mogelijk eerder werk van mensen wil respecteren. In sommige gevallen kost mij dat veel meer werk en tijd dan dat ik grofweg alles weghaal en opnieuw begin, maar daarmee heeft mijn voorganger niet voor niets gewerkt.

Persoonlijk vind ik het juist veel logischer om het landgebruik tot aan de wegkant, zoals ingetekend in BGT_omtrekgericht, aan te houden. Er ontstaat daarmee inderdaad een soort vacuüm op de kaart, maar dat maakt in vrijwel alle gevallen, de kaart ook een stuk duidelijker en vooral ook overzichtelijker.
BGT zie ik eigenlijk een beetje als leidende bron en pas als ik zeker weet dat zaken in BGT niet kloppen, wijk ik ervan af.

De luchtfoto’s en (sinds kort) het AHN gebruik ik eigenlijk meer als ondersteuning, want voor het wegverloop en begrenzing van percelen, gebruik ik de laatste maanden alleen nog maar BGT_omtrekgericht. Ik teken het zeker niet klakkeloos over, maar gebruik luchtfoto’s en het hoogtebestand maaiveld om BGT te controleren. In landelijke gebieden en bospercelen blijkt BGT soms verouderd te zijn. Een melding daarvan gaat dan ook naar “Verbeter de kaart”.
Met het verbeteren van de accuratesse ga ik eens verder aan de slag want de eerste ervaringen daarmee zijn positief. Ook het gebruik van de F-toets scheelt zoveel werk (waar heb ik dat nu weer gelezen???).
Zelf ben ik ook meer van het in één keer goed doen, maar dat lukt soms ook niet zonder soms hier en daar concessies te doen en foutloos werkt niemand.
De N278 parkeer ik even, maar ik heb idd gezien dat hier wat werk ligt, zeker als je omtrekgericht als basis neemt.

De eerste projectjes waren ook dichtbij, maar ik kijk nu een beetje naar behoefte, althans waar ik denk dat behoefte aan is. Zuid-Limburg is een Mekka voor fietsers (daarmee ben ik als automobilist in de regio zeker niet altijd blij) en het ontbreekt gewoon aan goede kaarten. Tot we de beschikking kregen over BGT en AHN dacht ik altijd dat OSM erg nauwkeurig was, maar we blijken nog heel wat werk voor de boeg te hebben.
Voor de wintermaanden heb ik het Mergelland uitgekozen: de Geul is een startproject omdat die een behoorlijk deel van het landschap inneemt. Wandelpaden en fietspaden komen daarna aan de beurt en tegen die tijd hoop ik zelf ook weer de fiets op te kunnen stappen om voor Mapillary nieuwe opnames te maken.

N.a.v. van dit heb ik een vraag over de area:highway.
JOSM geeft een foutmelding als een highway= (lijnelement) een area:highway

Is het de bedoeling dat de beide elementen met elkaar verbonden zijn (waar ze elkaar kruisen) of juist niet?

Snap je vraag niet helemaal. area:highway=x is voor vlakken, geen lijnobjecten. Je voegt het dus toe aan closed ways of multipolygons. Als er twee vlakken over elkaar liggen, denk aan een viaduct, dan zou ik die niet aan elkaar knopen, dat maakt het editen alleen maar nodeloos moeilijk. In werkelijkheid zijn het natuurlijk ook twee gescheiden vlakken.

Overigens raad ik je aan om bij area:highway ook altijd de** surface=x** op te geven. Hoewel sommige OSM’ers van mening zijn dat die informatie van de lijn highway=x moet komen, is dat technisch een hoofdpijn dossier… Daarnaast kun je met area:highway=x en surface=x in principe zelfs detail vastleggen over surface, die nooit van 1 highway lijnelement kan komen. Denk aan een verschillende surface=x voor aparte lanes, of zelfs een reparatievlak midden in 1 lane.

Mijn ArcGIS Renderer in ontwikkeling gaat die surface=x voor area:highway elementen trouwens tonen…

De vraag kwam omdat ik steeds meer foutmeldingen van josm hierover krijg.
Er is dan bv. een area=highway bij een splitsing. Aansluitend is er een area=highway waar een weg loopt.

De highway=unclassified snijdt dan de grensvlakken van beide area’s zonder dat deze verbonden zijn.

Momenteel controleer ik met de validator van josm steeds of het gedownload gedeelte klopt.
Bij een melding van kruisende wegen los ik dat op door deze te verbinden. Daar gaat het bv. om een highway=footway die een highway=residential kruist.
De area=highway met een highway=unclassified laat ik voor wat het is.

Als er tientallen (of meer) nodeloze meldingen komen dan stop ik met het controleren van deze foutmelding omdat de echte meldingen verzuipen in rest.

Het zou heel veel helpen als je een specifieke plek waar je problemen ondervindt en edits hebt uitgevoerd, hier linkt met een weblinkje naar de extent op de OpenStreetMap website. Zoom in op de plek, en kopieer dan wat er in je adresbalk staat hier in een post.

Dan kunnen mensen meekijken en hetzelfde gebied in JOSM downloaden.

Hier is een voorbeeld:
http://www.openstreetmap.org/#map=19/51.01538/5.81851

Als je dit download en de validatie uitvoert krijg je een waarschuwing dat er 20 overlapping ways zijn.

Download je heel Guttecoven dan zijn dat ca. 200 overlappingen.
Ik zie nu dat het waarschijnlijk hier iets anders is dan een highway die een area:highway kruist.