Gewoon te doen met luchtfoto’s. Het gaat vooral om binnenplaatsen met parkeerplaatsen of garages.
En ja, je kan blokken als geheel aanpassen. De tuinen zijn grote aaneengesloten vlakken die om de gebouwen heen lopen.
In het voorbeeld van Jeroen is het 3 lijntjes tekenen:
KiaaTiX, goed dat je weer van je laat horen. Helaas stemt je reactie me weinig hoopvol. Het is voor mij de omgekeerde wereld. Ik zal je uitleggen waarom.
Een import is aan regels gebonden. Het is o.a. belangrijk om de gemeenschap te informeren en te overtuigen. Een onbesproken of onjuist uitgevoerde import wordt daarom in principe teruggedraaid. Tenzij… de betreffende mapper de gemeenschap kan overtuigen.
Dan mag wel een extra inspanning worden verwacht van deze mapper. Helaas geef je mij de indruk nog minder moeite te willen doen dan voor een reguliere import nodig zou zijn.
Concrete punten:
Uiteindelijk is door de DWG vastgesteld dat het een import betrof. Het is alsof je het probleem in die vaststelling legt in plaats van je verantwoordelijkheid te nemen en te erkennen dat je had kunnen weten dat het onder import valt.
Je bagatelliseert de omvang van foute data. Dat is in deze fase helemaal niet meer aan jou om te doen! De gevonden fouten zijn niet een kleine opbrengst na een volledige zoektocht maar de eerste resultaten van een kleine steekproef.
“Fouten bestaan nou eenmaal” vind ik echt een misplaatste opmerking. Het was al jouw taak als importeur om zoveel mogelijk fouten te voorkomen en het gaat niet om losse fouten maar fouten voortkomend uit de onbesproken import-aanpak.
Je hebt dus blijkbaar de data na de import onvoldoende gecontroleerd. Er is inmiddels al veel tijd verstreken en er zijn meldingen gedaan van fouten en daar heb je niets mee gedaan.
Nog steeds lees ik geen motivatie en intentie om fouten te herstellen. Geen plan van aanpak. Het is alsof je vrijblijvend je visie geeft op andermans probleem.
Ik hoop dat je je mijn kritiek aantrekt en er alsnog werk van maakt.
Eén vlak voor een hele verzamelingen aanliggende ‘tuinen’ is volgens mij nog niet breed geaccepteerd en stel ik dus in vraag.
Hier nog een willekeurig voorbeeld van foute data.
Een toegangspad en inrit vallen onder een groot vlak ‘leisure=garden’. De inrit heeft tunnel=building_passage maar loopt dus dwars door ‘tuin’ dat overlapt met de contouren van het appartementengebouw Hoefstraat 262-264. De inrit loopt naar een parkeerterrein achter het gebouw dat eerder als node is aangegeven door een andere mapper. Ook foutief onderdeel van het grote ‘tuinvlak’.
Aan de overkant, tussen Hoefstraat 225 en 229, staat tuin ingetekend…
Een stapel fouten binnen een klein gebied na slechts een korte zoektocht. De geschiedenis van het appartementengebouw geeft nota bene een wijziging van zeven dagen geleden door KiaaTiX als onderdeel van een grote wijzigingenset met omschrijving “Nodes die op de randen van vlakken liggen aan die vlakken vastgemaakt, overlappende objecten samengevoegd”.
Niets opgemerkt? 
Er word mij persoonlijk gevraagd om een reactie en dan geef ik die. Dat er een verschil in mening is kan. Dat is verder prima. Ik probeer hier alleen te zeggen dat het belangrijk is dat het totaal plaatje niet vergeten wordt in deze discussie.
Maar ik heb nooit ontkent dat het een import betreft…
Aangrenzende tuinen met dus dezelfde landuse mogen best 1 vlak zijn. OSM hoeft geen kadastrale perceelkaart te zijn.
Dat was een volledig automatische edit geweest in de regio Tilburg met als doel mogelijke problemen in de data oplossen. De vorm van de vlakken is niet gewijzigd. De toegevoegde beschrijving van de edits legt het uit wat er gedaan is.
Dan nu waar het je denk ik eigenlijk om gaat.
De data is wel gecontroleerd. Alleen dicht bij het centrum van de stad zijn plekken waar de kwaliteit wat minder is. Daarbuiten zijn er geen problemen.
Ik sta open voor suggesties maar ik ga niet handelen zonder dat er consensus is binnen de community. Ik heb in de vorige post mijn ideeën een beetje kenbaar gemaakt (aanpassen of anders in z’n geheel verwijderen), maar zoals je al zegt is het niet aan mij alleen om daar nu over te oordelen. Ik wacht daarom de discussie even af.
Voordat je me gaat beschuldigen van dat ik het anderen maar op wil laten lossen: Het is asociaal om iets te importeren als men er vervolgens niet mee kan werken. Daarom ook instructies van hoe iedereen hier zelf dingen aan kan passen. Zodat als je zelf iets ziet wat niet klopt je tenminste de middelen hebt om zelf de kaart aan te passen.
KiaaTiX, ik zou willen voorstellen dat je de plekken waarvan je weet dat de kwaliteit minder goed is zelf ook aanpakt.
Eigenlijk had je dat al kunnen doen bij de datacontrole vind ik, maar beter laat dan nooit.
Ik hoop dat deze discussie positief kan worden voortgezet. Wellicht goed om de gemoederen wat tot rust te laten komen. Welke (senior) communityleden moeten hierover (misschien via een ander medium) een consensus over formuleren? Ik kan Jitsi Meet hiervoor aanbevelen. https://meet.jit.si/ Te gebruiken via webbrowser en hun FOSS app is sinds een week ook in F-Droid beschikbaar.
Je hebt gehandeld alsof het geen import betrof… Begin dit jaar heb je BGT-imports met o.a. de leisure=garden gedaan terwijl je in 2018 al was gewaarschuwd dat imports aan regels zijn gebonden. Zie ook het openingsbericht in dit topic.
De ene Wiki die je had aangemaakt gaat niet over deze import. Ondanks alle tijd die je hebt gehad om gebreken recht te zetten en zo je data te redden constateer ik aldus dat die Wiki en dus de onderbouwing nog altijd ontbreekt.
Dat laatste ben ik op zich met je eens. Al geeft het wel extra informatie en is het in Edinburgh, dat je in een eerder topic als voorbeeld aanhaalde van massa-tuin-import, wel zo gedaan.
Als onderbouwing van ‘waarom heb je al die tuinen toegevoegd’ was je antwoord eerder: “omdat het best relevante geografische informatie is”. Daar zet ik steeds meer vraagtekens bij. Ik ben voorstander van het gebruiken van BGT-info. Ik gebruik het zelf heel veel maar hoofdzakelijk voor uitlijning van zaken die ik ken en heb gecontroleerd.
Wat is dan die ‘best relevante geografische informatie’ die de Erf-vlakken van de BGT verschaffen?
Het geeft privéterrein aan zonder grensafscheiding, eigenlijk kadastervlakken zonder perceelgrenzen. Niet alleen valt ‘bestrate tuin’ zoals een terras onder het vlak, ook opritten en privéparkeerterrein.
Je hebt gehandeld zonder die consensus, dat is het probleem. Dat zou je naar mijn mening actief moeten compenseren, goodwill kweken, in plaats van dat passieve alsof het je allemaal maar aan het overkomen is.
Aanpassen of in z’n geheel verwijderen… dat is geen idee van jou, dat is gewoon een omschrijving van de situatie.
Uit al die passiviteit maak ik op dat je niet hecht aan de data en nooit van plan was om betrouwbare, handmatige controle en correctie op de data toe te passen. Dat had per slot van rekening onmiddellijk na import al moeten gebeuren en het heeft nog maanden geduurd voordat je op deze onbesproken import ben aangesproken.
Ik ben de beroerdste niet maar probeer wel resoluut te zijn in mijn mening betreffende inhoud en aanpak. Ik wilde je de kans geven mij en anderen te overtuigen. Dat zie ik nu niet meer gebeuren. Misschien heb je er nog iets aan als ik een voorbeeld geef van wat ik graag had willen lezen:
“Sorry collega-mappers, ik had deze import nooit zo moeten uitvoeren. Ik had de richtlijnen moeten volgen en met jullie overleggen. Daarnaast heb ik verzuimd om de data voldoende te controleren. Ik ga er meteen mee aan de slag om het recht te zetten. Geef me alsjeblieft wel even de tijd. Ik houd jullie op de hoogte van mijn vorderingen. Ik zal eerst een Wiki aanmaken volgens de regels en omschrijven hoe ik foute data ga repareren. Hopelijk kunnen jullie de import dan achteraf alsnog goedkeuren. Als jullie de import in geen geval meer accepteren dan aanvaard ik het terugdraaien ervan.”
De wiki waar in post #2 naar gelinkt wordt betreft inderdaad niet de tuinen. Of hij is incompleet en zijn ze er niet in opgenomen (maar dat is hij sowieso volgens mij, want ik zie toch echt nog wat tot do)
Wat voor mij een rol speelt en waarom ik tot nu toe gelaten heb gereageerd is dat er geen enkele klacht is gekomen vanuit Tilburg. Men heeft er kennelijk geen probleem mee dat hun stad tot proeftuin is gebombardeerd. Ook heb ik me afgevraagd wat ik zou hebben gedaan wanneer het binnen mijn woonplaats zou zijn uitgevoerd. Wat dit betreft zie ik een meerwaarde in perceelinformatie. Het maakt exact duidelijk (mits goed ingevoerd) welke delen wel en niet publiekelijk toegankelijk zijn en waar de meeste paden en steegjes zijn gesitueerd. Er wordt door sommigen gewezen op delen waar percelen dwars over paden lopen. Wat dat betreft moet ik er van mijn kant op wijzen dat dat in veel gevallen correct zou kunnen zijn. zoals in mijn woonstraat waar onlangs een pad werd afgesloten d.m.v. een bord en inderdaad privé-eigendom blijkt te zijn. Het zou wel mijn voorkeur hebben gehad als de informatie zou zijn ingevoerd als perceelinformatie en niet als tuingegevens.
Wat ik me nog steeds afvraag is wat er nu eigenlijk is ingevoerd. Het zijn geen tuinen want er zitten ook paden bij. Het zijn geen percelen want die zouden niet het hele blok omvatten. Waar het wel mee overeenkomt is landuse=residential maar dan op microniveau. In dat geval is de tagging verkeerd gekozen. Misschien kan KiaaTix dit verhelderen.
Punt 1.
Om me een beeld te vormen van waar knelpunten in de import voorkomen, ben ik zelf op zoek gegaan naar dergelijke zaken.
Ik heb dit onderzocht:
1. leisure=garden toegepast op iets wat duidelijk geen tuin is (garageboxen, parkeerplaatsen)
2. slechte uitlijning van de tuingrenzen waarbij deze over gebouwen heenloopt
Ik heb deze steeds gemerkt met de tags: fixme=import problem
Ik heb maar een klein deel onderzocht (het is zeer arbeidsintensief) ten noorden van het station (de wijk Oud-Noord/Het Goirke) en bovendien maar twee kwadranten in dat gebied.
Mij is opgevallen dat sommigen van jullie al bezig zijn geweest om de “fouten” van KiaaTiX op te lossen. Dat vind ik - in dit stadium - een slechte zaak. Hij heeft ons opgescheept met een flinke berg werk, discussie, ergernis en onduidelijkheden en verwacht hij nu ook dat wij de fouten (die hij had moeten voorkómen) gaan oplossen?
Ik stel voor dat iedereen die fouten in de import tegenkomt hetzelfde doet als wat ik heb gedaan: taggen zoals bovenomschreven.
Ook ik zal daar mee door blijven gaan, maar beschik helaas maar over 24 uur per dag…
Via deze overpass kun je dan snel terugvinden waar er iets niet klopt.
KiaaTiX zelf zou ons dan een dienst bewijzen door genoemde knelpunten zelf op te lossen.
Punt 2.
Ik heb bij aanvang van deze discussie KiaaTiX gevraag naar een wiki. Hij stuurde me toen de wiki die in die link staat. Mij was toen niet opgevallen dat die wiki niet gaat over de tuinimport, want hij schrijft:
Maar in de beschijving van de tags die hij gaat gebruiken komt leisure=garden niet voor.
Ik heb KiaaTiX vandaag verzocht om er toch nog wat meer werk van te maken.
=====
Marc Zoutendijk
**OpenStreetMap Foundation
Data Working Group **
Op de BGTviewer noemen ze het erf (de gele vlakken).
Dat klopt; ik ben al bezig geweest.
Maar ik kwam er snel achter dat het superveel werk wordt.
Op dit moment denk ik zelfs “verwijderen die zooi”.
Wat mij betreft verdwijnen de “tuinen die ook wel parkeerplaatsen, inritten of iets anders kunnen zijn” gewoon van OSM. Ik vind het geen goed idee om alles wat als “erf” in de BGT of KRT te boek staat, in OSM te dumpen als “tuin”. Maar zelfs wanneer er wel een logische vertaling van BGT-begrip naar OSM-tag was, is de procedure voor een import in dit geval compleet genegeerd. Zoals marczoutendijk ook al schreef: ik de wiki-pagina komt het woord garden niet voor, ook *erf *of *tuin *kan ik niet vinden. Zulk gedrag zou ik niet willen belonen met het achteraf alsnog goedkeuren van de import.
Zeker omdat KiaaTiX wist dat er mogelijk sprake was van een import voordat hij eraan begon, vind ik het verwijderen van de geïïmporteerde data niet een te zware maatregel. Als KiaaTiX (of iemand anders) nog steeds vindt dat de data een zinnige toevoeging aan OSM zijn, kan hij altijd alsnog de procedure volgen die voor een import in de wiki wordt beschreven.
Bovendien lijkt KiaaTiX op het vlak van automatische edits ook niet echt zijn leven gebeterd te hebben, als ik de volgende quote serieus moet nemen:
Ik kan niets terug vinden van enige communicatie over deze volledig automatische edit. Om op deze manier de data van een ter discussie staande import te gaan verlijmen aan bestaande gebouwen, roept bij mij ernstige vraagtekens op.
P.S. Gezien de titel van dit draadje is het blijkbaar niet de bedoeling om de import van groen en parkeerplaatsen hier te bespreken?
KiaaTiX heeft inmiddels de wiki uitgebreid met het onderdeel dat de tagging van de tuinen beschrijft.
Inderdaad, met die tuinen is nog een hoop ander groen binnengehaald, maar daarover moet misschien in dit topic van Martin worden gesproken? Zie echter wel de opmerking over parkeerplaatsen van KiaaTiX op de overlegpagina van de wiki.
====
Marc Zoutendijk
OpenStreetMap Foundation
Data Working Group
KiaaTix lijkt nog minder geïnteresseerd dan de rest. Ik ben er klaar mee.
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.
