d-wasserman / shared-row Goto Github PK

Shall we construct a .json version of the feed specification. https://github.com/d-wasserman/shared-row-spec/blob/master/specification/Shared-Row.xlsx

This is really interesting. Some initial thoughts:

1. I assume the sliced representation is given for a particular point (e.g. SSR201...3s4 @ 20 meters)? It doesn't seem like this could work for ranges (e.g. @ 20 meters to 40 meters) since as soon as one feature changes width, this method seems to break down. Not necessarily a flaw, just an observation.

2. Biggest question: how do you envision storing the input data features (e.g. sidewalks, bike lanes, motor vehicle lanes)? To be able to query the width at any given point along the street, you need the equivalent of polygons as an input layer. Maybe this is polygon-based spatial data, like you can sometimes get in OSM for sidewalks. But there would be some advantages to keeping everything in an LR model and avoiding spatial representations entirely. I'm thinking of a unit square. That approach would enable you to store the width of a feature at any given location from 0 meters to 100 meters (or whatever the length of the road is), without using spatial coordinates.

3. How will you get the input data? It's rare to find a polygon-based bike lane or sidewalk dataset. Even in OSM, it's rare to see sidewalks mapped as areas rather than lines. I can understand wanting people to start collecting this data... but do you have a plan for where you'd find enough good data to create examples and build tools with? There's considerable effort involved in creating this type of data so it will be hard to get cities to use this if there is not a clear benefit to them.

4. Interoperability. If we assume that cities, companies, etc are going to keep using their core tools (databases, GIS, etc), then users must be able to convert data back and forth from additive to slides data representations. As you develop the spec, it's worth keeping this in mind. So far it seems like you could do this in the additive data model by creating an index for every existing column, which would store its position in the left-to-right order of street features (e.g. bike Lane = 2.4, bikeLaneIndex=2).

5. Who creates the sliced data representation from input layers? This is pretty specialized/technical, which means it may be beyond reach of a lot of folks. But users may want to customize the input features included in their slice (either features they care about, or data sources they prefer or trust, like city centerlines instead of OSM). I'm not sure which audience is the data creator.

6. Problem statement and examples. It might help to clarify upfront the problem the industry currently has and how this would help (use cases, basically).

I work on an application that parses streetmix "segments" (analogous to "slices") json and I notice that the Slice Type table matches almost all of the Streetmix type names however this repo uses underscores instead of hyphens

For example streetmix is "drive-lane" but shared-row is "drive_lane" from:
https://github.com/d-wasserman/shared-row/blob/master/specification/MarkdownTables/Slice.md

Here is a simple JSON dump of a streetmix street output:
https://github.com/kfarr/streetmix3d/blob/master/sample.json

Is this specification in production elsewhere or should we discuss which should be the "standard" to use underscore or hyphen?

One area of need beyond visualization potential from StreetMix, AB Street, or CityEngine there is a need for some examples of people developing open metrics on the shared-row specification in GIS or within a web context. I think back to a multimodal plan I worked on a while ago that might provide some inspiration, but there are many others. I think some important metrics to think about create open examples on include:

• Bicycle Level of Traffic Stress
• Pedestrian Comfort Index -taking into account street scape, greenery, sidewalk width, maybe land use context as an additional variable
• Transit Orientation - Some metric connecting to information related to real-time GTFS or other dbs.
• Vehicle Orientation - Potential derived capacity estimates from lane configurations/network alignment. That one is harder.
• Others - impervious surface estimate from ROW, typology fits, curbside related metrics, others.

FHWA has developed a model road way inventory that includes many of the variables discussed in this specification. I think thinking about how to build upon their work and using the same classifications and field names would be a benefit modification.
Report: FHWA-SA-17-048
Link: MIRE 2.0 Documentation
It would basically modify how we represent elements of the Additive Spec (which this is similar too). I was curious what others think about this?

It is also possible MIRE is just something this specification plans to integrate with. They are not duplicating all aspects of the street discussed in the spec.

The spec appears to be using the term "crosswalk" to refer to a way of representing slices in the flattened additive format:

A share-row-crosswalk consists of each row representing a slice of a shared-street id. Intended to allow the conversion between Additive and Sliced based specifications in an editable GIS/SQL database.

The word "crosswalk" is synonymous with pedestrian crossings. I'm very confused by the crosswalk tab in the schema, because it doesn't seem to have anything to do with pedestrian crossings. Should this be renamed?

There is a need to create a series of scripts (open source & closed source) that parse OpenStreetMap data and tags and create both slice & additive versions of the shared-row spec. Anyone taking on such a project can be sure their repo will be linked in this repository under services.
Please reply if there is interest or a current project.

Related projects providing a starting place:

• OSMNX
• StreetSpace
• Shared-Row GIS Tools

I don't have Excel, so I'm using Google Sheets to view Shared-Row.xlsx. It'd be much easier to view and edit this spec in a text format. Some ideas:

1. Markdown tables. The rows would be really wide with the description, though.

2. Some formal schema, like https://json-schema.org/

3. Markdown using lists. An example:

Automotive (dedicated)

"Dedicated" means "primarily intended for." In each of these cases mixed traffic may be permitted and a meta tag will indicate what kind of mixing is allowed.

• drive_lane: This denotes a through-lane intended for automobile traffic.
  • sharrow (optional boolean): Describes whether a drive_lane slice has a sharrow stamp located within it.
• turn_lane: A lane where automobiles are taken out of traffic flow in order to queue for turning. These lanes are considered to be center-running and can be bidirectional if they represent a block to block segment with end and begin depths for symmetrical intersection end points (no additional turn lanes on either end of the segment). Segments should be split if one block has varying turn lanes counts.
  • sharrow (optional boolean): A turn_lane may have a sharrow stamp
  • end_depth (conditionally required number): This specifies the turn lane depth for the end point of the existing segment. If blank, it is assumed the turn lane is the depth of the entire length of the represented segment. For block to block representations, this parameter is required, and only works for symmetrical end points of intersections.

How to handle a shared row slice format when there are changes to a slice type within the street?

Some examples:

• a vehicle through lane turns into a right-turn-only lane
• lane width changes or merging (parking transitions to a larger sidewalk)
• a flex zone in a given street has all 3 of: bench, bus stop, bike share station

Or are changes to the slice beyond the scope of a slice and instead a new set of slices should be created?

I am starting to think about whether or not we should have a specific set of optional specifications for intersection points and their relationships to the "segments" we are describing in the specification. What attributes would be useful here? Would we move the crosswalks to this schema? How do we handle multiple legs?

@marsxul / @migurski / @louh / @emilyeros

@drewda and myself reconnected to discuss this specification. He pointed out that often more important to adoption than a specification is being able to articulate the problem we are solving between producers (cities/DOTs/OSM), and consumers (Remix, StreetMix, CityEngine, Scenario Planning Software).
We need to answer a few questions based on this discussion:

1. Are going to represent scenarios or focus on just the existing condition? Orient around one or the other?
2. Who are the players that would be interested in adoption?