Indoor corridor as closed way is misidentified as an area

[kymckay]

From our discussion in Slack:
iD thinks indoor=yes on closed ways implies it’s an area due to the generic indoor=* preset. highway=corridor can't match an area, so it defaults to the generic highway preset.

Some potential solutions we covered:

• Have areaKeys consume addTags. May have some side effects.
• Add the indoor=yes tag to tags of the corridor preset and use deprecated.json to provide a method of upgrading the tags. This issue here is that corridors without indoor=yes will no longer match the preset until upgraded.
• Add an unsearchable preset to match a corridor without indoor=yes which has it under addTags, then have the actual preset include indoor=yes in tags so that upon upgrading it is correctly recognised. Bit hacky.

[jeisenbe]

This issue here is that corridors without indoor=yes will no longer match the preset until upgraded.

Do you mean that under this second option, indoor=yes would be recommended for all highway=corridor features?

The wiki page does not suggest adding indoor=yes to this feature: https://wiki.openstreetmap.org/wiki/Tag:highway=corridor

The combination is used 38% of the time, but the majority of highway=corridor features currently lack the tag 'indoor=yes: https://taginfo.openstreetmap.org/tags/highway=corridor#combinations

The tag highway=corridor is only intended for use in buildings, so it seems redundant to require adding indoor=yes.

[kymckay]

I understand your point and can't say I've looked at the tagging enough to weigh in on it.

It's somewhat separate from this issue though (this is to do with iD correctly identifying the preset - which currently does include indoor=yes).

[danielsjf]

Shouldn't indoor=yes be depricated? According to the indoor tagging scheme, only five flavours of indoor are recommended of which yes isn't one.

https://wiki.openstreetmap.org/wiki/Simple_Indoor_Tagging

Of course this only holds for the presets, not for viewing it on the map where it would be good to still support the old tagging scheme.

[quincylvania]

Shouldn't indoor=yes be depricated? According to the indoor tagging scheme, only five flavours of indoor are recommended of which yes isn't one.

@danielsjf The simple indoor tagging scheme is for indoor-specific features, like rooms. indoor=yes is a general-purpose tag that should be used on any other feature when it's in a building—ATMs, sculptures, benches, train platforms, whatever.

The tag highway=corridor is only intended for use in buildings, so it seems redundant to require adding indoor=yes.

@jeisenbe Yes, this redundancy is intentional. Implied tags makes it harder for data consumers to accurately parse OSM data. By ensuring there's an indoor tag on everything that's indoors, we make it easy for renderers to include or exclude all indoor features at once by only dealing with one tag.

[jeisenbe]

Are there any renderers who currently interpret this tag?

I can make a wiki page, currently it is undocumented so most database users are probably unaware of it.

By ensuring there's an indoor tag on everything that's indoors, we make it easy for renderers to include or exclude all indoor features at once

That's reasonable in some cases, like requiring oneway=yes on motorways, since it's required for all other highway types and perhaps a motorway was mapped with only one line.

But it would be against established practice to require surface=paved or motor_vehicle=yes on motorways, wouldn't it? Some tags are implied; there's even a field in the "wikibase" data items and the "ValueDescription" boxes for implies= which could be interpreted by database users.

[quincylvania]

But it would be against established practice to require surface=paved or motor_vehicle=yes on motorways, wouldn't it? Some tags are implied; there's even a field in the "wikibase" data items and the "ValueDescription" boxes for implies= which could be interpreted by database users.

iD helps where it can, but there are limits to what's practical and useful. I wish OSM did more, like offer an endpoint to fetch features with implied tags filled in. As it stands, data consumers still need to be diligent about interpreting tags.

[quincylvania]

Have areaKeys consume addTags. May have some side effects.

I ended up doing this but only for the blacklist of tag values that override keys that would otherwise imply a feature is an area. This shouldn't have side effects except fixing any other lurking issues similar to this. (The function might also take slightly longer to run, but not noticeably.)