Re: [Tagging] How to put a name tag on an area with more than one type?

[Ture Pålsson via Tagging]

> 14 dec. 2020 kl. 19:06 skrev Ture Pålsson :
> 
> I have implemented the merge-adjacent-areas scheme in my renderer. I’ll try 
> to get a demo up… :-)
> 
> Having said that, as a renderer implementer, I have a slight preference for 
> the relation method. It is s implyeasier to join things on numeric id than to 
> join them by adjacency.

I don’t remember whether this has already been mentioned, but it just occurred 
to me:

One problem with merging adjacent areas for labelling purposes, is when the 
areas share no tags, except the name. For example, it is not unusual to have a 
natural=wetland sharing some boundary with a natural=water, where the name 
applies to the entire wet area. So you can’t just merge adjacent 
natuarl=wetland, you also have to remember to merge natural=water with adjacent 
natural=wetland, if their names match. And natural=riverbank. And 
landuse=reservoir ( :-) ). And the gods of cartography knows what else.

I am now leaning a bit heavier towards the ”relation” alternative…

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

[Ture Pålsson via Tagging]

> 16 dec. 2020 kl. 17:25 skrev Tomas Straupis :
> 
> What about maps made according to Cartographic conventions?
>  You know, something on the lines of: https://map.geo.admin.ch 
>  Would
> it be possible to make maps of such quality writing general queries
> like natural=water?

Could you elaborate a bit on what cartographic features on that map are 
possible or impossible with the different reservoir tagging schemes? Being 
Swedish, not Swiss, makes it hard for me to know what to look for.

(For the record, I have no particular opinion in this question, except that I 
think OSM should immediately adapt its tagging to the Swedish Terrängkartan, T5 
edition, but I think that’s going to be a hard sell! :-) )

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] How to put a name tag on an area with more than one type?

[Ture Pålsson via Tagging]

2020-12-15 08:48  Anders Torger a écrit:


However I'll soon go through these edits again and then I will add multipolygon 
for the split, and if your renderer takes that into account we should end up 
with a single multipolygon. I think in the case of Muddus it will work in all 
cases, ie we won't hit the corner case described above which should be very 
rare. So I think this naming concept is okay as a stepping stone until we can 
move forward on this issue. I hope we can make a point though that this is not 
a acceptable as a long-term solution.


I'm drifting away from tagging into renderer implementation territory
now, but this thread is large anyway, so what the heck... :-) 


Your last edits actually caused some headaches for my renderer, because
you added in some "satellite" bits of bog that were not (I think)
previously included. The renderer insists on putting a label on each
disjoint area, so I ended up with a handful of them. 


So I resorted to the old "buffer and join" hack, adding a 100-meter
buffer around each area and ST_Union:ing the result (isn't it fun when
you realize you have all the plumbing in place and can do new things by
just adding a few lines of code?). Now the map looks like this:
http://lab3.turepalsson.se/~ture/rijmmoahpe-20201216.pdf . The red
outlines show the areas that the renderer is actually considering when
placing the labels. 


The label placement for Aleldusáhpe near the top of the map looks...
less than ideal. I suspect that this is because I use (an implementation
of) the Mapbox polylabel [1] algorithm, and it gets derailed by the
small holes inside the areas. Maybe it would be better to use a convex
hull... or just a bigger buffer. Label placement is a black art... 


Links:
--
[1] https://github.com/mapbox/polylabel___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] How to put a name tag on an area with more than one type?

[Ture Pålsson via Tagging]

2020-12-15 23:38 skrev Martin Koppenhoefer:


Take a look back what I mentioned 3 days ago in my first answer: "...If we want to map all 
those "meta areas" with names we would do well to think about additional ways of 
delimiting space (i.e. different kind of geometry objects), e.g. a fuzzy border could be 
represented by providing different points for which it seems undisputed that they are in or out of 
the area in question. This would be very lightweight for all mappers, because it avoids clear lines 
which are confusing when they do not correspond with something observable."


This reminds me of my friend's somewhat tongue-in-cheek suggestion,
which I mentioned in another thread, that a fuzzy area should be mapped
as a function that takes a point as input and returns a number in [0,
1]; 0 for "definitely outside", 1 for "definitely inside". 


