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

Re: [Tagging] Ski picnic room

[Ture Pålsson]

2020-02-03 13:17 skrev Paul Allen:

> [...] 
> 
> I'm hoping somebody will come up with a less generic name.  Or a better name 
> than "indoor_food_consumption" that means the same thing.  Failing that, 
> "dining_area" is the least bad name I've thought of so far.  Or "eating_area" 
> might be better.

I am fairly sure that I have seen "picnic area" in some London museums.
At least the Science Museum uses the phrase on their web site.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Residential=rural, =urban?

[Ture Pålsson]

2019-04-10 10:28 a écrit Joseph Eisenberg:

[...]
Does anyone feel like doing some research into how these tags is
actually used, so that the wiki page can match? Or has anyone used
this tag themselves?


I took a quick look in Sweden. There are only a few hundred of them 
(369, to be exact, in my database), nearly(?) all by the same mapper. 
The residential=rural ones seem to be single houses or small groups of 
houses in the countryside. The residential=urban ones are mostly groups 
of detached houses within a village or town (like this one: 
https://www.openstreetmap.org/way/209513955). If that is "urban", I'm 
not sure how to tag high-rise areas or inner-city blocks!


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

Re: [Tagging] tree rows vs individual trees

[Ture Pålsson]

2019-02-11 14:55 skrev Tomas Straupis:


2019-02-11, pr, 11:29 Ture Pålsson rašė:
[ ... ]
  2. If (1) is true in other countries, maybe "tree_row" should be an
attribute of a road/railroad? Say
highway=residential+tree_row=left|right|both. This way it would be
much more convenient to create cartographically correct maps in 25k
50k scales without resorting to complex generalisation operations like
displacement?


That possiblity already exists, as tree_lined=*. However, I believe tree 
rows sometimes appear on their own. For example, the tree row in this 
picture (which was in the side bar of the Wiki for natural=tree_row) 
looks like it is not lining anything in particular: 
https://upload.wikimedia.org/wikipedia/commons/thumb/6/69/Row_of_Poplar_Trees_-_geograph.org.uk_-_242206.jpg/200px-Row_of_Poplar_Trees_-_geograph.org.uk_-_242206.jpg


Byt yes, using tree_lined=* when appropriate certainly makes my life as 
a renderer developer easier, though I guess it is harder to combine with 
also mapping individual trees. :)



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

Re: [Tagging] tree rows vs individual trees

[Ture Pålsson]

2019-02-09 15:23 skrev Tom Pfeifer:

If a renderer wants to cluster any trees that can be done 
algorithmically.


As someone who tries to render smallish-scale (typcally 1:25000 or 
1:5) maps from OSM data, I am always slightly annoyed when someone 
states that something does not need to be mapped bacuse it can be 
inferred algorithmically from other data, without describing or at least 
giving a reference to such an algorithm.


Tree rows -- real tree rows, i.e. a row of trees planted on purpose to 
function as a landscaping feature, not just some random trees which 
happen to be in a line -- are important landmarks and often show on maps 
as rows of green dots. However, the individual trees are typically too 
close to be shown at their real positions, so some generalization is 
required. Tagging the tree row provides such a generalization. I have no 
doubt that it is theoretically possible to synthesize tree-row objects 
from mapped trees, but I would guess that doing so with an acceptable 
number of false positives and negatives is close to a masters-thesis 
project.


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

Re: [Tagging] Feature Proposal – RFC – natural=peninsula

[Ture Pålsson]

2019-01-09 10:35, Frederik Ramm wrote
:

[ ... ]
I fear that people will otherwise with great diligence and fun tag
things like the "Iberian Peninsula" which will not be of any use and
just lead to more relation clutter. (Cf. discussion about bays.)


I mentioned the discussion of bays to a friend, who immediately said "of 
course areas with fuzzy boundaries should be mapped as a function that, 
given a point, returns 0 if the point is certainly outside the area, 1 
if it's certainly inside, and somewhere inbetween if it's in the fuzzy 
bit!"


I'd rather not be the one to implement that, though... :-)

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

Re: [Tagging] Tagging a named river bend

[Ture Pålsson]

And again, with a link, this time! =)

https://kso.etjanster.lantmateriet.se/?e=749899=7312843=9=default_background_noauth
 
<https://kso.etjanster.lantmateriet.se/?e=749899=7312843=9=default_background_noauth>


