osm_tags creation

[alanjosephwilliams]

Goal

Create a new property titled "osm_tags". Deliberate publishers of data will be able to extend the expressiveness of OpenTrails through an array of key-value pairs.

Key-value pairs should be included in osm_tags not individually, but rather as members of sets---in OpenTrails, we call these Extension Profiles.

The goal of this portion of the transformation is to ask whether or not the agency wants to include any Extension Profiles, and identify whether or not any existing columns/attributes should be included as part of that Profile.

Example from Sample Data

Many of the sample data sets we have on hand contain information meant to help describe the physical condition of a trail segment. These attributes are often helpful for describing the accessibility of a given trail segment.

Thus, if attributes such as "surface" or "width" are present in the uploaded data, we should

• tell the user that these attributes are not required by OpenTrails
• Suggest that the user include the entire "accessibility" Extension Profile
  • surface
  • width
  • condition
  • incline

For each of those key-value pairs in the Extension Profile, we want to identify whether or not the attribute exists in the uploaded data. If it does, we want that to inform the value of that key value pair. It it does not exist, the value of the pair will be null (but it will exist).

[migurski]

Can you remind me where the extension profile is documented?

[alanjosephwilliams]

Currently they are exclusively documented in the finalized v1.0 draft, as appendices:

https://docs.google.com/a/codeforamerica.org/document/d/1KF8KAio-SqGHhh9oFY_KjfwIi3PePOHg7KfTSPh27fc/edit

[ryanbranciforte]

Not clear if this has been implemented, if not, please ignore. If so, then in my testing, it's having issues, though might be an error on my end. Lower priority!

[ryanbranciforte]

sample data here on shared dropbox: Course_1/County/County of Santa Clara CA/Prepped/Final