Re: [Tagging] The actual use of the level tag

[Phake Nick]

>M (for mezzanine) is often in between G and 2, and often but not always
has some notion of being less than a proper full floor
Speaking of which  many editors, users, editing software, tenderer and such
seems to assume levels must be integer which is not necessary to be
correct. For instance, I am currently sitting at level 3M of a particular
building, which is physically outside the building and is higher than level
3 while lower than level 4 of such building. If expressed in numerical
format, one might naturally say this is level=3.5, however such value
doesn't seems to be commonly understood by different tools
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Forest parcel with other landcover (scrub, scree…): how to map?

[Warin]

On 21/01/19 16:47, Joseph Eisenberg wrote:
> “Once you combine the OSM keys and values of landuse=forest and 
compare it to natural=wood I think most will agree there is a difference,”


I certainly do, but I’m a native speaker of English (though not the 
British variety).


Many speakers of other languages just search for an English word in an 
online traslation service and then stick that into the editor to find 
a tag.


I would hope the OSM wiki would be better than that. It certainly could 
be a better method for mappers looking for some correct tags.


I recently came across 'sport=paddleboard' (non english speaking palce) 
and thought of table tennis .. contacted the mapper and no it is in 
my local version of English, a 'rescue board' used by surf life savers 
to rescue people.
Yes they do have completions for it, but no permanent infrastructure 
here so it does not get mapped. Only one instance in OSM so no wiki page 
for it.



On Mon, Jan 21, 2019 at 1:34 PM Warin <61sundow...@gmail.com 
> wrote:


On 21/01/19 10:17, Joseph Eisenberg wrote:

> The end to this madness is for renders to recognise that the
landuse=forest needs to be rendered differently from natural=wood.

Until several years ago the “standard” style
(Openstreetmap-Carto) did show a difference between
landuse=forest and natural=wood. However, mappers used these two
tags interchangeably even then. The rendering was changed to
match actually database usage on a global scale, which is that
both tags are often used to tag any area covered with trees.

The current rendering follows tag usage and the current wiki
page, which also discusses this issue in depth.

I wish it were possible to fix this, but the different meanings
of “forest” and “wood” in various English dialects make it difficult,


The meaning of the key 'landuse' is fairly clear in any English
dialect.

The problem of the key 'natural' remains.

Once you combine the OSM keys and values of landuse=forest and
compare it to natural=wood I think most will agree there is a
difference,
The former is for what the land is used for.
The latter is for the presence of plants, if you take any plant as
being natural then natural=wood is 'acceptable' for ant tree area.'


even before we add other languages and cultures to the mix.
On Mon, Jan 21, 2019 at 8:04 AM Warin <61sundow...@gmail.com
> wrote:

On 21/01/19 05:52, Kevin Kenny wrote:

> On Sun, Jan 20, 2019 at 1:33 PM David Marchal
mailto:pene...@live.fr>> wrote:
>> All is in the title: when hiking in a forest (I mean, an
area considered as a forest by authorities), I often
encounter other landcovers, like scrubs in recently teared
down parcels, or scree in the mountains. These area,
although, clearly and morphologically, not a forest, are
still mapped as such, as they are considered to be part of
the forest and are treated this may, but they are
morphologically not the forest: the forest is the area
administratively regarded as such, but it is not always the
case; if I want, for instance, to map them as a scrub area of
the forest, as the polygons overlapped, they are rendered in
a mixed way. Is there a recommended way of handling such
cases without broking display? If so, what are they? The
landcover tag? boundary=forest_compartment? Another?
> This again.

And it will continue to occur!

And reoccur, again and again.

>
> There's a failed consensus here - and you risk reversion
with either decision.
>
> I tend to follow the principle that landuse=* denotes the
land USE,
> not the land COVER, so I don't demand that every square
metre of
> landuse=forest be covered by trees.

+1

>   But many do, and the renderer
> follows their inclination.
>
> natural=wood is a possibility to show tree cover - but that
leads some
> to argue that it has to be a 'natural' wood - whatever that
means.
> I've heard it argued that the 'old second growth' forest that's
> increasingly common near me is still not 'natural' because
a skilled
> forester can still find the human impact. (Of course, that
was true
> even before the Europeans arrived - there was considerable
> pre-Columbian human impact on these forests.)

Those who argue this have no problem abusing the landuse tag,
so I see no reason why the tag 'natural' cannot be similarly
abused.
The OSMwiki for 'natural' even states that is can be used for
human effected things.

>
> landcover=trees doesn't render, but is at least unambiguous
  

Re: [Tagging] Forest parcel with other landcover (scrub, scree…): how to map?

[Joseph Eisenberg]

> “Once you combine the OSM keys and values of landuse=forest and compare
it to natural=wood I think most will agree there is a difference,”

I certainly do, but I’m a native speaker of English (though not the British
variety).

Many speakers of other languages just search for an English word in an
online traslation service and then stick that into the editor to find a tag.
On Mon, Jan 21, 2019 at 1:34 PM Warin <61sundow...@gmail.com> wrote:

