Het toevoegen van gemeentelijk groen.

Hallo

Ik ben bezig om groen toe te voegen in Tilburg. Ik doe dit aan de hand van deze data:
Viewer: http://www.arcgis.com/home/webmap/viewer.html?basemapUrl=https%3A%2F%2Fwebservices.tilburg.nl%2Farcgis%2Frest%2Fservices%2FBasiskaart%2FMapServer&source=sd
Link: https://data.overheid.nl/data/dataset/kernregistratie-topografie-tilburg

Hier is staat de landuse heel gedetaileerd in getekend en staan onder andere outlines van wegen, fietspaden, putdeksels, etc. Ik ben eigenlijk alleen geïnteresseerd in het groen.

Ik wil beginnen om deze data langzaam toe te voegen aan de openstreetmap database maar ik heb nog een aantal vragen over bijvoorbeeld het taggen. Op veel plekken staan verschillende soorten groen zoals gras, heggen, struiken los ingetekend. Ieder soort begroeing heeft zijn eigen polygon.

  • Ik weet dat je gras kan je taggen met Landuse:grass, maar hoe tag je bijvoorbeeld lage struiken, heggen en ander laag groen? En hoe zit het bijvoorbeeld met village green?

  • Op sommige plekken is een grasveld bijvoorbeeld opgedeeld in verschillende vlakken gras die aan elkaar grenzen (vooral in parken het geval). Vaak geven ze de layout weer van een park. Kan ik het zo laten of moet ik ze dan samenvoegen tot 1 polygon? Voor het renderen maakt het in ieder geval niet uit.

  • De ruimte die bomen innemen als ruimte in de stoep is ook ingetekend. Dus voor iedere boom die in een straat staat is een klein vierkant. Het makkelijkste is om die ook mee te importeren (en eventueel de bijbehorende bomen er ook bij te zetten uit de bomendatabase van de gemeente). Ik weet niet of hier bezwaar tegen is.

  • Zijn er nog andere dingen waar ik eventueel rekening mee moet houden?

Heb eerder deze week al een edit gedaan als test. Het geeft een beetje een idee hoe zo’n import er uit kan zien.
link: https://www.openstreetmap.org/changeset/58767548#map=17/51.55825/5.06608&layers=H
Archavi: https://overpass-api.de/achavi/?changeset=58767548

Dit is een lastig onderwerp, want er helemaal uit zijn we niet…
Hier vast wat leesvoer om de problematiek te onderstrepen…
https://forum.openstreetmap.org/viewtopic.php?pid=692148#p692148

Het probleem zit in die stukje onbestemd groen… waar van alles groeit. Hoe tag je dat.
Binnen de bebouwde kom is voor grasveldje landuse=grass het meest gebruikt. Losse bomen kun je als natural=tree op nodes zetten… dus niet als vlakken. landuse=forest wordt op de vlakken gebruikt.
Bomen op een rij worden getekend als natural=tree_row … ook hier loopt een proposal over om dit beter te laten renderen.
edit2: https://forum.openstreetmap.org/viewtopic.php?pid=697947#p697947

landuse=village_green wordt in GB gebruikt om een “brink” mee aan te geven. Wij zijn dat gaan gebruiken voor gemeentegroen. Het dekt dus niet geheel de lading.

Bosschages en kreupelhout worden vaak getagd als natural=scrub… maar is eigenlijk bedoeld voor wildgroei/ beginnend bos.

Al die vlakken samenvoegen zou ik niet doen. Ik laat meestal de paden vrij, maar dat is overigens niet verplicht. Soms zitten in een park ook vlakken beton. Bv basketball veldjes. Die teken ik dan weer als Leisure=pitch en zet je in een multipolygoon relatie als inner anders zie je ze niet op de afgeleide kaarten.

Park is weer een apart hoofdstuk.
Dit verhaaltje stuur ik altijd naar zogenaamde “parkenmappers”.

Niet simpelweg iets omzetten in een park.
Je verwijdert de details en vervangt deze door een transparant.
Een park is een (uitgestrekt) terrein, omvattende stukken grasveld, bos en bosschages, vijvers, paden etc. Het is een soort deken over al het andere heen. Bovendien heeft het meestal een naam.
Leisure=park is de functie en die moet je los zien van wat je ziet de landuse. Je edits zullen worden teruggezet.
Hier een voorbeeld van een park met landuse en een losse cover leisure= park er helemaal los overheen. http://www.openstreetmap.org/#map=18/51.80552/4.66665

Ik heb deze wijzigingen teruggezet.

