Closed emilyeros closed 4 years ago
Hi @emilyeros,
These are great questions, and there has been some thought that has gone into some of them.
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).