Import Rustpunt rest areas for hiking and cycling

From OpenStreetMap Wiki
Jump to navigation Jump to search

(work in progress)

Import into OSM of special rest-areas for hikers and cyclists.

Latest edit: 2022-10-30 Peter Elderson: layout and text improvements
2023-06-09 Peter Elderson: details of the actual import
2023-06-12 Status update

Status import

Import done 2023-06-09, OSMCha

The new Rustpunt nodes were loaded into JOSM, checked for obvious data errors and corrected, then uploaded as one single changeset. The import spec url (this page) was set as comment on the changeset.

Before upload, invalid website url's were corrected if possible. If not, the website value was discarded. Additional services were added as a note tag of the object. Mappers may want to add those as separate amenities, e.g. shop=farm, tourism=guest_house, tourism=camp_site, tourism=caravan_site Wifi (wlan) was tagged on the rustpunt node as internet_access=wlan

An overpass-query and a Maproulette challenge were created to manage the systematic verification. This is beginning to take off.

The main point is to verify the exact location. If verification is not possible, a fixme may be set by the mapper, to encourage survey. After verification check:date=* will be set. The overpass-query and the Maproulette challenge will filter by the presence of a check:date.

Mappers have already noted a few errors. Some already mapped 'Rustpunt's were added again by the import. This was an oversight in the matching script. Because the already mapped Rustpunt nodes and areas should be updated according to the new data and agreed tagging anyway, this actually helps!
One Rustpunt was not found in the import dataset, which would mean it's a deletion. Except, in reality it isn't. Which means it was a good choice not to do automatic deletions, but leave it to the mappers to verify first.
Also, some Rustpunt locations are located far (over 1 Km) from the address of the Rustpunt owner. We cleared this with the Rustpunt.nu operator: it actually is shown like that on their website. The fact that it does not help the hikers and cyclists, is not our problem; we map the actual Rustpunt, not the owner's address. Again, this "error" shows our procedure is working: it actually catches the exceptions.

Look ahead

Currently (2023-06-12), a script is being developed to handle the matches, i.e. Rustpunt nodes already in OSM that should be brought in line with the agreed tagging, including the ref:rustpunt and the link to the Rustpunt's webpage.


Summary

An automated import is proposed of ca 630 special rest areas for hikers and cyclists to take a break, branded as “Rustpunt”. A Rustpunt always includes an outside seating area with BYO permission, and (self_service only) coffee/drinks/snacks/sweets, and water, access to toilets and a shelter. Other facilities may be present such as a farm shop, a bicycle pump and bicycle parking, internet access, electricity for charging e-bikes and/or mobile phones.

The tagging specs and the proposed workflow are presented first. See below for details and explanations.

Tagging

Import the new Rustpunt objects as nodes tagged

  • amenity=cafe
  • self_service=only
  • outdoor_seating=only
  • name=name from dataset
  • note= (extra offerings to be mapped separately, e.g. shop=farm)
  • website=url from dataset
  • ref:Rustpunt=p_id from url from dataset
  • brand=Rustpunt.nu
  • brand:website=https://www.rustpunt.nu
  • fixme=resurvey NOT, WE USED A DIFFERENT TAG FOR MANAGING THE VERIFICATION
  • source=https://www.rustpunt.nu/
  • source:date=2022-11
  • wlan=yes (if offered)

Workflow

  1. The dataset will be split up as follows:

A. Close matches: found in OSM nearby the source location. B. Far matches: found in OSM, but too far from the source location C. New: not found in OSM D. Removed: found in OSM but not in the source dataset.

Set A will be checked and updated using a Maproulette challenge or an overpass-turbo query, and the location (if changed over 6m) will be reported back to the source operator. Sets B. and C will be imported, then checked using a Maproulette challenge or an overpass-turbo query Set D. Will be removed from OSM by hand at the time of import.

  1. At import, each node is marked with fixme=resurvey, aimed to set the exact location at the address post import. A Maproulette challenge or overpass-turbo query will be set up.
  1. After import, resurvey is required. The location of each Rustpunt node will be verified and, if necessary, adapted, to ensure that it matches the address on the website. At resurvey, it is up to the mapper to pick the exact spot for the node (the address itself, or a shed, barn or garden, a shelter, the sign, the seating area), and to add further detail such as a description, additional nodes for picnic tables/toilets/bins/bicycle stands etc. Or map it as an area.