Here's an off-the-charts complicated idea for doing that, just to get us
started: 


A fuzzy area is mapped as a relation, type=fuzzy_area. Some tag on that
relation ('code', perhaps) contains a program written in a small
stack-based language offering geometric operators, such as distance,
intersects, touches, etc. The program will get a point as input on the
top of the stack, and should consume it and leave a number on top of the
stack. Geometric constants needed by the program (points, lines, areas)
are supplied as members (nodes, ways, multipolygon relations) of the
relation. If the 'code' tag is missing, all members should be nodes, and
the result will be computed using a default algorithm (which remains to
be defined) using those points. 


1/2 :-)___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] How to put a name tag on an area with more than one type?

[Ture Pålsson via Tagging]

> 15 dec. 2020 kl. 08:26 skrev Anders Torger :
> 
> And about wetlands, couldn't those be just rendered on top of forests so we 
> didn't have to make these complex multipolygons? 

It does make sense to have overlapping wetland and forest, though. To take a 
swedish example: down here in 08-land (note to non-Swedes: Stockholm, telephone 
area code 08 :-) ), we get very little open bog, but a fair amount of soggy 
forest.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] How to put a name tag on an area with more than one type?

[Ture Pålsson via Tagging]

> 15 dec. 2020 kl. 08:26 skrev Anders Torger :
> 
> And about wasting mapper's time. What about that we have to punch holes and 
> make river areas for rivers nowadays? Punch holes for waters in forest areas? 

Anecdote: When I first started toying with rendering about ten years ago, I had 
problems with lakes disappearing under forests. I thought it was completely 
unrealistic to expect mappers to punch holes in forests for lakes, especially 
as everything looked fine on osm.org , so I added a rule that 
smaller areas always render on top of larger areas. Then the map at osm.org 
 changed to requiring holes, and for a very long time most 
lakes in Sweden had little trees growing on them on osm.org . 
I think most of them have been multipolygon-ized by now.


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] How to put a name tag on an area with more than one type?

[Ture Pålsson via Tagging]

> 14 dec. 2020 kl. 22:30 skrev Anders Torger :
> 
> Cool! It would be really nice to see a demo :-)

Rijmmoáhpe renders sort of reasonably now at http://lab3.turepalsson.se/map 
 . (On the generated PDF, not on the ”slippy 
map”. And it’s a bit hard to find, since my low-zoom tiles are so bad!). Or 
check my PDF at http://lab3.turepalsson.se/map/download/ecb7556.pdf 
 .

It still gets two labels because the area is split in half by Rijmmojåhko 
flowing through it.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] How to put a name tag on an area with more than one type?

[Ture Pålsson via Tagging]

> 14 dec. 2020 kl. 19:06 skrev Ture Pålsson  (that’s me!):
> 
> I think it would be good to keep the set of possible values for the ’type’ 
> tag small, so I’d like to propose another level of indirection; something like
> 
>  type=named_area, named_area=natural, natural=wetland, name=Peter’s Pot

After having slept on it, make that

type=named_area, natural=wetland, wetland=Peter’s Pot

I.e, skip the named_area=natural bit. I’m not too fond of OSM:s ”rootless” tag 
structure, but we seem to be doing ok with it everywhere else…___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] How to put a name tag on an area with more than one type?

[Ture Pålsson via Tagging]

14 dec. 2020 kl. 15:49 skrev Anders Torger :
> 
> Okay, but why does the OSM-Carto renderer, and all other renderers known to 
> man(?) make multiple text labels then, when it should be a single one? Look 
> at the result, it looks horrible. Do you really think this is the way it 
> should be done, also long-term? Also note that the tags do differ, otherwise 
> it would be a single multipolygon, it's both wetland=bog and wetland=marsh.

I have implemented the merge-adjacent-areas scheme in my renderer. I’ll try to 
get a demo up… :-)

Having said that, as a renderer implementer, I have a slight preference for the 
relation method. It is s implyeasier to join things on numeric id than to join 
them by adjacency.

I noticed that you have tagged the ”name” relation as (if I remember correctly)

  type=natural, natural=wetland, name=Rijmmoáhppe