> 27 sep. 2018 kl. 18:36 skrev Ture Pålsson :
> 
> 
>> 27 sep. 2018 kl. 13:03 skrev Yves :
>> 
>> Place=locality makes sense, I guess the name is also used for the area close 
>> to the bend by extension.
>> Locality on a node is always troublesome, and I wonder if anybody uses 
>> description=* to describe further the place, here this would be something 
>> like description=river bend. 
> 
> 
> A simple place=locality gives no hint to a renderer that this is a water 
> feature, and I can easily imagine a map style where one wants to do something 
> special with those, like using blue text.
> 
> Look at this example from northern Sweden, where features in the river 
> (Bredselet, Trångforsen and Vidselet) have lent their names, but in different 
> grammatical form, the the nearby villages/hamlets of Bredsel, Trångfors and 
> Vidsel.
> 
> (Follow there river and you'll see several other named rapids (-fors) and 
> stretches of smooth water between them (-sel).
> 

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

Re: [Tagging] Tagging a named river bend

[Ture Pålsson]

> 27 sep. 2018 kl. 13:03 skrev Yves :
> 
> Place=locality makes sense, I guess the name is also used for the area close 
> to the bend by extension.
> Locality on a node is always troublesome, and I wonder if anybody uses 
> description=* to describe further the place, here this would be something 
> like description=river bend. 


A simple place=locality gives no hint to a renderer that this is a water 
feature, and I can easily imagine a map style where one wants to do something 
special with those, like using blue text.

Look at this example from northern Sweden, where features in the river 
(Bredselet, Trångforsen and Vidselet) have lent their names, but in different 
grammatical form, the the nearby villages/hamlets of Bredsel, Trångfors and 
Vidsel.

(Follow there river and you'll see several other named rapids (-fors) and 
stretches of smooth water between them (-sel).


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

Re: [Tagging] What is a VTC car in OSM ?

[Ture Pålsson]

(Replying to the thread in general, not to any particular message)

The concept of a VTC in e.g. Spain and France seems similar to what londoners 
call a ”minicab". Are there any existing tagging practices for those?


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

[Tagging] Castles and manors

[Ture Pålsson]

I noticed that this structure: https://www.openstreetmap.org/way/190298018 
 is tagged historic=castle. It is 
certainly not defensive (Swedish Wikipedia: 
https://sv.wikipedia.org/wiki/Lennartsnäs), so I thought it needed a 
castle_type, but reading the wiki description of castle_type=manor 
(https://wiki.openstreetmap.org/wiki/Tag:castle_type%3Dmanor) confused me a 
bit. It says that historic=manor can be used for "manors which are not 
castles", which makes me wonder: what is the difference between a 
historic=castle,castle_type=manor and a historic=manor?

(I'm also not entirely sure whether this is a "manor" or a "stately".)

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

Re: [Tagging] Rock outcrops in forest

[Ture Pålsson]

2018-05-28 02:00 skrev Warin:

[ ... ]
Actually there are large areas that have flats/apartments with the
ground floor as shops ... so the suggested

landuse=residential and landuse:secondary=retail is what is happening
on the ground in some places.


Random thoughts:

Does this really buy anything compared to overlapping polygons (except, 
obviously, where the polygons are coincident, in which case it saves a 
polygon)?


I’m a bit nervous that primary/secodary/tertiary is a bit too fuzzy. In 
a city, primary is street level, secondary is above, while in the 
forest, primary is the forest and secondary is what’s on the floor?


With linear objects, such as streets, we gladly chop them into umpteen 
pieces to put the right tags on each piece (this bit is no-parking, this 
stretch is a pedestrian zone, those 50 meters are one-way, all of them 
are named "Main Street"). Do we want to do that for polygons as well 
(extreme case: for every point on the surface of the planet, there is 
exactly one polygon that covers that point and holds *all* the tags that 
apply at that point) or do we want to work with overlapping polygons?



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

[Tagging] Rock outcrops in forest

[Ture Pålsson]

The Swedish Geodetic Survey, Lantmäteriet, have released data corresponding to 
their printed 1:5 topographic maps under a CC0 license (i.e, compatible 
with OpenStreetMap).

One of the features in this data is ”berg i dagen”, translated as ”rock 
outcrop” on the legend of the printed maps. These areas often overlap forest. 
What you typically find on the ground in those cases is sparse pine forest, 
where the layer of organic material on the forest floor is so thin that there 
are large patches of more or less naked rock between the trees.

How should these areas be tagged in OSM? Some of them have been imported as 
natural=bare_rock overlapping with landuse=forest, but this has led to protests 
from persons stating that bare_rock should be used only for areas of naked 
rock, with little or no vegetation (and, looking at the Wiki, I can only agree 
with them).

(Do these areas belong on OSM at all? I believe they do, as they provide 
interesting information e.g. for hikers. I admit, however, that they are often 
hard to detect on the aerial photos available to us, and that their borders are 
somewhat unclear and difficult to determine.)


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