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

[tordans]

Context

OSM Data is gettting more detailed every day. That is on of the best things about OSM. But for the last couple of years iD and Rapid was not able to keep up in exposing this new data to make it accessible, maintainable, add-able.

Highways are one are 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 bluesky tickets around to create a unified lane editor for years (eg TICKET). And I have been monitoring and working on similar topics with AB Street / Osm2Streeet and our Bicycle atlas infrastructure processing. I am confident to say that the UX to build such a feature is an emense task that will not happen any time soon. In addition, the tagging schema for most of the data is not evolved (thought throught, discussed, documented) enought 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 neeed 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 a established and tested editing sidebar.

Lets start iterating on solutions to add more details in this system with minimal change. This will allow us to ship faster. But it will also allow the tagging ecosystem – the community discourse – to evolve to a 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 be able to successfully improve the parking tagging schema so 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 so see and edit OSM data. We cannot just add more and more fields on this UI without compromizing this important aspekt. We need a way to manage the fields.
• fields and moreFields are great to hide data until mappers look for it or until is was used. However they do not allow to preserve 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 useing sub-keys to create logal groups of data. Some of those tags rely on the presense of other tags (requires enhancing the schema-builder).

Add field-groups to presets

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

UseCase: Lets 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 lets see…)
• We change the way fields/moreFields work by making this a property on of the field in the groups. This will allow us to specify a fixed order of fields (the order does not depent 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 iterate on adding new fiels, 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 oben UI descision 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 additinal 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 possiblities…

Lets 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 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 answered are store in tags. parking:right:surface=sett one 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 user (other that 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.