DWG: Tuinimport in Tilburg

Pander · 2019-11-27 07:44:21

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.

AndriesWijma · 2019-11-27 21:49:42

KiaaTiX wrote:

Maar ik heb nooit ontkent dat het een import betreft...

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.

KiaaTiX wrote:

Aangrenzende tuinen met dus dezelfde landuse mogen best 1 vlak zijn. OSM hoeft geen kadastrale perceelkaart te zijn.

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.

KiaaTiX wrote:

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.

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."

Jillis Eikelenboom · 2019-11-28 07:27:15

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)

goedegazelle · 2019-11-28 08:59:37

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.

Last edited by goedegazelle (2019-11-28 09:23:43)

goedegazelle · 2019-11-28 09:39:19

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.

Last edited by goedegazelle (2019-11-28 09:39:47)

marczoutendijk · 2019-11-28 13:47:18

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.

Jillis Eikelenboom wrote:

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

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:

wiki wrote:

The main goal is:
- Acurately map landuse for the city.

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

Kogacarlo · 2019-11-28 17:26:21

goedegazelle wrote:

Wat ik me nog steeds afvraag is wat er nu eigenlijk is ingevoerd.

Op de BGTviewer noemen ze het erf (de gele vlakken).

marczoutendijk wrote:

sommigen van jullie al bezig zijn geweest

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".

alphensebezorger · 2019-11-28 19:17:48

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:

KiaaTiX wrote:

AndriesWijma wrote:
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? neutral
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.

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?

marczoutendijk · 2019-11-28 20:22:21

marczoutendijk wrote:

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.

KiaaTiX heeft inmiddels de wiki uitgebreid met het onderdeel dat de tagging van de tuinen beschrijft.

alphensebezorger wrote:

P.S. Gezien de titel van dit draadje is het blijkbaar niet de bedoeling om de import van groen en parkeerplaatsen hier te bespreken?

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

goedegazelle · 2019-11-29 11:32:12

KiaaTix lijkt nog minder geïnteresseerd dan de rest. Ik ben er klaar mee.

Jillis Eikelenboom · 2019-11-29 12:02:33

Kogacarlo wrote:

goedegazelle wrote:
Wat ik me nog steeds afvraag is wat er nu eigenlijk is ingevoerd.
Op de BGTviewer noemen ze het erf (de gele vlakken).

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.

Last edited by Jillis Eikelenboom (2019-11-29 12:22:48)

goedegazelle · 2019-11-29 12:17:06

Jillis Eikelenboom wrote:

En van mij mag dat ook onderhand wel een mass delete zijn.

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.

dvdhoven · 2019-11-29 12:43:03

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.

de vries · 2019-11-29 13:23:33

marczoutendijk wrote:

Ik heb dit onderzocht:
1.[...]
2. slechte uitlijning van de tuingrenzen waarbij deze over gebouwen heenloopt

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.

AndriesWijma · 2019-11-29 18:33:56

de vries wrote:

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.

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.

de vries · 2019-11-29 22:26:23

AndriesWijma wrote:

de vries wrote:
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.
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.

Uiteraard bedoel ik hier ook de KRT data zoals deze momenteel op osm staat.

AndriesWijma · 2020-03-17 22:08:56

Conclusie: onbesproken imports worden gedoogd.

Ninjoh · 2020-03-18 00:33:31

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.

Last edited by Ninjoh (2020-03-18 01:16:44)

Jillis Eikelenboom · 2020-03-18 06:18:52

marczoutendijk wrote:

Ik stel voor dat we proberen om uiterlijk 31 december 2019 tot een - voor allen acceptabele - uitkomst te komen

Voorstel heeft t niet gehaald inderdaad. Althans, er is niks besloten of gedaan volgens mij.

Last edited by Jillis Eikelenboom (2020-03-18 15:40:18)

AndriesWijma · 2020-03-18 14:40:29

@Ninjoh

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

Ninjoh · 2020-03-18 15:08:11

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?

Jillis Eikelenboom · 2020-03-18 15:37:44

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.

Last edited by Jillis Eikelenboom (2020-03-18 15:43:08)

Ninjoh · 2020-03-18 16:59:02

Jillis Eikelenboom wrote:

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.

marczoutendijk · 2020-03-19 16:17:41

AndriesWijma wrote:

Conclusie: onbesproken imports worden gedoogd.

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

marczoutendijk · 2020-03-31 10:44:50

In mijn openingspost in deze discussie, schreef ik:

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.

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

Announcement

#26 2019-11-27 07:44:21

Re: DWG: Tuinimport in Tilburg

#27 2019-11-27 21:49:42

Re: DWG: Tuinimport in Tilburg

#28 2019-11-28 07:27:15

Re: DWG: Tuinimport in Tilburg

#29 2019-11-28 08:59:37

Re: DWG: Tuinimport in Tilburg

#30 2019-11-28 09:39:19

Re: DWG: Tuinimport in Tilburg

#31 2019-11-28 13:47:18

Re: DWG: Tuinimport in Tilburg

#32 2019-11-28 17:26:21

Re: DWG: Tuinimport in Tilburg

#33 2019-11-28 19:17:48

Re: DWG: Tuinimport in Tilburg

#34 2019-11-28 20:22:21

Re: DWG: Tuinimport in Tilburg

#35 2019-11-29 11:32:12

Re: DWG: Tuinimport in Tilburg

#36 2019-11-29 12:02:33

Re: DWG: Tuinimport in Tilburg

#37 2019-11-29 12:17:06

Re: DWG: Tuinimport in Tilburg

#38 2019-11-29 12:43:03

Re: DWG: Tuinimport in Tilburg

#39 2019-11-29 13:23:33

Re: DWG: Tuinimport in Tilburg

#40 2019-11-29 18:33:56

Re: DWG: Tuinimport in Tilburg

#41 2019-11-29 22:26:23

Re: DWG: Tuinimport in Tilburg

#42 2020-03-17 22:08:56

Re: DWG: Tuinimport in Tilburg

#43 2020-03-18 00:33:31

Re: DWG: Tuinimport in Tilburg

#44 2020-03-18 06:18:52

Re: DWG: Tuinimport in Tilburg

#45 2020-03-18 14:40:29

Re: DWG: Tuinimport in Tilburg

#46 2020-03-18 15:08:11

Re: DWG: Tuinimport in Tilburg

#47 2020-03-18 15:37:44

Re: DWG: Tuinimport in Tilburg

#48 2020-03-18 16:59:02

Re: DWG: Tuinimport in Tilburg

#49 2020-03-19 16:17:41

Re: DWG: Tuinimport in Tilburg

#50 2020-03-31 10:44:50

Re: DWG: Tuinimport in Tilburg

Board footer