Fred: "Heb de laatste: weideterras Kotters -een van de grootste afwijkingen- alvast gecorrigeerd op onze website, apps en planners.
Wat jullie OSM aangaf: klopte. Wij hadden de locatie op de oude plek staan, van de vorige bewoners en vlakbij het woonhuis…
Fred zal er volgende week mee verdergaan.
Ik kan me er zeker in vinden wat je bedoelt te zeggen.
Ook ik zit een beetje met dat dilemma.
Maar…
Is het een optie om ze allebei te taggen, zowel:
amenity=cafe als, tourism=picnic_site.
Battle of the icons…
Dat betwijfel ik, waarom?
De gebruikelijke tag voor een rustpunt was ingeburgerd (destijds consensus) als amenity=cafe
Maar omdat er inmiddels meer dan 600 rustpunt.nu locaties zijn, en ik zag dat maar een fractie van deze rustpunten in OSM waren opgenomen, vond ik het tijd voor een nieuwe discussie, met wellicht voortschrijdende inzichten.
Het zou natuurlijk ook als volgt kunnen:
Tag de ruimte als amenity=cafe (als node)
Tag de buitenplaats/terras als tourism=picnic_site (als polygon)
Tag de picknicktafels op de plekken waar ze staan.
Tag de toilet locatie
Tag de speeltuin
Vandaar dat ik open sta om beide te taggen.
De discussie lijkt nu te gaan over wat we op de kaart zien: een koffiekopje of een picnic tafel.
Ik kan het standpunt van Dick goed begrijpen, maar heb bv. zelf voorgesteld om juist niet amenity=cafe te taggen, om de simple reden dat het geen cafe is zoals dat in de wiki staat beschreven.
Daarbij vergeten we misschien dat de beschrijving van wat in de wiki staat over een cafe, misschien wel in Europa een duidelijk begrip is, maar dat er talloze landen zijn waar dat hele begrip totaal niet geldt, terwijl er in die landen wel degelijk plekken zijn waar je informeel iets (koffie?) kunt drinken.
Er bestaat nu eenmaal geen tag die wereldwijd precies dekt wat in de wiki staat. Altijd zullen er lokale verschillen zijn. (Wegen die bij ons als highway=track worden aangemerkt zijn elders highway=secondary).
En we vergeten iets belangrijks:
De wiki geeft niet aan wat we moeten doen, nee, de wiki geeft aan wat we tot nu toe gedaan hebben.
Als vanaf vandaag alle mappers in Nederland amenity=cafe gaan gebruiken voor de rustpunt locaties, iets waar ze het volste recht toe hebben, dan zullen we dat moeten accepteren, en in ieder geval in de nederlandse versie van de wiki moeten documenteren.
OSM kent minimaal 2 belangrijke grondregels:
Daarmee zijn we vrij om te kiezen voor tags die duidelijk op de kaart laten zien wat er kan (koffie drinken), terwijl datzelfde icoontje in in ander land iets anders betekent.
Het idee dat OSM een internationaal geaccepteerde verzameling van uniforme tags zou kennen, is volledig achterhaald.
Het is, zoals commodoortje ook voorstelt, mogelijk om beide tags te gebruiken, maar zeker niet op alle plaatsen. Daarom is een import ook uit den boze, want er zijn teveel verschillen tussen de diverse rustpunten.
Waar staan we nu?
Ikzelf heb 54 rustpunten gecontroleerd en van de juiste website=* tag voorzien.Op 2 plaatsen heb ik de overige tags geplaatst die mij relevant leken en bij de andere locaties heb ik alles gelaten zoals het was.
Ik ga nu geen tijd meer besteden aan hoe we het met de andere 568 andere rustpunten moeten doen.
Mijn suggestie: als je er een tegenkomt zet hem dan op de kaart!
In dat geval stel ik voor om het opbouwend te doen, zoals ook op de weg mapping vaak van simpel en snel naar verder gedetailleerd gebeurt.
De simpelste vorm is dan een node die het gehele rustpunt vertegenwoordigt, met name het buitenzitje en de ‘bar’, dus zowel tourism-picnic_site als amenity=cafe, plus de naam. Met self_service=yes geef je aan dat het zelfbediening is. Latere mappers mogen er ter verfijning losse tafels, toilet, infoborden, afvalcontainers, waterpunten, en andere aanwezige voorzieningen (oplaadpaal?) als nodes bijzetten, dat kan nu ook.
Nadere detaillering op basis van survey kan zijn: polygoon met picnic_area en daarnaast of daarin een punt of polygoon met amenity=cafe en self_service=yes.
De basis: een node met zowel cafe als picnic_area bevat juiste en voldoende informatie, dus daar kan je een import op baseren. De voornaamste zorg is de geolokatie. De lokatie is niet 100% betrouwbaar, dat betekent dat je zeker moet nacontroleren. Gezien de betrouwbaarheid en direkte bereikbaarheid van de beheerder en de site en vooral de gedrevenheid die rustpunt.nu toont om alles goed te krijgen, denk ik dat dit in de meeste gevallen zonder survey goed opgelost kan worden. Dan vind ik nog steeds survey nodig, maar dat kan dan aangepakt worden bv per provincie op verzoek door de aldaar wonende mappers. Een streetcomplete challenge kan ook, gebaseerd op een kenmerk wat we bij import zetten (fixme=survey_rustpunt of zo. Na survey te vervangen door survey:date=…).
Een mogelijkheid is om eerst onzichtbaar toe te voegen, door bv proposed: voor de hoofdtags te zetten. Na eerste verificatie op bestaan en lokatie (zeg tot op 30 meter nauwkeurig, dat kan je met viewers en de foto’s en de lokatie op de website meestal wel zien, in ieder geval kan je het op het erf van het adres schuiven) kan de proposed: eraf.
Wat er daarna nog proposed: heeft kunnen we met rustpunt.nu overleggen, dat zal ergens een fout hebben die zij kunnen corrigeren.
Het alternatief, overlaten aan toevallige mappers, staat garant voor permanent onvolledige en onvoorspelbaar wisselende invoer, en dat vind ik een veel minder wenselijke situatie. De uitwisseling van bestanden en aangetroffen afwijkingen heeft in dat geval ook geen zin meer. Dat zou een gemiste kans zijn om de kaart voor wandelaars en fietsers te verbeteren.
Ik heb van rustpunt.nu een lijstje gekregen met lokatiefouten in OSM. Komt er zo te zien op neer dat het rustpunt op het woonhuis getagd is ipv bij een schuurtje. De lokatiefouten in rustpunt.nu past hij daar meteen aan, als het meer dan pakweg 6 m verschil is. Ik krijg handige aanwijzingen zoals “achter de koeienstal”, weet ik veel welk van de gebouwen de koeienstal is! Maar ik kom daar wel uit en zal ze aanpassen.
Ik heb al doende bedacht dat de juiste tag voor bij amenity=cafe is: self_service=only.
Verfijnen met wat er dan precies te halen valt kan altijd nog.
En misschien in plaats van picnic_area, outdoor_seating=only ?
Dat maakt het denk ik goed duidelijk, en dan heb je geen dubbele hoofdtag meer.
Niet echt mee eens, maar dat is maar een mening.
Waarom is dat een dubbeltagging?
Bij een rivier wordt toch ook het water en de loop van de rivier getagd, dat is geen dubbeltagging, zoals je in het voorbeeld van een rustpunt wel zou zijn.
Maar het maakt me echt niet uit hoe we het zouden taggen, en leg me eigenlijk bij alles neer, als de meerderheid hier maar instemming kan vinden.
tourism is een hoofdkey, amenity ook. Met de values erbij zijn dat twee hoofdtags op 1 object, de rustpunt node of polygoon. In het algemeen is het niet goed om twee hoofdtags te gebruiken op een object met meerdere onderdelen. Dan kun je beter elk onderdeel apart mappen en zijn eigen hoofdtag geven. outdoor_seating is een extra key voor een nadere tag bij een amenity.
Je kan het probleem bij twee hoofdtags op 1 object zien aan de vraag: wat moet een renderer nou afbeelden, het koffiekopje van cafe of het picknicktafeltje van picnic_site? Of allebei 50% doorzichtig over elkaar heen? Is niet onoverkomelijk, en het probleem van de data user, maar het is MI beter om het gescheiden te houden als dat kan.
Daarom stel ik nu voor om outdoor_seating toe te voegen aan cafe met self_service=only. Dat vind ik best een wel passende beschrijving, en dat kan je de al ingevoerde rustpunten gewoon volgens de oude afspraak als amenity=cafe getagd laten. Je beschouwt het dan als een (mini)-cafe met uitsluitend zelfbediening en uitsluitend buiten zitten.
Het belet niemand om als verfijning de onderdelen in twee aparte objecten te scheiden, namelijk cafe met self_service en picnic_site of rest_area en dan maakt het mij weinig uit welke dat dan is. Maar dan moet je wel ter plekke gaan om nóg preciezer de layout te weten. En kiezen waar je de naam en de website op zet.
Wat betreft tagging, alleen vandaag is de poll nog open.
Ik heb gezien dat de .gpx op de website ook is aangepast en wat mij betreft heet de .gpx voorkeur, die kan direct door het script ingelezen worden en ook josm weet er raad mee.
Ja hoor, ik kan ook een .osm file genereren maar zoals gezegd je kan ook de .gpx in JOSM inlezen. Zou de .osm file alle punten in die ik in de .gpx kan vinden maar geen match hebben met een OSM punt moet bevatten?
Mooi, de .gpx lijkt ook bijgewerkt te zijn en het script ziet op dit moment maar nog 1 node die het niet kan matchen, n2420279562
Dat is Ottink, daar krijgen we binnenkort nog uitsluitsel over.
Wat hij op de site aanpast zit dus meteen in de exports, dus dat heeft zeker de voorkeur!
Als je de gpx inleest in JOSM heb je nog niet alle attributen gelijk als tags beschikbaar, toch? Er zijn bewerkingen nodig om ze onze keys en values toe te kennen op basis van wat er in de gpx staat. En de export op de site bevat alles, ipv de selecties verwijderd/match/toegevoegd.
De verwijderingen zijn opgelost op 1 na, die wordt misschien verwijderd, we krijgen bericht.
Matches met verschillen: de meeste zijn opgelost en de rest hoor ik komende week.
Dus, inderdaad, alleen de niet-matches als nodes, met hun lat/lon en met de volgende tags:
amenity=cafe
self_service=only
outdoor_seating=only /* indien dit geen meerderheid van stemmen krijgt, eenvoudig te vervangen door wat dan wél een meerderheid krijgt: highway=rest_area, tourism=picnic_site, of whatever.
name=name from export
website=url from export
ref:Rustpunt=p_id from url from export
fixme=resurvey /* markeert voor ons of het punt afdoende gecheckt is. Kan ook door losse mappers opgepikt worden.
source=https://www.rustpunt.nu/
source:date=2022-10
MIjn plannetje is om hier een projekt van te maken. Namelijk de lijst per provincie of gebied te verdelen onder vrijwillige mappers die eerst in JOSM een leunstoelverifikatie uitvoeren, dan wat redelijk zeker is uploaden, en dan exacte verifikatie gaan doen waarbij de fixme vervangen wordt door de survey:date.
Bij blijvende twijfel niet uploaden, dan vragen we het gewoon aan rustpunt.nu. Maar ik denk dat je zo behoorlijk snel vrijwel alle rustpunten in ieder geval in de buurt van het juiste adres krijgt, en dat is beter dan niets. Daarmee zijn wandelaars en fietsers al behoorlijk geholpen.
Dan volgt de fase van precisie en verfijning, met behulp van alle digitale middelen plus survey én de hulp van Rustpunt.nu. Die ga ik gewoon vragen om de punten met Id op de juiste plek te schuiven. Misschien vindt-ie het zo waardevol dat hij een vaste bijdrager wordt! Hij wil zelf ook graag dat de punten op de site zo precies mogelijk zijn. Iedere dag 20 bekijken of zo, dan is hij er in een maand doorheen; als wij ondertussen ook aktief blijven met survey en feedback dan doet hij dat wel, het is win-win!
Ik heb een plan opgeschreven en ik zou daar wel wat gedachten over willen horen, kijken of we het zo kunnen aanpakken dat we ze er allemaal in kunnen krijgen met aanvaardbare precisie en kenmerken. Ik heb het voor de komende jitsi op de agenda gezet.
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)
https://wiki.openstreetmap.org/wiki/Import/Guidelines
https://lists.openstreetmap.org/pipermail/imports/
https://wiki.openstreetmap.org/wiki/Import/Getting_permission
Ik hoop er zaterdag bij te kunnen zijn, dit is van mijn kant nog niet geheel zeker.
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.
Het Engels is vooral voor de internationale kontroleerbaarheid, bv als referentie bij de changeset.
2022-10-27: Ik heb toch even een NL versie vooropgezet. De Engelse versie wordt binnenkort de verplichte beschrijving van de automated edit.
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.
Wat kan er dan nog verkeerd gaan?
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.