> On 21/01/19 10:17, Joseph Eisenberg wrote:
>
> > The end to this madness is for renders to recognise that the
> landuse=forest needs to be rendered differently from natural=wood.
>
> Until several years ago the “standard” style (Openstreetmap-Carto) did
> show a difference between landuse=forest and natural=wood. However, mappers
> used these two tags interchangeably even then. The rendering was changed to
> match actually database usage on a global scale, which is that both tags
> are often used to tag any area covered with trees.
>
> The current rendering follows tag usage and the current wiki page, which
> also discusses this issue in depth.
>
> I wish it were possible to fix this, but the different meanings of
> “forest” and “wood” in various English dialects make it difficult,
>
>
> The meaning of the key 'landuse' is fairly clear in any English dialect.
>
> The problem of the key 'natural' remains.
>
> Once you combine the OSM keys and values of landuse=forest and compare it
> to natural=wood I think most will agree there is a difference,
> The former is for what the land is used for.
> The latter is for the presence of plants, if you take any plant as being
> natural then natural=wood is 'acceptable' for ant tree area.'
>
> even before we add other languages and cultures to the mix.
> On Mon, Jan 21, 2019 at 8:04 AM Warin <61sundow...@gmail.com> wrote:
>
>> On 21/01/19 05:52, Kevin Kenny wrote:
>>
>> > On Sun, Jan 20, 2019 at 1:33 PM David Marchal  wrote:
>> >> All is in the title: when hiking in a forest (I mean, an area
>> considered as a forest by authorities), I often encounter other landcovers,
>> like scrubs in recently teared down parcels, or scree in the mountains.
>> These area, although, clearly and morphologically, not a forest, are still
>> mapped as such, as they are considered to be part of the forest and are
>> treated this may, but they are morphologically not the forest: the forest
>> is the area administratively regarded as such, but it is not always the
>> case; if I want, for instance, to map them as a scrub area of the forest,
>> as the polygons overlapped, they are rendered in a mixed way. Is there a
>> recommended way of handling such cases without broking display? If so, what
>> are they? The landcover tag? boundary=forest_compartment? Another?
>> > This again.
>>
>> And it will continue to occur!
>>
>> And reoccur, again and again.
>>
>> >
>> > There's a failed consensus here - and you risk reversion with either
>> decision.
>> >
>> > I tend to follow the principle that landuse=* denotes the land USE,
>> > not the land COVER, so I don't demand that every square metre of
>> > landuse=forest be covered by trees.
>>
>> +1
>>
>> >   But many do, and the renderer
>> > follows their inclination.
>> >
>> > natural=wood is a possibility to show tree cover - but that leads some
>> > to argue that it has to be a 'natural' wood - whatever that means.
>> > I've heard it argued that the 'old second growth' forest that's
>> > increasingly common near me is still not 'natural' because a skilled
>> > forester can still find the human impact. (Of course, that was true
>> > even before the Europeans arrived - there was considerable
>> > pre-Columbian human impact on these forests.)
>>
>> Those who argue this have no problem abusing the landuse tag, so I see no
>> reason why the tag 'natural' cannot be similarly abused.
>> The OSMwiki for 'natural' even states that is can be used for human
>> effected things.
>>
>> >
>> > landcover=trees doesn't render, but is at least unambiguous that it
>> > means tree cover and nothing else.
>> >
>> > landuse=forestry, for a managed forest, has been proposed but received
>> > a lukewarm reception.
>>
>> For forestry area I tag landuse=forest with produce=trees (or what ever
>> is produced by the area for human use). This makes it clare that the area
>> is for productive human use.
>>
>> >
>> > For the state forests and wildlife management areas around here, I tag
>> > at least boundary=protected_area. (Tag with the right protect_class,
>> > and add leisure=nature_reserve if it fits: 'nature reserve' covers a
>> > lot of things.) If I'm mapping land cover (I seldom do), I will use
>> > natural=wood to mean 'tree cover' and let others fight over it.
>>
>> I too use natural=wood with landcover=trees to map a tree area.
>>
>> --
>> The end to this madness is for renders to recognise that the
>> landuse=forest needs to be rendered differently from natural=wood.
>> The essential difference between 

Re: [Tagging] Forest parcel with other landcover (scrub, scree…): how to map?

[Warin]

On 21/01/19 10:17, Joseph Eisenberg wrote:
> The end to this madness is for renders to recognise that the 
landuse=forest needs to be rendered differently from natural=wood.


Until several years ago the “standard” style (Openstreetmap-Carto) did 
show a difference between landuse=forest and natural=wood. However, 
mappers used these two tags interchangeably even then. The rendering 
was changed to match actually database usage on a global scale, which 
is that both tags are often used to tag any area covered with trees.


The current rendering follows tag usage and the current wiki page, 
which also discusses this issue in depth.


I wish it were possible to fix this, but the different meanings of 
“forest” and “wood” in various English dialects make it difficult,


The meaning of the key 'landuse' is fairly clear in any English dialect.

The problem of the key 'natural' remains.

Once you combine the OSM keys and values of landuse=forest and compare 
it to natural=wood I think most will agree there is a difference,

The former is for what the land is used for.
The latter is for the presence of plants, if you take any plant as being 
natural then natural=wood is 'acceptable' for ant tree area.'



even before we add other languages and cultures to the mix.
On Mon, Jan 21, 2019 at 8:04 AM Warin <61sundow...@gmail.com 
> wrote:


On 21/01/19 05:52, Kevin Kenny wrote:

> On Sun, Jan 20, 2019 at 1:33 PM David Marchal mailto:pene...@live.fr>> wrote:
>> All is in the title: when hiking in a forest (I mean, an area
considered as a forest by authorities), I often encounter other
landcovers, like scrubs in recently teared down parcels, or scree
in the mountains. These area, although, clearly and
morphologically, not a forest, are still mapped as such, as they
are considered to be part of the forest and are treated this may,
but they are morphologically not the forest: the forest is the
area administratively regarded as such, but it is not always the
case; if I want, for instance, to map them as a scrub area of the
forest, as the polygons overlapped, they are rendered in a mixed
way. Is there a recommended way of handling such cases without
broking display? If so, what are they? The landcover tag?
boundary=forest_compartment? Another?
> This again.

And it will continue to occur!

And reoccur, again and again.

>
> There's a failed consensus here - and you risk reversion with
either decision.
>
> I tend to follow the principle that landuse=* denotes the land USE,
> not the land COVER, so I don't demand that every square metre of
> landuse=forest be covered by trees.

+1

>   But many do, and the renderer
> follows their inclination.
>
> natural=wood is a possibility to show tree cover - but that
leads some
> to argue that it has to be a 'natural' wood - whatever that means.
> I've heard it argued that the 'old second growth' forest that's
> increasingly common near me is still not 'natural' because a skilled
> forester can still find the human impact. (Of course, that was true
> even before the Europeans arrived - there was considerable
> pre-Columbian human impact on these forests.)

Those who argue this have no problem abusing the landuse tag, so I
see no reason why the tag 'natural' cannot be similarly abused.
The OSMwiki for 'natural' even states that is can be used for
human effected things.

>
> landcover=trees doesn't render, but is at least unambiguous that it
> means tree cover and nothing else.
>
> landuse=forestry, for a managed forest, has been proposed but
received
> a lukewarm reception.

For forestry area I tag landuse=forest with produce=trees (or what
ever is produced by the area for human use). This makes it clare
that the area is for productive human use.

>
> For the state forests and wildlife management areas around here,
I tag
> at least boundary=protected_area. (Tag with the right protect_class,
> and add leisure=nature_reserve if it fits: 'nature reserve' covers a
> lot of things.) If I'm mapping land cover (I seldom do), I will use
> natural=wood to mean 'tree cover' and let others fight over it.