PS1. The operator knows and visits all the locations repeatedly, so detailed reports by the operator will be seen as survey. Imported Rustpunt nodes which are relocated more than 6m by a mapper after survey, will be reported back to the operator, for verification and correction.

PS2. It is up to the regional import mappers to (partially or fully) perform the resurvey. After the first import, an organised effort will be done to ensure that the bulk will be reviewed.

  1. Maintenance of the data: The operator has promised we will receive new and changed data from the operator, about twice per year without asking. In the meantime, we can also freely use the current datasets found on the Rustpunt website . The comparison of existing OSM data against the dataset is done using scripts by user emvee and the results are shared on the Dutch OSM forum. The maintenance will be done manually; no further automated edits are proposed.

Planning and progress

A target completion date for the import operation of 2023-07-01 seems achievable. We will start as soon as the Dutch community is in majority ok with it. Progress will be reported here.


============

Background details and considerations

Introduction

In Nederland, some 630 locations are present under the reserved title “Rustpunt”. The title is assigned by a non-commercial operator called Rustpunt.nu. They are areas sporting outdoor seating where you can BYO, limited self_service items such as coffee, tea, soda and snacks, and access to a shelter and toilets. There may be other facilities such as air and electricity for bikes and mobile devices, drinking_water, waste bins, playground, bicycle stands. The sites are recognizable by a very notable (and copyright protected) sign at or pointing to the entrance, but most areas are themselves hidden from sight so you really have to enter to see the exact layout and offerings.

The operator/issuer is “rustpunt.nu” and we have permission to use the dataset they have provided to the Dutch OSM community, in exchange for us reporting OSM location changes. We can get current data any time we want.

Following the import a periodical update dataset (additions, removals and attribute updates including possible name change or relocation) will be provided by the operator. This is *not* part of any automated edit, but will help maintain the quality of the data in OSM manually.

Rustpunt objects (nodes and polygons)  already existing in OSM have been tracked and checked, and will be excluded from the import. Where the dataset differs from OSM, the operator has been notified and together we will manually correct the data at both sides. 10 Rustpunt objects no longer existing as Rustpunt (™) have been removed from OSM (or retagged, is they still exist but the Rustpunt permission has been revoked).

The new Rustpunt objects will be imported as nodes, each representing a self_service cafe with outdoor seating only, tagged with the official Rustpunt name + the official Rustpunt website page URL for the object, their unique poi number (p_id) + amenity=cafe + self_service=only + outdoor_seating=only. We will add source=[operator URL] and source:date=2023-07-* and fixme=resurvey (after survey to be replaced with survey:date=[date])

After import, all the objects will be checked for correctness and, if necessary, surveyed and refined. The after-import check is part of this proposal; later surveys depend on mapper findings. We plan the surveys, but not what will be done by the mappers. The workflow will be directed by fixme tags

Permission

The operator/issuer is “rustpunt.nu” and we have explicit permission to use the dataset they have provided to the Dutch OSM community. We can get current data any time we want. Updates of the dataset will be sent to us every half year without asking. This will trigger us to compare-and-update.

OSM

These resting areas with self-service of refreshments are very welcome to hikers and cyclists, and having them on the map or searchable as POIs is a vast improvement, that is, if we have them all, and if it’s are reasonably reliable that they still exist.

Spontaneous mapping during several years has yielded some 50 of these rest areas mapped, 7 of which no longer existed, according to the operator who assigns the right to call it a Rustpunt. (2022-10-20 These have been removed from OSM.)

The tags can differ. Most are tagged as amenity=cafe, and most have the word ‘rustpunt’ in one of the tags e.g. name=*, website=*, note=*. Checking and retagging already mapped nodes/areas is *not*  part of this import spec. (2022-10-24 As a side benefit, the exact locations have been checked by the Rustpunt operator and, if >6m off, are corrected in OSM as well as on the Rustpunt website).

Data

