recommendation for creating sidewalk map for charlottesville

[alibama]

Hi - just wanted to start a conversation in github for anyone else who might be interested :)

Charlottesville has some sidewalk data

https://opendata.charlottesville.org/datasets/pedestrian-sidewalk-area

we want to create a better pedestrian and wheelchair routing map for our area, and want to know whether it is going to be better to start with sidewalkify from the city streets and then cleaning that output with the data in the charlottesville data portal, or approaching this from the sidewalk area first and massaging that to generate usable routing graphs?

[nbolten]

Hi @alibama! Very interesting dataset and ideas!

We (OpenSidewalks/Taskar Center/AccessMap) are open to any form of data that can be productively coerced into a traversable accessibility map, so routing more directly from areas (polygons) is definitely on our radar. Some pedestrian spaces just aren't well-described by lines in the first place, like plazas, so we'll need to settle on a strategy for at least some polygons, eventually.

We'd be open to having a video chat about all of this stuff as well, if you want to strategize together.

To answer your actual question, my (probably not super helpful) answer is: it depends. I'll list some pros and cons for each data type that might be helpful for deciding or strategizing.

Extracting a routing graph from those polygons

Pros

• The data exists!
• Can work closely with your local open data provider to get up-to-date info.
• Avoids the need to make some 'executive decisions' on what paths exist and which don't. For example, there are some pedestrian streets in this dataset with 'holes' in their polygons for planters - you could enumerate many paths that criss-cross from the polygons and not have to decide on just a few canonical ones.
• More closely resembles some other data types that will hopefully exist more frequently in the future based on computer vision/AI techniques.

Cons

• The polygons have been segmented a little oddly. Those pedestrian streets I mentioned earlier are in the 'sidewalks' dataset with no way to distinguish them from actual sidewalks. The sidewalk areas are also frequently disconnected at driveways associated with 'parking' areas (the parking areas dataset), so you'd need to join the sidewalks and parking datasets to create a properly connected graph. To complicate matters, sometimes there is a curb where the sidewalk dataset meets the parking dataset and sometimes there isn't and I don't see any way to know when there's a curb or not. Sometimes the parking dataset is a big parking area (probably okay for pedestrians) and sometimes it's just streetside parking spaces (not something I'd tell someone to walk on for routing purposes).
• There are many potential paths forward for extracting routable paths from polygons (skeletonization, robotics-related pathfinding) but we haven't settled on one. None of them will really work without first joining the sidewalks and parking datasets together very carefully and with custom algorithms. Most of the work will probably revolve around massaging the polygonal dataset into a format is semantically correct and works with a pathfinding algorithm. You will also probably need to modify the pathfinding algorithm to handle important edge cases.

sidewalkify lines

Pros

• Can reuse our algorithm/package!
• Output is regular and predictable
• Is easy to combine with AccessMap/crossify

Cons

• You'd want to know the street offset distances of sidewalks in order to use sidewalkify. If this information is not already available, you'd want to write some code that can do searches on the left/right side of street lines (I have code to do this somewhere and am happy to include it in this package / share it freely).
• Will only create "proper" sidewalk centerlines, will miss other pedestrian paths or complicated sidewalks. Example: maybe there is a large sidewalk that has a single big planter in the center. sidewalkify will create just a single sidewalk line and it might even go straight through the planter. A polygon-based approach will avoid the planter and probably discover both paths going around it.

I think either approach is perfectly justifiable and they can even be complementary, it just depends on your team, their interests, and your time frame. We've been interested in exploring polygon-centric routing for some time, so if your team prefers that direction we could do a collaborative experiment around it!

[alibama]

I would definitely enjoy catching up & I've reached out to codeforcville.org where there's definite enthusiasm to support the data cleaning work that will probably spawn from this