opensidewalks / opensidewalks-schema Goto Github PK

I noticed large volume of project=opensidewalks and project=OpenSidewalks being tagged on OSM objects.

Is it still needed for any purpose? Note that all projects tagging all object of interest does not scale well and is not a good idea.

Do you need help to find all sidewalks within specific area or somehow find subset of sidewalks?

Show the OpenStreetMap community what data you are using. Add your project to the list of Taginfo Projects.

cc: @nbolten

The jsonschema generator currently expects properties that are optional to either exist or not and treats the case of null values as an error case. Many GeoJSON serializers (QGIS, Python's Fiona) may fill values as null when they are undefined (or None, in the case of Python).

We should explicitly decide how to handle this case and/or describe it to downstream users of the provided jsonschema file.

Hi, please don't recommend adding description=... sidewalk tags to OSM. That information is redundant as the other tags already specify that it's a sidewalk and the corresponding street can be figured out from the geometry (and the description tag isn't the proper place for that anyway).

https://www.opensidewalks.com/files/01_OpenSidewalksEditing.pdf

There has been an active and productive discussion in issue #2 around sidewalk-street associations, including ideas for how to infer this association and how OSM primitives may be used to unambiguously tag it. This has implications both for how OpenSidewalks makes OpenStreetMap tagging recommendations outside of this repo as well as what fields and primitives we describe in this schema document.

This issue will provide a forum dedicated to discussing how street-sidewalk relationships may be created, touching on all of these (separable) themes:

• Inferring the association using heuristics (e.g. spatial proximity between a sidewalk and a street).
• How this association might be taggable using current or proposed OpenStreetMap tagging schemas.
• How this association might be represented in the OpenSidewalks schema separate from but translatable to/from OpenStreetMap in the case that a sidewalk-street relationship can be explicitly tagged in OpenStreetMap.

@Woazboat, @amandasaurus, @matkoniecz, @1ec5, please continue any discussions on this topic here! It's very helpful. I believe the ball is partially in my court for creating some examples of challenges in inferring a sidewalk-street association spatially, so I'll ping again once I have those examples.

Our typing of the top-level GeoJSON object is currently very strict, requiring that the type and features keys, and only those keys, are defined. Real-world GeoJSON files often have additional top-level keys, such as crs (to specify an alternative coordinate system), bounds or bbox for the extent of the dataset, name to create a named layer, and so on.

To my knowledge, we don't really care whether there is additional information at that top level. At most, we may want to set restrictions on certain optional keys. For example, we do want the crs to have a value of WGS84, if it's defined.

This is a list of (currently) suggested changes (and whether they have been implemented):

• If crs is defined at the top level, require that it refer to WGS84. It may be difficult to set this requirement through jsonschema, but we could at least support an enum that includes { "type": "name", "properties": { "name": "urn:ogc:def:crs:OGC:1.3:CRS84" } }.
• Ignore and allow all extra keys