Hey @tekim, checking in here as well to try to aid in you feeling more comfortable with our trail import process! We directly work with a strava heatmap developer who creates our community map. In assessing this map, we have positively identified many social trails that are incorrectly reported as official trails, as well incorrect trail alignments and missing trails that we newly built within the past two seasons. We have looked into heatmap information, and although the community is continually mapping their routes not all of our new trails are on the map. Whatever the reason for this, we want to ensure that the public community has access to our trail data, and as the land/trail managers we can ensure that our newer trail alignments are highly accurate and correct. Our trails that were mapped over a decade ago may not be accurate, and we will be reviewing all of these trails in relation to heatmap data to ensure the proper alignment before changing OSM data.
For a social trail you donât want people to use, Iâd have access=no in addition to the informal=yes.
@Seychelle_Marcus Thanks! It is great to see a land manager take a positive interest in OSM! I appreciate your responses. I have not been feeling comfortable with the proposed âimportâ due to some obvious issues with the data (more to come on that).
By all means, if there is an informal/social trail, tag it as informal=yes. If, and only if, it is legally not permissible to use such a trail (if someone be fined if they are caught using the trail), also tag it as access=no, and remove all other access tags, such as bicycle=, foot=
I am pretty sure it is possible to create a shapefile, geojson file, etc. without these, but as long as the people that will be editing OSM know not to copy these into OSM, we are good.
Not just the âfieldsâ but generally, the values in those fields. For example, bicycle=yes not Bicycle=Yes. Again, proper names can be of the case that is generally used for them in the real world (trail names, operator, etc.)
Speaking of tags, for trails that you are adding to OSM, you will need either a highway=* tag and/or piste tags (for winter trails).
Others in the OSM community might want to weigh in on this, but it is better to use more specific tags, e.g. bicycle=yes, foot=no only. Some data users may interpret access=yes, bicycle=yes, foot=no to mean that horses are allowed for example. Again, access=yes may be interpreted by some data consumers to mean that anyone can use the trail with any mode of travel unless more specific access tags override them. Perhaps that isnât the best interpretation, but why not just only use explicit tags to say exactly what is allowed and not allowed?
Related to the above: it might be best to explicitly tag the trails as to whether horses are allowed or not. Also, are e-bikes allowed?
Yes, there are a few cases. By all means, correct those. But, most of the positional differences I have found are due to errors in the proposed âimportâ data.
Garmin is a brand name. It doesnât imply any particular level of accuracy. And âhighly accurateâ is a very general term. As far as I know Garmin does not make commercial/survey level devices - but I may be incorrect. Even with a commercial/survey grade differential GPS it is best if it is operated by someone trained in its use. And of course, if a trail was GPSâed two years ago and you rerouted the trail subsequently, the data will now be wrong.
Due to the way photogrammetry and orthorectification works, imagery can be âaccurateâ in one location, but only a short distance away can have a significant error. This is particularly true in areas where there is a high level of relief (i.e. where there are steep slopes). Looking at the topo map for this area, it seems this is an area of high relief. Also, at least part of this area is highly forested to the extent that trails are not visible on overhead (aerial or satellite) imagery like NAIP.
But if you know that a trail is official, you can then align it to the Strava Heatmap. Note that because the heatmap is essentially an average of many GPS/GPX tracks, it will tend to round off sharp corners by a few meters (I would not consider an error of a few meters a problem though). As I think @Hungerburg mentioned some trails may show in the USGS 3D Elevation Program data. The USGS has stated that this data is accurate to within one meter.
Here is an example of where the USGS 3D Elevation Program (3DEP) can be used to align a trail. This is near 40.6990834, -111.568833:
Like in previous examples, the proposed âimportâ data is in yellow, and the OSM data is dashed green-purple. In this case both sources would benefit from some positional improvement, but the OSM data is still more accurate. The maximum error between the âimportâ data and 3DEP is about 55 feet.
This same location illustrates that one cannot always use NAIP to align trails, even if it were perfectly accurate:
The symbology of the trails is the same as in the above example, the basemap is NAIP. One can see that because of the tree canopy, it is impossible to see in this imagery where exactly the trail is.
I am now going to illustrate some possible issues with the oneway= tagging of the proposed âimportâ data. I will start in the same general area as is shown in the above examples:
One can see that the âimportâ data for Robâs Trail is oneway (note small white arrows) headed into a trailhead/parking lot, and that it is the only trail connected to that parking lot. This is unlikely. It means that if a trail user parked at this lot, to legally use this trail they would have to hike/bike along a road for some distance to another trainhead in order to access the other end of Robâs Trail and to return to where they parked.
This next example is near 40.7102223, -111.5025023
One can see that the oneway direction of the OSM and the âimportâ data for the Bamm Bamm trail is opposite. Based on the other trails in the area and the elevation data, it appears that OSM is right (although positionally it could be improved).
Using the same screenshot as above, one can see that the oneway direction for the âUp Trackâ differs between OSM and the âimportâ data. Based on the name we can assume that its oneway direction is uphill. That along with elevation data suggests that OSM is again correct.
The next example is nearby near 40.7097315, -111.5042014
In this case I have highlighted the polyline/linestring from import data in red. The issue here is that it is a oneway trail that deadends! In otherwords, if someone headed down this trail, they would not be legally allowed to leave!
The next example is near 40.7099195, -111.50094:
Using the same logic as with Bamm Bamm, it seems that OSM has the oneway direction correct here.
I sit pretty much on the other end of the planet. But Iâd say, LIDAR is the most accurate source. In a resort close by two years ago the pylons for a gondola were positioned from 3D-LIDAR, no terrestrial surveying took place for those, only for the top and bottom stations. Perhaps RTK correlated GPS with a base and a rover might be as or more accurate. Strava gets close (in 2D), by producing the means of lots of measurements. It helps pin-point the features in the terrain model much better than any single reading from a consumer GPS. They have âlast week activityâ layers, but not for me, as I do not pay for the service. Note, that LIDAR scans only happen ever so often, but some things also change not so much.
Be warned: QA tools may scold you, hgv carrying hazardous substances really allowed? BTW: The pump track Iâd map as a âleisure=track;sport=cyclingâ, no highway tag at all. PS: Curious what you and others think of adding route relations to openstreetmap. They may be quite useful to highlight the officially maintained trails, as openstreetmap consumers do just that, highlight them for their users, and as far as I can tell are not used at all for social trails. I think that is why the website is called âwaymarked trailsâ and not âall trailsâ.
I am continuing to find a significant number of issues with the âimportâ data (btw, I am putting âimportâ in quotes because since this is going to be done manually it may not be an import per se, nevertheless it is a convenient way to refer to this source). While one could argue that these irregularities will not make it into OSM because this is going to be a manual process, I am concerned that same level of care will be applied to the OSM edits as has apparently been applied to the âimportâ data.
Here are just a few of many examples:
This is a extreemly short spur trail or âovershootâ near 40.7169161, -111.5566316 It is only 0.21 feet long:
Another âspurâ trail, this one near 40.7170697, -111.5566159 and oddly also 0.21 feet long. It is also a oneway trail whose start isnât connected to anything.
Duplicate geometry near 40.7097302, -111.5040225 The two trails are 0.04 feet apart.
More duplicate geometry, this one near 40.7097902, -111.5040471
Disconnected trails near 40.7148194, -111.4999011
Exact duplicate geometry (two ways/polylines right on top of each other) near 40.7139358, -111.4914039 In the feature service it is a multipolyline whose parts overlap each other:
A way/polyline that nearly doubles back on itself near 40.7178942, -111.5496172 (distance beween two segments is 0.04 feet):
More exact duplicate geometry, this near 40.71536, -111.4898086 In the feature service it is a multipolyline whose parts overlap each other:
Random little spur trail that is only 0.22 feet long near 40.7112032, -111.5022851
Another case where trail nearly doubles back on itself, this one near 40.7675393, -111.576593 The two segments are only 0.15 feet apart - unlikely to be valid:
Another example of disconnected trails, this one near 40.7239792, -111.5571956 (there are about 160 such cases in the data)
I agree with the comments of others that access= is probably unnecessary. As I understand and use it, each value of highway= will have default understood permissions (e.g. highway=footway implies motor_vehicle=no, typically). From there, you can specify exact modes with each key (like foot= and bicycle=), or override all access modes with access=. Unless you have some really unique trails, I suspect your trails are not for passenger motor vehicles, which your current combination of access tags says the opposite.
In addition, Iâd recommend using your full formal name and specifying that you are a government-related organization (operator=Snyderville Basin Special Recreation District + operator:type=public), since âBasin Recreationâ is unclear to anyone not already familiar with your organization (as shown by n76âs first comment).
Otherwise, I donât map trails very often, so Iâd defer to the resources put out by the Trails Working Group from OSMUS, especially since theyâve already done work in Utahâs national parks.
@Seychelle_Marcus
I have calculated the positional differences between the OSM trails and the Basin data you provided (âimportâ trails that are not within 10 meters of an OSM trail):
I also translated the tags to something more like what we use in OSM. Note that we generally do not tag oneway=no or seasonal=no, these are assumed values. I took @dknelson9876 's suggestion regarding the operator tag.
While we are on the subject of tags, you might consider adding tags indicating whether horses (horse=yes/no/designated), dogs (dog=yes/no/leashed), and ebikes (electric_bicycle=yes/no/designated) are allowed.
A couple of more comments on the data.
The data includes roads. While I understand what you are trying to say is that the hiker or biker should exit the trail and travel along the road for a bit before regaining the trail, in OSM roads are not mapped as trails. They can be put into route relations, but perhaps we should get the basic geometry and tags done before we get to that advanced topic. Here is an example from around: 40.7382751, -111.5988804
I am also finding trails in the âimportâ data that do not show up in the Strava Heatmap and do not show up in any imagery (including the latest NAIP). Perhaps these are proposed or planned trails or trails that are not yet open to the public. There is special tagging for these which we can discuss if this is the case. Here is an example from near 40.717738, -111.5496993:
In general, my view of the âimportâ data remains the same. It is not of the quality such that it can simply be copied into OSM. Each difference has to be individually investigated against available sources. However there are opportunties to improve OSM data here too.
I can provide some suggestions as to a procedure that your people can follow to improve the data in OSM, but I may not have time for a few days.
Hi @tekim, here is our newest location for our data download. This file should now be accessible to the public with or without an active GIS account!
Br trails OSM Data
Hi @tekim, thanks for your feedback. Much appreciated.
As a GIS specialist I appreciate your interest in the accuracy of satellite imagery and coordinate systems. I love getting into the details of this kind of work. In case you are interested in why FID data and shape_length fields are necessary components of shapefiles, gdbs, etc⌠here attached a good google that explains this information.
Hi @dknelson! Thanks so much for these references, we will adjust our operator tag and add the operator:type tag as well. These suggestions are highly useful and helpful. Much appreciated!
Hi @Seychelle_Marcus, Thanks for this. Have you made any corrections since you published the service? In other words, do I need to rerun my analysis?
Also, FYI, I have made some positional improvements to the OSM data.
Thanks for taking the time to look into this so thoroughly! Itâs useful for us to have these areas pointed out so we can improve our data.
This trail system including Pawmaste is a great example of why I mentioned the Strava Heatmap may not be representing our trails accurately, despite it being updated monthly. Our trails crew built this trail in the summer/fall 2024 and has been open to the public since October 2024. Due to itâs nature, it is not a trail that I can see people wanting to track on strava (It is an open-space off-leash dog area).
So from what Iâm understanding is for trails such as this, that we have built and are not represented on OSM yet, we can draw them in with our GPX tracks, rather than doing an import.
Hi again @Seychelle_Marcus - the file still has values that are not lower cased. Generally values, except for the name and the operator, should be lower case, so bicycle=designated, not bicycle=Designated.
Also, I would not have seasonal=no, I would omit that tag in that case (set to null). Same for oneway. It might be better to provide the data in a geojson file where such tags can be omitted for individual records.
Finally, it isnât immediately clear how one can actually download the data from that link.
Hi OSM Community,
Checking in with an update to the Basin Rec trail update project. Our team is learning so much about the OSM update process, and we appreciate the community for welcoming us and teaching us about this process! As a part of this work, we are realizing that our trail update project falls under the OSM terminology of an âorganized editingâ project not an âimportâ project.
The data file mentioned in our project page, is to be used for manual reference and update of OSM tags and alignments. The data fields within our data upload are meant solely as a reference to our trail regulations, to be used for community mappers to reference and update OSM tags as they see fit with reference to this information. In the case that features in the data layer are disconnected, or have minor inaccuracies of a couple of feet, we will be manually correcting these errors both is OSM data and in our BR trail file, and we hope and expect that the community will use your practical judgement to correct these errors. Our agency has been building and managing trails since 1986, hence some of our older data can be misaligned and/or not highly accurate today. We will be looking for the errors in our data as we go through OSM mapping corrections, but if the community identifies specific trails that look to be off by more than 10m, we hope that you alert us of these details so that we can review the trail alignments and get back to the community on if the trail alignment has been changed by our trail crew, or if these are inaccuracies caused by our large amount of trail data information gathered over the past 30ish years.
Hi @tekim, thanks for looking into the positional improvements. We have not changed any trail alignment data at this time, we are just starting to work on assessing our tagging data with the Trails Working Group to understand how to best tag our information. As far as capitalization of our field data, we are pursuing the âorganized editingâ route for our project, so manual addition of OSM tags will alleviate the issue of our data being capitalized while OSM tags are not capitalized.
here is the link to our open source data download and here is a screenshot of where you can download the data directly from this link:
You will make the process a lot easier for yourself if you got the tagging correct in your reference file. You will then, after manual review, simply be able to copy-paste from your reference file to the OSM data, as opposed to manually typing in tags, which is tedious and error prone.
That is a great point @tekim. After working with the Trails Working Group chapter to discern the best tags for this information, we will do our best to translate the tags to match OSM data well. Just so that you are aware, we are doing our best to pursue this project to help the public. As we are on-ground land and trail managers we are highly limited on time, and we may not be able to make everything perfect unfortunately. We will do our absolute best with the limited time we have going into field season this year.
If you are short on time (as we all are), you will save yourself a ton of time if you get the tagging correct up front (and it is not that difficult, I wrote a script to translate your original file to proper OSM tagging in about 1/2 hour). I made this quick video to show how if the tagging is correct you can just essentially copy-paste from your referenc file to OSM:
