Het toevoegen van gemeentelijk groen.

Identiek beeld vanaf een recente luchtfoto, doorlopende tractorsporen, waarneming in het veld en dergelijke zijn een goede indicatie om samen te voegen; al helemaal als de grenzen van de gebieden, daar waar ze elkaar niet raken maar andere landuse raken/overlappen of naderen, sowieso aangepast moeten worden.

En wellicht ten overvloede: OSM is geen backup database voor overheidsdata als kadastrale grenzen, bluswateraanluitingen (inclusief type en diameter van de koppeling!) en wat dies meer.

Het mooie van OSM is dat we mappen wat zichtbaar is en wat nuttig is, waarbij sommigen af en toe een beetje uitschieten; als prullebakken op waarneming gebaseerd gemapt worden: soit. Het importeren (“omdat het kan” ) van alle lantaarnpalen inclusief nummer volstrekt zinloos (daar hebben we highway/lit=yes voor).

Maar ik dwaal af en kan het mis hebben…:stuck_out_tongue:

Nou, voor drone-routes… :smiley:

Ik heb inmiddels toch al wat meer geimporteerd op dit account. Lijkt me niet een heel groot probleem (behalve dat het het tegen de guidelines is). Ik ga nu toch maar de guidelines volgen. Vond de upload guidelines in mijn geval een beetje vaag. Als ik op de wiki kijk voor andere import die gedaan zijn dan zijn dat allemaal veel grotere imports dan waar ik nu mee bezig ben (vond deze meer overeenkomen met bijvoorbeeld een simpele import voor brandkranen). Het oorspronkelijke plan was ook om alleen het centrum van Tilburg te doen en de plekken waar nog echt niks aan groen was maar later bedacht ik me dat ik net zo goed de hele stad gewoon kan doen.

Dus zoals je zegt ga ik eerst een wiki pagina aanmaken en comment met link naar dit forum voordat ik verder ga.

Met de al geimporteerde data kan ik verder 2 dingen doen:

Het makkelijkste is natuurlijk om alles wat al geupload is aan te passen door met een ander acount alle geimporteerde nodes te wijzigen. Dit door bijvoorbeeld een tag met source=BGT aan alle objecten toe te voegen. Net zoals bij de 3DShapes import gedaan is. Dan krijgen alle objecten wel V2 maar dan staat er wel de juiste user bij.

Wat ook kan is alle imports gemaakt op dit account allemaal terug te rollen en ze opnieuw te doen op het import account. Het is wat meer werk, maar is op zich ook prima te doen.

Dit vind ik wel interessant. Ik gebruik nu een eigen programma om de data zoals die van de gemeente komt om te zetten. Het kan data filteren en opsplitsen zodat het makkelijk te importeren is via JOSM. Als andere mensen hier behoefte aan hebben dan kan ik dit vrijgeven.

Mooi, dat kan gedoe schelen en zo kunnen we voortbouwen op elkaars werk en ervaringen.
Het is inderdaad wel zoeken met die guidelines, ik heb zelf ook zitten dubben daarover (net als bij jouw vooral copy-pasten in plaats van -het al geaccepteerde overtekenen van bgt data) maar hier -niet de ideale plek…- wordt iets duidelijker een grens aangegeven wanneer je in de import-molen komt:

https://wiki.openstreetmap.org/wiki/Import/Catalogue

Daar zit je al snel aan, en nog belangrijker: in onze beide gevallen vervangen we ook bestaande data. Dat maakt de noodzaak tot goede afstemming naar mijn idee ook groter dan als je alleen maar data toevoegt.

Beide opties voor aanpassen van updates klinken goed, hoewel het misschien nog makkelijker is om bij de betreffende changesets een lik naar de wiki van je importvoorstel en deze site te plaatsen, dan loopt het volgens mij ook rond.

