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

2019-02-03 Thread Tobias Knerr
On 22.01.19 22:18, Tobias Zwick wrote:
> First, I am still in the dark a bit how this affects SIT with S3DB
> compatibility, perhaps Tordanik can explain.

My comment regarding S3DB compatibility was about the related issues
that were brought up in this thread (e.g. indoor features outside of a
building outline). Your suggested tagging for non-numeric levels would
not harm S3DB compatibility, as long as mappers reliably add the levels tag.

To respond to the points from your previous mail:

On 21.01.19 20:16, Tobias Zwick wrote:
> In the current SIT scheme*, in this case, it is required to add 5
> additional outlines, one for each floor (indoor=level)

Using the currently documented tags, that's mostly true (the levels
where the number is actually used as the ref wouldn't require the
indoor=level) element. I admit that this is more work than one would
want for a simple case.

However, in addition to your suggestion, there are multiple other
possible approaches for making this easier. One is the level:ref key.
Independently from SIT, this has been proposed for use on individual
indoor elements alongside level. When you have a building that isn't
actually fully indoor-mapped, but simply has a few POI with level tags
(which is likely to be the much more common case), this might be an option.

If we wanted to do something similar to your suggestion (i.e. place a
tag on the building outline), this would be possible without redefining
level to allow non-numeric levels: We could invent a new key – say,
"level:refs" – that would be added to the building to indicate the
locally used level labels:

level:refs="LG,UG,M,1,2"

Then, if you want to know what to display for an element tagged as
level=0, you can just look it up in that list. This approach is pretty
much the precise mirror image of the one you suggested earlier, and
requires the same amount of elements and tags.

So which approach is the best? To be honest, I'm not sure about that
yet. But I agree that the current SIT definition leaves room for
improvement.

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


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

2019-02-01 Thread Richard
On Wed, Jan 30, 2019 at 02:44:50PM +0100, Tobias Zwick wrote:
> I stumbled upon a real-world example yesterday that may make the attempt
> to have the level-tag describe a "global" order (as used in OpenLevelUp,
> JOSM etc.) somewhat impractical -  with that level-selector UI element:
> 
> So, Hamburg is a really flat city. And even still, the mall "Europa
> Passage" ...
> https://www.openstreetmap.org/way/214840502#map=17/53.55223/9.99644
> ... does have two "ground floors". If you enter through the northern
> entrance, you are in the lower ground floor (level=0), if you enter
> through the southern entrance, you are in the upper ground floor
> (level=1). If you walk alongside the mall though (Bergstraße), there is
> no (apparent) elevation.
> 
> So, imagine there are more indoor-mapped places both around the northern
> and the southern end of that mall (there is, partly, but I am sparing
> you the details), and as a matter of fact, sprinkled throughout the
> entire city centre.
> Then, to have a global order of things, the ground floor of all the
> buildings South of that mall would need to be tagged with level=1 and
> the ground floor of all the buildings North of this mall would need to
> be tagged with level=0. In other words, must be relative to the level
> order used in this building.
> 
> I see two problems with this:
> 
> 1. Where to stop? How global is this global order? Going further South,
> at what point does the level-value for the ground floor revert back to
> 0? What then if two such places collide? (A mall and a multi-level train
> station were mapped separately and they built a tunnel to connect the
> two, but they connect on different level=X - or not even a tunnel, let's
> say they are just next to each other)

The level value is only valid inside one building in my interpretation. 
The safest value to join ways from different buildings would be using 
key:ele. Often enough there will be problems of the kind that a level 
value isn't even uniformly valid inside one building.

Richard


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


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

2019-01-30 Thread Minh Nguyen

On 2019-01-20 05:49, Tobias Zwick wrote:

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.


The numbering system can also vary by region within a country. Northern 
and central Vietnam uses a zero-based system while southern Vietnam uses 
a one-based system, and somehow both are national standards. [1] I'm 
unsure if there's a well-defined boundary between the two systems, but 
if there is, I like to think someone has built a building straddling the 
two, just to mess with us.


