Het toevoegen van gemeentelijk groen.

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…

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.