Here are some nits I would wish for assuming that the data continues to be distributed in gpx format:
7. Add elevations (gpx ele elements) for all waypoints (gpx wpt elements) and routepoints (gpx rtept elements, but not necessarily gpx extensions rpt elements). Today I toss all the ele elements and fetch them from
http://gisdata.usgs.net or if that fails from
http://ws.geonames.org and build a SQL database of elevations. This gives me elevations for all points, but the validity is problematic on bridges and tunnels as they fetched points will be on the surface, which in these cases is not where the route is. The elevation data is useful in displaying profiles, although because of the sparsity of the gpx rtepts they are rough. If your software cannot fetch the elevation data I could help with software but in my experience this is non-trivial and requires some maintenance as the web servers and protocols change with time.
8. Delete all times, i.e. (gpx time elements). I don't think these are meaningful for the ACA data and they can cause difficulties when viewing the routes in some tools, e.g. google earth. I could provide software to this if you don't want to take care of it upstream of the gpx file creation.
9. Delete all gpx extension Depth elements. There are only two in the entire set today, and they are used incorrectly. I could provide software to this if you don't want to take care of it upstream of the gpx file creation.
10. Validate all distributed gpx files. While I haven't found invalid gpx files from ACA, invalid files are a common cause of issues reported on the gpsbabel mailing list. I can supply software to do this. Note that this step doesn't change anything, it just guarantees that the gpx files that are about to be distributed obey the rules for gpx files as defined in the appropriate XML schema documents (xsd files).
11. Consistently organize and name the folders and files for each route, including case and blanks in directory and file names. These makes automated processing easier.
And one that I consider more important:
12. Have contiguous route segments, gpx rte elements, share a route point (gpx rtept). This make display of the overall route appear as one, instead of a bunch of separate and disconnected segments. Accidental violations of this are the most common reason I write Jennifer.
And one major request:
13. Continue to provide public access to all the gpx data, including the points of interest and route data. There was an article in one of last years magazines that stated that points of interest data would be restricted to members in the future. To me it seems restricting access to the points of interest is in conflict with the ACAs mission "Adventure Cycling Association inspires and empowers people to travel by bicycle." I am concerned that a revised policy on the waypoint data might prevent me from providing online viewing tools and google earth files to the public, and I certainly believe the maps at
http://tsteven4.qwestoffice.net/ inspire and empower people to travel by bicycle.
I question 5, the separation of the point of interest (wpt) and route (rtept and rpt) data. I see this as a violation of 6, "keep open and accessible across multiple platforms". I think the separation is convenient for some applications, e.g. mdxix seems to want this, but I am not convinced this is generally desirable. I would prefer they remain together.
I am still unsure of what Jennifer meant by "Do you like/use the sample routes provided?". Can you cite an example of a sample route? In 3 Fred seems to imply a sample route just corresponds to the route as shown on a paper map panel.
Thanks for all your work and including us in the conversation.