[1] https://en.wikipedia.org/wiki/Storey#East_Asian_schemes

--
m...@nguyen.cincinnati.oh.us


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


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

2019-01-30 Thread Tobias Zwick
I stumbled upon a real-world example yesterday that may make the attempt
to have the level-tag describe a "global" order (as used in OpenLevelUp,
JOSM etc.) somewhat impractical -  with that level-selector UI element:

So, Hamburg is a really flat city. And even still, the mall "Europa
Passage" ...
https://www.openstreetmap.org/way/214840502#map=17/53.55223/9.99644
... does have two "ground floors". If you enter through the northern
entrance, you are in the lower ground floor (level=0), if you enter
through the southern entrance, you are in the upper ground floor
(level=1). If you walk alongside the mall though (Bergstraße), there is
no (apparent) elevation.

So, imagine there are more indoor-mapped places both around the northern
and the southern end of that mall (there is, partly, but I am sparing
you the details), and as a matter of fact, sprinkled throughout the
entire city centre.
Then, to have a global order of things, the ground floor of all the
buildings South of that mall would need to be tagged with level=1 and
the ground floor of all the buildings North of this mall would need to
be tagged with level=0. In other words, must be relative to the level
order used in this building.

I see two problems with this:

1. Where to stop? How global is this global order? Going further South,
at what point does the level-value for the ground floor revert back to
0? What then if two such places collide? (A mall and a multi-level train
station were mapped separately and they built a tunnel to connect the
two, but they connect on different level=X - or not even a tunnel, let's
say they are just next to each other)

2. It is somewhat confusing for the user (and the mapper) because if you
look at such a map, at for example level=0, you would see an unexpected
split through the city centre where seemingly no building is
indoor-mapped South of that mall ... oh wait, it's all on level=1+.  ???

I, too, hope that the example was understandable.

Tobias

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


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

2019-01-24 Thread Simon Poole
See the original page on the Karlsruher schema:
https://wiki.openstreetmap.org/wiki/Proposed_features/House_numbers/Karlsruhe_Schema

Am 23.01.2019 um 05:04 schrieb Eugene Alvin Villar:
> On Mon, Jan 21, 2019 at 4:11 PM Simon Poole  > wrote:
>
> [...] addr tags are for postal addresses I don't think using them as a
> level name/ref makes very much sense outside of that very narrow
> application.
>
>
> I rechecked the two main OSM Wiki pages[1][2] on addr:*=* tags and
> addresses in general and there is no indication there that such tags
> are only intended to encode postal addresses (aside from the specific
> addr:postcode=* tag). Personally, I use addr:*=* tags in any scenario
> where addresses can be used, such as in contact/location addresses
> which is used when the general public (and not just the
> postman/mailman) wants to go to an office, shop, or an establishment.
> For example, the Consulate-General of Japan in Hong Kong lists their
> location where they can be reached[3] as "46-47/F, One Exchange
> Square, 8 Connaught Place, Central, Hong Kong". I could then encode
> this as:
>
> addr:floor=46-47/F
> addr:housename=One Exchange Square
> addr:housenumber=8
> addr:street=Connaught Place
> addr:place=Central (tag probably unnecessary if Central is already a
> boundary)
> addr:city=Hong Kong (probably unnecessary since HK already has a boundary)
>
> As for level=*, I don't know whether this building skips any floor
> numbers (4th? 14th? 24th? etc.) so I would hold off on tagging level=*
> until I get to see their elevator buttons.
>
> [1] https://wiki.openstreetmap.org/wiki/Key:addr
> [2] https://wiki.openstreetmap.org/wiki/Addresses
> [3] https://www.hk.emb-japan.go.jp/itpr_en/opentime.html
>
> ~Eugene
>  
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2019-01-23 Thread Richard
On Tue, Jan 22, 2019 at 10:18:51PM +0100, Tobias Zwick wrote:
> On 22/01/2019 10:47, Lionel Giard wrote:
> > So, i'm really in favor of the level=* for a "data user friendly" tag
> > (that could correspond to local numbering, but not always) and a special
> > tag for the local levels. At this moment i would see a *local level tag
> > *like "level:ref=*" or "loc_level=*" (like we have for name and loc_name
> > ?) but _*on each object*_, as it would not be realistic to use an
> > outline in the cases i present). 
> > 
> > PS: i hope my example is not too confusing, or badly explained. :-)
> 
> I understand it. (To recap - ) you are giving a real-life example of
> what Roland described: Using the level tag outside of (a single)
> building but in a wider scope.
> To be able to show on indoor maps what is really on the same level on a
> scope that exceeds single buildings, you need to use the level-tag also
> in a scope that exceeds single buildings, making it important that the
> level indices of (neighbouring) buildings match.
> 
> So, basically, your example is like a situation where two malls are
> connected by a footbridge, but one mall labels its level there as "UG"
> and the other as "M".[1]
> If the level tag was allowed to be non-numerical and required to always
> follow the building operator's denomination even if they are letters and
> not numbers, the information on what buildings (and non-buildings like
> footbridges, train stops, tunnels etc.) connect to each other is lost.

