Indoor mode

[zbycz]

Hi,

I am submitting a little larger pull request. I am not sure if its possible to be merged as is, but I did my best and will be happy to cooperate further to make it so.

I’ve been engaged in OpenStreetMap since 2008 and for the time being I’ve led many workshops, written some school works and worked on getting the Czech community together on openstreetmap.cz. Last summer I had to come up with a topic for my final engineer thesis, so I decided to use the effort already invested in indoor mapping and chose to update the iD editor accordingly. Let me elaborate...

Current work-in-progress proposal is called Simple Indoor Tagging. I didn’t want to rely on WIP, so I realized there is already an accepted solution – the level=* tag.

There are two challenges for indoor:

1. making underlying background map (this is addressed by Simple Indoor’s indoor=* area features)
2. display ways – the accessibility of places – and this kind of was the nature of OSM from the beginning. Until we had all the landuse=* areas, OSM started with highways + pois.

Drawing highways=* for indoor feels very natural – corridors usually repeats every floor even in multi-storey buildings, it displays clear accessibility information, can be already used for routing and also works with parking highways. The logic is also very simple - when a level=* feature is in viewport - show “Indoor” button, and let the user filter on these.

Several examples (my build):

• Shopping mall in Prague - underground parking, main foot passages and few shops POIs
• University building in Aachen - complete room plans with Simple Indoor (older proposal version with optional level=* xor repeat_on=*). Another building here.
• Berlin main railway station - several underground floors + indoor=* features
• University campus Prague - mapping in progress ;-)
• Another shopping mall - only POIs

Well, i think I made my point - let’s discuss the technical background :-)

---

Some thoughts / questions:

1. Is it ok, to call it indoor mode? It doesn't fit with current “modes” terminology, where modes are exclusive.
2. I think the philosophy of iD is to show disabled buttons for “availible” actions. I chose to hide the button completely, where there isn't any level=* features on screen. Would you agree?
3. Current level=* allows only separate values by semicolon, I borrowed three useful tagging from SimpleIndoor. Is it ok to use these? Should i maybe make new official proposition?
   • ranges – level=0-12 or -3--1 for features spaning several floors.
   • repeat_on – for repeating the same (possibly multilevel) feature on other floors - ie. doors,toilets
   • min/max_level – when set on building, the building spans through these levels. It helps as a visual cue, and also for the renderers.
4. I had to unclip the building-outline shape, because a building completely covered with indoor=* areas, couldn't be clicked anyway. Kind of addresses the issue Right now it is impossible to select between multiple overlapping polygons #2225.
5. I submitted my original development commits, rebased to current master. Is it appropriate to squash the commits into one or few?
6. Although I tried to abide the current code style and wrote some test, tell me if i should change something globally. Easiest would be to comment the code in the specific commits..

Something to do in future

