Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposed output fields #2

Open
mkbrk opened this issue Oct 6, 2014 · 8 comments
Open

Proposed output fields #2

mkbrk opened this issue Oct 6, 2014 · 8 comments
Labels

Comments

@mkbrk
Copy link
Contributor

@mkbrk mkbrk commented Oct 6, 2014

Proposed fields to include in the "properties" object in the geojson we emit.

Required Fields

  • Name [string, the trail name, required even if null or blank]
  • Source [string, where the record originated, required]
  • System [string, the trail grouping for this trail, required even if null or blank]

Optional Fields

  • Surface [paved, earth, etc.]
  • Class [primary, minor unpaved, etc.]
  • Lighting [true/false]
  • Difficulty [Novice, Intermediate, etc.]
  • SkiType [classic]
  • Direction [2way, 1wayforward, 1wayreverse, 1wayalternate]

Example

"properties": { 
"Source": "Muni", 
"System": "Coastal Trail", 
"Name": "Coastal Trail", 
"Identifier": "Muni\/Coastal Trail\/Coastal Trail", 
"Surface": "Asphalt", 
"Class": "Primary Paved", 
"Lighting": "No", 
"Difficulty": "Novice", 
"SkiType": null }
@mkbrk mkbrk added the help wanted label Oct 6, 2014
@thermokarst

This comment has been minimized.

Copy link
Member

@thermokarst thermokarst commented Oct 7, 2014

I like this --- hopefully we can get some input from some others in the brigade.

@NigelKibodeaux

This comment has been minimized.

Copy link

@NigelKibodeaux NigelKibodeaux commented Oct 7, 2014

What do 1wayforward and 1wayreverse mean?

@hansthompson

This comment has been minimized.

Copy link
Member

@hansthompson hansthompson commented Oct 7, 2014

I think that they specify that everyone on the trail should be going one way or reverse to avoid collisions. Important for the mountain bike courses. But what does 1wayalternate mean?

I think SkiType should handle "classic", "skate", "both", or "na". How about trail length, handicap accessibility, and if dogs are allowed?

@thermokarst

This comment has been minimized.

Copy link
Member

@thermokarst thermokarst commented Oct 7, 2014

I think 1wayalternate is for trails that alternate directions according to a schedule: e.g. CW even days, CCW odd days.

@NigelKibodeaux

This comment has been minimized.

Copy link

@NigelKibodeaux NigelKibodeaux commented Oct 8, 2014

How would I proceed on a trail marked 1wayreverse? Travel in the opposite direction of the one way signs?

@thermokarst

This comment has been minimized.

Copy link
Member

@thermokarst thermokarst commented Oct 8, 2014

@mkbrk, feel free to chime in here, but I feel like I have heard about trails that had opposing traffic directions based on usage type (e.g. cyclists: CCW, pedestrians: CW). Is that what was envisioned here?

@mkbrk

This comment has been minimized.

Copy link
Contributor Author

@mkbrk mkbrk commented Oct 8, 2014

Right, I know of at least the following scenarios:

  • 2 way traffic
  • 1 way traffic "forward" (meaning if you were traveling the polyline of the trail, you would hit the points in order)
  • 1 way traffic "reverse"
  • and 1 way traffic where the direction of travel depends on the day of month or week. There might be a number of variations on this one.

I don't know of a situation where the direction depends on mode of travel, but it might exist.

My main concern was to be able to draw little arrows on the map.

On Oct 7, 2014, at 6:41 PM, Matthew Dillon notifications@github.com wrote:

@mkbrk, feel free to chime in here, but I feel like I have heard about trails that had opposing traffic directions based on usage type (e.g. cyclists: CCW, pedestrians: CW). Is that what was envisioned here?


Reply to this email directly or view it on GitHub.

@mkbrk

This comment has been minimized.

Copy link
Contributor Author

@mkbrk mkbrk commented Oct 13, 2014

Revised proposal based on feedback and technical constraints

Note that field names are now lowercase, since some tools for handling the dataset are case-insensitive (e.g. SQLite)

source
string, where the record originated, required

system
string, the trail grouping for this trail, may be null or missing for unnamed trails

name
string, the trail name, may be null or missing for unnamed trails

surface
string, one of: Earth, Asphalt, Concrete, Gravel, Other, Unknown - missing or null implies Unknown

lighting
string, one of: Yes, No - missing or null implies No

winter and summer usage
at least 4 options here:

  1. Array of strings, e.g. ["Ski", "Bike", "Foot"]
  2. Single delimited string, e.g. "Ski,Bike,Foot"
  3. Bitmask, e.g. Ski = 1, Bike = 2, Foot = 4, therefore Ski/Bike/Foot = 7
  4. Separate properties for each mode, e.g. "winter_usage_ski":"Yes", "winter_usage_bike":"No"

The decision here depends almost entirely on what ogr2ogr will support easily. Personally, I think option 1 is technically the best, but I'm not sure how arrays as property values will flow through the GDAL tools.

Regardless, I believe the valid usage modes to be:

  • Ski
  • Bike
  • Foot
  • Skijor
  • Snowshoe
  • Mush

and I think it might make sense to add these (though I could see a dedicated field for "dog rules"):

  • Dog Walk
  • Off-Leash Dog

ski_difficulty
one of: Novice, Intermediate, Advanced, Unknown - missing or null implies Unknown

ski_mode
one of: Skate, Classic, Both - missing or null implies both

direction
one of: 2way, 1wayforward, 1wayreverse, 1wayalternate - null or missing implies 2way

handicap_accessible
one of: Yes, No - null or missing implies no

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.