Hi, I am a new mapper to OSM and my coworker and I want to import our data file of the trails managed by Basin Recreation, of which we have recently updated with new GPS tracked routes and corrected to a higher degree of accuracy than what we had previously. We are following the Import Guidelines and are working on our plan/proposal which will be posted to the respective forum shortly.
I was hoping to get some insight on the best way to go about this process. Much of the data are already mapped and just need to be realigned and there are three new trails that are not on OSM yet. As we are both new to OSM, any advice on this project is extremely helpful. Thank you!
This Basin Recreation? I don’t see a summary of hiking trail mileages but they mention 45 km (28 miles) of nordic ski trails so I am guessing the hiking trail mileages are probably similar.
Based on that, if it were me I’d just upload the GPX track files to OSM then open the area in JOSM and make the edits to bring the currently mapped trails into alignment and add the unmapped trails. And I’d put the change set comment to be something like “survey, GPX tracks”.
Hardly worth all the notification work, etc. involved in a formal import. Especially since you basically are doing what I would consider normal everyday trail mapping.
2 Likes
Thanks for your reply! Yes that is the correct Basin Rec. This was essentially our plan and we had originally reached out to an OSM rep who directed us to the Import Guidelines and to follow that route. So, what would be the difference between our import and a more formal one?
To me an import is getting a data set from some organization, usually a governmental one, and using some usually custom tools to munge it into OSM format then doing a bulk upload. The custom tools need to do things like see if each object is already in OSM or not and if it is in OSM do something reasonable, often conflating (merging) the data. Things that are often imported are address data and buildings. Those are tedious to manually map, I know as it took me months of daily walks to get address data for the town I live in but a data import from the county GIS department would only have taken a few hours once the conflation scripts were working properly.
But if I go out and hike a trail or even a whole trail system collecting GPS track data and taking notes as I go, then I am simply doing bog standard OSM mapping and can use a bog standard OSM editor. If I see an error in something that already exists, for example bad trail alignment, I just adjust it per imagery, any field notes I took, and my GPS track (or preferably from all the GPS tracks that have are available as a single track can have substantial errors).
edit: The problem with imports is that often the data being imported is not all that good. Look at all the TIGER road data that still exists in the US as a poster child for a problematic import. So a whole involved procedure has evolved to help assure that the people who are doing the import know what they are doing, that the tools they are using seem reasonable, that the way they propose to deal with conflicts seems reasonable, etc.
If you have actually walked the trails then you have done a survey and know what is there in reality so when you make your edits you have first hand knowledge of what you are doing. You are not just trying to do a data translation from someone else’s dataset.
5 Likes
As you seem to strive for accuracy: LIDAR terrain models and Strava heatmaps can help a lot when aligning both existing mappings and new ones. Latter are available as editor or browser plugins, former perhaps just one or two clicks away in standard environment. Personal GPX tracks might be loaded into editor without uploading but uploading certainly useful for others to reproduce.
2 Likes
Accurate ways is the ground layer. Then there are the routes a.k.a relations that build upon those ways: hiking, cycling, nordic skiing come to mind. This is a bit of an advanced topic. These are quite prominent in OSM space, but I have no idea if going that extra mile will pay off? Others may have more to say.
2 Likes
This is extremely helpful, I appreciate your feedback thank you!
1 Like
For more context here is our data file https://basinrec.maps.arcgis.com/home/item.html?id=8742991cfa774fefacdce02ec6da36f9
2 Likes
That is a nice resort! I see why you were considering an import.
I managed to put openstreetmap carto into the background from the layers menu in the viewer. What I see does speak against importing: The trails all/most already there. Even more of them.
The area looks a bit empty in waymarked trails, there are no route relations.
I am not aware of a tool to merge openstreetmap and third party data. I’d do like that: Export each trail as gpx or geojson, load that into the editor, align geometries to what is on the ground including all sources, create a route relation of it, mode, name, operator set.
The OSM account should say on its profile that it is used for organised editing.
2 Likes
Is there a way we can download the data?
I have looked at a few cases where there was a positional difference between the current OSM data and the proposed “import”, and based on the Strava Heatmap, the current OSM data is more accurate. If I can get an actual copy of the data, rather than just looking at it in the ESRI viewer, I can do more analysis and provide some examples.
Also, if the attributes in your data is representative of the OSM tagging you intend to use, there are several issues.
2 Likes
I was able to get a local copy of the data by opening the service in QGIS and then exporting as a shapefile.
I have found one or two cases where the position of the current OSM trail data could be improved, but for the most part aligning OSM to the proposed “import” data would make OSM worse. Here is an example from near 40.665357, -111.546045:
The proposed “import” data is in yellow, the existing OSM data is dashed purple-green, the Strava heatmap is in blue. One can see that the OSM data is much more closely aligned with the Strava Heatmap. In case the scale in the upper left corner cannot be seen in the screenshot, the maximum difference between the two data sources appears to be more than 230 feet (70 meters).
2 Likes
Here are two more examples I found where the existing OSM data is positionally better than the proposed “import” data. These is near 40.6890143, -111.5726175
The maximum difference in this case is about 220 feet.
1 Like
@astotes I don’t think you mentioned how your new routes were generated, e.g. by just one person walking the trails and recording a GPX track, or by drawing on a map or aerial images?
1 Like
Hi, thanks @tekim for taking the time to look into this. We are working on making the data available to download that should be changed either today or sometime next week, but I’m glad you were able to get it.
I will have to look more into specific trails, but many of them have been rerouted just this past summer and fall and may not be represented accurately on Strava Heat maps. There are also a lot of social trails that we have worked on limiting access to.
@alan_gr, the newest routes (3 trails) that were built this past season were walked and recorded with a GPX track. Our lead mapper has been working on making our routes more accurate since they started at Basin. A few of the trails have been updated with walked GPX tracks and most of them have been drawn using NAIP imagery. There are a few that were drawn before our lead worked here and will need to be double checked(we plan to get GPX tracks on these this coming spring-fall).
Hopefully this is all helpful, I can respond with more information once we look into the heat maps with our specific reroutes. As for now I’m thinking we will start with the trails that we have GPX tracks for.
What are the issues you notice with the tagging?
- OSM tags (keys and values) are case sensitive, and generally are lower case (an exception is the value of the name tag).
- The key “Oneway1” should be “oneway”, also, make sure that the order of the nodes in the way correspond to the allowed direction of travel.
- We don’t record “Shape__Len” or “Shape_Leng” in OSM. The length of a way can be calculated from the actual geometry by the end user if desired. In any event, as ways are split and combined it is likely to become inaccurate.
- In OSM we don’t use a "FID=* tag. The IDs are assigned automatically. If your organization has a trullly unique and persistant ID that you think should be included in OSM we can discuss if and how that should be done.
- Instead of seasonal=yes/no, consider seasonal=winter/sumer, etc. if the trail exists only part of the year, e.g. a winter only trail. If use of a trail is legally probibited part of the year, consider conditional restrictions (Conditional restrictions - OpenStreetMap Wiki)
- Opinions may differ, but access=yes + foot=no (e.g.) might be interpretted as ALL uses are allowed except for foot traffic. When I map I generally don’t use access=* if I have more specific tags, such as bicycle=* foot=*
- Might be other things…
The Strava Heatmap is updated monthly, so any trails that were rerouted, would show up fairly quickly. I suspect that Strava is current in most case unless the trail was rerouted within the last month.
If a there is a social trail in OSM, do not delete it! You can however tag it as informal=yes.
The particular technology doesn’t matter so much as the accuracy.
Imagery can be positionally inaccurate due to a lot of factors. One is the orthorectification process and the elevation model used in that process. Also, even recently captured imagery will continue to show the old location of trails.
Hi @tekim, thanks so much for your input!
I want to clarify a couple of items for you to help you understand our data. Some of the OSM data may be the accurate alignment, but we are positive that some of the OSM data is incorrect and/or misaligned. The reason why we are looking to work with community mapping with OSM is both to correct the incorrect trail tags and/or alignments that we have identified, and we are also looking to review our trail alignments with heatmap data to identify areas where we should correct our trail alignment. As we are the agency that manages the Basin Recreation trails, our most recently mapped data has been tracked with highly accurate Garmin GPX tracks or we have used NAIP imagery which we know is accurate because we check that it includes our most recent on-ground trail reroutes that we have personally implemented during field season. The areas that you are finding misaligned with heatmap data are our older mapped trails, and the information you are reporting is really helpful to us as we can double check this information and correct our data accordingly. We do not specifically run our data off of heatmap data, because we have identified many social trails that people are using, that are reflected in heatmap data, and incorrectly reported on these maps. This information is also helpful for our review as we can change the tags to reflect the tags informal=yes and access=no.
Thank you for this input as well!
For further clarification, our data layer is created as a GIS feature layer, of which the shape_length and FID fields are an integral part of the data geometry that cannot be deleted. You may not always see these fields within data because they can be hidden from public viewing, but they are necessary pieces of information that you cannot delete from a feature layer or gdb file.
We are planning on manually adding the tags referred to in our BR trail layer to the OSM data, not using automated data uploads to transfer these tags. But it is useful to understand that these fields are case sensitive, and we can change the names of our data fields to match the OSM community’s naming system. We have been in direct contact with an OSM board member, who referenced us to using the specific tags that we have included in our data layer.
I would specifically like to ask your input on the access tags you are referring to. As we are a government agency, we thought that it would be fitting to include access=yes in all of our trail layers, as all of our trails are publicly accessible. The only features that include foot=no are specifically mountain bike designated trails, of which bicycle=yes and mtb=yes. Do you see these tags as fully encompassing, or is there another way that you would personally tag this data? At this time, from a government agency perspective it appears from our end that we should retain access=yes in all of our tags, as we serve the public community and it is a priority for us to reflect that are trails are publicly accessible for the entire community.