Migrate polyline sidewalk data into centerline? (Two lines into one without attribute loss)

[KrzysztofMedyna]

I'm in the process of amalgamating several sidewalk datasets which require updating. All data I intend to consolidate within my centerline is based off of older versions of the data, and is a single line. I got my hands on some external data that tracked a portion of my city's sidewalk infrastructure. I am hoping to pull some of the attributes from it and into my city wide dataset. I've attached some screenshots of both datasets below to illustrate their attributes and design. 

While the sidewalk data represents the same roads as the centerline, it is a series of (not connected to each other) segments set on either side of the centerline. The end points also don't align with any similarity to the intersection nodes/end points of the centerline itself (Ex: centerline can have 4 connected segments along a road whereas there are 10 segments of the sidewalks).

I created a buffered polygon of the centerline and then attempted a spatial join but found that in doing so, many segments from the sidewalk data get removed in favor of a single one, relative to the centerline segment itself it was nearest to.

Secondly, the sidewalk data segments carry their own unique attributes (So not dual lines with one attribute table row) which I am hoping to migrate over. If I can join the data successfully, I'm not sure how to accommodate data from two lines being accurately represented within the centerline.

Should I completely forgo the single line data and start from scratch with a dual line set? (We have some topological networks and other dual line type options...none of which relate to the centerline in any way).

Would greatly appreciate some thoughts on how best to tackle this set of pickles.

Thanks!

[jcarlson]

Sidewalks can be pretty tricky, either as separate features or as centerline attributes. A lot depends on how you envision using this data.

I personally prefer the separate feature style, as it makes the centerlines simpler, and enables the addition of other sidwalk-specific point features like curb cuts and tactile paving, should you want accessibility-based pedestrian routing or something like that. Of course, this vastly inflates the number of features you have to maintain, and can make the map look busy, so perhaps you don't want to do that. And for connectivity, you'd need to fill in all the crossings, if you wanted the sidewalks to participate in the road network.

Another option is adding attributes like left_sidewalk_width, right_sidewalk_material, etc. This allows you to specify either sidewalk separately, if the features are present, without adding extra layers. The major downside here is that your centerlines would have to be split every time a sidewalk attribute changed, so what was once a single feature may have to become many features. And unless these attributes come with their own unique symbology options, it can quickly become difficult to track.

[KrzysztofMedyna]

Firstly, thanks for taking the time to share your thoughts. I'm also apologizing in advance for the lengthy reply, as the scope of my current project is two fold and I want to provide as much clarity as I can.

The first problem is my attempt to standardize years of historically siloed GIS data from four municipal districts. This unfortunately means four different ways of creating, modifying, and maintaining the data. 

In terms of the general data I've got, it all begins with a no longer maintained city wide "Sidewalk Inventory" shapefile. It was based on the same centerline but provided added descriptions of sidewalks, paths, and walkways. One of the four districts used this for its operational winter data of which I've attached a view.

 Two other districts have utilized the centerline as a basis for their sidewalk operations, but described sidewalk type differently, or not at all. 

The last district is potentially my Achilles heel as a previous analyst manually created a dual line dataset for their operations but then decided to remove all centerline related data from it. I have not even started to think how to deal with this problem yet.

So given that 3/4 districts were centerline based, I started migrating them into the newest centerline release and kept the "type of sidewalk" attributes where they exist as the old city wide inventory data did to have some uniformity. The sidewalk segment screenshot in my original post reflects a dataset from external consultants who mapped sidewalks in the district that omitted having a sidewalk type attribute in their data. That is the reason I want to pull all usable attributes from it into my consolidated data. 

Lastly, the second task is to then compare my consolidated data against the consultants metrics to ascertain the length of sidewalks which if exist, are physically serviceable by winter equipment and how many routes are required to provide complete coverage. I am obviously not concerned with this right now but wanted to provide an A-Z of the entire picture.

Please let me know if anything is unclear or you'd prefer some further detail.