check_date of survey:date?

Ik heb voorgesteld om survey:date=* te zetten op de relatie als je een wandelroute hebt nagelopen en verbeterd.

Ik zie dat er ook check_date=* gebruikt wordt voor hetzelfde doel.

Het lijkt mij goed om dit gelijk te trekken. Ik heb een voorkeur voor survey:date omdat:

  1. Deze tag volgens taginfo veel meer gebruikt wordt dan andere tags voor dit doel. Zie ook https://wiki.openstreetmap.org/wiki/Key:check_date.
    (NB de opmerking dat survey:date geen echt gebruik door mappers aangeeft, klopt alleen voor gebruik op ways. De Antarctica import zette deze tag niet op relaties.)

2 Je kunt ook andere survey-gegevens op dezelfde manier taggen: survey:source, survey:note, survey:type, …
(Dit wordt voor mij extra handig als ik met een padwerkgroep een hele LAW ga bijhouden en periodiek kontroleren. Dat werkt dan naadloos samen met “losse” mappers.)

  1. check_date heeft naar mijn gevoel meer te maken met periodieke kontrole van data uit een databron.
    Bijvoorbeeld dat ik periodiek kijk of alle TOPpen die ik heb ingevoerd nog in de bronlijst bestaan en of er nieuwe zijn toegevoegd. Zeer bruikbaar, naast de survey-gegevens. Een TOP kan dan een survey:date hebben (Daadwerkelijk waargenomen op…) én een check_date (geverifieerd tegen de TOPpenlijst van de operator op…).

Dus mijn voorstel zou zijn om check_date voor nagelopen routes om te zetten in survey:date. Met overpass zie ik dat het in Nederland om een beperkt aantal routes gaat, vooral in Noord-Brabant.

Meningen?

Ik heb toevallig vanochtend check_date toegevoegd aan een aantal routes die ikzelf heb gelopen en toegevoegd. Die tag kende ik van wegen in aanleg waar die was toegevoegd om aan te geven dat die weg op dat moment nog in aanleg was. Wat mij betreft is er geen bezwaar om deze tag op wandelroutes om te zetten naar survey:date.

Edit: Ik heb bij de routes waaraan ik vanochtend check_date heb toegevoegd, check_date omgezet naar survey:date.

Superdeluxesnel! Bedankt. Dat was het, voor Nederland. België en Duitsland heeft ook wel wat check_date’s op een paar wandelroutes, als ik tijd heb zal ik daar s vragen hoe ze erover denken.

Ik heb het ook op het BE-forum aangekaart. Daar hadden wel 2 wandelroutes een check_date. Ik heb die met hun goedvinden omgezet naar survey:date.

Volgende stap: een op survey:date gesorteerde lijst op een wiki-pagina of zo. Die zou dus zelf de wandelroutes moeten opzoeken en gesorteerd weergeven.

Weet iemand toevallig hoe je dat zou moeten aanpakken?

Kun je hier iets mee?
Wandelroutes: https://wiki.openstreetmap.org/wiki/WikiProject_Nederland_Wandelroutes#Routes_van_de_ANWB
Fietsroutes: https://wiki.openstreetmap.org/wiki/WikiProject_Nederlandse_Fietsroutes#Gelderland

edit: Deze ken je al, en zoekt naar iets anders.

Ja, ik zoek naar het genereren van zo’n soort tabel vanuit een OSM-query. Dus ofwel op het moment dat je de pagina ververst, ofwel vanuit een dagelijks ververste tabel. Zoals vmarc.be doet voor knooppuntnetwerken.

Check_date is ook handig bij winkelcentra die tegenwoordig een zeer dynamisch winkelverloop hebben.

check_date is naar mijn gevoel verbonden met een datasource. Je checkt tegen de bron of de informatie nog klopt.
survey:date zegt heel specifiek dat het object op de weg gezien is.

Bijvoorbeeld bij de TOPpen die ik heb ingevoerd. Ik heb daarbij gebruik gemaakt van een bronlijst.