• if agreed, I would like to add level indicator as shown here https://github.com/zbycz/iD/wiki/devnotes-zbycz – but rather use another svg layer instead of filters.
• once proposition is accepted – enable switching over floating point level values (ie. level=1.5). But even now - any string value could be written in the level chooser, so it “works”.
• add icon for ‘highway=elevatorandindoor=corridor+stairs=yes` as these had to be distinguished easily.
• Unfortunately I found later, I developed very similar changes as Panier’s id-indoor fork. Although he added many more indoor presets, which could be eventually merged here.
• Create a level switcher in osmbuildings.org 3D viewer ;-) .. well, distant future indeed.

Changelog until now:

• added iD.ui.IndoorMode control ui
• added filtering using features.indoor_different_levels
• added .indoor-mode class for svg surface
• added general preset for indoor=* when indoor-mode enabled
• added several map styles for enabled .indoor-mode
• added indoor_levels as general field for building, using iD.ui.preset.range

btw, it was a pleasure to work with iD codebase, also d3 is so very amazing :-)

[bhousel]

Wow, impressive work @zbycz! I really like this and would like to see this merged in some form.

I'll need some time to think about how to present the UI in a way that doesn't clutter things up too much.

I'll try to answer your questions now:

Is it ok, to call it indoor mode? It doesn't fit with current “modes” terminology, where modes are exclusive.

I think it's ok to call it indoor mode. (People will call it that anyway). You're right it's not technically a "mode" like the other exclusive drawing modes.

I think the philosophy of iD is to show disabled buttons for “available” actions. I chose to hide the button completely, where there isn't any level=* features on screen. Would you agree?

I'm leaning towards having the button smaller but available, maybe just an icon with tooltip, and it can transition open to reveal the indoor drawing controls when active. (I'm struggling with this same problem on #2699 - it's cool and useful, but where to put it?)

Current level=* allows only separate values by semicolon, I borrowed three useful tagging from SimpleIndoor. Is it ok to use these? Should i maybe make new official proposition?
ranges – level=0-12 or -3--1 for features spaning several floors.
repeat_on – for repeating the same (possibly multilevel) feature on other floors - ie. doors,toilets
min/max_level – when set on building, the building spans through these levels. It helps as a visual cue, and also for the renderers.

The right thing to do is to make a proposal and loop in the OSM tagging list. At this point, indoor editing is not solidly established, so I think you have a good chance of pushing the community in a sane direction.

I had to unclip the building-outline shape, because a building completely covered with indoor=* areas, couldn't be clicked anyway. Kind of addresses the issue #2225.

Makes sense.. Yes I agree that in "indoor mode" the building outline should not render as an area, as this covers up the indoor features.

I submitted my original development commits, rebased to current master. Is it appropriate to squash the commits into one or few?

It would be better to squash them into fewer commits, but I'm not super picky about this.

Although I tried to abide the current code style and wrote some test, tell me if i should change something globally. Easiest would be to comment the code in the specific commits..

I'll try to review it in more detail, but what I saw at a quick glance looks great! And the tests are much appreciated...

[zbycz]

Thanks, @bhousel !

I will make the proposal next week, in the meantime I am looking forward to your code comments 👍 Once we're done, I will sqash the commits in fewer.

ad button positioning) the more buttons, the more the user think how complex the software is (aka Norman: The design of everyday things) - and I think iD should stay "simple". But also its a bad practise for controls to disappear unexpectedly.

I completely agree with a smaller icon expanding to full control. What about placing Indoor-mode button in a dropdown menu "Tools" on the right of the top toolbar. It could be left closed forever, or left toggled opened. It would be a nice drawer for more useful tools in the future (including the #2699).

[bhousel]

What about placing Indoor-mode button in a dropdown menu "Tools" on the right of the top toolbar. It could be left closed forever, or left toggled opened. It would be a nice drawer for more useful tools in the future

I've been playing around with making the UI more responsive and supporting something like a "drawer" for more commands or options on existing commands.

I don't really like it.. Maybe @samanpwbb has ideas?

The problem is it either bumps down the other things in the layout, or it overlaps them. So we'd either need to 1. position the other UI stuff differently or 2. be ok about having them move (eh) or 3. something else.

[zbycz]

Because the ui.type.range needs second input without border.
Would you suggest a better selector maybe?

[PanierAvide]

I'm glad to see the opportunity of integrating indoor editing in main iD version. Feel free to reuse any custom part of iD-indoor, like presets or level parser (which handles lot of level-related tags) ;)

[samanpwbb]

Indoor mode would work well as a Map data filter:

If the auto-tagging piece of this PR is mandatory, we can add a note about it in the filter panel:

[jirutka]

@zbycz Please never ever omit curly braces around if-else, it’s generally considered as a bad practice and there are many documented cases when it caused a security issue.

[zbycz]

Hi, just letting you know, we have moved a little further. I created official proposal and submited RFC to tagging list.

In near future i will create new pull-request based on current master, thus I am closing this one.

[bhousel]

Hi, just letting you know, we have moved a little further. I created official proposal and submited RFC to tagging list.

In near future i will create new pull-request based on current master, thus I am closing this one.

Great! We are thinking a lot about plugins lately and I would love to find a good way to merge your work into iD to make indoor editing easy for everyone.

[TheAdventurer64]

Progress?

[quincylvania]

@TheAdventurer64 As I've mentioned before, any progress on an issue will be shown there. If you have any substantive questions or comments feel free to voice them.