Ja… en iets importeren uit een database… heeft veel haken en ogen. Daar zijn veel draadjes over. Een voorbeeld van de lantaarnpalen en brievenbussen had ik al eerder genoemd op een changeset. Wellicht dat iemand anders daar nog iets zinnigs over kan zeggen. Niet elke bron is toegestaan en over bulkimport moet consensus bestaan.
Er zal vast nog wel iemand van de experts op dit gebied reageren. Goed in iedere geval dat je het op het forum inbrengt.

edit3: En hier nog een knap voorbeeld van barrier=hedge op paleis Het Loo
https://www.openstreetmap.org/#map=18/52.23468/5.94638

Hoi en welkom op het forum!

Ik zal even kort & bondig proberen te antwoorden zodat je deze regenachtige moederdag alvast door kunt komen… :stuck_out_tongue:

Hier is staat de landuse heel gedetaileerd in getekend en staan onder andere outlines van wegen, fietspaden, putdeksels, etc. Ik ben eigenlijk alleen geïnteresseerd in het groen.
Alleen geïnteresseerd in groen is wel leuk en aardig, maar dat gaat niet werken. Doordat je groen toevoegt kom je al snel in de knel met wegen en paden (die overigens sowieso erg knullig en niet echt waarheidsgetrouw staan ingetekend) daar rondom het CZ en bureau van politie in Tilburg. Je ziet nu al bijvoorbeeld dat het Cyprespad midden door een gebied met gras gaat lopen, dat overigens ook niet eens gras is.

Ik wil beginnen om deze data langzaam toe te voegen aan de openstreetmap database maar ik heb nog een aantal vragen over bijvoorbeeld het taggen. Op veel plekken staan verschillende soorten groen zoals gras, heggen, struiken los ingetekend. Ieder soort begroeing heeft zijn eigen polygon.
Verschillende soorten begroeiing komen vaak voort uit verschillende percelen of bestemmingen. Als de stukken groen zijn opgedeeld in meerdere vlakken, zou ik die vooral in stand houden. Bij gemeentelijke groen is dat nog niet zo’n issue, maar in bospercelen, weidegebieden of parken, “moeten” de verschillende gebieden in stand blijven.
Door het samenvoegen van dezelfde stukken groen tot één groot gebied, gaat vaak waardevolle informatie “achter de schermen” verloren.

Ik weet dat je gras kan je taggen met Landuse:grass, maar hoe tag je bijvoorbeeld lage struiken, heggen en ander laag groen? En hoe zit het bijvoorbeeld met village green?
De algehele stelregel luidt: “map what’s on the ground”. Bij gemeentegroen (zoals struiken en aanverwant spul) gebruik ik nu village_green, maar daarover is officieel geen consensus bereikt (zoals heel veel hier op het forum).

- Op sommige plekken is een grasveld bijvoorbeeld opgedeeld in verschillende vlakken gras die aan elkaar grenzen (vooral in parken het geval). Vaak geven ze de layout weer van een park. Kan ik het zo laten of moet ik ze dan samenvoegen tot 1 polygon? Voor het renderen maakt het in ieder geval niet uit.
Zie hierboven: NIET samenvoegen!

- De ruimte die bomen innemen als ruimte in de stoep is ook ingetekend. Dus voor iedere boom die in een straat staat is een klein vierkant. Het makkelijkste is om die ook mee te importeren (en eventueel de bijbehorende bomen er ook bij te zetten uit de bomendatabase van de gemeente). Ik weet niet of hier bezwaar tegen is.
Als je losse bomen gaat intekenen, kan dat ook al snel te druk worden, maar dat zou geen reden zijn om het niet te doen. Als er een boom staat, dan zou ik dat ook als zodanig mappen en niet al een perceeltje van 1x1 m met gras (dat wss toch niet zichtbaar is op kaart omdat je niet zo ver kunt inzoomen).
Het soort, geslacht enz. erbij te zetten is leuk en aardig, maar het maakt in het uiteindelijk zichtbare resultaat niks uit.

- Zijn er nog andere dingen waar ik eventueel rekening mee moet houden?
Er zijn meerdere bronnen die je kunt gebruiken bij het goed in kaart brengen, gebruik iig JOSM als je aan de slag gaat.

Als je iemand citeert kun je beter [ quote ] [ /quote] gebruiken in plaats van [ b ] [ /b ].

Ten aanzien van het niet mogen samenvoegen van aangrenzende identieke landuses (waarvan ds alle tags identiek zijn), veelal gebaseerd op oude 3dshapes-imports, verschil ik toch van mening:

Waar de oorspronkelijke onderverdeling op gebaseerd is, is niet bekend en, nogmaals, als alle tags identiek zijn, blijft dat bij samenvoegen ook. Het kan, imho, geen kwaad het zo te laten, maar bezwaren tegen samenvoegen zie ik ook niet; zouden deze grenzen gebaseerd zijn op (verouderde) kadastrale data bijvoorbeeld, dan is die mogelijk zeker niet actueel meer en OSM is geen back-up van de kadastrale kaart…