Een check_date zou aangeven dat gecheckt is of de TOP nog in de bronlijst aanwezig is, of de url, operator, website en description daarmee nog kloppen, dat soort dingen.

Een survey:date geeft aan dat iemand het ding echt gezien heeft.

Toegepast op winkelcentra: als er een bron is die aangeeft welke winkels er aktueel in een winkelcentrum zitten, en je checkt periodiek of er wijzigingen zijn om ze vervolgens door te voeren, dan lijkt mij een check_date op zijn plaats. Of je die dan per winkel zet of eerder op de wijzigingenset kan je je afvragen.

Als het puur om waarneming ter plekke gaat, dan zou ik survey:date gebruiken. Je zegt daarmee: deze winkel is op … gezien. Ook daar kan je je afvragen of je het per winkel wil aangeven, of dat je het hele centrum doorloopt en de datum aan de wijzigingenset hangt.

Bij wandelroutes is er geen periodieke check tegen een bron. Ik heb wel zelf alle LAW’s en streekpaden mbv de gegevens van de Wandelnet, de lijst op de wandelwiki en wat ar al in OSM aanwezig was kompleet gemaakt. Als startpunt heb ik daarbij survey:date gezet op de datum waarop ik er naar beste weten van uit zou mogen gaan dat er een suvey moet zijn geweest. Dat was vaak de datum waarop het laatste boekje over de route verschenen was. Je mag er toch vanuit gaan dat op dat moment op de weg dezelfde route gold als in het boekje beschreven staat.
Aangezien de meeste boekjes oerend oud waren liggen de aanvankelijke survey:dates ook in een ver verleden. Die gaven dus alleen maar aan dat je er niet blind op moet vertrouwen dat de route helemaal klopt.

Vervolgens is het aangescherpt. De allerbekendste paden zoals het Pieterpad en Floris V worden vaak gelopen en bijgewerkt door verschilende personen waaronder ikzelf. Dus die survey:dates (op de secties) zijn behoorlijk recent en dat zal wel zo blijven. De nieuwe LAW16 Romeinse Limes is inmiddels bijna volledig nagelopen door Sint E7 en mijzelf, die heeft dus heel recente survey:dates op de secties. En passant zijn daarmee ook delen van andere routes gesurveyed, want tegenwoordig lopen die vaak voor een deel samen.

Ook anderen zijn inmiddels mee gaan doen. Daarom heb ik goede hoop dat we kunnen komen tot een systeem wat in de richting gaat van dat voor de knooppuntnetwerken. Als eerste stap zou ik willen dat er een pagina komt die de aktuele wandelroutes laat zien, gesorteerd op survey:date oplopend.

Zelf ben ik wel zo OSM dat als ik een wandeldag plan, ik ga kijken of er een leuke wandeling is die al heel lang niet gesurveyed is. Kleine moeite om die dan te tracken en daarna te verbeteren. Als iemand anders er een loopt en trackt en dat aan mij mailt (of hier op het forum zet met een linkje?) dan voer ik het graag even in, voor mij een kleine moeite. Inmiddels ben ik dank zij de vele tips op dit forum behoorlijk ervaren met routes!

Ook in Duitsland waren maar enkele wandelroutes getagd met check_date. Ik heb kontakt gehad met de betreffende zeer ervaren mapper daar, hij heeft taginfo gecheckt en gaat voortaan survey:date gebruiken voor dit doel. De bestaande tags heeft hij gelijk omgetagd.

De rest van de wereld heeft geen check_date op wandelroutes staan.

Goed punt!

Goed nieuws! Op de tagging list heeft ene Jan Macura met behulp van SOPHOX een query gemaakt die een sorteerbare lijst van routes geeft.

Sophox gebruikt de SPARQL zoektaal, die wel wat op SQL lijkt dus die snap ik! Resultaat wordt een grafiek en/of een dataset in een sorteerbare tabel. In de tabel staat bij elke route een edit-met-Id knopje wat voor het aanpassen van de tags van een route genoeg is. Ik heb al een serie foute datums (formatfouten, tikfouten) verbeterd!