I think "level" in adjacent buidlings can never be relied upon. In some 
cases key:ele would help.

 
> So, though, this means that (already now), the level tag enjoys somewhat
> of a dual-usage:
> - On the one hand, it should follow the building operator's denomination
>   as long as it is numeric, thus, is or comes close to how the level is
>   really named "on the ground"
> - On the other hand, in a wider context, it is used similarly to the
>   layer tag: An arbitrary ("programmer's") value to arrange a Z-order.
> 
> I think this dual usage may come back to bite us.

correct and it is tempting to do it so. If and when it bites us I think we
will find "rescues".

> Second, why can not the layer tag be used to arrange the global z-order
> of things?

layer is too weak as ordering operator. 2 ways layer=-1 + layer=2 can meet 
in a node and (depending on node type if any) - will usually be assumed
to meet exact level.

Also there are loads of historical baggage associated with layer limiting
its usability. Because of widespread errors/abuse data consumers will/have 
to ignore layer in many combinations.

Richard
 

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


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

2019-01-22 Thread Phake Nick
>
> One reason that's of particular interest to me is that SIT is intended
> to be compatible with 3D rendering, allowing for the creation of 3D
> models that represent both the inside and outside of buildings at the
> same time.
>
> At the moment, Simple 3D Buildings has no support for "half" levels, so
> if we want to preserve that feature of SIT, we would need to update both
> tagging standards at the same time.
>

For indoor tags to be compatible with 3D rendering, there should be a way
to indicate 3D position of bridge/tunnel/stair/any other structures that
connect multiple structures together. Unless I'm mistaken, I don't think
there's currently a universally accepted way in indoor tagging and 3d
tagging to tag a bridge between level 3 of a building and level 6 of
another nearby building, which is a rather common scenario for building
cluster built on a mountain or slope and thus each individual building have
different ground levels.

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


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

2019-01-22 Thread Eugene Alvin Villar
On Mon, Jan 21, 2019 at 4:11 PM Simon Poole  wrote:

> [...] addr tags are for postal addresses I don't think using them as a
> level name/ref makes very much sense outside of that very narrow
> application.
>

I rechecked the two main OSM Wiki pages[1][2] on addr:*=* tags and
addresses in general and there is no indication there that such tags are
only intended to encode postal addresses (aside from the specific
addr:postcode=* tag). Personally, I use addr:*=* tags in any scenario where
addresses can be used, such as in contact/location addresses which is used
when the general public (and not just the postman/mailman) wants to go to
an office, shop, or an establishment. For example, the Consulate-General of
Japan in Hong Kong lists their location where they can be reached[3] as
"46-47/F, One Exchange Square, 8 Connaught Place, Central, Hong Kong". I
could then encode this as:

addr:floor=46-47/F
addr:housename=One Exchange Square
addr:housenumber=8
addr:street=Connaught Place
addr:place=Central (tag probably unnecessary if Central is already a
boundary)
addr:city=Hong Kong (probably unnecessary since HK already has a boundary)