Maar ik kan het mishebben…:slight_smile:

Met samenvoegen bedoelde ik vooral daar waar stukken land dezelfde tags hebben. Op sommige plekken is men aardig bezig geweest zoals hier:

Op de bovenstaande foto volgen ze mooi de contouren van de heuvels en dijklichamen. Maar op sommige plekken lijkt het wel willekeur geweest te zijn. De data maakt zelf geen onderscheid tussen gras en bos, dus die moet ik er sowieso op veel plekken zelf in zetten. Ik denk dat ik het gewoon per situatie bekijk.

Is dat soms een BMW-stuur dat ze hebben gekartificeerd daar links?
Of is het “geparkeerd”, in de zin van ze hebben er een park van gemaakt?

Daar waar ik groen importeer zal ik de paden ook wel aanpassen zodat ze niet meer overlappen. Slecht ingetekende wegen en paden komen helaas op wel meer plekken voor in Tilburg. Heb op verschillende plekken al paden beter ingetekend.

Village_green gebruiken kan op zich wel een oplossing zijn. Ik laat denk ik alle vlakken gewoon intact. Mocht er in de toekomst wel een concensus zijn dan hoeft alleen de juiste tags toegevoegd te worden.

Ik gebruik ook de satelietfoto’s van PDOK en bing om de landuse te bepalen en welke stukken tot bos gerekend kunnen worden en welke niet. Op veel plekken buiten de stad staat landuse in de openstreetmap database beter dan die van de gemeente (die geen bossen kent). Enkel de outlines zijn dan beter.

KiaaTiX… Houd er wel rekening mee dat de BING behoorlijk verschoven ligt.
Die dus niet gebruiken om over te tekenen.
Pdok 2017 ligt goed. In JOSM kun je ook de BGT omtrek gericht als transparant gebruiken om de wegen goed te leggen.
Tilburg is een voorbeeld waar door PokemonGo-mappers massaal is vernield aan de groene ruimte. Soms dezelfde mappers onder verschillende accounts.
Veel parken heb ik hier opnieuw ingetekend omdat de 3dshapes verloren waren gegaan. Na zo’n herstel was alles opeens weer Leisure park en weg de landuse.
Dus alles kan nu alleen maar een verbetering zijn. Wees alert als er weer een golf van pokemonedits komt.

Dat was een van de eerste diskussies die ik hier volgde. Nadat ik heel goed gekeken had wat een village_green precies is, ben ik tot de slotsom gekomen dat niet te gaan gebruiken voor “gemeentegroen”. Een village green is een bepaalde plek, een “brink” of dorpsplein/stadsplein/evenemententerrein. Het kan gras zijn maar andere surfaces komen ook voor. Wij hebben die dingen ook, bijvoorbeeld in den Haag het Malieveld (vooral gras) , maar ook het Plein (bestraat) en het Lange Voorhout (heeft gras, maar ook straat, stoep en een groot voetgangersgebied met schelpen). In Nieuwerkerk hebben we het Raadhuisplein (geheel bestraat), dat valt onder de definitie van een village_green.

Omdat dan te gaan gebruiken voor allerlei begroeide groenstroken, dat vond (en vind) ik te ver oprekken van de eigenlijke betekenis, vooral omdat die op andere (echt verschillende) objekten nog steeds van toepassing is.

Dus ik gebruik voor gemeentegroen nu grass, scrub, eventueel gekombineerd met hedge en tree_row, soms ook forest. Tot we het eens worden over een speciale natural=* value voor dit soort opvulgroen. Waar ik heel erg voor zou zijn.

Ik heb gezegd.

Hoi KiaaTix,

Welkom en goed dat je werk maakt van het verbeteren van landuse in de database!
Daar is veel ruimte voor verbetering en het is daarnaast ook dankbaar werk omdat het leidt tot zichtbaar mooiere kaarten :slight_smile:

De proef-import ziet er goed uit, hoewel je inderdaad er niet aan ontkomt om ook andere zaken dan groen aan te passen zoals paden en andere landuses. Uit ervaring kan ik vertellen dat de inpassing met de andere data (conflation) de grootste uitdaging is bij een import en de meeste tijd kost. Maar het is wel nodig om die tijd eraan te besteden, want anders komen er samen met de positieve aspecten van de import gelijk een aantal nieuwe problemen terug (zoals bij een pad waarvan het globale verloop niet zo’n probleem was voordat de landuses waren aangepast zoals hier https://www.openstreetmap.org/?mlat=51.55932&mlon=5.06674#map=19/51.55932/5.06674 ).

Misschien had je het al meegekregen, maar voor imports geldt -terecht- een vrij uitgebreide procedure, om te voorkomen dat er ongelukkige grootschalige dataverschuivingen plaatsvinden. De te nemen stappen zijn omschreven op
https://wiki.openstreetmap.org/wiki/Import/Guidelines

Door de discussie hier op het forum en de positieve reacties ben je al een goed eind op weg, maar het importvoorstel zelf en de databron moeten wel in de wiki worden gedocumenteerd. Daarnaast moet je de imports doen met een aparte account (met achtervoegsel -import) en moeten de changesets ook een tag voor import meekrijgen (type=import).

Als je je daar niet aan houdt, dan kan de Data Working Group je edits terugdraaien en dat is zonde.
Het lijkt me handig als je bij de changeset van je proef-import (in het Engels) een comment toevoegt met de link naar deze forumpagina, de melding dat positief wordt gereageerd en dat je de stappen van de import guidelines volgt voordat je verder gaat met het vervolg.

Bij het opstellen van je importvoorstel kan mijn -vergelijkbare- voorstel voor import van water-data wellicht van pas komen:
https://wiki.openstreetmap.org/wiki/Basisregistratie_Grootschalige_Topografie/Rijnland_polder_water_import

Als ik naar jouw dataset kijk, dan lijkt dit ook te gaan om de data die de bronhouder aanlevert voor de BGT, lijkt me ook handig om dat expliciet te vermelden in je importvoorstel, want er zijn nu op veel meer plekken vergelijkbare bestanden beschikbaar en anderen kunnen daarna voortbouwen op de ervaringen van de imports voor andere brondata van de BGT, zodat we kunnen toewerken naar een meer algemene importvoorstellen waardoor je niet alles elke keer helemaal zelf hoeft uit te werken.

Succes!

Ik ben het eens met Martin.

Heb in mijn eigen omgeving behoorlijk uitgebreid gekeken naar de relatie tussen 3dshapes-vlakken, kadastrale grenzen en de situatie in het veld en heb geen 1-op-1 relaties kunnen ontdekken.

Erven die in het veld 1 geheel zijn kunnen uit meerdere kadastrale percelen bestaan. Omgekeerd kan ook: 1 kadastraal perceel kan in verschillende delen zijn opgedeeld in het veld (bijvoorbeeld bij verpachting aan verschilellende gebruikers). Kadastrale grenzen zijn dus prachtig als overlay, maar niet geschikt voor OSM waar alles in 1 laag zit en het uitgangspunt de situatie in het veld is.

Ook de relatie tussen identieke 3dshapes-vlakken en kadastrale grenzen is niet eenduidig, net zoals de situatie in het veld.

Het meest consequente wat ik in 3dshapes tegenkwam in de polder, was dat een grens tussen twee graspercelen op de plek waar eigenlijk een sloot loopt (de graspercelen grenzen feitelijk niet aan elkaar). Mogelijk het gevolg van gebruik van AHN-achtige data bij genereren van 3dshapes?

De grote hoeveelheid aangrenzende vlakken in de 3maakt het bewerken lastig en zorgt ook voor veel mogelijke fouten (overlap, spleten). Als ze echt identiek zijn (ook in het veld) dan is samenvoegen naar mijn idee een vooruitgang.

Wel is zo’n splitsing aanleiding om nader te kijken wat er aan de hand is, staat er misschien een greppel, hek, of is er een ander verschil dat binnen OSM relevant is?

Dus voordat je voor je import op grote schaal gaat samenvoegen, is het wel goed om door vergelijken van verschillende bronnen en veldwerk wat meer gevoel voor de achtergronden te krijgen.

In het verleden zijn er vaker discussies over het samenvoegen van landuse vlakken geweest.
Er was redelijk wat weerstand tegen.

Zelf ben ik geen voorstander van het samenvoegen van percelen landbouwgrond als ze op de luchtfoto duidelijk als verschillend perceel herkenbaar zijn. Bij het veranderen van de landuse (bv. landbouwgrond wordt boomgaard) is het lastiger om de zaak weer splitsen.
Percelen met dezelfde landuse and die op de luchtfoto herkenbaar zijn als 1 samengevoegd perceel voeg ik wel samen (dezelfde beplanting, tractorspore lopen door).

Eens, als ze in het veld als duidelijke aparte percelen te herkennen zijn, dan is dat een goede reden om ze ook in OSM te splitsen, mijn punt is vooral dat kadastrale scheidingen sec geen reden zijn om ook in OSM een splitsing te behouden. Voor het al dan niet samenvoegen is vooral de vraag in hoeverre het in de context van OSM (en dus ook vaak in het veld) verschillen zijn.

Samenvoegen vind ik wel een goed idee als het echt artefacten zijn van een oude import, zoals de 3dshapes die voor onze context meer nadelen dan voordelen leveren.

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…