replace cycleway with flexible directionalCombo field type

[tyrasd]

See openstreetmap/iD#9423 for more details and openstreetmap/id-tagging-schema#674 for a possible first application of this new field.

[tyrasd]

One quite popular "directional" tag are maxspeed:<direction> with ~200k uses, but in order to support these also, the would need to be extended further, as the maxspeed field currently uses the special roadspeed field type.

Perhaps directional should rather be an option which could be used with different field types?

[tordans]

…as the maxspeed field currently uses the special roadspeed field type

Just for those of us, wo wondered what that looked like:

[tordans]

One quite popular "directional" tag are maxspeed:<direction> with ~200k uses, but in order to support these also, the would need to be extended further, as the maxspeed field currently uses the special roadspeed field type.

I have a slightly different take: Exposing those tags is more important, than the fact that they have their own special field type. Why? If they are hidden, the chance of miss-tagging is higher than having them visible but a less convenient editing experience.

Perhaps directional should rather be an option which could be used with different field types?

Looking at the fields features (https://github.com/ideditor/schema-builder#fields) that would require an additional layer / hierarchy, right?

Adding to my comment above, I would vote for first refactor the cycleway feature to be used with parking. And only then look into solving the maxspeed case. No need to do it all at once… — Update: I see you merged openstreetmap/iD#9423, so that comment is out of date :-).

Back on topic:

We could also turn this round:

• The directionCombo is a special field
• And a field can have an additional, optional property of unit or format, which would be format: "speed" | "height" | "colour".
  One could even move more of the type values to the format like "text" | "number" | "tel" | "url"

What I don't like is, that the HTML "type" attribute has values like "tel", "color"; the current schema fits more into this pattern.

Another take:

Staying with our idea, to make add add a wrapperType: "directional" (or something like this). The "localized" field could be moved into this pattern as well. That would allow us to add "description:de" as a type="textarea" + wrapperType="localized".