I think it would be good to keep the set of possible values for the ’type’ tag 
small, so I’d like to propose another level of indirection; something like

  type=named_area, named_area=natural, natural=wetland, name=Peter’s Pot

And having said all *that*, on the subject of adjacent-areas vs. relations, 
again as a renderer implementer, I very much prefer when there is one way 
rather than two of doing something. First of all, if there are two ways, I need 
to write code for both of them. Second, some things invariably end up being 
tagged with *both* schemes (adjacent areas with name tags *and* a relation) 
which means that I need to detect that case to eliminate duplicate labels. So 
if a majority of mappers find relations too hard to use, I think I would vote 
for the adjacent-areas method, even though using a relation seems ”cleaner”.



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] How to put a name tag on an area with more than one type?

[Ture Pålsson via Tagging]

> 13 dec. 2020 kl. 16:15 skrev Christoph Hormann :
> 
> I am trying to understand what the issue is with the recommendation for 
> mapping you have received from multiple sides here.

Just to clarify, could you summarise what that recommendation is, for the 
Rijmmoáhpe case? The thread has become a little unwieldy (partially my fault… 
sorry about that!).


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] How to put a name tag on an area with more than one type?

[Ture Pålsson via Tagging]

> 13 dec. 2020 kl. 15:21 skrev Paul Allen :
> 
>  I'm probably misunderstanding this, but torp doesn't seem to be a type of
> building.  The tag building=torp says that this building IS a torp (as
> opposed to a house, or a shop, or a garage, or a shed, or a barn).
> If you feel a need to indicate that a building was once part of a torp,
> building=torp isn't the way to do it.
> 

You’re right; I was extremely sloppy with terminology there. A torp is (or 
rather was) a small farm, usually either part of a bigger farm and farmed by a 
tenant, paying rent to the bigger farm in the form of work, or farmed by a 
soldier (paying rent by, well, being a soldier). Today, most of them are either 
completely gone or used as summer houses, very probably not with the original 
building.

I suppose what I wanted to say was:

* place=locality is used about all sorts of things, both inhabited and 
uninhabited, and is pretty much useless.

* There are many places around Sweden (and probably the rest of the world as 
well!) where there is just forest (or fields) today, that have a name because 
they were, at some time, a torp (or some other kind of settlement). To render 
these in ”swedish topo-map style” (i.e, italics), some sort of tagging is 
needed to say ”this place has a name because it used to be a 
farm/torp/whatever, but today there is nothing here”. (I suppose some would 
argue that these should not be in OSM at all, because they are very hard to 
verify on the ground).

* There are also isolated dwellings, hamlets, villages, suburbs and airport car 
parks (comparing old and present-day maps around Stockholm-Arlanda airport is 
quite fun) whose names refer to long-gone torps, but those can be tagged 
according to their present-day usage.

And I’d like to apologize to Anders for derailing this thread by bringing up 
the subject at all! It was intended as an illustration of the uselessness of 
locality, but I got a bit carried away. Trying to render consistent maps from 
inconsistent OSM data does that to you. =)

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] How to put a name tag on an area with more than one type?

[Ture Pålsson via Tagging]

> 13 dec. 2020 kl. 11:40 skrev stevea :
> 
> Thank you, Ture:  an excellent example and a great brief overview.  From my 
> perspective (if I were more of an OSM beginner), I might ask about the 
> example of "torp:"  might creating a tag like building=torp seem like it's on 
> a good track?  Maybe not, as the value is a Swedish word, but there is an 
> historical cognate in British English (more OSM-like for tagging purposes) of 
> "thorpe" (maybe with an e at the end, maybe not) which came from, but doesn't 
> really mean the same thing all by itself in English, 

In many cases, the buildings are long gone and just the name remains. I 
*thought* that those places were still labelled in upright letters in the 
”official” maps, but it turns out that I was wrong — in the present-day 
online-only version of those maps, those names that have lost their buildings 
have turned italic. Which is good for us, because it means we could still map 
building=torp where there actually is a building, and something else 
(historic=torp? historic=farm, farm=torp?) where there isn’t. :)


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] How to put a name tag on an area with more than one type?

[Ture Pålsson via Tagging]

