show location/level data if present to allow less confusing editing of objects not on surface level

[matkoniecz]

In many cases location and quest type is enough to identify the object.

But there are also more complex areas like multilevel shopping malls, underground passages + surface level shops, train stations etc.

In this cases it would be useful to show information like "this object is underground" (for ones with location=undeground) or "this object is on floor 6" (it has level=6)

I thought about showing it on text bar, below/above quest interface for all object with location=undeground, location=roof, location=rooftop, level!=0 (or maybe also for level=0 in multilevel objects?)

I can make an UI mockup if that would be helpful.

examples:

https://www.openstreetmap.org/node/5989365695 (invisible from street level, they even have no sign visible fo street - information that they are on level=6 would reduce confusion)

https://www.openstreetmap.org/way/388758688 (location=undeground tourism attraction, accessible from an U-bahn station)

https://www.openstreetmap.org/node/5613220777#map=19/50.06713/19.94662 (shop in a multilevel mall, has level=1)

[westnordost]

Right, this would be an important feature for indoor-places (malls, train stations etc.)

I see two locations where this information could go:

1. it could appear as a label at/above the quest pin
2. in the question speechbubble above the question. i.e. "in the first floor: \n What are the opening hours of ...?"

This feature also requires research how floor levels are denominated correctly. E.g. I think there are countries/languages where the ground floor is the first level and some countries where the ground floor is the 0st level etc. This information would need to go into the country metadata and a concept needs to be worked out how to combine this data and localization to refer to the levels correctly.

[matkoniecz]

https://www.openstreetmap.org/user/Anton%20Khorev/diary/46933 about level tag mess just appeared

I guess that it would be easier (and still useful) to start from showing location tag data.

[westnordost]

Location could be used as a fallback if neither level nor level:ref is set. I answered to the blog post. Isn't it resolved after @simonpoole's comment?

[goldfndr]

Rather than text, a less distracting possibility would be to display an icon:

• ↥ for objects with level > 0 or upper locations
• ↧ for objects with level < 0 or lower locations
• _ for objects with level = 0 or location=surface or an object without either within a mutilevel building polygon

Icon could perhaps be tapped to open a new activity that shows and perhaps permits editing of location, level, level:ref.

[goldfndr]

Additionally, if location is edited, perhaps add a note with before/after values and suggest confirming that the layer value is correct?

Oh, above "within" should include "on the border of".

[westnordost]

Does this sound like a good logic for wording? (In en/de, people like @matkoniecz with other mother tongues are invited to say if this works for them, i.e. can be expressed unambiguously)

If level:ref is available, always this is picked, level is the fallback.

tagging	en	de
level:ref=1	on floor 1:	im Geschoss 1:
level:ref=-1	on floor -1:	im Geschoss -1:
level:ref=OG	on floor OG:	im Geschoss OG:
level=3	3 levels above the ground floor:*	im 3. Obergeschoss:
level=0	on the ground floor:	im Erdgeschoss:
level=-2	on basement floor 2:	im 2. Untergeschoss:

* long description, but "3rd floor" is ambiguous because different countries have different numbering schemes. Question to native speakers: Is "on upper floor 3:" (literal translation from German) equally unambiguous and understood?

and maybe: In countries where the ground floor is (usually) the "1st floor" only, add this info in italics in the language of that country. This may be both important for the European tourist in the US but also for any other person from the US to not get confused.

tagging	en	de
level=3 in the US	3 levels above the ground floor (4. floor):	im 3. Obergeschoss (4. floor):
level=3 in Russia	3 levels above the ground floor (4 этаж):	im 3. Obergeschoss (4 этаж):

[westnordost]

Additionally, it is the question whether if both level and level:ref is available, if both should be shown? E.g.

• on floor 14 (13 levels above the ground floor): / im Geschoss 14 (13. Obergeschoss)
• on floor EG (ground floor): / im Geschoss EG (Erdgeschoss)
• on floor 1 (ground floor): / im Geschoss 1 (Erdgeschoss)

[westnordost]

