Add strings for house= field and disable Taginfo suggestions

[Dimitar5555]

Description, Motivation & Context

Currently the house field doesn't have any strings and it shows any value with 100+ uses. This creates a lot of variants for tagging the same thing.

This PR introduces strings for the documented values of house= tag and disables Taginfo's suggestions for the field.

P.S. It doesn't affect the tag editor, I'm not sure if we can influence it.

Related issues

None

Links and data

Relevant OSM Wiki links:
https://wiki.openstreetmap.org/wiki/Key:house

Relevant tag usage stats:
https://taginfo.openstreetmap.org/keys/house#values

Checklist and Test-Documentation Template

Read on to get your PR merged faster…

Follow these steps to test your PR yourself and make it a lot easier and faster for maintainers to check and approve it.

This is how it works:

1. After you submit your PR, the system will create a preview and comment on your PR:

   🍱 You can preview the tagging presets of this pull request here.
   If this is your first contribution to this project, the preview will not happen right away but requires a click from one of the project members. We will do this ASAP.

2. Once the preview is ready, use it to test your changes.

3. Now copy the snippet below into a new comment and fill out the blanks.

4. Now your PR is ready to be reviewed.

## Test-Documentation

### Preview links & Sidebar Screenshots

<!-- Use the preview to find examples, select the feature in question and **copy this link here**.
     Find examples of nodes/areas. Find examples with a lot of tags or very few tags. – Whatever helps to test this thoroughly.
     Add relevant **screenshots** of the sidebar of those examples. -->

<!-- FYI: What we will check:
     - Is the [icon](https://github.com/ideditor/schema-builder/blob/main/ICONS.md) well chosen.
     - Are the fields well-structured and have good labels.
     - Do the dropdowns (etc.) work well and show helpful data. -->

### Search

<!-- **Test the search** of your preset and share relevant **screenshots** here.
     - Test the preset name as search terms.
     - Also test the preset terms and aliases as search terms (if present). -->

### Info-`i`

<!-- **Test the info-i** for your fields and preset and share relevant **screenshots** here.
     The info needs to help mappers understand the preset and when to use it.
     [Learn more…](https://github.com/openstreetmap/id-tagging-schema/blob/main/CONTRIBUTING.md#info-i)
 -->

### Wording

- [ ] American English
- [ ] `name`, `aliases` (if present) use Title Case
- [ ] `terms` (if present) use lower case, sorted A-Z
<!-- Learn more in https://github.com/openstreetmap/id-tagging-schema/blob/main/GUIDELINES.md#2-design-the-preset -->

[github-actions]

🍱 You can preview the tagging presets of this pull request here.

[Dimitar5555]

house=link-detached has only ~750 uses and less than 20 in the building key. There isn't a preset for it in iD. It is documented though, so it might be a good idea to create a preset.

[Dimitar5555]

(The screenshot tool doesn't want to capture the dropdown menu)

[tordans]

FYI: I looked into houses in #1155 when I tried to understand the different wording in SC vs iD vs Wiki but never finished it.

[tordans]

@Dimitar5555 I think this is a good addition. But we need to make sure we are not missing something relevant and make the situation worse for some cases.

Could you double check that we have all values in this list that StreetComplete uses?

And we should also check document the taginfo most used values so we support any that are used often, like maybe 5k+?

[tordans]

Btw, a great follow up to this would be to create small icons for those values like we have for crossings. Those are supported via icons https://github.com/ideditor/schema-builder?tab=readme-ov-file#icons

---

And once openstreetmap/iD#10613 is done and we have a better display of the value description, we should IMO add a description for those as well.

[Dimitar5555]

Could you double check that we have all values in this list that StreetComplete uses?

Note that SC is using the building=house/detached/semi-detached/... while this field is shown on elements with building=house + house=(empty value).

SC seems to be missing an answer for terraced houses.

https://github.com/streetcomplete/StreetComplete/blob/master/app/src/main/java/de/westnordost/streetcomplete/osm/building/BuildingType.kt#L9-L13

SC is treating building=terraced as deprecated. The documented replacement in SC is terrace but this is not always correct. terraced is for the individual houses while terrace is for the whole row of houses.

https://github.com/streetcomplete/StreetComplete/blob/master/app/src/main/java/de/westnordost/streetcomplete/osm/building/BuildingType.kt#L172-L174

P.S. Whether SC should be using building=*_house or building=house + house=* is a matter of discussion there.

---

And we should also check document the taginfo most used values so we support any that are used often, like maybe 5k+?

✅

---

Btw, a great follow up to this would be to create small icons for those values like we have for crossings. Those are supported via icons ideditor/schema-builder#icons

It is a good suggestion in principle but I'm not sure how they could look. detached is easy but semi-detached and terraced could be represented with the same icon (which might be confusing). terraced could have 3 houses next to each other but we will have to change the icon for terrace as well.

---

And once openstreetmap/iD#10613 is done and we have a better display of the value description, we should IMO add a description for those as well.

I will add it in the coming days (or maybe next year 😄).

[tordans]

Note that SC is using the building=house/detached/semi-detached/... while this field is shown on elements with building=house + house=(empty value).

Ah, sorry, I did not fully realize, what we are actually looking at here …

So this list is only used for the building=house preset at https://github.com/openstreetmap/id-tagging-schema/blob/main/data/presets/building/house.json#L8

(Side note: There is no other usage of this field https://github.com/search?q=repo%3Aopenstreetmap%2Fid-tagging-schema+%5C%22house%5C%22+path%3A%2F%5Edata%5C%2Fpresets%5C%2F%2F&type=code )

FYI: We have three unsearchable presets for specific values of this list in https://github.com/openstreetmap/id-tagging-schema/tree/main/data/presets/building/house which where all added in #921 – those unsearchable presets don't have "fields" themselves so they will reuse the parent fields which in will include the house=* field that we are editing here. This is important because it will allow to change the type of house even after one of those three was selected back to something else. This is not true, see the test cases below. IMO we need to fix this

TBH I am not sure if we actually want those separate, unsearchable presets. The only benefit I can see is that https://github.com/openstreetmap/id-tagging-schema/pull/921/files#diff-cb5181126156c42a37b82bff9e25d5bf13d6c2b4331b6980a24262ceaf8b2c06R2 has a different icon now.

---

P.S. Whether SC should be using building=*_house or building=house + house=* is a matter of discussion there.

The question for this repo that I see from this is: How can we make those sub-types discoverable when searching or browsing for houses in iD. Right now only https://github.com/openstreetmap/id-tagging-schema/blob/main/data/presets/building/detached.json will be findable but https://github.com/openstreetmap/id-tagging-schema/blob/main/data/presets/building/house/_detached.json will be hidden from the search and browser section.

Again, this is something we don't have to solve now, but we might want to create a follow up issue for this to see if there is a solution for it. Right now it looks like conflicting tagging practices that we cannot really resolve(?)

[tordans]

Test-Documentation

Find test cases: https://overpass-turbo.eu/s/1Wan

• 🟢 https://pr-1412--ideditor-presets-preview.netlify.app/id/dist/#background=Bing&disable_features=boundaries&id=w1271824908&locale=en&map=20.00/52.20455/13.58388

  • 🟡 one thing we should improve here is to move the "type of house" to the top of the list by changing the order of https://github.com/openstreetmap/id-tagging-schema/blob/main/data/presets/building/house.json#L7-L8

  

• 🔴 https://pr-1412--ideditor-presets-preview.netlify.app/id/dist/#background=Bing&disable_features=boundaries&id=w1219479104&locale=en&map=20.00/52.30051/13.78133

  • I consider this a blocking issue. Right now those unsearchable sub presets remove the "type of house" field from the list of fields. I remember from crossing refactoring that this is some kind auf automatism that I don't think is smart. It means that once I select a "type of house" the UI changes and the only way back is to cmd+z or to start again or edit the raw tags. Instead the "type of house" should always be present at the top to allow to change the preset easily.

• same issue https://pr-1412--ideditor-presets-preview.netlify.app/id/dist/#background=Bing&disable_features=boundaries&id=w1324673770&locale=en&map=20.00/52.30858/13.50386

• same issue https://pr-1412--ideditor-presets-preview.netlify.app/id/dist/#background=Bing&disable_features=boundaries&id=w1328793108&locale=en&map=20.00/52.40519/13.53411

Preview links & Sidebar Screenshots

Search

Just to document the "two tagging standards" issue described above: This find the building=* but now the house=* that as mapped (manually)

Info-i

• 🟢 blank works good
  
• 🟢 bungalow works good
  
• 🔴 semi detached has a missing wiki data entry
  
• detached => OK
• residential => MISSING

==> We should check that all those values have a meaningfull wikidata entry.

Wording

🟡 this line https://github.com/openstreetmap/id-tagging-schema/pull/1412/files#diff-5fbab217bab0453164ec163e40f00955f65ebb1900518439ae0066393f5c2bceR12 is written different than the others. Should that be "Row of Terraced Houses"?

[Dimitar5555]

• 🟡 one thing we should improve here is to move the "type of house" to the top of the list by changing the order of main/data/presets/building/house.json#L7-L8

Done.

🔴 pr-1412--ideditor-presets-preview.netlify.app/id/dist#background=Bing&disable_features=boundaries&id=w1219479104&locale=en&map=20.00/52.30051/13.78133

* I consider this a blocking issue. Right now those unsearchable sub presets remove the "type of house" field from the list of fields. I remember from crossing refactoring that this is some kind auf automatism that I don't think is smart. It means that once I select a "type of house" the UI changes and the only way back is to cmd+z or to start again or edit the raw tags. Instead the "type of house" should always be present at the top to allow to change the preset easily.

Fixed.

🟡 this line #1412 (files) is written different than the others. Should that be "Row of Terraced Houses"?

Updated accordingly.

---

residential => MISSING

I skipped this value on purpose. It isn't clear to me what it means. Is it building=residential, building:use=residential or something else? It is also undocumented despite the large usage.