Ik vermoed dat daar wel interesse in is, ik heb de hulp die ik krijg bij de dataverwerking in ieder geval hard nodig (-:

De algemene mening hier over het wel of niet samenvoegen van vlakken onderschijf ik.
De laatste maanden heb ik veel met weilanden, sloten en grasstroken gewerkt. De bestaande vlakken van 3dShapes komen soms niet (meer) overeen met de werkelijkheid. Ik controleer tegenwoordig altijd even de BGT-viewer maar volg die niet altijd. Eigen waarneming gecombineerd met luchtfoto’s blijft van belang.
Als over bijna de gehele lengte een sloot loopt dan beschouw ik dat meestal als afscheiding en zorg ik een vlak aan elke zijde. Kleine stukjes groen tussen weilanden (‘grasland overig’) teken ik niet apart in. Daar laat ik de weilanden gewoon op elkaar aansluiten.

BGT-imports zullen op termijn mijn gedane handwerk wel grotendeels overbodig maken.

Aanvulling: ik zorg er wel voor dat er niet te grote en lange aaneengesloten stukken groen ontstaan, dus bijv. een berm die kilometers doorloopt toch maar af en toe opknippen.

Vervolg…

Een groenstrook langs een woonstraat tekende ik eerst als één aaneengesloten strook. Later heb ik het opgeknipt zodat bijv. opritten zichtbaar worden zonder ze daadwerkelijk in te tekenen, zoals hier: https://www.openstreetmap.org/#map=19/53.27582/6.14680.

Weilanden heb ik eerst standaard als landuse=grass aangegeven. Sindskort ga ik toch maar voor landuse=meadow.

Stukjes dichte en wat hogere begroeiing met bomen → landuse=forest (ondanks dat het in spreektaal zeker geen bos laat staan ‘forest’ genoemd zou worden).

Lage begroeiing / struikgewas had ik eerst niet ingetekend en later allemaal met landuse=village_green (bij gebrek aan beter).

Van belang zijnde heggen: barrier=hedge.

Bomen: ik begon met de meest opvallende bomen (natural=tree) en opvallende bomenrijen (natural=tree_row) op gemeentelijke grond. Vervolgens ben ik bomen telkens meer los van elkaar gaan tekenen indien zodanig herkenbaar en ook iets minder grote bomen en bomen op private grond. Moeilijk om ergens een grens te trekken…

Ben vandaag weer even bezig geweest, dit keer met een apart account. Ik heb nu alles wat ik geimporteerd heb voorzien van “source”=“KRT Tilburg”. Dit moet in ieder geval weer voor duidelijkheid zorgen wat waar vandaan komt. :slight_smile:

Ik heb verder nog een boel losse duplicated nodes verwijderd. Ben wel benieuwd hoe die er in gekomen zijn. Kan het zo zijn dat als je met JOSM een upload annuleert hij toch de deels geuploade data gewoon in de OSM database stopt?

Sowieso bestaat er met taggen van landuse altijd wel een grijs gebied. Waar bijvoorbeeld de grens zit tussen een bos en een grasveld met bomen blijft altijd lastig. Alles met bomen waar je niet doorheen kan lopen (door bijvoorbeeld struiken) tag ik als bos. Maar als er gras groeit onder de bomen zie ik het niet als bos.

Eigenlijk mist er gewoon een “groenvoorziening” tag waar je makkelijk al het beheerd openbaar groen mee kan taggen.

Ja, uploadvolgorde van een changeset is toevoegen alle nodes, toevoegen alle ways die de nieuwe en bestaande nodes verbinden en tot slot het verwijderen van de ways en daarna de nodes (relaties zitten er ook nog tussen, maar is minder van belang voor dit issue).
Dus bij grotere changesets waarbij alles niet in 1 chunk past (dacht default in JOSM 100 objecten) en als het halverwege afbreekt (zowel bij toevoegen als bij het verwijderen) kunnen er losse nodes in de database komen of achter blijven.

Ik heb toen waarschijnlijk geupload in chunks. Normaal doe ik dat alleen als meer dan 10000 wijzigingen zijn. Heb de chunksize gezet op 1000 objecten, wat opzich wel overeenkomt met het aantal verkeerde nodes (ongeveer 2x1000).

JOSM had een changeset geopend, wat data er aan toegevoegd, en toen heb ik dat gecancelled. Deze changeset was niet gesloten. Bij de 2e poging heeft JOSM geen nieuwe changeset geopend maar is alles toegevoegd aan de eerste changeset waar al de incomplete data instond. JOSM had het eigenlijk in losse changesets moeten uploaden zodat je de foute dan terug kan rollen. Of liever dat JOSM dat meteen al doen als je annuleert. De verkeerde data was hoe dan ook geupload, maar dan had ik het iig meteen gezien. Voortaan dus beter uitkijken met annuleren.

Ik heb in de engelstalige tagging groep gevraagd wat een goede term zou zijn voor ons gemeentegroen. De eerste vraag was gaat het vooral om het landgebruik, om wat er op het land zit, of om eigendom en beheer. De indruk was 1. landuse en 2. landcover, en beheer en eigemdom boeit niet zo.

Wat voor landuse is het? Eigenlijk is het decoratief opvullen. De suggestie: landuse=decorative.
En dan landcover=scrub, grass, flowerbed, … Bomen apart neerzetten of als treerows. Bij veel bomen is het een forest.

Nou nog een mooie rendering verzinnen voor als er geen landcover gezet is. Egaal zachtgroen of zo.

landuse=decorative zou wel een goede oplossing zijn. Lekker breed en de naam impliceert ook een beetje dat het beheerd groen is. en dus niet zoals *meadow *of scrub bedoelt is voor grote stukken land. Voor het renderen lijkt me een kleur groen die iets donkerder is dan gras, maar lichter is dan bos (en heggen) me wel handig. Kan je aan de mooi zien hoe hoog of wilder de begroeiing is.

Heb wat voorbeeld foto’s van de discussiepagina over *village_green *van de wiki gehaald.

Deze zou ik dan zelf taggen met landcover=scrub

Deze ook met landcover=scrub en de bomen los.

Deze heb ik nu veel als barrier=hedge, area=yes getagged. Ook al is het niet helemaal een heg. landuse=decorative, Landcover=hedge zou eventueel ook wel een uitkomst kunnen zijn hier. Maar met barrier=hedge lijkt het me duidelijker.

Ja maar hoe tag je dat speeltje? leisure=whipkhip?

Kon ik het maar zo goed zien op de satellietbeelden.

Maar op dit moment gebruik ik leisure=playground daarvoor. Ieder speeltoestel (of veldje) in een park die tags geven werkt natuurlijk niet als de speeltuin meerdere speeltoestellen heeft. Maar dat wil ik nog een keer allemaal aanpassen. Het krijgt dan landuse=grond onder speeltoestel en dan een losse node (of losse achtergrond area zoals bij parken) met leisure=playground.

Sorry, ik probeerde humor. Blijft lastig.

Andere meningen over het idee landuse=decorative?

:laughing:

Laatste onwtwikkelingen uit de tagging-maillist, met name van de renderers die daar ook inzitten, zijn weinig hoopgevend als het om landuse en landcover gaat. Er lijkt vanuit het verleden een veto te rusten op renderen van landcover en het systematischer gebruiken van de landuse, natural en leisure tags die nu gebruikt worden om stukjes groen in (onder meer) een landuse=residential area gerenderd te krijgen. Voor het principe is onder taggers in ieder geval veel support, maar sommigen daarvan zien het niet zitten om over te stappen omdat het zoveel werk is (enorme installed base).

Desondanks neemt het gebruik van landcover=* voor dit doel toe. Er zal MI een moment komen waarop landcover gerenderd gaat worden als het over een ander landuse heenligt. Het oude systeem zal dan nog een tijd doorwerken, en dat is prima want het bijt elkaar niet.

Daarom tag ik vanaf nu stukjes gemeentegroen (in een landuse=residential area) die nog niet getagd zijn, met landcover=grass, landcover=scrub of landcover=trees, en accepteer dat ze nog niet gerenderd worden op OSM carto (dus geen verschil ten opzichte van nu)

Stukjes “decoratief” groen op een residential (of bv military, industrial, commercial area) die al getagd zijn met natural=grass, landuse=fores of, landuse=scrub, geef ik bijpassende landcover tag er gratis bij, als ik in de buurt aan het taggen ben. (dus ook: geen verschil in standaard rendering tov nu)

Op het moment dat landcover wel gerendered gaat worden zijn die objekten er dus klaar voor. Ze hebben dan wel een overbodige tag, die voor wat betreft opgespoord kan worden door te zoeken naar landuse-over-landuse, en natural=grass over een landuse heen. Maar daar is dan geen haast mee.

Het is denk ik bijna onvermijdelijk dat landcover breder beschikbaar komt, maar het is nog even een (politieke) puzzel om daar te komen. Het verzet ertegen op de tagging-mailinglist lijkt (voor zover ik het kan overzien) beperkt tot een handje vol heel vocale stemmen. Sommigen zijn principieel tegen initiatieven zoals landcover=trees/grass, omdat je (volgens hun) als mapper en data-consument maar moet snappen dat landuse=grass „bedekt met gras” kan betekenen en meestal niets met landgebruik te maken heeft, terwijl bijna alle andere veelgebruikte landuse-tags wel op landgebruik slaan. landuse=forest voor een strookje met boompjes in de stad is natuurlijk nog bizarder.

Wat landuse=decorative betreft; op de mailinglist stelde iemand landuse=greenery voor, voor stukken beheerd groen die niet onder een andere landuse vallen. Dit is heel geschikt voor gemeentegroen waar geen landuse is, zoals groenvoorzieningen tussen wijken en hoofdwegen (let op dat sommige amenities en leisure gebieden ook een soort landuse impliceren, zoals leisure=park).

Misschien is het een idee om bij dat idee aan te haken.

Waarom niet de landcover=bushes die in het landcover-voorstel staat?

Het aardige is dat landcover ook prima zonder landuse, leisure of amenity kan. Dus als je geen idee hebt waar een gebied voor dient, kan je toch gewoon beschrijven wat je ziet. Mocht iemand later een landuse eronder gooien, dan maakt ook dat niet uit (want niet de landuse, maar de landcover wordt gerenderd; landuse heeft vaak wel een default landcover).

Dus, als landcover eenmaal gerenderd wordt, is de noodzaak voor een landuse=decorative of landuse=greenery eigenlijk weg. Met landuse=greenery heb je ook nog het probleem dat steeds vaker rotsen, keien, grind, speciale bestrating en gigabloembakken op siertegels gebruikt worden als ruimtevulling.

scrub, scrubs, shrub, scrubland, shrubland, brush, bush, bushes: dat mogen anderen verzinnen. Ik heb wat rondgegoegeld en er zit geen enkele lijn in de meningen en overtuigingen. Het duidelijkste is nog dat scrub meestal voor één struik gebruikt wordt en alle andere dingen voor struikgewas of land met struikgewas. Daar brand ik mijn handen niet aan! Ik heb zo’n idee dat dat allemaal door elkaar gebruikt wordt en dat het allemaal precies hetzelfde gerenderd en behandeld gaat worden.

Ja dat is precies het idee erachter.

Ja, voor rotsen rek je het begrip ‘greenery’ wel iets op, maar aan de andere kant volstaat ‘decoration’ weer niet voor de functionele stukken groen waarvan we best veel hebben (waterberging, verkeersveiligheid, etc.). Misschien zijn het inderdaad verschillende (maar verwante) soorten landgebruik.