> 12 dec. 2020 kl. 16:18 skrev Anders Torger :
> 
> Indeed, place=locality seems to be a dead end, it's been misused quite much 
> and there's talks about removing it from OSM-Carto, and you can't render good 
> maps from it, so it's technically a poor concept as well. 


Around where I live (Stockholm), most place=locality seem to refer to old 
”torp” [1] and other (at least historically) inhabited places. At least the 
classic ”Terrängkartan” (the ”official” paper maps of Sweden, sadly no longer 
in production) rendered those differently from pure terrain names (upright vs. 
italic font).

Here in the lake Mälaren valley almost every square meter has been farmed at 
some point, so most names refer to settled places (or archaeological traces of 
them). Up north where I grew up, and where Anders seems to be mapping, you get 
a lot more names that refer to bogs, slopes, mountains and that sort of thing.

It would be nice to have that distinction in OSM, too.

[1] https://en.wikipedia.org/wiki/Torp_(architecture)


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] coastline v. water

[Ture Pålsson via Tagging]

By the way, an... amusing test case for all things related to water and 
label placement is Lake Mälaren, the lake that Stockholm is separating 
from the sea, and all its (named!) nooks and crannies: 
https://www.openstreetmap.org/relation/1433877 . I've had at least 3 
different bits of it poking into different corners of the map at times.


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] coastline v. water

[Ture Pålsson via Tagging]

I mentioned the problem of mapping "fuzzy" areas to a friend, who 
replied along the lines of "why, of course such areas should be mapped 
as functions, taking a point as input and returning a real between 0 
(definitely outside) and 1 (definitely inside)!".


I'd rather not have to implement that, though. =)

(And I agree with Kevin about reconstructing an area from a point + 
surrounding coastline. I'd like to see at least an outline of an 
algorithm for that! Having said that, I also recognise that 
gazillion-point polygons to outline Skagerrak, Kattegatt, the North Sea 
and what-have-you may not be the prettiest state of things either...)


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Basic cartography features missing, why?

[Ture Pålsson via Tagging]

> 6 nov. 2020 kl. 19:31 skrev Anders Torger :
> 
> Hello everyone, newcomer here!
> 

Only marginally related to the discussion, but: For Sweden, you may want to 
look at the rendering at http://lab3.turepalsson.se/map/ 
 (the generated PDF:s, not the tiles; those 
are horrible at smaller scales. :-) )

If there’s any data that isn’t rendered but should be. I can probably add that 
quite easily.

(The data used may be a few weeks old, since I need to trigged rendering DB 
updates manually.)

 — T


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] PTv2 public_transport=stop_position for stop positions that vary based on train length

[Ture Pålsson via Tagging]

Here in Stockholm, trains seem to line up one end of the train with one 
end of the platform. Usually, that's the end where the entrance is, but 
sometimes there are entrances at both ends, so if you arrive just in 
time at an unfamiliar station and find that it's a short train, you may 
be in for a run... (BTDT, with a day hike rucksack...)


2020-08-10 09:20 skrev Warin:

[...]
Why is the front of the vehicle (bus, train, ferry.. and possibly
others) mapped?

Would it not be better to map the thing most usefull to most people?
That would be where passengers get on/off, on multiple exit vehicles
like train then the average of these positions could be used.

Trains here of varying lengths tend to place the middle of the train
at the middle of the platform - thus it is consistent for any train
length. The only exceptions are where the platform is shorter than the
train so the train stops such that the designated car/carriage is
centered on the platform - thus it is still a consistent location for
OSM.


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Ture Pålsson via Tagging]

> 27 maj 2020 kl. 12:42 skrev Volker Schmidt :
> 
> 
> 
> […]how to indicate that a path is a hiking trail. It has been proposed to 
> introduce a new value path=trail or path=hiking for that purpose. 
> As we do already have the sac_scale tagging for level of difficulty of hiking 
> paths and the lowest level of that is sac_scale=hiking. This would correspond 
> exactly, in my view, to the new proposed tag value(s) without introducing a 
> new tagging.
> sac_scale=hiking is used 319 785 times - so I do not see a need to create a 
> new tagging meaning exactly the same thing.
> 