As for level=*, I don't know whether this building skips any floor numbers
(4th? 14th? 24th? etc.) so I would hold off on tagging level=* until I get
to see their elevator buttons.

[1] https://wiki.openstreetmap.org/wiki/Key:addr
[2] https://wiki.openstreetmap.org/wiki/Addresses
[3] https://www.hk.emb-japan.go.jp/itpr_en/opentime.html

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


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

2019-01-22 Thread Tobias Zwick
On 22/01/2019 10:47, Lionel Giard wrote:
> So, i'm really in favor of the level=* for a "data user friendly" tag
> (that could correspond to local numbering, but not always) and a special
> tag for the local levels. At this moment i would see a *local level tag
> *like "level:ref=*" or "loc_level=*" (like we have for name and loc_name
> ?) but _*on each object*_, as it would not be realistic to use an
> outline in the cases i present). 
> 
> PS: i hope my example is not too confusing, or badly explained. :-)

I understand it. (To recap - ) you are giving a real-life example of
what Roland described: Using the level tag outside of (a single)
building but in a wider scope.
To be able to show on indoor maps what is really on the same level on a
scope that exceeds single buildings, you need to use the level-tag also
in a scope that exceeds single buildings, making it important that the
level indices of (neighbouring) buildings match.

So, basically, your example is like a situation where two malls are
connected by a footbridge, but one mall labels its level there as "UG"
and the other as "M".[1]
If the level tag was allowed to be non-numerical and required to always
follow the building operator's denomination even if they are letters and
not numbers, the information on what buildings (and non-buildings like
footbridges, train stops, tunnels etc.) connect to each other is lost.

This is an interesting point. I agree, this is important information for
an indoor-map.
And from this standpoint, your suggestion to allow "level:ref" on single
shops within one building as a replacement for "level" sounds like a
good solution to accommodate for the points I made.

---

So, though, this means that (already now), the level tag enjoys somewhat
of a dual-usage:
- On the one hand, it should follow the building operator's denomination
  as long as it is numeric, thus, is or comes close to how the level is
  really named "on the ground"
- On the other hand, in a wider context, it is used similarly to the
  layer tag: An arbitrary ("programmer's") value to arrange a Z-order.

I think this dual usage may come back to bite us.

First, I am still in the dark a bit how this affects SIT with S3DB
compatibility, perhaps Tordanik can explain. After all, a clearly
defined global Z-Order of things would be in the best interest of
3d-rendering, but he mentioned that this is not how the level tag was
intended (for SIT).

Second, why can not the layer tag be used to arrange the global z-order
of things?

Regards
Tobias


[1] By the way: The most complex example of such a situation I know is
Pathum Wan (ปทุมวัน) junction in central Bangkok, a multi-level skytrain
station, five different malls and a culture centre connect with each
other with various footbridges. Photos:
http://www.komchadluek.net/photo-gallery/512

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


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

2019-01-22 Thread Lionel Giard
As pointed out for underground station, the building outline doesn't always
cover the underground levels (i.e. the underground levels can extend far
beyond the building limit (and potentially under other buildings/roads...).
We find this problem for metro station, train station or other buildings
like mall.

One example is the mall "L'Esplanade" (Louvain-la-Neuve, Belgium) that you
can see indoor mapped (except parking levels) here
https://openlevelup.net/?l=1#18/50.67045/4.61647 .
It is on a concrete slab (only pedestrian traffic) that cover all the city
center and is more or less 2 levels above the streets where car drive (the
streets are in a "tunnel" when going under the city center. Most of the
time these 2 levels can be described like "street level / ground level" and
the "first level" is for parking, and the "second level" is at the surface
with the pedestrian area) and you have building going up to 6-7 floors
above that. But for the mall, you have a different leveling : the street
level is still the parking entrance, but the two levels above with shops,
so that means that the "first level" of shops is below the surface, and
indeed it is extended below two plazas and another building. To avoid the
mess that could occur with the levels tags, we choose to set an arbitrary
level tagging for the whole city center that's on the concrete slab (it can
be seen as a large building, and it is not too far from reality).