What is definitely not an option is to decide on a country-by-country basis whether to call something 2nd floor or 1st floor depending on the numbering scheme, because it may very well be that the user is from a country where this scheme is different but he does not know about that. Not only this, but even if the user knows about the differences, he does not know if the app knows - e.g. if it took this already into account or not. So, this would be a massive source for misunderstanding. Better choose an unambiguous wording, even at the cost of brevity.

[rugk]

I hope no building really uses "level:ref=-1" as nobody understands what that is. Possibly it would also be a tagging error and they really meant "level=-1". I mean "level:ref=A/B/C/…" makes sense, but otherwise it should just be "level", as you can then translate it into proper (non-integer) strings for users, that not only programmers can understand.

Personally I'd favor "Untergeschoss" over "Kellergeschoss" in the German translation, but that likely depends on where you live in Germany – accent-wise.

Additionally, it is the question whether if both level and level:ref is available, if both should be shown?

Seeing your examples, I'd tend to say yes. This may help to prevent the ambiguity of whether the ground floor is 0 or 1. (I mean, even in Germany that may not always be clear to people :wink:) So, I'd also say rather be more explicit.

[rugk]

Also translating numbers into words would be awesome, i.e. "im 3. Obergeschoss" = "im dritten Obergeschoss". I guess/hope there are libs or stuff for this, at least for JS there is something although it seems they also want to expand this support for other programming languages.

---

Thinking about this, however:

tagging	en	de
level=3	3 levels above the ground floor:*	im 3. Obergeschoss:

If you want to make it explicit, you also have to translate the German translation to "3. Geschoss über dem Erdgeschoss". Also note you are likely to fall into a "where is the dev from" trap, as an American developer would probably have expressed it like this:

tagging	en	de
level=3	4th level (including ground floor):	im 4. Geschoss (inklusive Erdgeschoss)

So I would definitively argue for your "and maybe:" idea. If you would apply this as a US programmer, it would look like this:

tagging	en	de
level=3	4th level (including ground floor, level 3):	im 4. Geschoss (inklusive Erdgeschoss, 3. Geschoss)

So seeing this as a German translation I would be confused anyway. So maybe it may not be so helpful for Americans anyway?

[westnordost]

If you want to make it explicit, you also have to translate the German translation to "3. Geschoss über dem Erdgeschoss".

You really think so? You can also say "3. Etage" or "3. Geschoss" in German, but only "Obergeschoss" is pretty unambiguous in that the first "Obergeschoss" (=upper level) will be the one above the ground floor. Hence "Ober". In other words, noone would think that 1. Obergeschoss is the ground floor.

Also, I want to stay away from any wording with "inclusive ground floor" etc., because I find this pretty ambiguous as well, also in German. (At least I find your examples pretty confusing).

I now implemented the first table and https://github.com/westnordost/StreetComplete/issues/1270#issuecomment-455800561 but not the "maybe:"-table because I am not sure if it really makes things clearer, especially when https://github.com/westnordost/StreetComplete/issues/1270#issuecomment-455800561 is implemented.

[rugk]

You can also say "3. Etage" or "3. Geschoss" in German, but only "Obergeschoss" is pretty unambiguous in that the first "Obergeschoss"

Hmm, okay, get your idea, but this is hard to answer. Personally I would use "Obergeschoss" and "Geschoss" interchangeably and only use "Obergeschoss" to differentiate it from "Untergeschoss" (basement floor).

Also, I want to stay away from any wording with "inclusive ground floor" etc., because I find this pretty ambiguous as well, also in German. (At least I find your examples pretty confusing)

I find them confusing, too. That's also what i wrote. However, an American would probably find our examples with "x levels above the ground floor" confusing and tend to easier understand what "4th level (including ground floor)". Basically this "annotation" is just a "confirmation of "the way the user is used to this". If it is different, the user understands this, but it nevertheless confuses them… The only thing I want to express here is that we are of course culturally biased in a sense that we find one way of saying it intuitive while other's would thing that way is confusing/strange and vice-versa. So a kinda hard UX challenge here…

[westnordost]

