Add markings:crossings=* and deprecated crossing=marked/unmarked

[nbolten]

Schema Change Proposal

Short description

This schema change proposal would replace the use of crossing=marked/unmarked with crossing:markings=*. crossing:markings=* is a new (technically currently proposed, but is very likely to be accepted tomorrow) OpenStreetMap tagging standard that addresses long-running problems with ambiguity and non-orthogonality in the crossing=* tagging schema. This change will disambiguate information about pedestrian crossings and whether they have markings, including new and more detailed descriptions of ground markings.

Purpose

This schema change is in response to a beneficial tagging change in the OpenStreetMap community that is in alignment with our long-running hope of being able to map crossing markings and crossing signalization separately. While we could use our existing crossing=marked/unmarked entity definitions and remain largely compatible, there is value in having close alignment with high-quality schemas in OpenStreetMap, and because this schema is in the pre-alpha stages it would be good to align at this time.

Longer description

The OpenSidewalks Schema currently keeps track of markings on pedestrian street crossings using the crossing=marked/unmarked field. This field simply indicates the presence or absence of ground markings for a given pedestrian street crossing. In OpenStreetmap, the crossing key can also be used with values like uncontrolled or traffic_signals that don't reliably mean that there are ground markings present. The decision to use only the marked and unmarked values reflects our attempt (and hope) that OpenStreetMap et al would use separate and unambiguous schemas in the future; that ground markings and signalization would be mapped separately. The new tagging schema, crossing:markings, represents a significant step towards that reality by making ground markings a property of the crossing rather than a distinct category. Full disambiguation will also require that signalization (pedestrian light signals, sounds, APS devices) be consistently treated as one or more properties as well.

This proposal recognizes that our current schema is a workaround that was used in anticipation of a tagging schema like OpenStreetMap's new crossing:markings=*. Now that this new, better tagging schema exists, we should reflect it directly. In addition to matching the mainline OpenStreetMap tagging standards, this tagging schema also brings the potential for more information by having values for specific marking types, such as lines (just an outline), surface (there's only a surface difference), or ladder (there are also horizontal bars along the path). We should capture these specific descriptions in our schema to aid with navigation and also because different markings types imply different rights of way and cross-traffic control in certain locales.

This proposal specifically (1) deprecates the use of crossing=marked/unmarked and (2) adds the crossing:markings=* tag, adding all of its current values. The new values can be seen in the README or in jsonschema/src/fields.ts.

Tasks needed to implement this change

Note: we should automate as many of these tasks as we can going forward.

[] The README.md (draft schema description)
[] The TypeScript code base that generates a jsonschema for OpenSidewalks Schema GeoJSON.
[*] The jsonschema for OpenSidewalks Schema GeoJSON.
[] Update the jsonschema and the README.md to be versioned and indicate version 0.1.0.
[] After accepting this pull request, immediately create a release (version 0.1.0) with a note of the changes.
[] Create a changelog file?

[galdi]

The proposed change was approved on 9/17!
This change will mean changes to the following mapper onboarding materials: the City Team Mapping Guide; the OpenSidewalks iD Editor Tags reference spreadsheet; the Rules For Mapping Crossings; all onboarding workshop presentations that refer to this value; the Canvas onboarding course pages that refer to it; as well as to how OpenSidewalks mapping of crossing ways should be handled in the onboarding videos. This list is by no means borne out of a comprehensive review, but rather an initial set of documents that must be revised at the earliest date possible, so as to not sow confusion with mappers.

Additionally, notices will need to be sent to previous mapping cohorts; and, an announcement relating to this change needs to be posted in the appropriate OpenSidewalks Slack channel. A notice about this new method of mapping crossings should be posted at the top of the landing page for tasks.opensidewalks.com and at the top of the projects list page.

Last but not least, consideration should be given to move the Rules For Mapping to a dedicated document (pdf) so that instead of each project in the Tasking Manager needing to have the Rules For Mapping posted in each project's Instructions page, as is the case now, it would greatly reduce the cost of maintenance if/when mapping protocols are revised. My proposal, to be clear, is that: The Rules For Mapping are listed in a single (pdf) document that can be linked to from the Instructions of each project page in the tasking manager. That document can also be referred to in all other mapping documents and guides, so that future changes in mapping protocols can be more easily rolled out.

I suggest that the same approach should be used with any now fixed content across various web pages that is deemed to be debatable or have a high likelihood of revisions in the near future.