[Tagging] Reviving the path discussion - the increasing importance of trails in OSM

Fri May 22 16:57:03 UTC 2020

> going from gravel to dirt to sections with many trees roots.

This can be tagged as surface=unpaved - 99.9% objective and verifiable. (If
you have sections of half-crumbled, old asphalt or concrete, mixed in with
gravel and dirt, it gets a little iffy, but that situation is rare in most
places).

I agree that width can be hard to tag consistently on trails or paths
which developed informally. In theory it is possible to break it into many
short ways and tag each section with an approximate width, but that can get
tedious. (It's also possible to do that if the surface changes from gravel
to compacted to dirt frequently, but not necessary).

In the short term, it's okay to tag an estimated, average width. If it's 1
to 0.3 meters, use 0.5 - this still shows a difference from a path which is
1.5 to 4 meters wide (which you might estimate as 2.5 meters?).

-- Joseph Eisenberg

On Fri, May 22, 2020 at 9:22 AM Jake Edmonds via Tagging <
tagging at openstreetmap.org> wrote:

> I’m going to throw this in rather randomly but the reason i don’t tag
> width and surface is that the footpaths I’m mapping vary widely. Getting
> wider and thinner and going from gravel to dirt to sections with many trees
> roots. Plus the surface tag is rather subjective.
>
> Sent from Jake Edmonds' iPhone
>
> On 22 May 2020, at 17:48, Daniel Westergren <westis at gmail.com> wrote:
>
> 
> Yeah, I think in terms of tagging we don't get further in this discussion.
> But it has been very valuable to me. I've done a couple of video tutorials
> about the basics of mapping trails in OSM and the next one will be about
> what tags to use and why.
>
> They are in Swedish, but I'm planning to do English versions later as
> well. It's probably been done before, but I guess we need to use different
> ways in this widespread community to reach mappers to get more useful data
> to work with.
>
> And regarding rendering of surface... Yeah, both an advantage and
> disadvantage of OSM is its diversity. What for many sounds like the only
> logical way may conflict with the views of others.
>
> Great work with your rendering btw! I'd love to discuss more about that
> outside of this mailing list, as I'm also helping out with creating a
> custom rendering for trail running purposes. OpenStreetMap is indeed very
> urban-centred still, which brings me back to my opening lines of this
> thread, that OSM hasn't caught up with how lots of people actually are
> using it now, like routing and rendering for hiking, cycling and running,
> areas where Google Maps etc. are and will continue to be way behind.
>
> Thanks for valuable input!!
>
> /Daniel
>
> Den fre 22 maj 2020 kl 17:26 skrev Andy Townsend <ajt1047 at gmail.com>:
>
>> On 22/05/2020 15:55, Daniel Westergren wrote:
>> > And there actually seems to be a pull request finally solving the
>> > paved/unpaved rendering that was opened 7 years ago?!?
>> > https://github.com/gravitystorm/openstreetmap-carto/pull/4137
>> >
>> > If that makes it to the default map it will certainly help people to
>> > tag surface, because they will see that it makes sense.
>> >
>> >
>> I'm sure you didn't mean it to sound like it, but this does read
>> somewhat as if rendering "surface" on paths is somehow "obvious" and
>> "easy", and it's an "oversight" that the OSM Carto folks haven't been
>> doing it since basically forever.
>>
>> It's not - I think that pnorman's comment of
>>
>> https://github.com/gravitystorm/openstreetmap-carto/pull/3399#issuecomment-596656115
>> still applies:
>>
>>  > I'm of the opinion that the only way we can get the cartographic
>> "space" to render unpaved surfaces is to drop something else, like
>> access restriction rendering.
>>
>> I think that there's another problem with the standard style as well -
>> aside from surface rendering it's hugely biased towards urban centres.
>> Looking at https://www.openstreetmap.org/#map=13/53.9023/-0.8856 you
>> can't see any paths at all at that zoom level due to the "Central
>> European Graveyard problem" - compare with
>>
>> https://map.atownsend.org.uk/maps/map/map.html#zoom=13&lat=53.9006&lon=-0.8795
>> to see what you're missing.
>>
>> What we need are concrete suggestions of how to get there from here,
>> (and Ture Pålsson's mail of
>> https://lists.openstreetmap.org/pipermail/tagging/2020-May/052747.html
>> is exactly the sort of thing I'm looking for).
>>
>> Adding a sane surface rendering in addition to everything else is hard -
>> I've not managed it across the board at https://map.atownsend.org.uk
>> although that is influenced by sac_scale, trail_visibility and width.
>> All suggestions gratefully received, but what's needed some code that
>> people can play with and see what the effect is on various areas and
>> different zoom levels - not just emails to the tagging list*.
>>
>> Best Regards,
>>
>> Andy
>>
>> * yes, I do realise the irony of "yet another email to the tagging list"!
>>
>>       75  Tag:amenity=motorcycle_taxi not approved
>>       58  Remove non-prefixed versions of 'contact:' scheme
>>       49  RFC ele:regional
>>       42  relations & paths
>>       35  Doorzone bicycle lanes
>>       34  Permanent ID/URI --- off topic email
>>       28  Feature Proposal - RFC - Recreational route relation roles
>>       27  Reviving the path discussion - the increasing importance of
>> trails in OSM
>>
>>
>>
>> _______________________________________________
>> Tagging mailing list
>> Tagging at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20200522/2e47c0fb/attachment-0001.htm>