I too use natural=wood with landcover=trees to map a tree area.

--
The end to this madness is for renders to recognise that the
landuse=forest needs to be rendered differently from natural=wood.
The essential difference between the two is that landuse must have
some human benefit, a produce, and a clear way of doing that is to
add the rendering of a axe to the tree.


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

Re: [Tagging] Forest parcel with other landcover (scrub, scree…): how to map?

[Andy Townsend]

On 20/01/2019 23:17, Joseph Eisenberg wrote:
> The end to this madness is for renders to recognise that the 
landuse=forest needs to be rendered differently from natural=wood.


Until several years ago the “standard” style (Openstreetmap-Carto) did 
show a difference between landuse=forest and natural=wood. However, 
mappers used these two tags interchangeably even then. The rendering 
was changed to match actually database usage on a global scale, which 
is that both tags are often used to tag any area covered with trees.


One suggestion that I've made here before is explicitly to use 
"landuse=forestry" for areas that may or may not have trees on them, if 
the areas with trees within have been mapped separately


An example is 
https://www.openstreetmap.org/way/620189661#map=15/54.0158/-0.9549 , and 
the result, in a renderer that deals with it, looks like 
https://map.atownsend.org.uk/maps/map/map.html#zoom=16=54.01539=-0.95744 
.


That renderer also processes landuse=forest the same way - see 
https://www.openstreetmap.org/way/44018882 and 
https://map.atownsend.org.uk/maps/map/map.html#zoom=15=53.21319=-1.18217 
for an example of that.


So from both a tagging and a rendering perspective it's a solvable 
problem, but the way I've done it does go against a couple of the "ways 
of working" that OSM's standard style has (e.g. transparency).


Best Regards,

Andy



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

Re: [Tagging] The actual use of the level tag

[Greg Troxel]

Here's a perhaps-radical set of comments and suggestion:

  in any building, there is a set of names (which often but not always
  look like numbers) for levels.  These are evident in the elevators
  (buttons inside, matching values outside) and in things painted on
  walls, on room numbers. etc

  In the US, you'll typically find something like B/G/2/3, corresponding
  to level -1, 0, 1, 2.   Presumably in the UK that's B/G/1/2.

  (probably not relevant) In the US, there is a star in the elevator
  next to the floor which is considered ground.  This is purely about
  how to get out of the building.  Basically, when you get in an
  elevator, if you wish to get outside, push the button with the star,
  and then follow exit signs.  Almost always, this is "G".

  In the US, you'll often find 12 and then 14, just because people who
  number floors think other people don't want to be on a floor numbered
  13.

  M (for mezzanine) is often in between G and 2, and often but not
  always has some notion of being less than a proper full floor

  some buildings have two different floors that are both at-grade in
  different parts of the building.

  therefore, floor numbering is not something that can be mapped to a
  number.  Instead, it is a set of names, which often look like
  sequential numbers.

  So,

 there should be a tag with a list of names in order, something like
 "B2 B G 2 3" (for a building with a sub-basement below the
 basement), and

 floor values should take on one of those names, and

 there should be a tag that denotes the floor that is most
 considered the ground floor, in the above case "G".

 probably do not try to think about buildings that have different
 ground floors in different places

This totally blows up the notion of numeric levels, but given the above
ordered list of floor names, one can compute an n-floors-above
relationship from any two floor names in the list.


Another example is a building I've been in with floor names

  P6 P5 P4 P3 P2 P1 G 1 2 3 4 5 6 7 8 9

yes, that is six levels of below-grade parking.  It might actually have
a B between P1 and G - I don't remember.  It had two sets of elevators,
one set P6-G, and one set G-9.

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

Re: [Tagging] The actual use of the level tag

[Graeme Fitzpatrick]

I've seen a similar issue with a shop in our area

https://www.openstreetmap.org/way/351561908#map=19/-28.08993/153.45070

The street address is 15 Park Avenue, but the only thing there is the car
park, with staff entry, goods lift & customer stairs & lift, but that
should (?) be level=0 as that is it's street address.

The actual shop, & main entry door, is downstairs at the level of James
Street, but is it level=0 James Street, or level=-1 Park Avenue?

Thanks

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

Re: [Tagging] Forest parcel with other landcover (scrub, scree…): how to map?

[Joseph Eisenberg]

> The end to this madness is for renders to recognise that the
landuse=forest needs to be rendered differently from natural=wood.

Until several years ago the “standard” style (Openstreetmap-Carto) did show
a difference between landuse=forest and natural=wood. However, mappers used
these two tags interchangeably even then. The rendering was changed to
match actually database usage on a global scale, which is that both tags
are often used to tag any area covered with trees.

The current rendering follows tag usage and the current wiki page, which
also discusses this issue in depth.

I wish it were possible to fix this, but the different meanings of “forest”
and “wood” in various English dialects make it difficult, even before we
add other languages and cultures to the mix.
On Mon, Jan 21, 2019 at 8:04 AM Warin <61sundow...@gmail.com> wrote:

> On 21/01/19 05:52, Kevin Kenny wrote:
>
> > On Sun, Jan 20, 2019 at 1:33 PM David Marchal  wrote:
> >> All is in the title: when hiking in a forest (I mean, an area
> considered as a forest by authorities), I often encounter other landcovers,
> like scrubs in recently teared down parcels, or scree in the mountains.
> These area, although, clearly and morphologically, not a forest, are still
> mapped as such, as they are considered to be part of the forest and are
> treated this may, but they are morphologically not the forest: the forest
> is the area administratively regarded as such, but it is not always the
> case; if I want, for instance, to map them as a scrub area of the forest,
> as the polygons overlapped, they are rendered in a mixed way. Is there a
> recommended way of handling such cases without broking display? If so, what
> are they? The landcover tag? boundary=forest_compartment? Another?
> > This again.
>
> And it will continue to occur!
>
> And reoccur, again and again.
>
> >
> > There's a failed consensus here - and you risk reversion with either
> decision.
> >
> > I tend to follow the principle that landuse=* denotes the land USE,
> > not the land COVER, so I don't demand that every square metre of
> > landuse=forest be covered by trees.
>
> +1
>
> >   But many do, and the renderer
> > follows their inclination.
> >
> > natural=wood is a possibility to show tree cover - but that leads some
> > to argue that it has to be a 'natural' wood - whatever that means.
> > I've heard it argued that the 'old second growth' forest that's
> > increasingly common near me is still not 'natural' because a skilled
> > forester can still find the human impact. (Of course, that was true
> > even before the Europeans arrived - there was considerable
> > pre-Columbian human impact on these forests.)
>
> Those who argue this have no problem abusing the landuse tag, so I see no
> reason why the tag 'natural' cannot be similarly abused.
> The OSMwiki for 'natural' even states that is can be used for human
> effected things.
>
> >
> > landcover=trees doesn't render, but is at least unambiguous that it
> > means tree cover and nothing else.
> >
> > landuse=forestry, for a managed forest, has been proposed but received
> > a lukewarm reception.
>
> For forestry area I tag landuse=forest with produce=trees (or what ever is
> produced by the area for human use). This makes it clare that the area is
> for productive human use.
>
> >
> > For the state forests and wildlife management areas around here, I tag
> > at least boundary=protected_area. (Tag with the right protect_class,
> > and add leisure=nature_reserve if it fits: 'nature reserve' covers a
> > lot of things.) If I'm mapping land cover (I seldom do), I will use
> > natural=wood to mean 'tree cover' and let others fight over it.
>
> I too use natural=wood with landcover=trees to map a tree area.
>
> --
> The end to this madness is for renders to recognise that the
> landuse=forest needs to be rendered differently from natural=wood.
> The essential difference between the two is that landuse must have some
> human benefit, a produce, and a clear way of doing that is to add the
> rendering of a axe to the tree.
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Forest parcel with other landcover (scrub, scree…): how to map?

[Warin]

On 21/01/19 05:52, Kevin Kenny wrote:


On Sun, Jan 20, 2019 at 1:33 PM David Marchal  wrote:

All is in the title: when hiking in a forest (I mean, an area considered as a 
forest by authorities), I often encounter other landcovers, like scrubs in 
recently teared down parcels, or scree in the mountains. These area, although, 
clearly and morphologically, not a forest, are still mapped as such, as they 
are considered to be part of the forest and are treated this may, but they are 
morphologically not the forest: the forest is the area administratively 
regarded as such, but it is not always the case; if I want, for instance, to 
map them as a scrub area of the forest, as the polygons overlapped, they are 
rendered in a mixed way. Is there a recommended way of handling such cases 
without broking display? If so, what are they? The landcover tag? 
boundary=forest_compartment? Another?

This again.


And it will continue to occur!

And reoccur, again and again.



There's a failed consensus here - and you risk reversion with either decision.

I tend to follow the principle that landuse=* denotes the land USE,
not the land COVER, so I don't demand that every square metre of
landuse=forest be covered by trees.


+1


  But many do, and the renderer
follows their inclination.

natural=wood is a possibility to show tree cover - but that leads some
to argue that it has to be a 'natural' wood - whatever that means.
I've heard it argued that the 'old second growth' forest that's
increasingly common near me is still not 'natural' because a skilled
forester can still find the human impact. (Of course, that was true
even before the Europeans arrived - there was considerable
pre-Columbian human impact on these forests.)


Those who argue this have no problem abusing the landuse tag, so I see no 
reason why the tag 'natural' cannot be similarly abused.
The OSMwiki for 'natural' even states that is can be used for human effected 
things.



landcover=trees doesn't render, but is at least unambiguous that it
means tree cover and nothing else.

landuse=forestry, for a managed forest, has been proposed but received
a lukewarm reception.


For forestry area I tag landuse=forest with produce=trees (or what ever is 
produced by the area for human use). This makes it clare that the area is for 
productive human use.



For the state forests and wildlife management areas around here, I tag
at least boundary=protected_area. (Tag with the right protect_class,
and add leisure=nature_reserve if it fits: 'nature reserve' covers a
lot of things.) If I'm mapping land cover (I seldom do), I will use
natural=wood to mean 'tree cover' and let others fight over it.


I too use natural=wood with landcover=trees to map a tree area.

--
The end to this madness is for renders to recognise that the landuse=forest 
needs to be rendered differently from natural=wood.
The essential difference between the two is that landuse must have some human 
benefit, a produce, and a clear way of doing that is to add the rendering of a 
axe to the tree.


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

Re: [Tagging] The actual use of the level tag

[Jarek Piórkowski]

On Sun, 20 Jan 2019 at 16:58, Tobias Zwick  wrote:
> Well, all of which I mentioned is optional. But I can come up with two
> use cases for wanting to know which level is the ground level:
>
> 1. Localization
>
> In an application, it is much nicer to be able to write
> "ground floor" (en-GB), "first floor" or "basement floor 2"
> than "level 0", "level M" or, worst, "level -1"

For any sufficiently complicated building, localization might be
better covered by putting the local level name in "building
nomeclature" in addr:floor as mentioned by Eugene.

To give an example, my local big shopping centre (400 m long, on
slightly sloping ground) names its "ground level" (with entrances from
street) "Level 2" or "Level 3" depending on where you are, the level
below "Level 2" is "Level 1", and the level below that is named "Urban
Eatery". In your scheme this would be levels=UE,1,2,3,4 and
ground_level=2 (I guess), which is fine for ref and determining
vertical orientation. But reconstructing a recognizable name from this
is hard. One could also make the argument that "Level 1" is the main
level of this centre: more people arrive at this level because that's
where the entrances from rapid transit stations are.

Another centre I'm familiar with (again on sloping ground) names its
levels in ascending order: "Ground Level", "Lower Level", "Upper
Level", with official refs M0, M1, M2 respectively, and depending on
definition all of them have street entrances.

--Jarek

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

Re: [Tagging] The actual use of the level tag

[Tobias Knerr]

On 20.01.19 19:37, Tobias Zwick wrote:
> - a shop on level M with "level=M"
> 
> - the mall building with "levels=P2,P1,G,M,1-12,14-99" (the order of the
>   levels). If levels is missing, a numerical order is assumed

So essentially, one uses the local level reference in level=*, and
provides a mapping onto a standardized level sequence with separate,
building-wide tags.

Admittedly, I haven't really considered that yet. It's also interesting
because I would have suggested the exact opposite: Using standardized
level numbers in the level=* tag, and defining a mapping onto the local
level references for display purposes. This is pretty much the current
logic behind SIT.

One comparatively minor issue with your approach is that it becomes
harder for editors to provide basic indoor mapping support: Something
like the level switcher currently available in JOSM won't work any more,
because there would no longer be a consistent order of levels across
buildings. You would need to select a building to edit first, and use a
building-local level switcher. Manually-defined tag filters would
likewise need to be updated, e.g. in order to support level ranges
properly (a staircase tagged level=G-1 should be visible while editing
level M).

