Travel Mapping Highway Data Folder system

[english si]

Existing collaborators - how would you want the data arranged?

[Jim]

I just voted "By (sub)region and then by system" but it's not a strong preference over system then (sub)region.  I would like to see more of a hierarchy than the data folder from CHM, though.  I don't think our choice here makes much difference in the big picture from an implementation point of view, but will make it easier (I hope) to wade through all of the data manually.  More find-grained control also might lead to a better way to permit various contributors to pull/merge into the mainline things from only the (sub)regions where they are the primary caretaker.

[english si]

I just voted "By (sub)region and then by system" but it's not a strong preference over system then (sub)region.

I just did the reverse. I like your points about easier to find if done by system.

Big systems (KY state routes, LA state routes, GB A roads, etc) that have been added by subsystem could be split. Easier to have the 1500+ English files (mostly A roads) in folders with a maximum of about 400 files in them.

Actually, I'm convinced. Option 3 over Option 2.

[oscar]

How would we handle the csv/index files for systems spanning multiple regions/subregions, if we split primarly or only by (sub)region? International European Roads is the most obvious one, but maybe also affected would be national systems such as the Trans-Canada Highway and U.S. Interstates.

[froggie]

TCH and US Interstates could be remedied by making the sub-regions "Canada" and "U.S.".  Not sure offhand for the European E-routes.

[english si]

Surely you could have the pickup look at <region>/<system> or <region> rather than <system> fields to find the file though the CHM browser doesn't seem to care what system?= is, leading me to suspect that the .csv files created the system for the database, and the folder structure was largely meaningless for the back end and existed to stop there being thousands of files all in one place. All file names are meant to be unique anyway (though there's the Toronto freeways in two systems, and perhaps a few state routes).

eg: http://cmap.m-plex.com/hb/hwymap.php?sys=usadc&rg=ak&gr=p&r=arm.e002&showint=30&dl=1 has Armenia's E002 in the DC district highways system, and in the region of Alaska, but works just fine.

Froggie - CAN, USA and EUR would be regions (currently CAN and USA are split into subregions and not really used outside of system names, and EUR is a 'super region' that only exists in the name of the eure system).

[rickmastfan67]

I think 'By (sub)region and then by system' would be the best way IMO.

[Highway63]

Subregion then system seems more manageable than having one folder dedicated to (say) all the bannered US routes nationwide. That way someone in charge of a state only has that state's folder to worry about.

[rickmastfan67]

I just want to know what to do with the Utah SR dataset I compiled for CHM.

This doesn't have anything to do with this post.  We're just talking about how to store the data online in folders on the server end, not the public end, here.  The question would be better asked in this thread.

[hobsini2]

I also think that for people to enter their data points, going by (sub)region then system would be easier to find.

[oscar]

I also think that for people to enter their data points, going by (sub)region then system would be easier to find.

I think the folder structure will be irrelevant to users logging their waypoints, just like with the existing CHM. Folder structure will matter most (or only) to team members maintaining the overall system, or building new route files or systems.

[Jim]

As posted in the "status" thread, the data in the new directory organization (but keeping the original .wpt format for now) is live in my testing area.