In this case, the level tag need to be synced with all the neighboring
building that are built on the same structure (the "concrete slab"),
otherwise you would have multiple objects at the same position when
rendered on a map. Ex : The mall is officially labelled as "-1" for the
parking entrance, "0" and "1" for the shops levels (the level 1 is on the
surface), while the building that's on top of some part of the mall have
level starting at "0" (the surface level with entrances from the concrete
slab) and going up to level 6 above that. If we use these local numbers for
the level tag, any tools would render the building surface level at the
same position than the shops level that's underneath it !!! For POI it
would be like "is it at level 0 in the mall or at level 0 in the building
?", thus an arbitrary level for all these buildings is really needed to
avoid such problems.

So, i'm really in favor of the level=* for a "data user friendly" tag (that
could correspond to local numbering, but not always) and a special tag for
the local levels. At this moment i would see a *local level tag *like
"level:ref=*" or "loc_level=*" (like we have for name and loc_name ?) but *on
each object*, as it would not be realistic to use an outline in the cases i
present).

PS: i hope my example is not too confusing, or badly explained. :-)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2019-01-21 Thread Tobias Knerr
On 21.01.19 22:38, Roland Olbricht wrote:
> I do consider both to be SIT compliant.

I'm not sure if it's clear from the written text of SIT, but neither
fractional levels nor indoor features outside of a building outline were
part of SIT's design. (And yes, these are obvious omissions that will
need work.)

> In particular, there is no object that could or should carry tags
> applying to all involved objects.

Levels only have meaning within a single structure, though. Level "2" in
the neighbouring building (or even building part) might represent an
entirely different absolute elevation.

An important assumption (and limitation, because this isn't always true
in reality) of SIT is, therefore, that there is some kind of outline
within which a level number refers to a single, fixed elevation.

I didn't really raise that point so far because I don't have a better
solution to offer yet, but your station mapping does contradict the
assumptions we had when writing SIT, and I feel we should collaborate to
define the semantics of such a situation.

> But I do not see yet why there should be a mapping of levels to integers
> at all.

One reason that's of particular interest to me is that SIT is intended
to be compatible with 3D rendering, allowing for the creation of 3D
models that represent both the inside and outside of buildings at the
same time.

At the moment, Simple 3D Buildings has no support for "half" levels, so
if we want to preserve that feature of SIT, we would need to update both
tagging standards at the same time.

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


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

2019-01-21 Thread Roland Olbricht

Hi Tobias,

thank you for keeping the discussion. One extra thing I have just 
learned is that non-numerical level refs are not-so-uncommon in the US, 
hence should be covered by a tool to be helpful there.


> I do not want to sound so combative or negative here - to reason
> for why a new tag may be useful, I just need to describe the problem.
> I want us all to be on the same page.

I am still not yet sure about where we are starting from and where we 
are going to.


Typical examples would be for me:
https://openlevelup.net/?l=-2#20/55.68178/12.55260
https://openlevelup.net/?l=-0.5#18/51.23423/6.77858

I do consider both to be SIT compliant.

In both cases there is no building outline (at least no canonical one; 
footprint on the street level is different from the total of passenger 
visible area is different from the area covered by concrete foundations 
and so on).


In particular, there is no object that could or should carry tags 
applying to all involved objects. Given that one often cannot even 
decide for a station complex whether it is one or multiple stations, 
there often cannot be a global object responsible for the structure as a 
whole.


The half numbered levels for the small mezzanines fit intuitively into 
the whole level order -2, -1, 0 as signposted by the operator. Thus 
there also is no need for an explicitly declared order on a global object.


There is an obvious order of the levels there by reading them as 
fractional numbers. And all tools I am aware of (OpenLevelUp, JOSM, 
OpenStationMap and others) can work with this sequence of levels.


So I do support to have new extra tags that keeps whatever important but 
yet missing information.


