Sections

Did you ever go anywhere with this Matthew? My recollection was that sections were implemented (I remember celebrating), but having just gone to start entering route notes and gpx files for the Raukumara east-west crossing as sections I can't see and 'section'/'segment' flag available on the add track page.

I've been struggling with it actually -- in two minds. One approach is to make them a track with a "section" flag. Another is to make them a different type of data. My reasoning is that it would be nice to slim them down and get rid of all the overhead info like associated huts etc. Also, it would be nice to have times and descriptions in both directions. Hence I'm leaning this way. It's very easy for me to set up another data type, and I am inclined to do this in this case. If it simply does not work, I can migrate the data over anyway. Properties of a section in my mind: 1) name 2) description 3) walking time 4) grade 5) (optional) reverse name 6) (optional) reverse description 7) (optional) reverse walking time 8) gpx path 9) distance would come from the gpx path To me, I think it might be that simple. A track is composed of multiple sections chained together in order. You could of course also link your own sections together without necessarily submitting it as a track.

yes. Sounds good. however, I'd have worked on a node & vector system. the vector is the segment. the node is the start & end point plus optional other intermediate points. so I'd allow huts, campsites, places (anything represented by a point) to be associated with the segment as start, end and intermediate points 'Sth Temple Hut to Shamrock Hut", or: "Irthing roadend to mansion hut" being typical segments. you can then loosen your rules to say: EITHER a segment MUST have a start and end point OR it must have a gpx file"

Thinking further however I suspect my above suggestion of start and end points refernced to huts, places etc would result in numerous duplicate but differently named start and endpoints created in your database. So maybe just a grid reference for start and end (select from map as-per location data) if we don't have a GPX file. My gripe about GPX being mandatory is: Personally, I'm happy, if I have time on my hands, to go into ArcGIS or maptoaster and draw myself a route to upload as a GPX file. However, I suspect that insisting on a GPX file of every route will result in many (most) potential users not uploading any routes as they don't carry a GPS, or don't record GPS tracks; and creating a GPX off a map requires special software and is just too hard..

Hi @madpom, I am anticipating storing a path. The path could come from a GPX file, from DOC data, could be a series of points entered (even just two, start and end), or could be drawn directly on a map (a bit of a fiddle to implement, but would be nice). Once entered, the source would be irrelevant and it would just be a path. I'm not convinced sections need to be associated with huts etc as they're already effectively associated by virtue of proximity. That raises the question, do tracks need to be associated with huts etc? Maybe not. I think there's some sense but...maybe not. However, that's already done so I think it should stay that way for now. I agree: making GPX data mandatory makes it too hard. However, I am looking at importing all DOC data either as sections or as paths available to add to sections.

Let me know if you figure out a way to auto-generate track times from raw spatial data. I had an idea some time ago for a hutbagging board game, and wanted to generate a game-board from real data with 'effort' values (based on things like gradient and distance) for different sections of track that could somehow be multipled by a person or group's ability. Pulling Topo50 track data and Topo250 contour data (more convenient in my case because it's only every 100m) from LINZ is easy enough because you can download all the components of those maps separately, and from there I could use a free app like QGIS to generate a data point each time a track (or a river) intersected with a contour, and apply the correct elevation to that data point. Then I got bored and distracted. :) But the next step was going to be to figure out a way to auto-compare elevations between data points at each contour along a track and very roughly guesstimate some kind of effort value to get between the two... eventually to be added together and generate comparative times between places.

There's Naismith's rule et al (cf Wikipedia). But I think that's too fast for NZ (or me). I usually estimate 300-500m climb per hour, 2-3km per hour horizontal, and downhill is about 60% of the uphill time. NZ tracks and routes are pretty rough though. Oh and that's based on map distance. GPS distance would be longer so you'd be measured as travelling faster. What do you think? Interesting idea for a game btw...

Pretty easy in ArcGIS. If you want to send me the vector files I can return them with a slope attribute. Not sure about QGIS though ...

Thanks for the offer. That project's a recurring thing and I'd need to get that project back in my head again. I've been trying to tune it roughly to the rules in various Tararua Hutbagging competitions but there's this awkward balance between realism and complexity. :) I normally go with a ~300m/hour vertical metric for a reasonably capable group, but I'd close to double that under normal circumstances for me by myself or with people who I know are quick up slopes. One of the problems I ran into with trying to auto-calculate it from map data was with sidling tracks. If the track repeatedly crosses the same contour over and over, an algorithm needs to notice that it's not necessarily climbing and dropping <20m or <100m repeatedly. For the game thing it's getting to the point where it might just be easier to draw some lines on the board and make up numbers, but it'd be neat to not have to restrict movement to common tracks and routes. :)