The main challenge I see with your proposal, though, is that the
levels=* tag on the building would be utterly required to make any sense
of the order of floors. Without it, applications would have no idea
whether "M" is above or below "P2", for example. So at the very least,
adding levels=* should explicitly be documented as mandatory when using
non-standard levels.

If we can get our fellow mappers to largely stick with such a rule, your
idea would work. So would the existing solutions, though, and that "if"
is something I am worried about.

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

Re: [Tagging] The actual use of the level tag

[Richard]

On Sun, Jan 20, 2019 at 10:57:47PM +0100, Tobias Zwick wrote:
> >> - also the building with "ground_level=G" to define which level is
> >>   the ground level. If ground_level is missing, 0 is assumed.
> >>
> > Do we really need a ground level? I think not. We need connections to
> > outside ways and entrances.
> 
> Well, all of which I mentioned is optional. But I can come up with two
> use cases for wanting to know which level is the ground level:
> 
> 1. Localization
> 
> In an application, it is much nicer to be able to write
> "ground floor" (en-GB), "first floor" or "basement floor 2"
> than
> "level 0", "level M" or, worst, "level -1"
> 
> To refer to a "level" may be even less understandable when trying to
> translate that into other languages.
> 
> But for this to work, it is necessary for the application to know which
> level is the ground floor.

maybe we should endorse "level:xx" instead of thinking about translating it.

> 2. 3D indoor levels
> 
> When displaying the floors of a multi-storey building in 3D on top of
> each other, you need to know where on the Z-Axis you have to place it.

for this key:ele would much better. The ground floors of any 2 buildings may
be at very different elevations if the buildings are seemingly adjacent.

Richard

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

Re: [Tagging] Forest parcel with other landcover (scrub, scree…): how to map?

[Joseph Eisenberg]

> “an area considered as a forest by authorities”

If this is a protected or administrative “forest”, you can use
boundary=protected_area with the proper class

But we usually try to map what is “real” and “current”. So if there is an
area without formal protection, that people call “XXX Forest”, but it
contains meadows, trees, rock and scrub, then map each area separately.

You might need to make a multipolygon if there are large areas of woodland
with patches of other landcover inside. This lets data users know that the
trees end there.
On Mon, Jan 21, 2019 at 3:54 AM Kevin Kenny  wrote:

> On Sun, Jan 20, 2019 at 1:33 PM David Marchal  wrote:
> > All is in the title: when hiking in a forest (I mean, an area considered
> as a forest by authorities), I often encounter other landcovers, like
> scrubs in recently teared down parcels, or scree in the mountains. These
> area, although, clearly and morphologically, not a forest, are still mapped
> as such, as they are considered to be part of the forest and are treated
> this may, but they are morphologically not the forest: the forest is the
> area administratively regarded as such, but it is not always the case; if I
> want, for instance, to map them as a scrub area of the forest, as the
> polygons overlapped, they are rendered in a mixed way. Is there a
> recommended way of handling such cases without broking display? If so, what
> are they? The landcover tag? boundary=forest_compartment? Another?
>
> This again.
>
> There's a failed consensus here - and you risk reversion with either
> decision.
>
> I tend to follow the principle that landuse=* denotes the land USE,
> not the land COVER, so I don't demand that every square metre of
> landuse=forest be covered by trees. But many do, and the renderer
> follows their inclination.
>
> natural=wood is a possibility to show tree cover - but that leads some
> to argue that it has to be a 'natural' wood - whatever that means.
> I've heard it argued that the 'old second growth' forest that's
> increasingly common near me is still not 'natural' because a skilled
> forester can still find the human impact. (Of course, that was true
> even before the Europeans arrived - there was considerable
> pre-Columbian human impact on these forests.)
>
> landcover=trees doesn't render, but is at least unambiguous that it
> means tree cover and nothing else.
>
> landuse=forestry, for a managed forest, has been proposed but received
> a lukewarm reception.
>
> For the state forests and wildlife management areas around here, I tag
> at least boundary=protected_area. (Tag with the right protect_class,
> and add leisure=nature_reserve if it fits: 'nature reserve' covers a
> lot of things.) If I'm mapping land cover (I seldom do), I will use
> natural=wood to mean 'tree cover' and let others fight over it.
>
> But that's just what I do, and I do not argue that it is right. With
> the current state of the discussion, which has been in stalemate for a
> few years, there simply is no correct tagging, and what I do appears
> 'least wrong' to me.
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] The actual use of the level tag

[Tobias Zwick]

>> - also the building with "ground_level=G" to define which level is
>>   the ground level. If ground_level is missing, 0 is assumed.
>>
> Do we really need a ground level? I think not. We need connections to
> outside ways and entrances.

Well, all of which I mentioned is optional. But I can come up with two
use cases for wanting to know which level is the ground level:

1. Localization

In an application, it is much nicer to be able to write
"ground floor" (en-GB), "first floor" or "basement floor 2"
than
"level 0", "level M" or, worst, "level -1"

To refer to a "level" may be even less understandable when trying to
translate that into other languages.

But for this to work, it is necessary for the application to know which
level is the ground floor.

2. 3D indoor levels

When displaying the floors of a multi-storey building in 3D on top of
each other, you need to know where on the Z-Axis you have to place it.

Tobias

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

Re: [Tagging] The actual use of the level tag

[Richard]

On Sun, Jan 20, 2019 at 07:37:23PM +0100, Tobias Zwick wrote:
> > So from a SIT perspective, the problem isn't that the US (and other
> > places) call the ground level "1". It's that the level below that is
> > called "-1" rather than "0". You could still make it compatible with
> > Simple Indoor Tagging by adding a skipped_levels=0 tag to the building,
> > but this tag has only been used five times so far.
> 
> skipped_levels is also pretty awkward because one needs to recalculate
> the indexed (OSM) level from the real (on the ground) level all the
> time. Even worse if the levels are not actually numbers on the ground
> but letters or something else (like in that mall in Bangkok).
> 
> If SIT (and by consensus in the SotM 2016 indoor session) encourages to
> use the level numbering scheme of the building operator, why keep the
> "tied to numbers" requirement?
> 
> Someone mentioned earlier in a diary discussion a pretty nice
> solution[1]. So, in a mall with the levels P2,P1,G,M,1-12,14-99 one
> simply tags:
> 
> - a shop on level M with "level=M"
> 
> - the mall building with "levels=P2,P1,G,M,1-12,14-99" (the order of the
>   levels). If levels is missing, a numerical order is assumed
> 
> - also the building with "ground_level=G" to define which level is
>   the ground level. If ground_level is missing, 0 is assumed.
> 
> I find this would have the following advantages while completely
> compatible with the current SIT scheme and has no disadvantages (I can
> come up with):