But I do not see yet why there should be a mapping of levels to integers 
at all. Clarifying this point probably would help to understand whether 
there is a preferred choice for 0, whether missing levels need to be 
modeled at all and what to do with small mezzanines: Shall they trigger 
to have a gap for them in a potentially large building complex? Can 
disjoint mezzanines between larger levels get the same level designation 
to keep the index dense?


Best regards,

Roland

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


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

2019-01-21 Thread Tobias Zwick
On 21/01/2019 09:19, PanierAvide wrote:
> Just for your information, there is also this "level:ref" tag which was
> used in various context to solve this problem 

I know of "level:ref". However, on the SIT wiki page, "level:ref" is
documented as a tag for the level-outline tagged with "indoor=level",
not as an alternative to "level" on each individual shop.

So, it is possible to make the connection between the index and the
level denomination, but it is not exactly straightforward. I just wrote
a longer description (of the problem) on another branch:
https://lists.openstreetmap.org/pipermail/tagging/2019-January/042369.html

Regards
Tobias

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


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

2019-01-21 Thread Tobias Zwick
On 20/01/2019 23:39, Tobias Knerr wrote:
> 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.

Yes, the levels=* would be mandatory for proper ordering in those cases
where the floor levels are not numerical. For places where it is
numerical, nothing changes. It'd be an extension after all.

Consider: For places where they are not numerical, only
levels="LG,UG,M,1,2" on the building (part) outline is required to allow
tagging shops with a non-numerical level, nothing more.

In the current SIT scheme*, in this case, it is required to add 5
additional outlines, one for each floor (indoor=level), and tag each
with a level-index (level) and floor denomination (level:ref) in order
to create the relation between the level-indices as tagged on each
individual shop and the actual floor denomination.
In other words, to map a mall with non-numerical floor numbers already
requires to use the stuff described under "advanced modelling", and it
is more than one tag, it is 5 times "level" and 5 times "level:ref".