Would it be wrong to set sac_scale=hiking on an urban footway? I’m worried that 
we’ll get highway=path, foot=designated, cycle=designated, surface=paved, 
width=2.5, lit=yes, rubbish_bins_every=100m, sac_scale=hiking.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Ture Pålsson via Tagging]

> 27 maj 2020 kl. 06:54 skrev Yves :
> […]
> I'm as fool as you, and always mapped the paved, urban-style as 
> highway=footway and the ones in the wilderness as highway =path. 
> 

So have I, and so have, as far as I can tell from the areas I am familiar with, 
most mappers in Sweden.

Not all of them, however, and given the current state of the Wiki, I can’t 
really say that those others are *wrong*.

And if I draw a new way in JOSM, and then pick the preset which has the ”white 
walkers above white bicycle on a blue background” [1] icon, which is what I 
would do as a naïve mapper to map an urban cycleway (most of them are shared 
around here, to the annoyance of cyclists and pedestrians alike), I get 
highway=path, bicycle=designated, foot=designated.

So, as I have said before, when rendering a map and faced with a 
highway=footway or highway=path I can always make an initial guess about how to 
render it, but I have to be prepared to consider at least *=designated, surface 
and width as well.

[1] 
https://www.transportstyrelsen.se/sv/vagtrafik/Vagmarken/Pabudsmarken/Pabjuden-gang--och-cykelbana/
 



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Ture Pålsson via Tagging]

26 maj 2020 kl. 11:33 skrev Volker Schmidt :
> 
> We have now been reviving the path discussion in 73 messages, and counting ...
> I still feel we are not understanding each other (or is it only me who is 
> lost?)
> To me a highway=path is a concept that is well defined in the wiki, and the 
> various types can be described with existing tags.

The text and image at the top of 
https://wiki.openstreetmap.org/wiki/Tag:highway%3Dpath 
 seems to indicate that 
highway=path is mainly intended for more or less unprepared paths. Yet, the 
examples at the bottom of the page show how to tag paved, signed, urban foot- 
and cycleways.

And I am fairy sure I have seen people advocate that highway=footway and 
=cycleway should be deprecated and replaced with =path plus various extra tags.

Personally, I would love to see highway=path in the woods and =cycleway/footway 
for the purpose-built stuff, but existing tagging seems to disagree. Only a few 
days ago, someone changed a >2-metre-wide, paved, signed [1], lit (I may be 
wrong about that), cycleway near where I live from highway=cycleway to 
highway=path.

So the problem is not that we can’t describe things, but that there are too 
many ways to describe them. The reason that I have the complicated rule set I 
described earlier for rendering highway=path is not that I think it’s fun, but 
that it’s necessary to make sense of the data.

Admittedly, adding yet another tag to the soup might not be the right solution 
to that problem...

[1] https://wiki.openstreetmap.org/wiki/File:120px-Zeichen_240.svg.png___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Ture Pålsson via Tagging]

> 22 maj 2020 kl. 17:25 skrev Andy Townsend :
> 
> 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=53.9006=-0.8795
>  to see what you're missing.
> 

Slightly off-topic for the tagging list, since it's more of a rendering issue, 
but: This is something I have been scratching my head over, too. In some areas 
of Sweden, it is perfectly possible to render all footpaths even on at 50k 
scale map, but then you come across areas like this, which just clutter up 
completely: 
https://www.openstreetmap.org/?mlat=59.4373=17.8101#map=15/59.4373/17.8101=N
 
.
 I would like to render only the "main throughfares", but it's hard to know 
what they are, when everything is just highway=path. I have considered just 
running some spanning-tree algorithm and hoping for the best. :-)

The 50k "official" maps I am trying to emulate used to have a rule that paths 
were shown if they were at least 500m (I think) and led to a destination which 
was also visible on the map. However, Lantmäteriet ("OS Sweden") no longer 
maintain footpaths except those that are reported by sports clubs, local 
councils, hiking clubs etc because they lack the "boots on the ground" to do 
so. (THis is obviously a niche for OSM to fill!) Unfortunately, the "leads to" 
bit is tricky to automate given OSM data.