looks nice to me.. just hope that nobody needs level names with a ",".

Do we really need a ground level? I think not. We need connections to
outside ways and entrances.

Richard

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

Re: [Tagging] Yay, new howto map for diabilities created in wiki

[Richard]

On Sun, Jan 20, 2019 at 10:39:55AM +1100, Warin wrote:
> On 20/01/19 09:00, Richard wrote:
> >Hi,
> >
> >renamed it to
> >https://wiki.openstreetmap.org/wiki/How_to_map_for_the_needs_of_people_with_disabilities
> >
> >hope it is not too offensive for now and can be renamed later.
> >
> The map is of features ... not needs... ummm
> 
> 'Mapping features that cater for people with disabilities'???

not all features are special for the disabled, also mapping many general purpose
features can help: barriers, kerbs..

Anyway, created a section in the Talkpage to collect possible alternative
names for the page.

Richard

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

Re: [Tagging] The actual use of the level tag

[Eugene Alvin Villar]

On Mon, Jan 21, 2019, 2:38 AM Tobias Zwick  2. no calculating forth- and back between level "indices" and real names
>for the levels (for neither the software nor the mapper) because this
>effectively eliminates the concept of indices
>

I use level=* for the machine-readable zero-based level/floor of an object
and addr:floor=* for the real name or human-readable value. Currently, many
mappers treat both tags as synonyms but I like how I use both for different
audiences.

https://taginfo.openstreetmap.org/keys/?key=addr%3Afloor

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

Re: [Tagging] The actual use of the level tag

[Shawn K. Quinn]

On 1/20/19 11:06, Roland Olbricht wrote:
> we have here in Wuppertal, Germany at least three indoor-tagged
> structures that have street level entrances at multiple levels, making
> "street level" a not-at-all defined concept. In case of the university
> e.g. the main entrance is on level 7, and street level entrances range
> from levels 2 to 10. I am also aware of dozens of buildings across
> Europe with "street level entrance" on multiple levels.

Deerbrook Mall in Humble, TX, is also like that, with an entrance on the
second floor. I'm sure there are many others.

-- 
Shawn K. Quinn 
http://www.rantroulette.com
http://www.skqrecordquest.com

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

Re: [Tagging] Forest parcel with other landcover (scrub, scree…): how to map?

[Kevin Kenny]

On Sun, Jan 20, 2019 at 1:33 PM David Marchal  wrote:
> All is in the title: when hiking in a forest (I mean, an area considered as a 
> forest by authorities), I often encounter other landcovers, like scrubs in 
> recently teared down parcels, or scree in the mountains. These area, 
> although, clearly and morphologically, not a forest, are still mapped as 
> such, as they are considered to be part of the forest and are treated this 
> may, but they are morphologically not the forest: the forest is the area 
> administratively regarded as such, but it is not always the case; if I want, 
> for instance, to map them as a scrub area of the forest, as the polygons 
> overlapped, they are rendered in a mixed way. Is there a recommended way of 
> handling such cases without broking display? If so, what are they? The 
> landcover tag? boundary=forest_compartment? Another?

This again.

There's a failed consensus here - and you risk reversion with either decision.

I tend to follow the principle that landuse=* denotes the land USE,
not the land COVER, so I don't demand that every square metre of
landuse=forest be covered by trees. But many do, and the renderer
follows their inclination.

natural=wood is a possibility to show tree cover - but that leads some
to argue that it has to be a 'natural' wood - whatever that means.
I've heard it argued that the 'old second growth' forest that's
increasingly common near me is still not 'natural' because a skilled
forester can still find the human impact. (Of course, that was true
even before the Europeans arrived - there was considerable
pre-Columbian human impact on these forests.)

landcover=trees doesn't render, but is at least unambiguous that it
means tree cover and nothing else.

landuse=forestry, for a managed forest, has been proposed but received
a lukewarm reception.

For the state forests and wildlife management areas around here, I tag
at least boundary=protected_area. (Tag with the right protect_class,
and add leisure=nature_reserve if it fits: 'nature reserve' covers a
lot of things.) If I'm mapping land cover (I seldom do), I will use
natural=wood to mean 'tree cover' and let others fight over it.

But that's just what I do, and I do not argue that it is right. With
the current state of the discussion, which has been in stalemate for a
few years, there simply is no correct tagging, and what I do appears
'least wrong' to me.

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

Re: [Tagging] Forest parcel with other landcover (scrub, scree…): how to map?

[marc marc]

Le 20.01.19 à 19:32, David Marchal a écrit :
> The landcover tag?

you may of course, despite it's not used by osm-carto
(but we don't map for the render, isn't it ?)

> Another?

map with natural=wood for the area with treet
map the scrub area as usual

> boundary=forest_compartment?
i dislike it.

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

Re: [Tagging] The actual use of the level tag

[Tobias Zwick]

> So from a SIT perspective, the problem isn't that the US (and other
> places) call the ground level "1". It's that the level below that is
> called "-1" rather than "0". You could still make it compatible with
> Simple Indoor Tagging by adding a skipped_levels=0 tag to the building,
> but this tag has only been used five times so far.

skipped_levels is also pretty awkward because one needs to recalculate
the indexed (OSM) level from the real (on the ground) level all the
time. Even worse if the levels are not actually numbers on the ground
but letters or something else (like in that mall in Bangkok).

If SIT (and by consensus in the SotM 2016 indoor session) encourages to
use the level numbering scheme of the building operator, why keep the
"tied to numbers" requirement?

Someone mentioned earlier in a diary discussion a pretty nice
solution[1]. So, in a mall with the levels P2,P1,G,M,1-12,14-99 one
simply tags:

- a shop on level M with "level=M"

- the mall building with "levels=P2,P1,G,M,1-12,14-99" (the order of the
  levels). If levels is missing, a numerical order is assumed

- also the building with "ground_level=G" to define which level is
  the ground level. If ground_level is missing, 0 is assumed.

I find this would have the following advantages while completely
compatible with the current SIT scheme and has no disadvantages (I can
come up with):

1. The correct denomination of the floor is always directly tagged on
   the shop -> much easier for end-user apps to display the correct
   floor for a shop because no special SIT software support is necessary

2. no calculating forth- and back between level "indices" and real names
   for the levels (for neither the software nor the mapper) because this
   effectively eliminates the concept of indices:

   a) thus avoids the whole 0-index-based vs 1-index-based problematic
  that I started this thread with.

   b) thus no workarounds like non_existent_levels necessary

What do you think about this?

[1]
https://www.openstreetmap.org/user/Anton%20Khorev/diary/46933#comment43565

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

[Tagging] Forest parcel with other landcover (scrub, scree…): how to map?

[David Marchal]

Hello, there.

All is in the title: when hiking in a forest (I mean, an area considered as a 
forest by authorities), I often encounter other landcovers, like scrubs in 
recently teared down parcels, or scree in the mountains. These area, although, 
clearly and morphologically, not a forest, are still mapped as such, as they 
are considered to be part of the forest and are treated this may, but they are 
morphologically not the forest: the forest is the area administratively 
regarded as such, but it is not always the case; if I want, for instance, to 
map them as a scrub area of the forest, as the polygons overlapped, they are 
rendered in a mixed way. Is there a recommended way of handling such cases 
without broking display? If so, what are they? The landcover tag? 
boundary=forest_compartment? Another?

Awaiting your answers,

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

Re: [Tagging] The actual use of the level tag

[Tobias Zwick]

On 20/01/2019 18:06, Roland Olbricht wrote:
> we have here in Wuppertal, Germany at least three indoor-tagged
> structures that have street level entrances at multiple levels, making
> "street level" a not-at-all defined concept. In case of the university
> e.g. the main entrance is on level 7, and street level entrances range
> from levels 2 to 10. I am also aware of dozens of buildings across
> Europe with "street level entrance" on multiple levels.

Defining what is the ground level wouldn't be the problem, and it is
necessary for S3DB for building:levels anyway. As far as I remember, it
is "the lowest level that has a (normal) entrance from the street".

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

Re: [Tagging] The actual use of the level tag

[Tobias Knerr]

On 20.01.19 18:06, Roland Olbricht wrote:
> I am also a bit surprised: a common interpretation of the text of
> https://wiki.openstreetmap.org/wiki/Simple_Indoor_Tagging
> (which is where https://wiki.openstreetmap.org/wiki/Key:level
> refers to) is that the level tag keeps the level numbering scheme of the
> operator whenever it is sufficently tied to numbers (that's almost
> always the case).

That's true, and having entrances at different "street levels" is
therefore not a problem: You can just follow the operator's choice.

Being "sufficiently tied to numbers" is an issue, though. SIT assumes
integer level numbers, where the level above level=n is level=n+1

So from a SIT perspective, the problem isn't that the US (and other
places) call the ground level "1". It's that the level below that is
called "-1" rather than "0". You could still make it compatible with
Simple Indoor Tagging by adding a skipped_levels=0 tag to the building,
but this tag has only been used five times so far.

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

Re: [Tagging] The actual use of the level tag

[Roland Olbricht]

Hi Tobias,

we have here in Wuppertal, Germany at least three indoor-tagged 
structures that have street level entrances at multiple levels, making 
"street level" a not-at-all defined concept. In case of the university 
e.g. the main entrance is on level 7, and street level entrances range 
from levels 2 to 10. I am also aware of dozens of buildings across 
Europe with "street level entrance" on multiple levels.


I am also a bit surprised: a common interpretation of the text of
https://wiki.openstreetmap.org/wiki/Simple_Indoor_Tagging
(which is where https://wiki.openstreetmap.org/wiki/Key:level
refers to) is that the level tag keeps the level numbering scheme of the 
operator whenever it is sufficently tied to numbers (that's almost 
always the case).


That had also been consensus in the SotM 2016 indoor session and has 
since then been used for thousands of stations in at least France and 
Germany.


What about just rewriting the section "Values" of the page
https://wiki.openstreetmap.org/wiki/Key:level
This affects the subsection "Numercial Values", but the subsection 
"String values" is misleading as well. There are only 118 objects with 
indoor=level in the world, and only 7 of them have a "name" and a 
"level:ref" tag, and only 2 use the tags as intended on the wiki pages 
(the other use the name for the whole structure).


Best regards,

Roland

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

Re: [Tagging] The actual use of the level tag

[Tobias Zwick]

Maybe. My point though is that the (un)intuitiveness of this definition
will be a constant source of error because as shops close and new shops
open, the data is changing and thus the potential for error remains.
(With incomplete software support.)

Turns out, it is even a problem in countries where the ground floor is
level 0. I was just researching what floor numbering scheme Thailand
follows by looking at mall maps in Bangkok and found that it is common
for malls to have a storey named "M" between "G" and "1"
( https://www.emporium.co.th/directory/ ), making it as mistake-prone as
mapping a mall in the US.

On 20/01/2019 16:16, Tobias Knerr wrote:
> On 20.01.19 14:49, Tobias Zwick wrote:
>> 2. generally, tagging definitions that are not intuitive to use (in a
>> region) will not be used consistently (in that region), leading to
>> ambiguous data.
> 
> I believe the high number of (potential) errors is temporary, resulting
> from the relative lack of software support for indoor mapping. Once
> application support is commonplace, mappers will likely notice that it
> "renders wrong", and fix their data accordingly. Proper editor support
> would be valuable, too, of course.
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
> 


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

Re: [Tagging] The actual use of the level tag

[Tobias Knerr]

On 20.01.19 14:49, Tobias Zwick wrote:
> 2. generally, tagging definitions that are not intuitive to use (in a
> region) will not be used consistently (in that region), leading to
> ambiguous data.

I believe the high number of (potential) errors is temporary, resulting
from the relative lack of software support for indoor mapping. Once
application support is commonplace, mappers will likely notice that it
"renders wrong", and fix their data accordingly. Proper editor support
would be valuable, too, of course.

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

[Tagging] Last call Re: Feature Proposal - RFC - Mapping disputed boundaries (Version 1.6)

[Johnparis]

I intend to put this to a vote starting next weekend, so please take a look
at the proposal and discussion.

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

Re: [Tagging] The actual use of the level tag

[Eugene Alvin Villar]

On Sun, Jan 20, 2019, 9:50 PM Tobias Zwick  Region| likely zero-based | likely one-based
> --|---|-
> Washington, Philadelphia, NY  | 3 |2
> Silicon valley, Los Angeles   | 4 |4
> Quebec, Montreal, Ottawa  | 6 |0
> Moscow|23 |   51
> Tokyo |14 |   16
> Seoul | 0 |2
> Bangkok   | 8 |5
> --|---|-
>
> For comparison:
> whole Phillipines |23 |4
> whole Netherlands |11 |2
> Berlin|19 |2
>
> *likely zero-based: there was at least one shop tagged with level=0
> *likely one-based: there was no shop tagged with level=0 but shops at at
>least two different other levels
>

A note: the Philippines is actually a one-based system (first floor =
ground floor) because our economy follows the U.S. as a result of being a
territory of the U.S. before and during WWII. The fact that you get more
zero-based level=* tagging in OSM for the Philippines is because of mappers
like me who actually do read the wiki and inform other new mappers of OSM's
system.

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

[Tagging] The actual use of the level tag

[Tobias Zwick]

Hi there,

In the wiki, the level tag is defined to be a 0-based-index so that
level=0 is the ground floor, i.e. at the street level. In other words, a
two-storey mall with no basement will have shops at level=0 and level=1.

This is intuitive for (at least) Europeans, people from Commonwealth
countries and parts of Asia as this coincides with common language.
However, in at least the USA, Canada, Japan, Korea, China and most
probably more regions, the floor at street level is denominated as the
"1st floor" in common language. In other words, it is a 1-based-index.

To my knowledge, no editor (neither iD nor JOSM) and no user-end
application takes this into account and localizes the level tag to
common language (properly). Instead, it is assumed that everybody knows
about this and adheres to this scheme.

This is why I suspect that despite it being mentioned several times in
the wiki, the level tag is not used the way it was defined in those
regions where the definition of the level tag to be 0-index-based does
not coincide with common language. Deliberately, or unwittingly.

So, I did a little research.

Via overpass, I searched for multi-storey malls in some metropolitan
regions where the first floor is at street level and looked at with
which levels the shops inside were tagged.

Results
===

Region| likely zero-based | likely one-based
--|---|-
Washington, Philadelphia, NY  | 3 |2
Silicon valley, Los Angeles   | 4 |4
Quebec, Montreal, Ottawa  | 6 |0
Moscow|23 |   51
Tokyo |14 |   16
Seoul | 0 |2
Bangkok   | 8 |5
--|---|-

For comparison:
whole Phillipines |23 |4
whole Netherlands |11 |2
Berlin|19 |2

*likely zero-based: there was at least one shop tagged with level=0
*likely one-based: there was no shop tagged with level=0 but shops at at
   least two different other levels

Note that cases where mappers did not add level=0 to shops at street
level because they thought level=0 is the default and should not need to
be specified would be counted as "likely one-based" in above table.

Conclusions
===
Two immediate conclustions can be made:

1. user-end software cannot reliably assume that level=0 is the ground
level in certain regions because the data is not mapped consistently
according to the wiki definition

2. generally, tagging definitions that are not intuitive to use (in a
region) will not be used consistently (in that region), leading to
ambiguous data.

Regards
Tobias

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

Re: [Tagging] Feature Proposal - RFC - (Hierarchies route=bicycle)

[Paul Allen]

On Sun, 20 Jan 2019 at 11:05, Axelos  wrote:

[footpath/bridleway fingerposts]

>
> I have already seen this type of symbols, but never added in OpenStreetMap.
>

There's no defined tag for them (or I can't find it).  Which makes adding
them to OSM
difficult.

Always on destination=*, there is the alternative relation that offers ideas
> (https://wiki.openstreetmap.org/wiki/Relation:destination_sign#Tags and
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Destination_details#destination:symbol
> ).
>
> Maybe to be inspired?
>

Sadly, neither of them work for footpaths/bridleways.  Nor for the other
problem I posed, that
of fingerposts with multiple arms in different directions.

The destination relation isn't a standalone, but has to be part of a route
(if I understand
the page correctly).  The fingerposts with multiple arms I'm thinking of
indicate that the
library is in one direction, the swimming pool another and the tourist
information centre
another.  They're not (necessarily) on a bus/cycle/hiking/walking route,
they're just
telling tourists the direction to certain POIs.  If you have OSM you don't
need the signs
to find those POIs, but knowing the location of such a sign helps confirm
your position
when GPS isn't getting a lock.

The icons for destination signs are interesting, but not really
applicable.  Because the
walking man icon or horse icon on the fingerpost isn't a destination.  The
hospital icon
shows "This way to the hospital."  The walking man says "this is a
footpath."  Again, with
OSM you already know it's a footpath, but the presence of the sign confirms
your position
or tells you that you should be looking for such a sign.  Quite often there
are two adjacent
gets or two adjacent tracks and the presence of the sign tells you which
one to use.

It seems to me that it's useful to map these fingerposts but that we don't
yet have a way
of doing it.

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

Re: [Tagging] Feature Proposal - RFC - (Hierarchies route=bicycle)

[Axelos]

Hello Paul,


Paul Allen wrote
> On Mon, 14 Jan 2019 at 10:38, Axelos 

> axelos@

>  wrote:
> 
> The direction signs are a real problem. An alternative solution is to
>> exploit the destination key
>> https://taginfo.openstreetmap.org//search?q=destination%3Abicycle
>>
> 
> However, it's an incomplete solution.  Around here, official cycle routes
> have fingerposts
> which show a bicycle icon and the number of the route.  It's not a
> destination, just an
> indication that cycle route 82 is along a particular direction.
> 
> Similarly, the UK has many public footpaths and bridleways.  Where they
> join a highway there
> is usually a fingerpost with an icon of either a walking person (footpath)
> or a horse (bridleway).
> No destination is given.  It's useful to indicate, in some way, that these
> are signs for
> footpaths or bridleways so that people know what they're looking for when
> navigating.

I have already seen this type of symbols, but never added in OpenStreetMap.

Always on destination=*, there is the alternative relation that offers ideas
(https://wiki.openstreetmap.org/wiki/Relation:destination_sign#Tags and
https://wiki.openstreetmap.org/wiki/Proposed_features/Destination_details#destination:symbol).

Maybe to be inspired?

Regards, Axel.



--
Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html

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