DWG: Tuinimport in Tilburg

De Data Working Group (DWG) volgt al enige tijd de forumdiscussie over ‘Het toevoegen van gemeentelijk groen’ die door KiaatiX is gestart op 13-5-2018 en de discussie 'leisure=garden voor privé voor- en achter “tuinen” ’ die door PeeWee32 is gestart op 30-6-2019.
In mijn verdere tekst noem ik de eerste discussie A, de tweede B en de reactienummers binnen die discussies geef ik aan met een #.

In deze discussies draait het (vooral) om twee zaken:

  1. hoe dient een privétuin te worden getagd?

  2. is hier sprake van een import en is deze besproken in de NL OSM gemeenschap?

Punt 1 is ook op andere kanalen (tagging lijst bv.) uitvoerig besproken en daarbij zijn zeker, lokale, verschillen waar te nemen. Op dat punt wil ik hier niet verder ingaan, de DWG ziet geen grote problemen in het gebruik van leisure=garden voor het genoemde doel, maar als een ander taggingschema de voorkeur heeft, dan kan dat (ook weer ná goedkeuring van de gemeenschap) natuurlijk worden gebruikt.

Punt 2, is er sprake van een import?.
In de ogen van de DWG is dat inderdaad het geval omdat de data die door KiaaTiX is gebruikt, afkomstig is van externe bronnen (zoals hijzelf in reacties A#8 en B#117 al aangeeft) en niet doordat hij visueel op inspectie langs alle Tilburgse tuinen is gegaan of doordat hij vanaf het PDOK beeldmateriaal die tuinen heeft ingetekend. Hij voegt bovendien zelf al de tag source=KRT Tilburg toe.
Er zijn veel positieve reacties te lezen op zijn import, maar ook waarschuwingen en voorbeelden van wat je zou moeten doen, zoals in A#11.

KiaaTiX schrijft zelf in A#17:

en ook:

Ook reactie A#18 maakt duidelijk dat het hier wel degelijk een import betreft.

De wiki waarover hij hier spreekt is volgens de DWG niet aangemaakt en de daaruit voortvloeiende discussie is ook niet gevoerd, behalve datgene wat er in de twee genoemde forumdiscussies langs is gekomen, maar die gingen voornamelijk over de wijze van taggen. Bovendien liepen in deze discussies ook verschillende zaken door elkaar heen.

De bedoeling van die wiki en de discussie is, dat andere mappers leren hoe ze soortgelijke imports aan kunnen pakken. KiaaTiX schrijft in A#17:

De DWG denkt dat er inderdaad meer mappers deze software zouden willen gaan gebruiken, maar daarbij is medewerking van KiaaTiX wel nodig. Op de eerste plaats aan het goed documenteren in een wiki, en op de tweede plaats door in de daaropvolgende forumdiscussie actief mee te doen maar ook open te staan voor ideeën van anderen.

De DWG is het ook opgevallen dat KiaaTiX (maar nu vanaf account KiaaTiX_BGT) bezig is met een import van Spoor landuse. De DWG neemt aan dat hij hierbij dezelfde werkwijze hanteert als bij de tuin-import en dat betekent dus ook dat hierbij niet volgens de regels te werk is gegaan! Ook hier zou een wiki (met beschrijving) en een discussie de juiste volgorde zijn geweest en de DWG verzoekt KiaaTiX_BGT dan ook om daar eerst werk van te maken voordat hij verder gaat met deze import.

Wat moet er nu gebeuren?

Hopelijk reageert KiaaTiX en kan de discussie over de wenselijkheid en bruikbaarheid van deze import hier plaatsvinden.
Die discussie dient ook alleen maar te gaan over dat gedeelte, niet over de manier waarop tuinen dienen te worden getagd.
KiaaTiX heeft zelf al aangegeven:

Maar dat sluit niet uit dat anderen ook op deze wijze tuinen zouden willen importeren (of andere data, afkomstig van soortgelijke en toegestane bronnen) waar de software-tools van KiaaTiX van pas kunnen komen.

En als KiaaTiX niet reageert?
Dat zou op de eerste plaats heel erg jammer zijn, want hij is een goede mapper die een uitstekende plugin voor JOSM heeft geschreven en zijn bijdragen aan de kaart zijn verder uitstekend en nauwgezet gedaan.
Maar reageert hij inderdaad niet, dan kunnen de overblijvende deelnemers een standpunt innemen (na discussie hier) en als de uitkomst daarvan is dat deze import moet worden teruggedraaid dan zou dat moeten gebeuren. Een revert is waarschijnlijk niet meer mogelijk zonder veel andere schade aan te richten, maar een tussenoplossing zou bv zijn dat (vanuit de DWG) alle door KiaaTiX aangebrachte “leisure=garden” tags worden vervangen door “non-discussed-import:leisure=garden”. Daarmee verwijnt de rendering van die tuinen, maar blijven de overige tags gehandhaafd. Mocht op een later tijdstip alsnog worden besloten dat deze import wel is toegestaan, dan is het een simpele operatie om die tuinen weer terug te krijgen.

De DWG staat ook open voor suggesties uit de gemeenschap hoe deze kwestie het beste kan worden opgelost. Indien dat zo is, dan hoor ik die ook graag hier.
Ik draai lang genoeg mee op dit forum om te weten hoe het soms gaat, en ik wil geen druk op de ketel, maar ik wil ook geen discussie van een half jaar. Ik stel voor dat we proberen om uiterlijk 31 december 2019 tot een - voor allen acceptabele - uitkomst te komen.
Ik verzoek ook alle deelnemers om zich strikt aan de opdracht te houden: blijf bij het thema! Als zich een situatie aandient waarbij een nieuw onderwerp noodzakelijk lijkt, start dan een nieuw topic en verwijs daar naar.

Ik hoop op een gezonde discussie en een werkbare oplossing!

=====
Voor alle duidelijkheid over “welke pet” ik op heb: als ik namens de DWG schrijf, staat er altijd onderstaande ondertekening. Schrijf ik als privépersoon dan doe ik dat op de wijze zoals ik altijd post op dit forum.

Marc Zoutendijk
OpenStreetMap Foundation
Data Working Group

KiaaTiX heeft naar mij persoonlijk gereageerd.

Er is inmiddels een (nog niet volledige) wiki beschikbaar over de gevolgde werkwijze, en die staat hier:

https://wiki.openstreetmap.org/wiki/Kernregistratie_Topografie_Tilburg_/_Landuse_import

=====
Marc Zoutendijk
OpenStreetMap Foundation
Data Working Group

Klinkt in ieder geval positief

Ik vraag me af wat we willen horen van KiaaTiX. Het is duidelijk dat de procedures niet zijn gevolgd en dat er geen overleg heeft plaatsgevonden. Kernvraag is volgens mij of de gegevens goed genoeg zijn.

Er is nog niet heel veel reactie gekomen.
Ik heb ook op talk-NL een bericht achtergelaten met een verwijzing naar mijn oorspronkelijke bericht hier.
Klaarblijkelijk zijn er maar weinig mensen die het interesseert.

Moet de DWG dit beschouwen als “wie zwijgt stemt toe”?

=====
Marc Zoutendijk
OpenStreetMap Foundation
Data Working Group


edit: typo.

Mij interesseert vooral het eindresultaat. Als de aangebrachte tagging aanvaardbaar is (ik weet niet of er konsensus was, of tegegengeluiden maar niet zodanig dat het afgekeurd moet worden) dan is het MI geen goed idee om alles rucksichtslos terug te draaien.

  • Als het meeste goed is maar er zitten veel willekeurige fouten bij, dan is correctie aangewezen: alles individueel nalopen en ev. verbeteren. De door DWG voorgestelde tagging lijkt me dan handig: alles waar de tag nog aanzit moet nog beoordeeld worden.
  • Als er vooral systematische fouten inzitten, dan zou selectieve DWG-tagging van de voorkomens van deze systematische fout het beste zijn.

Het zou mooi zijn als er met de betreffende mapper een afspraak over kan worden gemaakt. Wat moet het worden, welke fouten zitten erin, wie gaat (helpen met) nalopen en wie gaat (helpen met) verbeteren. En een plan dat regelt wanneer het klaar gaat zijn.

Uit het gehele gebeuren kan dan een les getrokken worden voor eventuele toekomstige projekten, al dan niet met behulp van de betreffende tools.

Het viel me op dat de parkeervlakken in Tilburg met de verkeerde tag getagged zijn. Ik heb dit op de overlegpagina toegelicht.

Dat er geen reacties komen, kan ik wel begrijpen.
Het algemeen gevoel zal zijn: laat maar staan, het hindert mij niet.

Het is een vorm van micro-mapping waar velen niet geïnteresseerd in zijn.
Bij het maken van een kaart is het ook het eerste wat niet meer zichtbaar zal zijn.

Het is dus alleen interessant voor iemand die een klein gebied op grote schaal wil maken.
Bijvoorbeeld: een gemeentelijke kaart waarop alle waardevolle bomen staan aangegegeven.
En dan nog zal het hem niet interesseren of dat perceel is bestraat of beplant.

De aanname “wie zwijgt, stemt toe” lijkt mij alleszins redelijk.

Ik heb aan de eerdere discussies niets bijgedragen vanwege andere verplichtingen destijds, maar wat opvalt in Tilburg is dat daar waar nu leisure=garden gebruikt wordt eigenlijk sprake is van landuse=residential (of landuse=garages als je nog nauwkeuriger wil zijn bij dit specifieke voorbeeld).

Ik kan me niet voorstellen dat dit achterstraatje voor garages door een tuin loopt. (Google streetview toont beton)

Qua importgeschiktheid bekruipt mij de neiging om te pleiten voor uitsluitend niet-automatische imports. Dus: steeds in JOSM een stukje van de geautomatiseerd gegenereerde ways openen, en per huizenblok of buurtje ze nalopen en uploaden indien geschikt.

Over hoe om te gaan met de reeds gedane imports heb ik geen uitgesproken mening.

Voor spoor-landuse zou ik zelf ook semi-automatisch te werk gaan: de landuse-vlakken genereren op basis van open data is prima, maar ik zou ze stuk voor stuk door de handen willen hebben in JOSM voor ik ze per redelijk afgebakend gebied (wijk of spoorbaanvak) upload.

Als iemand dat in “mijn” stad zou doen zou ik er een probleem mee hebben vanwege de rücksichtlose bombardering van alles dat privégrond is tot tuin, die het in veel gevallen niet is.
Maar ik woon niet in Tilburg en denk daarom inderdaad “laat maar”.

edit: Jeroen laat een mooi voorbeeld zien hierboven :slight_smile: 70 meter noordelijk hiervan exact hetzelfde.

Puur qua kaartbeleving vind ik het niet per se lelijk trouwens. Het is een beetje op het randje of elke ruimte om een woonhuis ook daadwerkelijk een ‘tuin’ te noemen valt, maar dat is qua tagging wel verdedigbaar. Voorwaarde voor mij is wel dat ook alleen echt de percelen die overduidelijk ‘tuin’ (tegenwoordig vaak enkel tegels…) als functie hebben zo getagged zijn. Aan de andere hand; er mag heus wel een bepaalt percentage fout zijn als het leeuwendeel van de data klopt.

In het hoekje van Tilburg hierboven is nogal wat bedrijvigheid waardoor schat ik ongeveer 50 % fout is.

Hier in een nieuwbouwwijk diverse BGT-import’s van KiaaTiX c.q. KiaaTiX_BGT: https://osm.org/go/0EvwGhB9p–?layers=N&m=
Ik kan het ook niet echt lelijk vinden.
Wel ook de nodige amenity=parking_space bij de woningen. Dat zou dus niet goed zijn?
Worden ook veel area’s geïntroduceerd.

Volgens de gangbare definitie van amenity=parking_space niet. Die is voor een enkele parkeerplaats binnen een parkeergebied (amenity=parking) waar één voertuig parkeren kan (zo dus).

Het moet amenity=parking zijn in deze import.

: het gaat hier puur om de tuinen in Tilburg, niet het andere importwerk van KiaaTiX(_BGT).

Ik zie dat ik in dit topic nog niet had gereageerd, wel in de eerdere topics. Ik verwijs naar dit bericht van mij in oktober en nogmaals dit bericht van september met voorbeelden van foute data.

Dit laatste zou dan voor KiaaTiX gelden die niet van zich laat horen.
Ik quote uit het openingsbericht:

Dat standpunt neem ik inderdaad in. Behalve naar jou persoonlijk, Marc, zie ik geen verdere reactie van hem naar de gemeenschap toe. Die reactie was dan een maand na zijn laatste aanpassing aan de import-wiki waaraan sindsdien niets meer is gedaan.

Ja, ik zou er ook meer bovenop zitten als het in mijn regio was. Ik vrees wel precedentwerking. Het is niet ondenkbaar dat binnenkort een andere mapper Tilburg als voorbeeld neemt en keurig het advies volgt van ‘kijk hoe andere mappers het doen’.

Er zit nu gewoon veel foute data in OSM te Tilburg.

Ik heb geen idee wat de reden is voor het ontwijkende gedrag van KiaaTiX maar zeker zolang hij niet reageert ligt de verantwoordelijkheid voor het probleem volledig bij hem.

Omdat er door Marc Zoutendijk namens de DWG nadrukkelijk om een reactie gevraagd wordt bij deze die van mij - zonder dat ik de eerdere discussies gevolgd heb.

  • Als ik nu Tilburg bekijk op osm.org geeft het kaartbeeld daar naar mijn mening geen goed beeld van het terrein. Zelfs op zoomlevel 13 hangt er een groen “waas” over de stad, alsof het een bungalowpark of zoiets is. Aan de andere kant “niet taggen voor de renderer” betekent ook “niet niet taggen voor de renderer”, en de tiles van osm.org moeten niet maatgevend zijn.
  • Ik vraag me af wie controle en onderhoud gaat doen.
  • De import voegt volgens mij weinig waardevols toe. Het is alleen bruikbaar voor Tilburg, en het verrijkte kaartbeeld is volgens mij even goed met een mashup te reproduceren. Het lijkt een import meer gebaseerd op “omdat het kan” dan op het nut (voor de gemeenschap). Heeft degene die de import heeft gedaan ooit de meerwaarde benoemd?

En meer in het algemeen:

  • Ik heb het gevoel dat ik steeds meer imports of massale overnames zie van informatie uit de BGT en soortgelijke bronnen, en vraag me af of dat een goede ontwikkeling is… Heb daar zelf (nog) geen mening over maar denk dat het goed is er controle over te houden door te verlangen dat men zich aan de importrichtlijnen houdt.

Al met al heb ik er weinig moeite mee als de DWG deze import zou “wegtaggen”.

Ik heb andermaal KiaaTiX uitgenodigd om hier zijn stem te laten horen.
In de bijdragen hierboven worden voldoende vragen opgeworpen waarop hij een antwoord zou moeten geven.

=====
Marc Zoutendijk
**OpenStreetMap Foundation
Data Working Group
**

Over de wiki pagina:

Deze heb ik vorig jaar zomer aangemaakt (volgende week anderhalf jaar oud). Het is, zover ik het zie inmiddels up to date. De import is inmiddels afgerond en er zal ook niks meer uit die dataset geïmporteerd worden.

Voor de BGT zal een andere wiki pagina aangemaakt moeten worden. Andere import met andere databron. Die bestaat nog niet maar dat heeft geen invloed op de huidige situatie in Tilburg.

Over kwaliteit van de tuinen:

Laat ik eerst maar beginnen met het feit dat geen enkele kaart dataset zal ooit compleet of volledig correct zal zijn. Fouten bestaan nou eenmaal. Op enkele plekken, vooral in het oudere gedeelte van de stad, klopt het niet helemaal. Nieuwbouw zoals Reeshof klopt daarentegen wel.

Geïmporteerde tuinen kunnen makkelijk aangepast worden. De polygoncutout plugin die ik ooit gemaakt heeft een split object functie die hetzelfde werkt als die van de utils2 plugin Maar dan werkt deze wel met multipolygonen. Het is allemaal relatief makkelijk aan te passen, maar het moet wat nagelopen worden wat tijd kost.

Aanpassen lijkt me praktischer dan het wegtaggen. Dan blijft het er maar staan en kan je ze beter in z’n geheel verwijderen.

Dit zijn denk ik voor nu wel de belangrijkste dingen. Als er meer dingen zijn moet het maar even aangegeven worden. Dan wil ik daar ook wel antwoord op geven.

@KiaaTiX
Om hoeveel te kontroleren objecten gaat het eigenlijk?
Nalopen, moet ik dat letterlijk nemen? Of is het meeste mbv luchtfoto’s te kontroleren en te verbeteren?
Is het tuintje voor tuintje of kan je hele blokken tegelijk aanpassen?

@Allen
Ik kan me een samenwerking op basis van hulptags voorstellen waarbij

  1. Alle geïmporteerde objecten een “Te controleren” tag krijgen (dat kan ook een DWG-stempeltag zijn)
  2. Kontroleurs bijtaggen (fixme note?) of en wat er moet gebeuren; indien niets, dan kan de hulptag weg.
  3. Handige aanpassers de aangegeven dingen uitvoeren en daarna de hulptags verwijderen.

Dit vraagt wel overeenstemming over hoe uiteindelijk de objecten getagd moeten worden afhankelijk van wat het op de weg is en/of wat de viewer toont.