(Graveyards are less of a problem for me. I haven't bothered, but I could tell 
my renderer not to render footpaths in them, unless the scale is 1:12500 or 
bigger. Ideally, I would like to ignore everything but paths leading from one 
gate to one on the opposite side, but I haven't come up with a way of 
identifying those, yet. Some kind of graph analysis seems to be called for. 
Again, it would be nice with some sort of hints about that the throughfares 
are.)

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Ture Pålsson via Tagging]

> 22 maj 2020 kl. 12:52 skrev Daniel Westergren :
> 
> […] Then there is width, which is only tagged on 3.5% of highway=path. I was 
> discussing width of paths in another forum. For a forest path, would you say 
> width is measured as the actual tread on the ground only? For a runner and 
> MTB cyclist that would make sense, but for a hiker with a big backpack a 
> width of 0.3 m may mean they think it's not possible to walk there. 

We need loading_gauge=* tag. :-)

(https://en.wikipedia.org/wiki/Loading_gauge 
)


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Ture Pålsson via Tagging]

21 maj 2020 kl. 09:21 skrev Daniel Westergren :
> 
> Expanding on the discussion about attributes for trails. What's the current 
> status of the highway=path mess? OSM is increasingly becoming more useful for 
> forest trails than for car roads (for which other sources are usually more 
> up-to-date, to be honest). But the default rendering doesn't differentiate 
> between a forest or mountain path and a paved, combined foot- and cycleway in 
> an urban environment.

Just as an example, from a data-consumer POV, here's my current rules for 
rendering highway=path (using the symbols from 
https://www.lantmateriet.se/globalassets/kartor-och-geografisk-information/kartor/tf_terrangkartan.pdf
 
;
 the Swedish equivalent of the OS Landranger maps). (You can check the results 
at http://lab3.turepalsson.se/map ).

1. If it's in a built-up area, and the scale is smaller than 1:12500, don't 
render it. It just clutters things too much. This rule should probably be moved 
a bit later to cater for those paths that are more like roads...

2. If it has trail_visibliity = "horrible", "poor" or "no", don't render it. 
Rationale: If I can't see the damned thing when I'm standing on it, it is 
useless for navigation.

3. If it has bicycle=designated and (no mtb_scale or mtb_scale < 1) and (no 
width or width > 2.5), there are some alternatives (rationale: people put 
bicycle=designated on just about everything, from normal cycle paths to 
advanced MTB tracks)

3.1 if it has a "hard" surface ("paved", "asphalt", "concrete"), render it as 
an "approach road, park road, cycle path" (thin solid line). Rationale: This is 
*probably* a bog standard Swedish cycleway. You could drive a car down it (but 
you'd have problems passing someone, and it's probably illegal, unless you are 
a service vehicle from the local council out to empty rubbish bins and change 
light bulbs).

3.2 If it doesn't have surface, or it has a surface which is not "ground", 
render it as a "tractor track" (thin dashed line). Rationale: No hard surface, 
but apparently intended for bikes in some way. The way people usually tag 
things, it is probably possible to drive tractor, or even a car, if you're 
careful, but given that we may not have an explicit width, there is a chance of 
error.

3.3 Otherwise, render it as a "foot path" (dotted line). If we got here, then 
it has surface=ground, so even if it's bicycle=designated (see 3), you don't 
want to commute to work on it in nice shoes and trousers.

4. If we got this far, render it as a "foot path" (dotted line). Whatever is 
is, it has failed all attempts at classing it as anything other than that.

What I suppose that I wish to say with all this is that in practice, I have 
seen highway=path used to mean anything from something that is not even visible 
on the ground, to something that is impossible to distinguish from a small road 
(I have seen "single track roads" in Scotland that were on par with some of the 
highway=path:s I have come across). To know which is is, you have to check 
several other tags, but you can't rely on any of them being there. OSM tagging 
is a complete mess of tags describing intention (but not very well -- is 
"bicycle=designated" a bicycle superhighway or an MTB track?), tags describing 
legal access (are bicycles required, or even allowed, to use this), and tags 
describing physical properties such as width and surface and as a data 
consumer, you have to be prepared for any combination of them. This is my 
ruleset for highway=path; many of the other highway=* are equally complicated.

I'm sorry this ended up so long and unfocused. Map renderer's frustration, I 
suppose...

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging