Proposal to add field groups in presets (How to start iterating on more detailed OSM data)

[tordans]

Context

OSM Data is getting more detailed every day, which is one of the best things about OSM. However, for the last couple of years, iD and Rapid have not been able to keep up in exposing this new data to make it accessible, maintainable, and addable.

Highways are one area where this is true. I work with OSM data every day to combat climate change by making it easier to build and maintain cycling infrastructure. Highly detailed data on highways is essential for this.

There have been blue-sky tickets around to create a unified lane editor for years (e.g. openstreetmap/iD#387, facebook/Rapid#1465). I have been monitoring and working on similar topics with AB Street/Osm2Street and our Bicycle Atlas infrastructure processing. I am confident in saying that the UX to build such a feature is an immense task that will not happen any time soon. Additionally, the tagging schema for most of the data is not evolved (thought through, discussed, documented) enough to make such a tool even possible (it is simply unclear how many of the detailed tags are supposed to be interpreted in detail).

Start Iterating with What We Have

The big solution will not happen any time soon. But we need to start improving the editing UI and the way we expose detailed taggings.

I propose to use what we have and start iterating. We have a great preset and field schema. And we have an established and tested editing sidebar.

Let's start iterating on solutions to add more details in this system with minimal change. This will allow us to ship faster and enable the tagging ecosystem – the community discourse – to evolve to more standardized and better-defined tagging solutions.

For example, it took the group behind the parking data processing about two years to learn enough about the use case and tagging to successfully improve the parking tagging schema to something that is now much more likely to be supported by editors like iD and Rapid.

We Have a Few Problems to Solve…

• Adding more fields to the sidebar breaks the UX. The core idea of the presets is to make it less overwhelming for users to see and edit OSM data. We cannot just add more and more fields to this UI without compromising this important aspect. We need a way to manage the fields.
• fields and moreFields are great to hide data until mappers look for it or until it was used. However, they do not allow preserving the context of presets that have a logical connection. We want 'surface' as a field, for example, but 'smoothness' as a moreField. But we want both to be located together.
• The tagging evolved into using sub-keys to create logical groups of data. Some of those tags rely on the presence of other tags (requires enhancing the schema-builder).

Add Field-Groups to Presets

What would a first iteration look like? And let's try to change as little as possible.

Use Case: Let's look at adding more fields to the highway presets and group the existing fields more logically.

• We introduce a group property on fields. (I think the group should be part of the preset, not the field, but let's see…)
• We change the way fields/moreFields work by making this a property of the field in the groups. This will allow us to specify a fixed order of fields (the order does not depend on which field was added last).
• Each group can be open/closed by default per preset.
• We modify the editor sidebar to show those groups. And we might also need to adjust the spacing (paddings, margins, …) to make the overall UI look compact and easy to grasp as a whole.

This can be applied to existing highway presets right now.

We can then start iterating on adding new fields, which will open new requirements on the schema builder quickly. We already found a few limitations that prevent us from adding more detailed fields in a way that preserves the current UX.

Possible Implementation in the Tagging-Schema

Current cycleway preset

Possible modifications

{ "icon": "fas-biking", "fields": [ "name", "oneway", "surface", "smoothness", "width", "structure", "access", "incline" ], "moreFields": [ "bridge/ref", "covered_no", "dog", "lit", "maxspeed", "maxweight_bridge", "not/name", "stroller", "wheelchair" ], "geometry": ["line"], "tags": { "highway": "cycleway" }, "terms": ["bicycle path", "bike path", "cycling path"], "name": "Cycle Path" }

{ "icon": "fas-biking", "fields": [ { "type": "field", "field": "name", "visibleWhenEmpty": true }, { "type": "field", "field": "not/name", "visibleWhenEmpty": false }, { "type": "field", "field": "oneway", "visibleWhenEmpty": true }, { "type": "group", "name": "Surface", "fields": [ { "type": "field", "field": "surface", "visibleWhenEmpty": true }, { "type": "field", "field": "smoothness", "visibleWhenEmpty": false } ] }, { "type": "field", "field": "width", "visibleWhenEmpty": true }, { "type": "field", "field": "structure", "visibleWhenEmpty": true }, { "type": "group", "name": "Acces", "fields": [ { "type": "field", "field": "access", "visibleWhenEmpty": true }, { "type": "field", "field": "dog", "visibleWhenEmpty": false }, { "type": "field", "field": "stroller", "visibleWhenEmpty": false }, { "type": "field", "field": "wheelchair", "visibleWhenEmpty": false } ] }, { "type": "field", "field": "incline", "visibleWhenEmpty": false }, { "type": "field", "field": "bridge/ref", "visibleWhenEmpty": false }, { "type": "field", "field": "covered_no", "visibleWhenEmpty": false }, { "type": "field", "field": "covered_no", "visibleWhenEmpty": false }, { "type": "field", "field": "lit", "visibleWhenEmpty": false }, { "type": "field", "field": "maxspeed", "visibleWhenEmpty": false }, { "type": "field", "field": "maxweight_bridge", "visibleWhenEmpty": false } ], "geometry": ["line"], "tags": { "highway": "cycleway" }, "terms": ["bicycle path", "bike path", "cycling path"], "name": "Cycle Path" }

Possible implementation in the editor sidebar

Note

TODO MOCKUP

There are open UI decisions to be experimented on like …

• A group should probably not behave like a disclosure that hides all children. What does a group with just one visible field look like? Maybe the groups are more like a sub-heading…

• Where is the plus-Button to add additional fields? One (small element) per group and one (bigger element) below all fields?

• What does the plus-Element look like below all fields? For example, a grouped input box that follows the given group-field-structure.

This Opens Up New Possibilities…

Let's collect a few examples of what this would unlock.

But before we do, let's look at StreetComplete (SC). SC has been adding quests that allow users to add very detailed tagging to OSM data on more and more topics. One of the great things about SC is that the user does not need to know about the obscure ways answers are stored in tags. parking:right:surface=sett is one example. A simple answer that requires a very detailed tagging schema to be used.

StreetComplete can be our source of inspiration on which tags to add to iD in the first round of adding more details with this new setup. Those tags are well defined (via SC) and already have good usage. It is also a problem right now, that iD and Rapid do not highlight the existing data to users (other than via the full tags table).

Back to some examples…

A group for cycleway tags on the centerline:

• cycleway:right:lane=exclusive|advisory (Wiki)
• cycleway:right:surface=*
• cycleway:right:width=*
• cycleway:right:traffic_sign=*

A group for sidewalk tags on the centerline:
(Finally a sane way to expose existing sidewalk data on the centerline…)

• sidewalk=left|right
• sidewalk:right:surface=*
• sidewalk:right:width=*

A group for the parking schema:

• parking:right:fee=*
• parking:right:surface=*
• … and many more (JOSM preset)

A group for width for example on highway=path|footway|cycleway

• width, width:source (for SC 'ARCore')
• maybe 'est_width'
• And for highway=path|cycleway+cycleway=designated+footway=designated also bicycle:width, footway:width

There are other things we might want to group…

• A group for external images (mapillary, …)
• A group for surface, smoothness, tracktype and similar values

---

External conversations:

• We talked about this in the last iD Community Chat. Ben (Rapid) and Martin (iD) are also looped in.
• I chattet with Ben from Rapid about this idea.

---

Related issues

• Grouped fields #2050
• Naming of street level imagery tags #1429
• Add roof shape and roof height fields to building presets #1552 – a group for all roof related fields