Feature Services

[stdavis]

We need to figure out where the feature services that back this app will be hosted. The data is contained in both the Roads and Trails and Pathways SGID datasets.

Relevant fields in Roads

FULLNAME, BIKE_L, BIKE_R, and perhaps BIKE_NOTES.

The BIKE_* fields use the following domain:

Code	Name
1A	1A Cycle track, at-grade, protected with parking
1B	1B Cycle track, protected with barrier
1C	1C Cycle track, raised and curb separated (may be multiuse with peds)
1D	1D Cycle track, bi-directional
1E	1E Cycle track, center-running
2A	2A Buffered bike lane
2B	2B Bike lane
2C	2C Bi-directional buffered bike lane
3A	3A Shoulder bikeway
3B	3B Marked shared roadway
3C	3C Signed shared roadway
1	1 Cycle track, unspecified
2	2 Bike lane, unspecified
3	3 Other bike route, unspecified
PP	Parallel Bike Path, Paved
PU	Parallel Bike Path, Unpaved
UN	Unknown Category

Relevant fields in Tails & Pathways

PrimaryName

BikeDifficulty	Count
Beginner	3762
Intermedi*	2420
Expert	1339
Advanced	46
Intermediate	17

CartoCode	Count
4 - Road-concurrent	18198
3 - Paved Shared Use	8792
2 - Hiking and Biking Allowed	8206
1 - Hiking Only	3139
9 - Link	3012
8 - Bridge, Tunnel	147
5 - Biking Only	140
7 - Steps	82
6 - Equestrian Primary	7

DesignatedUses	Count
Multiuse	34039
Pedestrian	2572
Bike	140

Question for @bert-granberg:

What queries should go with what values in the filter for the app? What other attributes should show up in the identify panel?

Editing

Possible branch versioning via the UGRC portal instance.

[stdavis]

@bert-granberg is going to get us an ETL script and then we will push out the feature services.

[bert-granberg]

@bert-granberg is going to get us an ETL script and then we will push out the feature services.

@joshua-reynolds is planning to do the ETL script that brings the road centerlines features with Bike_* attributes together with the trails/pathways features. Basically deriving one new feature class with the needed data elements from from the two feature classes. The end product would essentially be "bikeways" (on street + pathways bike routes in the real world). The on street would need the type of bike facility and the level of traffic stress.

[joshua-reynolds]

@bert-granberg Don't we already have this in the bike layer of the multimodal network? If this is true, we just need to figure out where and how to host it.

[nathankota]

• One service for existing infrastructure
• One service for planned

[stdavis]

A preliminary feature service from @joshua-reynolds this morning:

https://wfrc.maps.arcgis.com/home/item.html?id=cc0db244166f486891c02b6d306165fd

This schema is as follows:
'NAME' - name of the street or trail
'CARTOCODE' - cartographic code,
'SIDE_1' - direction (N,S,W, E),
'SIDE_2' - direction (N,S,W, E),
'TYPE' - bike facility type ,
'STATUS' - existing or planned,
'SOURCE' - roads or trails,
'SOURCE_ID' - id for joining back to global id of source data

*highlighted fields have unofficial data

[joshua-reynolds]

The script is complete and can be found here:
https://github.com/WFRCAnalytics/Bike-App-Create-Features

[stdavis]

The latest draft web map is here: https://wfrc.maps.arcgis.com/apps/mapviewer/index.html?webmap=1da30e08d4ce4950bb44662e5c9a54fb