The operator has granted us the use of the data of all the Rustpunt locations, which is provided though the website and, if a different format or special attributes are required, by mail. The operator would like feedback from OSM about differences, and offers to provide a half-yearly actual dataset in return, without us asking. Changes to the locations and attributes on the Rustpunt.nu website are reflected without delay in the available export files.

The permission is recorded on the OSM wiki contributors page.

The data encompasses:

  • lat and lon
  • Name (Official name of the Rustpunt)
  • Address (street, city/municipality, postal code), address of the owner
  • URL of the subwebsite for the Rustpunt, format https://www.rustpunt.nu/poi/<p_id>
  • p_id (Unique Rustpunt id)
  • {facilities} (Extra facilities, a string).

The address will not be tagged. It will be used for check-up to verify the location before the upload is done.

The subwebsite of the poi gives details and often pictures of the Rustpunt, and a map with a pin at the right spot near the address. Part of the URL is the unique poi-Id, which can be used in the future as a unique link between OSM and the source data.

Assessment of the data items in a record (row in the table)

The name is somewhat arbitrarily assigned, sometimes the word ‘Rustpunt’ is included, sometimes not; it may be the surname of the owner, or the name of a camping, or a house name, or a fantasy name. The name on the road is often not the same as in the data. For us, any name is fine, though it is not suitable as a unique key.

The owner’s address we think should not be in OSM. It cannot be seen at the spot, you would have to explore to find it. Providing the URL also provides access to the addres on the rustpunt.nu site.

The URL of the Rustpunt’s page on the rustpunt.nu site is unique, because the unique p_id is there. The p_Id of a Rustpunt remains the same over time.

The lat and lon are a mixed story. We don’t know exactly how they are defined, it looks like they have simply pointed at a map. For the Rustpunt objects mapped in OSM the comparison shows exact matches, near matches and a few not-so-near matches (e.g. 250m off because of a relocation). OSM mappers regularly locate the Rustpunt itself some 30 meters off, compared to Rustpunt.nu, and so far OSM has been more precise than the operator. One location was very far off, this has been corrected on both sides, but it shows errors can occur. The near matches can be e.g. 100m, which on a farmer’s grounds can be the result of relocation from the front to the back. This means that before the import, the locations need to be verified to at least be at the given address.

Comparing and processing the data

The comparison of existing OSM data against the dataset is done using QGIS and scripts by user emvee and the results are shared on the Dutch OSM forum.

OSM data is retrieved using an overpass query based on earlier tagging consensus. The comparison against the dataset will generate three lists:

  1. Removals: the object exists in OSM but not in the current dataset
  2. Matches: the object exists in both OSM and the dataset
  3. Additions: the object exist only in the dataset, not in OSM

Lists 1 and 2 are checked and handled manually. Changes in geolocation will be reported back to the operator, who will then enter the OSM geolocation into his database.

List 3 is processed as explained in this document.

After receiving an update dataset, the same comparison is run again. The expected result is that lists 1 and 3 may have a few entries, while list 2 (matches) contains nearly all the Rustpunt locations with near-exact (<6m) geolocations.

Tagging discussion results

A few years back, there was a consensus in the Dutch OSM community to map the Rustpunt areas as an area or a node with the main tag  amenity=cafe.

Some of the locations do resemble an enclosed self service cafe, there is an inside where you help yourself to cafe and snacks and pay, and there is an outside where you sit, drink and eat. Other locations are more like an open picnic area where -if weather permits- a table is put out with thermoses, paper cups and a box for the coins.

And very few of them have been mapped as a special Rustpunt over the past years.

That’s why the issue was raised again. Turns out that there is importable data, which means decide on the tags.

Viable suggestions were:

  1. highway=rest_area with name=*, self_service=yes, cafe=yes and other toggle tags; the existing definition of rest_area needs to be slightly adapted to encompass non-motorized uses.
  2. tourism=picnic_area with self_service=yes
  3. stick to amenity=cafe even though it’s often not a cafe;
  4. both amenity=cafe and tourism=picnic_area on the same node or polygon.
  5. Map all parts separately: picnic_tables or benches, picnic_area, cafe room, toilets, shelter.
  6. The latest idea is to use amenity=cafe and include self_service=only and outdoor_seating=only.

Current discussion (Dutch)