d-wasserman
commented
5 years ago Hi @emilyeros,
These are great questions, and there has been some thought that has gone into some of them.
- Generally, I envisioned the specification relaying the general cross-section "block-to-block" for high level visualization, scenario planning, and public communications. I think we need to start somewhere with defining how the right of way is defined, and leave some flexibility for extensions to address where it breaks down (GTFS had many examples of these types of extensions). This method may or may not break down. For example, should we specify "joint" transitions in the specification as a metadata trait, where it specifies which elements of the right-of-way are being removed/given a new width. Generally, there are ways to determine common transitions between connected joints based on rules. Curb extensions reallocate parking space to sidewalks, like slices from one segment to the next can be assumed to connect in some way. This might be out of scope for the immediate specification, but we can address connections in the future.
- This is a good question. In effect, this would provide a schema to unify them in a single line. There are precedents for centerline databases that have these types of attributes including OSM (cycleway,busway,sidewalk tags). The goal would be to create a database schema that connects back to a ShareStreet geometry ID (can you confirm that understanding is correct? an intersection to intersection unique geometry ID?). It is possibly the city could maintain their own version of the database, or jump start one from OSM. It is possible it does not need to be spatial, but my hope is cities could find this to be a helpful add-on to their centerline database or be a derivative from it. Also widths would be stored as numeric data rather than as polygons, I was not thinking shared streets would store the data but provide a join geometry/reference ID for an LR based analysis/problem. I expect this type of data could be used to render polygons based on the input width data. Does that make sense? I will likely rewrite this if my understanding adjusts.
- Actually, it would not be polygon at all (planimetrics), we just need the width attributes associated with our understanding of the right of way. Planimetrics might be one way to approach getting the width data. Though, I do have scripts that can help extract widths based on a polygon. There are 3 ways we are thinking about addressing this however, and might be the hardest aspect of this specification.
-
Smart Defaults - I could this this starting out as just an arcpy/geopandas script that adds and attributes to a centerline file based on functional classification, OSM, or some other reference database. It would then be updated on a project by project basis for redesign, corresponding analysis, or other applications such as visualization.
-
Partnerships - I am currently talking with EcopiaTech.AI about seeing if they can extract width attributes for bike lanes, sidewalks, roadbeds, medians, and lanes based on their currently feature extraction algorithms. They already have provided examples of roadbed and sidewalk width data at large scales and low cost (relatively speaking). Mapillary also could be a partner here, helping to create the linear attributes and features we want based on street level imagery.
-
Distribution of ML Model Derivatives with Repo - This one is out there, but involves work I am doing with @mflaxman10 on seeing if we can develop basic models that can classify some of these attributes based on their derivation from synthetic images created from the complete street rule. We were thinking about distributing attributed OSM highway segments with cross-section segments. This all depends on this approach actually, well, working. If not we might try other approaches to OSM feature extraction.
-
I think the additive model was developed with this in mind. It is possible that the order could be stored in a key:value pair column that does just that (storage pattern maybe like "other_tags" for OSM2PGSQL/Geofabrik PBFS of OSM). That might be something we add to the table as an optional field. As you mentioned, the sliced based representations are very technical, and might depend on us to make transform tools in arcpy/geopandas. I think arcpy/arcgis python API has the easiest mechanism of entry because most of these cities have ArcGIS. I also know it would be less code than if we did it with the QT API in QGIS.
-
This is a good question. I think everything from scripts that do Additive Transforms to Web Based renderers / editors of the slices could be possible. Remix/StreetMix might be able to provide it as an export? I think generally, this might be the data format that the technology companies use to build scenario based applications. I think generally this level of multimodal cross-section specificity has a very large base of applications in planning, but it could provide a standardized format for streets that enable scenario based revisions of entire street networks, visual communications as part of active transportations, and even provide key attributes for transportation demand models to make them increasingly more focused on other modes of transportation (rather than depending on on-off modifiers, include real metrics of network quality for bicyclist, pedestrians, etc).
-
You are absolutely right. I will think of developing a list of use cases and how it can be applied across transportation/urban design/technology disciplines.
This is really interesting. Some initial thoughts:
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.
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.
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.
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).
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.
Problem statement and examples. It might help to clarify upfront the problem the industry currently has and how this would help (use cases, basically).