Het plan is goed, en zeker goed dat je het oppakt, en zelfs uitwerkt.
Maar persoonlijk ben ik geen voorstander van een import in deze.
Zoals al eerder aangegeven door andere(n), kunnen we handmatig zelf goed aan. het zijn er pakweg 600.
Er zijn te veel variabelen die verkeerd kunnen gaan, waardoor het vervuiling gaat worden ipv een verbetering.
Er moet terdege rekening worden gehouden met hetgeen nu al in OSM staat.
Je kunt je bijvoorbeeld voorstellen dat op de al aanwezige node al een shop oid op staat, deze data moet gescreend worden, zodat deze data behouden blijft.
Zoals je weet dient een import te voldoen aan een hele screening, en goedkeurd worden door de Foundation/Import Support Working Group (niet alleen door de Nederlandse community)
De hele discussie hier is in het Nederlands, het gaat om typisch Nederlandse “rustpunten”, dus ik zou dat plan vooral in het Nederlands schrijven en dan een korte toelichting in het Engels erbij doen. Dan bereik je maximaal de doelgroep.
Die zitten er niet meer bij, die zijn al gekontroleerd en, indien vervallen, weggehaald, en indien nog juist, positie handmatig verbeterd. Dus het gaat alleen om nieuwe punten met afgesproken tag-set, en vóór de upload een kontrole of het punt inderdaad bij het juiste adres staat. Zo niet, dan eerst ophelderen iom Rustpunt.nu.
Ik kijk wel eens op de kaart al toerend, waar we iets kunnen drinken, koffie met appeltaart, een icoon is wat het eerst op valt, daar hebben we immers een kaart voor.
Alle, de meeste, van de cafe’s hebben een toiletvoorziening, m.a.w. die cafe is een mogelijkheid.
Kijk ik naar de wiki
(café) is for a generally informal place with sit-down facilities selling beverages and light meals and/or snacks. This includes coffee-shops and tea shops selling perhaps tea, coffee and cakes through to bistros selling meals with alcoholic drinks.
Als daar straks 600 niet echte cafe bijkomen, vele zonder toilet en geregeld maar een enkel bankje.
Verliest het cafe icoon zijn waarde.
Deze niet echte cafe, passen wat omschrijving slecht bij de wiki omschrijving.
Daar over nadenkend heb ik er toch wat moeite mee.
De Rustpunten moeten toiletten bieden, en zitplaatsen voor een gezelschap, en ze verkopen ‘beverages and light meals and or snacks’. Het is allemaal kleinschalig, maar ze voldoen er wel aan, en de organisatie kontroleert erop.
Zeker goed uitgewerkt plan, ik zou wel graag iets willen zien van een (semi-)automatische herimport voor specifieke cases. Als er bijvoorbeeld de eigenaar aangeeft dat een rustpunt ermee stopt dan moet die eigenlijk direct automatisch verwijderd worden. We kunnen natuurlijk alles wel met de hand blijven doen, maar dat is op de lange termijn niet houdbaar en ik denk dat dit een mooie kans is om na te denken over integraties met organisaties/bedrijven over het beheren van alle filialen in OSM. Want als we daar nu niet over na denken zetten we over 10 jaar met achterhaalde POIs.
Ik heb automatisch verwijderen niet opgenomen, daar zitten teveel haken en ogen aan. Bijvoorbeeld, het kan een losse node zijn met alleen de standaard kenmerken eraan, maar het kan op basis van survey ook gemapt zijn als de polygoon van een bouwwerk, met of zonder de aparte voorzieningen die ofwel op de polygoon, ofwel apart als nodes of andere polygonen (shelter, picnic_site, picnic_table, toilet, bin,…) gemapt zijn. En dan kan het nog zijn dat de rustplaats blijft bestaan (bv als picknickplaats, maar alleen niet meer als door die stichting erkend Rustpunt.)
Al bij al is bij automatisch verwijderen het risiko gewoon te groot dat je ten onrechte informatie verwijdert.
Dus dat is nu voorzien als: bij een update van de dataset eerst bekijken welke punten niet meer in de dataset zitten maar wel in OSM, en die eerst goed verifiëren, vervolgens afhankelijk van de bevindingen ofwel alleen de Rustpunt-informatie verwijderen ofwel het hele gebeuren (bahalve als het op een object getagd is wat blijft bestaan).
De punten die al in OSM zitten worden ook niet automatisch bijgewerkt, want in pricipe is wat mappers in het veld tegenkomen en mappen nieuwere informatie. We hebben afgesproken belangrijke wijzigingen terug te koppelen naar de Rustpunt website.
Als laatste heb je dan toegevoegde punten, en daarover gaat het importvoorstel. Als dat eenmaal gebeurd is, zal het daarna periodiek om zo weinig toevoegingen gaan dat we het beste kunnen zeggen “wie gaat daar even kijken” en dan in 1x handmatig en volledig invoeren. We kunnen er ook een JOSM preset voor maken, maar voor mezelf vind ik dat nauwelijks de moeite waard.
Mijn reactie was mogelijk te kort, laat ik het even iets uitgebreider uitleggen. Wat ik hieronder uitleg is niet iets was we zouden moeten doen voor de rustpunten aangezien de hoeveelheid data nog te beheren valt. Maar voor grotere imports zou ik het zo aanpakken:
Je moet het zo zien: Je hebt twee soorten data. Data van de mappers en data vanuit de data source (toegevoegd door de import).
Bij data heb je: aanmaken, lezen, updaten en verwijderen. Om de aangemaakte geïmporteerde data automatisch te kunnen updaten en verwijderen is het cruciaal om de twee soorten data apart te houden. Bijvoorbeeld met een id.
Op het moment dat een mapper een geïmporteerd object aanpast dan moet je vanaf dan het object behandelen als data toegevoegd door de mapper. En dus nooit meer automatisch aanpassen of verwijderen. Het object is dan afgesplitst van de source in niet meer in sync.
Dit kun je doen door bij het importeren ook het versie nummer van het object op te slaan als het nummer niet overeenkomt dan is het object geupdate door een mapper.
Als er een object toegevoegd wordt moet er eerst gekeken worden of dit object al in OSM staat. En mogelijk moet het object dan in sync gebracht worden met de data source en anders laat je het met rust.
Op deze manier voorkom je alle haken en ogen en behoud je het single source of truth principe zonder daarmee de vrijheid van mappers in te perken. En hou de data in sync met de source.
Op het moment dat er een wijziging of verwijdering is van een object die niet meer in beheer is van de datasource of het object is niet in sync met de datasource. Dan kan je een notitie plaatsen bij het object.
Om de bovenstaande strategie foutloos uit te kunnen voeren heb je eigenlijk een laag tussen de data source en de eindbestemming nodig. (En bijbehorende integratie SDK) Daar moet je dan de osm id + version koppelen met het id van de data source. Zo kan je bijvoorbeeld een delay toevoegen en de mechanische edits reviewen en objecten toevoegen aan de set van beheerde objecten.
Ik ben het grotendeels met je eens, tegelijk denk ik dat de rustpunten-casus laat zien hoeveel haken en ogen er aanzitten. Ook interessant is de methodiek die Friso Smits in een tool gegoten heeft, Update knooppunten tool , die in feite hetzelfde probleem aanpakt. Misschien dat we deze diskussie -die natuurlijk al eerder gevoerd is, maar altijd aktueel blijft- apart moeten voeren.
Vooralsnog denk ik dat wb de rustpunten best veel van jouw gedachten aan de orde zijn geweest, bijvoorbeeld het koppelen dmv een unieke sleutel, detekteren van al bestaande objecten en bepalen wat je daarme doet, detekteren van objecten die uit de source wegzijn en bepalen wat je daarmee doet. En: hoe gaat het verder na de eerste import, hoe verifieren we het en wat doen we met latere mutaties.
Deze koppeling kun je eenvoudiger maken zonder externe database, namelijk door het id van de data source als tag op de OSM-changeset te specificeren. Dan kun je in OSM altijd achterhalen wat de laatste import was en wat de wijzigingen sinds de laatste import zijn.
In de jit.si ontmoeting vanmorgen zijn geen nieuwe punten ingebracht, dus we gaan ervoor!
Ik zal een wiki maken zoals dat hoort bij een import.
Voor de indeling per provincie heb ik een intekenlijstje gemaakt. Het staat in Het Dokument. Als het goed s kan iedereen daarin nu wijzigen, en het verzoek is om als je mee wil werken, zelf je naam achter de provincie(s) te zetten.
Wat er verwacht wordt:
de Rustpunten voor jouw provincie inlezen in JOSM
Een snelle kontrole of ze allemaal dicht genoeg bij het juiste adres staan (tot ca 30m); zo niet, schuiven tot het wél in de buurt is (exacte lokatie is voor de latere surveyronde)
Tagging aanpassen voor zover dat niet al in het geïmporteerde bestand geregeld was
Uploaden onder vermelding van de wikipagina (die ik nog moet maken, maar dat komt goed)
Inschatten hoeveel survey er op de weg nodig gaat zijn, en wat er vanuit de leunstoel goed genoeg is.
Na de import komt de survey voor de detaillering en de exakte positie (tot ca 6m). Daar moeten we nog over overleggen hoe we de voortgang erin houden.
@emvee ik stuur je even een PB, want ik merk dat ik wel erg gemakkelijk heb aangenomen dat jij van alles kan leveren…
Voor mij is self_service=yes, dat je zowel bediend kan worden als het zelf doen.
Bijv. bij AhtoGo kun je je aan de kassa laten helpen, maar je kunt ook dingen zelf pakken en zelf scannen.
De gewone supermarkt heeft vaak zelfscannen en ook nog kassa’s.
Dus self_service=yes in zo’n geval.
Bij self_service=only is het alleen mogelijk om je zelf te helpen. Je moet alles zelf doen.
Bijv. een AhtoGo met alleen zelf scannen, een automatisch tankstation.
Raar, ik wist toch zeker dat ik het goed gedaan had… zo zie je maar. Toch even de wiki nagekeken:
“In case a feature is part of a brand/chain, brand:website=* can be used to specify the general website for the whole brand” Aangepast!