Additionally, one has to tag each shop not with the actual floor
denomination, but with the said level-index referenced in each floor
outline.
In the described case of non-numerical floors, the level-index becomes a
purely virtual ("programmer's") value which only becomes meaningful when
all the data is put together. And apart from making the machine
understand the relation between index and ref, the mapper himself needs
to make the conversion (in his head - .oO("UG is 0", "M is 1", "1 is
2",...)) for every shop he maps as well, which is prone to error,
especially with sporadic contributors.
In a nutshell, mappers and software are expected to know and use the
(advanced) SIT scheme if they "just" want to map on which floor a shop
is located.

I do not want to sound so combative or negative here - to reason for why
a new tag may be useful, I just need to describe the problem. I want us
all to be on the same page.

* as far as I understand it, correct me if I am wrong

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


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

2019-01-21 Thread Lionel Giard
Yes it makes sense to keep this distinction : level tag can just be the
"logical order" of levels going from -xx to xx with an arbitrary 0 for each
building, so tools know the order (which one is above the other). Simple
Indoor Tagging already suggest the level:ref for the "local" naming scheme.
It could be used by tools when they show you the name of the level in their
interface (One example : a building with tags "level=0" + "level:ref=Ground
floor", instead of showing "level 0", the tool can display "Ground floor"
-> both the data user and the data consumers are happy ;-) ).

Le lun. 21 janv. 2019 à 09:20, PanierAvide  a
écrit :

> Hello,
>
> Just for your information, there is also this "level:ref" tag which was
> used in various context to solve this problem :
>
> - level tag is still used as defined in Simple Indoor Tagging
> - level:ref has a value which is linked to operator naming of levels
>
> That way, casual mappers/consumers don't need to stick to level definition
> which doesn't make regarding operator naming, they can set level:ref
> according to what they are used to see. And we keep the level definition
> which makes more sense for tools.
>
> Regards,
>
> Adrien.
>
> PanierAvide
> Géomaticien et développeur
>
> Le 21/01/2019 à 09:05, Simon Poole a écrit :
>
> As tordanik has already pointed out the main issue with the proposals is
> that there is no inherent ordering that can be deduced from level values
> on objects if they are not (integer) numbers, so any such scheme
> requires far more insight, effort and available context from
> joe-casual-mapper and joe-casual-data-consumer to get layering right.
> With the current scheme that is a no-brainer even if there are
> discrepancies between actual numbering of the floors and what is being
> used in OSM.
>
> Simon
>
> PS: addr tags are for postal addresses I don't think using them as a
> level name/ref makes very much sense outside of that very narrow
> application.
>
>
>
>
> ___
> Tagging mailing 
> listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging
>
> ___
> 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

2019-01-21 Thread Martin Koppenhoefer
Am So., 20. Jan. 2019 um 23:41 Uhr schrieb 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.
>


+0.95
The mapping should relate to the most useful unit (the one which is locally
used), this can be the building, but it can also be a building:part.
Sometimes, numbering follows building parts, not the "global" building.

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


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

2019-01-21 Thread Martin Koppenhoefer
Am So., 20. Jan. 2019 um 18:07 Uhr schrieb Roland Olbricht <
roland.olbri...@gmx.de>:

> 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.




+1, also from my experience, entrances on different levels are typical for
big structures without a single centralized entrance, like shopping malls
usually are. Different street levels are used to reduce congestions.

I would see the level as indicated locally (on the ground) the most useful
thing to know. This can also deal with things like level B1, B2 for
intermediate levels of smaller buildings parts and similar. Huge structures
sometimes use levels 0, 1, 2, 3, 4, ... for the "main levels" (sometimes
with significant bigger vertical floor distances than the 3-4 m that are
the minimum)  but also have numbering for intermediate levels.

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


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

2019-01-21 Thread PanierAvide

Hello,

Just for your information, there is also this "level:ref" tag which was 
used in various context to solve this problem :


- level tag is still used as defined in Simple Indoor Tagging
- level:ref has a value which is linked to operator naming of levels

That way, casual mappers/consumers don't need to stick to level 
definition which doesn't make regarding operator naming, they can set 
level:ref according to what they are used to see. And we keep the level 
definition which makes more sense for tools.


Regards,

Adrien.

PanierAvide
Géomaticien et développeur

Le 21/01/2019 à 09:05, Simon Poole a écrit :

As tordanik has already pointed out the main issue with the proposals is
that there is no inherent ordering that can be deduced from level values
on objects if they are not (integer) numbers, so any such scheme
requires far more insight, effort and available context from
joe-casual-mapper and joe-casual-data-consumer to get layering right.
With the current scheme that is a no-brainer even if there are
discrepancies between actual numbering of the floors and what is being
used in OSM.

Simon

PS: addr tags are for postal addresses I don't think using them as a
level name/ref makes very much sense outside of that very narrow
application.



___
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

2019-01-21 Thread Simon Poole
As tordanik has already pointed out the main issue with the proposals is
that there is no inherent ordering that can be deduced from level values
on objects if they are not (integer) numbers, so any such scheme
requires far more insight, effort and available context from
joe-casual-mapper and joe-casual-data-consumer to get layering right. 
With the current scheme that is a no-brainer even if there are
discrepancies between actual numbering of the floors and what is being
used in OSM.

Simon

PS: addr tags are for postal addresses I don't think using them as a
level name/ref makes very much sense outside of that very narrow
application.




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2019-01-20 Thread 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] The actual use of the level tag

2019-01-20 Thread 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

2019-01-20 Thread 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] The actual use of the level tag

2019-01-20 Thread 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

2019-01-20 Thread 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

2019-01-20 Thread 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] The actual use of the level tag

2019-01-20 Thread 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

2019-01-20 Thread 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] The actual use of the level tag

2019-01-20 Thread 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

2019-01-20 Thread 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] The actual use of the level tag

2019-01-20 Thread 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


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

2019-01-20 Thread 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

2019-01-20 Thread 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

2019-01-20 Thread 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

2019-01-20 Thread 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

2019-01-20 Thread 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


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

2019-01-20 Thread 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

2019-01-20 Thread 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