/*
This query looks for nodes, ways and relations
with the given key.
Choose your region and hit the Run button above!
*/
[out:json][timeout:150];
// fetch area "search in Nederland
{{geocodeArea:Nederland}}->.searchArea;
// gather results
(
// query part for: “rustpunt*”
node[~"rustpunt"~"."](area.searchArea);
way[~"rustpunt"~"."](area.searchArea);
relation[~"rustpunt"~"."](area.searchArea);
);
// print results
out body;
>;
out skel qt;
Als deel van value:
Zoek:
[~"."~"rustpunt"]
Alle values natrekken in een gebied met “rustpunt” in de value.
Dat is best zwaar, met overpass. Kleine gebieden.
Neem bijvoorbeeld een woonplaats.
/*
This query looks for nodes, ways and relations
with the given key.
Choose your region and hit the Run button above!
*/
[out:json][timeout:150];
// fetch area "search in area
{{geocodeArea:Hardenberg}}->.searchArea;
// gather results
(
// query part for: “rustpunt*”
node[~"."~"rustpunt"](area.searchArea);
way[~"."~"rustpunt"](area.searchArea);
relation[~"."~"rustpunt"](area.searchArea);
);
// print results
out body;
>;
out skel qt;
Voor een aantal rustpunten waarvan ik de locatie ken, heb ik de geografische coordinaten opgezocht op OSM om te zien waar ik dan uitkom. In de meeste gevallen zitten die er een meter of 30 naast. De naam in Nominatim zit wel op de juiste locatie.
Zie hier mijn voorbeeld:
Wat me ook opvalt: Alle rustpunten hebben een id, maar het POI nummer in de rustpunt website is niet hetzelfde als de id voor dat adres. Deze heeft id 261, maar is POI 2807.
Overigens kan ik in Nederland hooguit 20 rustpunten vinden die ook een website in de tagging hebben staan (zoals in het door genoemde Jister).
Ja, dat probleem heb je met de meeste geolokaties uit andere systemen, bijvoorbeeld knooppunten en TOPpen. Als die id klopt, is dat samen met het adres wel heel handig voor de identifikatie, maar de exacte lokatie moet toch van survey of viewer komen.
Een vergelijking zou liefst een attentielijst van (waarschijnlijke) mismatches moeten geven: waarschijnlijk toegevoegd, waarschijnlijk verwijderd, waarschijnlijk verplaatst, adres klopt niet of onvolledig.
Dan is het id waarchijnlijk geen bruikbaar nummer, en dat POI-nummer vertrouw ik ook niet, dat zou wel eens gekoppeld kunnen zijn (een volgordenummer) aan de webtoepassing. Als ze dan een keer upgraden krijgen ze zo weer een ander nummer.
Het is volgens mij wel essentieel om de website van een rustpunt op te nemen, een operator lijkt me niet handig. Daarnaast vind ik rest_area meer aangeven wat een rustpunt is dan café.
Bij het rustpunt wat ik kortgeleden bezocht stond er een caravan waar een koffiemachine klaarstond, maar die moest ik eerst repareren voor ik koffie kon drinken…
Ik vind de tags die ik heb gebruikt prima weergeven wat er te vinden was.
Mee eens. Ik heb gevraagd of de p_id geleverd kan worden ipv de id, dan kunnen we er de URL van maken. De minimumtagging is dan highway=rest_area. Dringend gewenst zijn name=* website=*
De toggles voor de voorzieningen zijn optioneel lijkt me.
Voor De Jister zie ik trouwens de naam op Carto staan, maar zonder verder icoontje of zo. Dat is gelijk aan de rendering van rest_area langs de snelweg. We zouden een ikoontje kunnen voorstellen, op Carto en Waymarkedtrails, Osmand en andere renderende toepassingen.
Als je latitude longitude als kolom vooraan neer zet en zo benoemd.
Dan kan je het in JOSM laden, JOSM vraagt nog naar het coördinaten stelsel. (plugin OpenData) Hier WGS 84.
Dat moeten we dus juist niet doen Allroads. Ik heb hiervoor al aangetoond dat die coordinaten niet kloppen met de werkelijkheid en bovendien heeft die dataset niet de juiste gegevens voor een belangrijk punt: wat is het website adres van dat rustpunt?
Kortom, niet importeren en zeker niet op die manier.
Ik heb het definitieve bestand nog niet, maar ik vind het mooi dat we alvast kunnen kijken wat je met zo’n bestand kan. Ik heb eerder knooppunten"wolken" op die manier in JOSM ingelezen, met het idee dan zie ik visueel wel waar de verschillen zijn en dan werk ik die een voor een af. Nou, met die hoeveelheden punten zie je weinig, of eigenlijk zoveel dat je er geen wijs uit wordt, en je bent heel snel veel tijd kwijt zonder dat je merkbaar opschiet. Ik kon er geen handige workflow van maken.
Daarom vind ik zo’n vergelijkingstool zo belangrijk, die kan verschillen detekteren en kategoriseren en dan kan je een werkplan daarvoor maken. Zoals wat Friso Smit nu voor wandelknooppunten maakt, en wat emvee voor drinkwaterpunten had gedaan.
In dit geval zijn ook de matches van belang, omdat je daar de gegevens van wil aanvullen. Een match is dan, een punt in de dataset ligt binnen pakweg 50 m van een punt (met voldoende passende kenmerken) in OSM. De OSM lokatie blijft zo, de overige gegevens kunnen uit de nieuwe dataset worden overgenomen.
Toevoegingen zou je kunnen overnemen maar dan met een note of fixme dat de lokatie nog geverifieerd moet worden.
Verwijderingen zou ik altijd volledig handmatig houden, maar wel als eerste verwerken.
Rustpunt.nu heeft mij gevraagd om de verschillen die wij vinden ook aan hem terug te leveren. De operator zegt dat hij alle 600+ rustpunten persoonlijk uit het hoofd kent, en ik denk dat hij denkt dat er misschien achterhaalde informatie in OSM blijft staan. Een terechte gedachte, want verwijderingen, daar is OSM niet zo goed in, met name omdat we geen signaal hebben als iets vervalt.
[out:json][timeout:300];
(
node["website"~"rustpunt"]({{bbox}});
way["website"~"rustpunt"]({{bbox}});
);
out body;
>;
out skel qt;
vind ik in totaal 38 POIs die een website-vermelding hebben. Maar alle andere zoekopdrachten naar iets met “rustpunt” in de naam leveren uiterst weinig op (misschien 10?).
Dat betekent dat het vergelijken van de dataset die Allroads heeft bewerkt met dát wat wél in OSM staat, een behoorlijke lastige klus is omdat er geen enkele lijn zit in de manier waarop we die rustpunten hebben vastgelegd. Dat is natuurlijk precies waar dit topic over gaat!
We moeten eerst zien te achterhalen welke rustpunten er in OSM staan en welke tags daarbij gebruikt zijn. Vervolgens moeten we die zien te vertalen naar de gegevens die in het totaalbestand staan en pas dan kunnen we er iets mee gaan doen…
Dat wordt dus een heel lastige klus.
Welke tags zijn echt nuttig voor die rustpunten?
Al eerder is hier opgemerkt dat de tag amenity=cafe niet goed de lading dekt.
In een café kun je fatsoenlijk zitten, je wordt er bediend en er is een ruime keuze aan eten en drinken.
In dat opzicht is de tagging van de rustpunten (die ik eerder noemde en die die allemaal een website=* tag hebben) niet correct, want die staan bijna allemaal als cafe genoemd.
Maar bij een café zetten we ook niet het complete drank- en voedselaanbod op OSM, waarom zetten we bij een rustpunt dan wel tea=yes en coffee=yes in de tags? Dat is vrijwel bij alle rustpunten het standaard aanbod (naast koekjes en repen).
Soms staat er self_catering=yes (2x) en dan weer self_service=yes (1800+ x). Volgens mij kunnen we die self_catering laten vervallen en gewoon self_service gebruiken.
Belangrijk is het opnemen van een website met de rustpunt.nu POI link.
En ook de naam is belangrijk.
Daarnaast zie ik bij een aantal rustpunten een duidelijke ruimte waar je kunt zitten of schuilen, daar zou ik dan amenity=shelter bijzetten, op het gebouwtje. En soms staan er ook veel picnicbanken, die kunnen dan allemaal afzonderlijk worden ingetekend.
Ik ga voor:
highway=rest_area (maar zie ook alternatief hieronder)
name=*
self_service=yes
website=https://www.rustpunt.nu/poi/?p_id=XXXX
ref:rustpunt=(hier kan het interne id van rustpunt komen, dat is waarschijnlijk handig bij updates)
en indien aanwezig:
toilets=yes
Het assortiment eten/drinken dus niet.
Wat blijft er te wensen?
Bij gebruik van highway=rest_area is er geen icoontje. Dat probleem is nu (meestal) opgelost door amenity=cafe te gebruiken, maar dat is taggen voor de renderer (tenzij je inderdaad vindt dat het een café is).
Je zou bv. ook leisure=picnic_table neer kunnen zetten en alle andere tags daar ook aan vasthangen (maar dan dus niet de rest_area).
Om te zien hoe dat op de kaart oogt, heb ik het rustpunt dat ik kortgeleden bezocht, aangepast.
Maar goed, we moeten dan dus ook nog een manier vinden om al die rustpunten op de kaart te krijgen…
We hebben ook de tag tourism=picnic_site…
Dat levert ook een icoontje op en dekt wellicht ook de lading. Het is meer algemeen.
Wanneer er geen picnic tafel is dan klopt leisure=picnic_table ook niet.
Het is het allemaal net niet…