We need an American and maybe some other native English speakers in this thread. Maybe @dbdean , @goldfndr or also @bhousel? I wonder how/if iD avoids this translation trap / ambiguity. (Newcomers to this thread, start here: https://github.com/westnordost/StreetComplete/issues/1270#issuecomment-455800088)

[westnordost]

First draft implementation

[gdt]

(I'm a native en_US speaker.)

I find a lot of the above terminology confusing. The discussion above that says that in the US, the first floor is the one at street level is correct. Generally the level below will be called B in the elevator, for basement. And B2, B3 for subbasements. A wrinkle is that often there is no floor 13, especially in hotels, and floor 14 is above floor 12.

This feels like a locale (l10n) issue. If I set my phone locale to en_US (ignoring blurring android and posix mechanisms, because that's not the issue), and go to the UK, I should still see dates etc. in US format . So there's a good argument that how "level=1" translates to "first floor" (UK) vs "second floor" (US) should be controlled by the locale. For example, two Americans while traveling might speak of the second floor of a hotel which is floor 1 locally.

That raises the question of whether things should be described in the native locale of the object or the locale that the phone is set to. And perhaps a warning is in order when those are different. Or perhaps it could be crazy verbose then, and when local locale and phone locale match, written for native speakers.

I think "2 levels above ground floor" will seem bizarre to Americans who are not nerds, and some of them will absorb that incorrectly as "2nd floor".

Also, some buildings are on hills, and have at-grade entrances in different places on different floors. You really know which floor is which by how they are labeled on stairwells, office numbers, and elevators, and really it is a little arbitrary.

I wonder about a popup explaining the locale issues when there's a mismatch, warning that the text is in the local locale.

[gdt]

A related question is if you expect the user to understand OSM tagging rules. My understanding is that for streetcomplete, the answer is no.

[rugk]

What is definitely not an option is to decide on a country-by-country basis whether to call something 2nd floor or 1st floor depending on the numbering scheme,

Actually, I think, this would be the best option. Maybe not on a country-by-country basis, but maybe based on what language the user chooses?

user is from a country where this scheme is different but he does not know about that

I mean yes, that's why I would suggest to represent it into the user's locale, not the countries locale. (Maybe only show a note, if they are different as you proposed in the "and maybe:" part.)

even if the user knows about the differences, he does not know if the app knows

Yep, that's why I would suggest to make it "unambiguous" anyway, i.e. the way with "Obergeschoss" instead of "Geschoss", so people really know what is meant. But at the same time, you are just confirming their expectations (that it is written in "their" language.)

I also guess most people use SC in their home country(/language)… And if not, then the "and maybe:" would make it even clearer to them.

If done like this, you may be able to keep some "brevity" if users are only in their home country(/language).

---

Side-notes:

Also one thing to keep in mind: This translation only needs to be understood by the user, there is no problem (that we usually have here in SC) that the user could read different data from a sign and enter wrong info into OSM. I.e. it's only about reading and understanding.

Also unambiguous here seems to counter the aim of understandable by the user. As I've elaborated, users will be confused anyway if you use one form they do not know by themselves.

This is a hard topic…

[rugk]

So I fiddled around a little bit with fluent to understand that whole thing. And I also had some problems with fluent.

But I cold come up with this gist. Iit is totally a WIP and due to the issues in fluent, they only work properly in the range of -1 to +1. (It may also be that I do not know how to do it in fluent, I am totally new to that syntax, but that's why I've asked.) https://gist.github.com/rugk/b7886c7332dac68d9b83ed534b5062e0

To test:

1. Go to https://projectfluent.org/play/.
2. Paste the data in there, so it looks like this:
3. Modify "levels" in the middle to test for different levels.

In this structured way I now at least properly understand the problem. Programmers style… :stuck_out_tongue_winking_eye:

[westnordost]

Fluent is off topic because an implementation detail.

So, both @gdt and @rugk argue for translating level using the user's locale and/or the current location to each the correct floor numbering scheme. @gdt mentions the problems with this himself and I previously mentioned it here ( https://github.com/westnordost/StreetComplete/issues/1270#issuecomment-455801400). There can be misunderstandings for:

• non-Americans in America and the other way round: Elevator buttons, mall maps and signs will disagree with how the app denotes the level
• anyone in OSM, not knowing whether the app correctly converts/translates this or not. More StreetComplete users than anticipated are actually experienced OSM mappers

So, this is what I strive to avoid by choosing a wording that is so clear that it can be used independent of locale/location. The solution for named floors is the level:ref tag. So if level:ref=B3, the app would denote the shop to be on "floor B3".

[westnordost]

Ok, so if the app is going to alter the floor level display according to locale-based assumptions, then these assumptions must be absolutely reliable.

I tried to find which countries use which numbering system (main sources: 1, 2), but apart from the obvious candidates (US, Russia, China, Japan), information on it is hard to come by and partly contradictory. Furthermore, I read that in some countries, in some areas one system is used, in other areas, the other system is used (Vietnam, Indonesia), and even that sometimes, it differs from building to building.

I take this as a further strong argument for choosing an unambiguous yet maybe awkward wording over altering the level value for display.

For me the question is, which is the least awkward and most clear way of putting it? level=X denotes:

• X levels above the ground floor
• X levels above street level
• upper level X
• upper floor X
• (or if none is clear enough, something like this for certain locales:) X levels above street level (X+1. floor)
• ...something else?

I need help here especially from native American English speakers.

[rugk]

Fluent is off topic because an implementation detail.

Boah, hey, … :roll_eyes: I know this and I only used this as an illustration and to try out values/ideas. I never said and I even explicitly explained that it is impossible to implement this way. Reading certainly helps! Sorry for being rude.

I make this one comment now, so you can hide it again if you want to get people angry…

[bhousel]

I wonder how/if iD avoids this translation trap / ambiguity.

Thanks for looping me in... iD just calls the level field "Level". We don't try to translate it.

I've always understood it to mean "whatever system the building itself uses" - and not try to derive any relation to the ground floor or the entrance. It's just whatever the elevator buttons and the numbers on the doors say, if any. The point is so that if you want to find something in the building, you can find it.

I've never heard of level:ref before. I'd just stick to level.

[rugk]

So I would say:

• level:ref (<user-locale-level>)
• if no level:ref fallback to: <user-locale-level> (<foreign-level denotation>)
• and if users are contributing in the same level-system as they have their OS language set: <user-locale-level>

So I agree though, in all cases, it should be obvious that the app localized the in <user-locale-level>.

---

So to make the translation actually unambiguous I've made this with fluent.

Test it out: https://gist.github.com/rugk/f657628db4bf7fd59f8e5b19594e0854

Things I noticed (in case I did not do anything wrong):

• You do not have to separate too many cases, actually. The -n values always stay the same. Also level=0 has it's own unique translation and is also easy.
• actually with such an "append" solution you can build the to be localized string programmatically
• In my examples I just added the <foreign-style> in brackets afterwards
• You can keep the brevity in most cases, as you do not need to avoid ambiguity if the user is not traveling in a foreign country.
• You also can keep the brevity, as in most cases the user is just in their own region (i.e. not traveling in a foreign country is likely the "default"), and only in the other 2 of the 4 cases (for n>0) you need to actually append the "foreign format":

This is what I meant with testing!

[rugk]

So I would still think the best way is to localize it properly.

To address your concerns:

non-Americans in America and the other way round: Elevator buttons, mall maps and signs will disagree with how the app denotes the level

That's why we should include both versions, in case the user is traveling…

anyone in OSM, not knowing whether the app correctly converts/translates this or not. More StreetComplete users than anticipated are actually experienced OSM mappers

In the traveling case I made this obvious. However, missed it in the EN_USSTYLE case. (In all other cases, this does not apply, as it is the same way as in OSM)

So maybe like this?

```ftl floor_EN_USSTYLE = { $level -> [-2] on basement floor B{ $level } [-1] on basement floor B(1) [0] on ground floor [one] on floor 2 (including ground floor) *[other] on floor { $level }+1 (including ground floor) } ```

Vietnam, Indonesia

As for that I cannot really comment unless we have more information/data there. In such a case, you may just have indeed a hard case for translators… :wink: However, I would not take this as an argument against a proper translation. In the worst case, you just need to include both versions. I mean, in such countries all such apps likely have the same problem. So maybe it's rather kinda an edge case.

[westnordost]

@bhousel

I've never heard of level:ref before. I'd just stick to level.

level:ref is for naming the floors according to how they are named on signs and elevator buttons in the buildings, e.g. something like PH, B2 or B3. But, my mistake, it is actually only documented for simple indoor mapping as a property on the floor outline, not for each individual shop. So, never mind that.

I've always understood it to mean "whatever system the building itself uses" - and not try to derive any relation to the ground floor or the entrance

That sounds like a pragmatic approach. However, in European (etc.) buildings, the American "1st floor" is not called "0th floor", but "ground floor". So, for correct localization, it must be known which level is the one at the street level. But when level=0 is not clearly defined as always the one at street level, the information which level is at the street level is lost. And this is the reason why in the wiki documentation, it is stated several times that level=0 is the ground floor.

This definition can be very confusing to OSM contributors from countries where the numbering starts with 1, especially if the (user-end) software used does not translate this scheme. I suspect, that many mappers from these countries may not adhere to that wiki documentation for that reason, deliberately or not. I will do some research.

[westnordost]

Okay, so I did the research and posted the result on the tagging mailing list. Maybe I should edit the wiki to add this information.

[westnordost]

So, from my research I learnt that it cannot be reliably assumed that level=0 is the ground level, at least in countries where usually the floor numbering starts with 1. In the subsequent discussion on the mailing list, I learnt additionally that even someone involved in defining and writing software for indoor mapping felt that "level=0 equals ground level" is not a hard rule and can be overridden by whatever numbering scheme the operator of the building uses. So, basically something similar to what @bhousel said.

This means for StreetComplete that translation from level to localized names like "ground floor", "first floor", "basement floor" (de: Erdgeschoss, 1. Obergeschoss, 1. Untergeschoss,...) etc. is not possible as the words used are in relation to a ground level. So, I am going the iD way and don't attempt to translate it to floors.

[gdt]

Since I was asked, I find "upper floor 2" to be something that almost all Americans will say "huh? what are they talking about".

I sent a long rant to the tagging list. Basically I advocate treating floor names as names, not numbers, and typing in what the labels/elevator buttons say, or would say if there was one.

[rugk]

Basically I advocate treating floor names as names, not numbers, and typing in what the labels/elevator buttons say, or would say if there was one.

Well, I do personally like that tagging as it is. I mean it has to be machine readable... For the "floor names" something like levels:ref may have been useful, but as it's only used for indoor mapping, that's now strange.

That seems also where the mailing list discussion is heading to... Such a thing as named levels (similar to what we thought of levels:ref). However, named levels are then hard to localize. (-1 can be "Untergschoss 1"/basement floor 1, but "P1" would likely be "Parkgeschoss 1"/parking floor 1, but in the GUI it might end up being "floor P1" - I am not sure what is better there...)

[matkoniecz]

What about location=underground?

[westnordost]

I do not think that shops in a basement floor would be tagged that way and I also think this should not be applied on individual objects within a building that is underground but only on that building.

On January 21, 2019 1:16:49 PM GMT+01:00, Mateusz Konieczny notifications@github.com wrote:

What about location=underground?

[rugk]

BTW FYI great news I did not notice¹, but apparently they have decided to include this information in CL;DR. (Or do they? TBD = to be done? or "to be decided"? And is the tag "new" better than "accepted" uff what?? Phase "dsub" – sry, whaat?)

So it's always good to propose things! Seems to work here that I could bring this idea into, great.

¹ (because apparently Unicode migrated from Trac to Jira and I also did not got any mails in Trac etc.)

[westnordost]

What is CLDR?

[rugk]

https://en.wikipedia.org/wiki/Common_Locale_Data_Repository - basically an official translation/localisation dict, so one does not need to translate the same things again and again in a project.