Daar valt heel veel onder, zelfs stukken grond waarvan je het niet verwacht. Een begraafplaats in Tilburg-Zuid is ook ‘erf’ volgens de BGT. Niet in OSM gelukkig.
Hoewel er wel enige filtering toegepast lijkt te zijn omdat ik veel ruimte voor achterpaden zie kun je niet zomaar alle stukken erf bij en tussen gebouwen tot tuin bombarderen. Dat is wel gedaan, en daar moet gewoon wat aan gedaan worden.
En van mij mag dat ook onderhand wel een mass delete zijn, als dat nog mogelijk is. En anders wegtaggen. Tenzij de veroorzaker op korte termijn met een plan van aanpak komt om alle foutieve data zelf te corrigeren.
Ik zie dat je dat net hebt toegevoegd. En ik ben het ermee eens.
Korte toelichting:
Het is duidelijk dat de richtlijnen niet zijn gevolgd. Ook is het duidelijk dat de gemeenschap niet echt op deze gegevens zit te wachten. Ik heb het nooit nodig gevonden dat de import door KiaaTix nog verder wordt toegelicht maar die reactie is nu toch gekomen. In die reactie wordt geïnsinueerd dat de gemeenschap de fouten mag gaan verhelpen.
Daar gaat voor mij de deur dicht. Die reactie had beter achterwege kunnen blijven. Als KiaaTix deze tuinen belangrijk vindt dan zou hij zelf allang de fouten eruit hebben gehaald. Ik hoop dat KiaaTix dit onder ogen wil zien want de gemeenschap heeft ieder recht om deze import terug te draaien en onderhand ook iedere reden daartoe.
Geheel mee eens. Ik vind het ook verbijsterend dat hij gewoon stelt dat andere mappers de fouten kunnen gaan verbeteren.
Als je een import doet, dan heb je de zorg om goede data te leveren.
Wat mij betreft, kunnen die tuinen gewoon weg.
Ik kom dit ook regelmatig tegen in Tilburg bij het updaten van BAG panden. Echter in de meeste gevallen komt dit doordat de KRT import actueler is dan de BAG import. In deze gevallen zijn de conflicten te verhelpen door de geometrie van de BAG panden te updaten. Zo zijn er bijvoorbeeld vaak uitsparingen in de KRT tuinen waar de geometrie van een pand na import precies in past.
Dit geldt voor in ieder geval een deel van de conflicten die Marc aanhaalt.
Hoewel je kan stellen dat de situatie niet optimaal is en er misschien meer afstemming moet komen tussen (de invoer van) de verschillende datasets, gaat het mijns inziens te ver om te beweren dat deze conflicten betekenen dat de KRT data van slechte kwaliteit zijn.
Mijn algemene indruk is dat, met uitzondering van de procedurele problemen, de KRT import netjes is uitgevoerd. Ik vind de gegevens van goede kwaliteit zeker, zoals KiaaTix zelf al aangaf, verder van het centrum. Ook vind ik het een goede toevoeging aan osm. Vooral als je bedenkt dat dit in de plek is gekomen van de uit 3dShapes geïmporteerde landuses.
De kwaliteit van de KRT- of BRT-data doet niet eens ter zake en wordt hier volgens mij niet bekritiseerd.
Het gaat om de kwaliteit van de data na afronding van het import-proces.
Zo kan de ‘erf-data’ heel actueel, nauwkeurig en bruikbaar zijn binnen het kader van de BGT, maar OSM heeft een ander kader.
En dan nog is het een incorrecte import geweest, waarbij voor mij alle coulance-lichten nu wel op rood staan.
Met alle respect,
Ik denk dat er hier over het algemeen gezegd is wat er te zeggen valt door alle geïnteresseerden, daar kan iedereen zijn eigen conclusie uit trekken. De draad liep natuurlijk niet zomaar aan zijn (voorlopige?) einde. Tenzij iemand met veranderde inzichten komt lijkt het me niet productief om deze draad ellenlang door te zetten en een discussie te starten over de semantiek van het al dan wel ‘gedogen’ of niet. Wat nu interessant is is de vraag hoe verder te gaan, maar daar kwamen we vorige keer blijkbaar al niet uit.
Ik begrijp werkelijk niet hoe de uitkomst anders kan zijn dan het terugdraaien van de import.
Nog eens de tijdlijn:
Een mapper doet een onreglementaire (want onbesproken en ongedocumenteerde) import.
Mapper wordt hierop gewezen en doet er niets mee.
Nadat de kwestie blijft terugkomen gaat de DWG zich ermee bemoeien.
DWG is coulant en geeft mapper de kans zijn data te redden.
Enkele mappers zijn zelfs zo behulpzaam om alvast wat van het vuile werk voor hem te doen.
Mapper reageert mondjesmaat, komt niet met een plan van aanpak, doet zelf niets met geconstateerde fouten in de data.
Mapper doet dus niets om brede steun te verwerven om zijn data te redden, discussie kantelt logischerwijs naar overwegend negatief.
Hele decembermaand geen reactie en actie meer tot het verstrijken van de gestelde einddatum van de discussie.
Half maart staat de data schijnbaar onaangeroerd nog steeds in OSM.
Je kunt dus blijkbaar speculeren op passiviteit van de gemeenschap en het ontbreken van een volledige consensus tegen je import.
Hoe kun je dan nog verwachten dat mappers die een import in gedachten hebben de moeite gaan nemen om het arbeidsintensieve proces van een aangekondigde en gedocumenteerde import te doen?
Mijn verzoek aan de gemeenschap en de DWG is aldus om een keuze te maken:
of onbesproken en ongedocumenteerde imports blijven verboden en worden in principe teruggedraaid
of imports zijn voortaan gewoon toegestaan zonder procedurele vereisten
Zonder een uitspraak te doen over het al dan niet terugdraaien, is het terugdraaien uberhaupt nog mogelijk en praktisch? Haast alle topografie in Tilburg is inmiddels afkomstig uit deze actie, is het overblijfsel niet van nog veel slechtere kwaliteit na het verwijderen van alle geimporteerde data?
Het onderwerp is nog steeds de import van tuinen (en ‘tuinen’!) in Tilburg.
Dat is wat er al dan niet teruggedraaid zou gaan worden. Lijkt mij nog steeds goed te doen.
En ik ben er nog steeds voor.
Over al het andere - al dan niet gedocumenteerde - importwerk van deze mapper kan ook gesproken worden daarna.
Mooi, dat is duidelijk. Naar mijn inziens kunnen de tuinen relatief probleemloos verwijderd worden d.m.v. een automatische edit mochten we overgaan tot terugdraaien.
Ik stel voor om KiaaTiX een allerlaatste kans te geven om de fouten handmatig op te ruimen, gebeurd dat niet op korte termijn dan kunnen we ook wat mij betreft besluiten om over te gaan op verwijdering van de tuinen.
Ik ben er geruime tijd mee bezig geweest, heb hier reacties gevraagd en gekregen, en ik zal ook zeker binnenkort reageren namens de DWG.
Ik was echter ook enige tijd met andere zaken bezig die belangrijker waren en die niets met OSM van doen hadden, waardoor de “officiële reactie” nog even moest wachten.
=====
**Marc Zoutendijk
OpenStreetMap Foundation
Data Working Group
**
In mijn openingspost in deze discussie, schreef ik:
Vervolgens is de discussie hier, na nogmaals aandringen van mijn kant op 25-11-2019 (#5) op gang gekomen en een vijftiental personen heeft aan die discussie meegedaan.
Ook waren er twee discussies (discussie 1 en discussie 2) waar nog eens zo’n 20 anderen hun stem hebben laten horen, alhoewel dat dus vooral over de wijze van taggen ging en niet over de wenselijkheid/geldigheid daarvan.
Feitelijk hadden al die discussies plaats moeten vinden voordat KiaaTiX aan zijn toevoegingen begon, maar hij heeft zich in de discussie daarna (zowel op het forum als in prive berichten aan mij) nogal op de vlakte gehouden.
Bij een discussie vooraf weet je dat aan het eind een conclusie volgt en dat je dan je plan kunt uitvoeren óf dat je je plan niet kunt uitvoeren in de voorgestelde vorm.
De conclusie van de discussie zoals die hier is gevoerd is niet echt eensluidend en voor iedereen: “nee, zo willen we de tuinen niet op de kaart hebben”, maar voor een aantal deelnemers aan de discussie is duidelijk dat de import niet door had moeten gaan.
Wat stoort in dit hele proces is dat KiaaTiX nogal lichtvoetig over onduidelijkheden en fouten in de import heenstapt met de mededeling dat dat simpel kan worden gerepareerd, maar dat repareren laat hij wel aan anderen over. Ook is hij weinig actief (geweest) in het zoeken naar een oplossing voor dit probleem.
Conclusie: de DWG stelt vast dat deze import niet plaats had mogen vinden. Welke stappen kunnen nu worden genomen?
Een complete revert. Die is niet meer goed mogelijk doordat er teveel tijd is verstreken en er enorm veel conflicten ontstaan met later toegevoegde elementen;
Compleet verwijderen van alle tuinen die door KiaaTiX waren toegevoegd. Technisch gezien was de import correct en is er zorgvuldig gehandeld en blijken bv. overlappingen van tuinen en bebouwing vooral te komen door een achterlopende BAG import. Dit neemt niet weg dat veel tuinen zijn komen te liggen op plaatsen (garage-opritten, binnenplaatsen, parkeerplaatsen e.d.) die niet als tuin kunnen worden aangemerkt. Maar ook deze stap lijkt meer kwaad dan goed te doen en verwijdert veel werk dat - bij betere controle - feitelijk gebruikt had kunnen worden;
Alle tuinen uit de import (leisure=garden en source=KRT Tilburg) worden getagd met not_accepted_import:leisure=garden, overige tags blijven onveranderd. Daarbij zou het mooi zijn als KiaaTiX dat zelf doet, maar uiteraard kan ik dat ook namens de DWG doen.
Deze laatste methode zorgt ervoor dat de *rendering* van het element leissure=garden onzichtbaar wordt maar geeft ons de kans om de tuinen die wel correct zijn opnieuw te retaggen en zichtbaar te maken, maar dat moet dan wel gebeuren op basis van “ground truth” en/of verkenningen, eventueel voorafgegaan door een nieuwe discussie die duidelijk moet leiden tot overeenstemming.
In principe beschouw ik deze discussie nu gesloten en als ik uiterlijk 15 april 2020 geen wezenlijk andere voorstellen heb gehoord (op deze plaats), dan zal ik uit naam van de DWG met mijn account marczoutendijk_mechanical de hierboven (bij punt 3 genoemde) wijziging uitvoeren. Tevens zal ik op de discussiepagina van de wiki een verwijzing naar deze conclusie opnemen.
Omdat deze discussie na 15 april zal zijn gesloten, verzoek ik de moderatoren om dit onderwerp - na die datum - op slot te zetten. Mocht er reden zijn voor een vervolgdiscussie, dan is het zinvoller om daar een nieuw onderwerp/discussie voor te openen.
===== Marc Zoutendijk
OpenStreetMap Foundation
Data Working Group
Ook ik dank Marc voor zijn inspanningen. Uiteraard zijn dit geen leuke klusjes maar wel zeer noodzakelijk en dan is het fijn te merken dat er iemand is die de kar wil trekken. TOP.
Bij deze roep ik allen op om mogelijk ongedocumenteerde import snel te melden. Dan is een revert vaak nog mogelijk. Zo kunnen we voorkomen dat velen energie kwijt zijn aan edits van een mapper die niet in een community kan en/of wil werken.
Methode 3 lijkt me een goede maatregel. Ik wil als suggestie toevoegen om al hetgeen zodanig getagd is en na bv. een jaar nog steeds bestaat, dan alsnog te verwijderen.
Ik ben het met HenkL eens. We moeten dit niet tot in lengte van dagen laten staan. Iedere termijn is discutabel maar het verwijderen na 1 jaar kan ik goed mee leven (als zou het voor mij ook morgen verwijderd mogen worden) .
