Re: My thoughts on the PATC Map Database and Data Collection - AT Section Num

[Mrzac...@aol.com]

 

 

In a message dated 11/23/2010 14:15:51 Eastern Standard Time, tart...@gmail.com writes:

4)  How would I group this database?

Pretty much by State and then the PATC Map grouping.

You have outlined a good reference system for PATC territory. Would it make sense and be most consistently clear to assign the AT Guidebook section number to AT data traces collected for non PATC sections of Trail? This would/could be in addition to "county" and "state" and could simplify boundary straddling sections like those around Harper's Ferry, Pearisburg and the long run down south from Damascus on the TN/NC line. Same true for county boundaries. Other guidebooked trails could work the same way if they were accepted, standard guides. Would need to reference publish dates or edition numbers in case the sections, usually stable, change over the years. Metadata scheme, gotta love it.

Steve

[D. Tundra]

Steve,

 

My example wasn't a good one since Harpers Ferry "IS" on the PATC map.  But let's say it isn't.  And let's say there are two traces in the database - one in the Harpers Ferry on the AT and one in the Bolivar Heights Battlefield also in WV right next to Harpers Ferry but not on the AT.  In my way of grouping both these hikes will be in the same group, so if a person wants to go to hike in Harper's Ferry, he can see everything that's available in the whole area, not just on that section of the AT.  USGS uses 7.5min maps for that purpose, each of which has a name, but I think it's too small a division for our purpose.

 

-Dimitri

[Mrzac...@aol.com]

Isn't a large part of the problem the lack of a unique or even nearly unique, useful identifier for the all segments, whether in or out of PATC's mapping area? I am confident most of us understand USGS sheet names are unique and cover, at our lat/long, a pretty standard area too small for this application (our old AT maps, in the 80's and some today, did index the USGS 7.5's to the sheet) but they are still familiar to a wide audience and a standard reference in their own right. To simplify queries, a hierarchical place name approach permits the returns in your example, plus supports returns for all other collective/additive results likely omitted by your example. A section number becomes a place name on a linear feature. In addition to supporting a spatial query, which is probably beyond the ability of most consumer software anyway. My thought was limited to a simple common reference for AT and other well known segments not covered by existing PATC mapping and/or situated in multiple jurisdictions and legal divisions. With the extent of data collection and validation unknown at time of collection, as well as the existence of multiple ad lib collections, even the numerous, established and published Guidebook section numbers may require further subdivision to support useful query results. Assignment of unique identifiers associated to common aliases is an undiscussed option here as well. I will review the thread as I think we are really discussing different issues for which I apologize if so. You present a methodology that works well in PATC mapped areas. I propose an approach for the rest of the AT leaving your subset of PATC mapped trails and side trails untouched, if desired and ask if it makes sense for application wide use. The Guidebook section reference proposed may be supplanted by AT map reference scheme if desired, but a common and useful reference used by many will be marginalized. What ever you decide to do, it is still the fun of useful metadata.

[D. Tundra]

Steve,

 

I agree with you.  Let me clarify what I meant by grouping.  I meant it as a subdirectory in the database directory or as a subcategory on the web site.  Each of the traces should have as much tags or metadata as possible, including trail names, peaks, segments of the AT that the trace covers, etc., etc.  I think that's what you were referring to.  Then if a person wants to go specifically to the Bolivar Heights in my example, he can search for that in the tag search of the whole database.  If he wants to see all hikes in the Harpers Ferry area (assuming it wasn't part of the PATC maps), he would just look for West Virginia and whatever County Harpers Ferry is at, or would go to section associated with map 5-6 as it is right now.  Not all the tags will be associated with the hike trace (we can't force people to fill huge tag lists all the time), but at least the general geographical location will be clear.

 

By the way, Topo! State Series (such as Mid-Atlantic or Pennsylvania -New Jersey)  that I mentioned before allows you to search for a geographic or historic name (it's called Gazetteer).

[Richard & Sybille Stromberg]

The sites I mentioned before all provide an "index" map, so you can choose hikes wherever you want:

 

- Hiking Arizona http://hikearizona.com/dex2/index.php 

- Backpacker Magazine http://www.backpacker.com/destinations/ 

- MidAtlanticHikes.com  http://midatlantichikes.com/buckhollow.htm

 

Richard Stromberg

[Mrzac...@aol.com]

These index maps are a nice graphic approach to obtaining the linear data that meets the purpose at hand. Headaches seem to begin in the less-frequently-used-by-consumers realm of selection by attribute. The relief for nearly all of this, I think, is that as others succinctly previous mentioned, perhaps in another sting, essentially "just give me the tracks". Although a challenge and or more work for techies, if the coordinates and time stamps are good, many, maybe most, perhaps even all other attributes may be determined and assigned administratively - that is through non field effort.

Steve

[Chris Mangold]

Some input on the database design/approach:


2)  Who's and what data do we want to allow to the database?

CSM >> Right now I have been trying to work with the team to establish a set of criteria for collecting data so we have a base line that all volunteers can follow.   As you state we are just starting out and we have people with various degrees of experience.  As data comes in and we load it into the ESRI software we are going to have a validation process where team members will validate acquired data with imagery.

We have a lot of very motivated volunteers and I don’t think we are going to have problems getting current data with the collection parameters we have established.  

3.) What are the objectives of this database?

CSM>>  One of the major goals of the GIS database we are building is very much for the purposes of the club’s cartographers to have recently collected and validated trail segment data so they can produce the club's maps.  Another major goal of this project is to establish criteria for PATC’s GIS database to insure its integrity and reputation.  Most GIS clearinghouses have standards to allow for seamless integration into established systems and analysis tools. Currently we are not focusing on producing a Website where anyone can upload random data that was not collected to some standard.
What we are first trying to do is establish a reliable process to collect and store data for trails that the club is responsible for maintaining and presenting in the club’s maps.  There has been a lot of discussion about making the data available to the public i.e. GPX, KML formats, web services via ESRI or Open Source Mapping Servers but this is a task we have purposely not addressed as yet, since we are first focusing on ironing out the data collection and validation processes.  Down the line we want to make our data widely available and envision Web based applications that will allow users (inside and outside PATC) to accomplish such tasks such as network analysis and route finding, asset management, trail management (maintenance), emergency management, etc.

Thom’s project overview document initial presentation at the Sept 25th meeting is an  excellent resource for reviewing the goals of project at hand.

4.)  How would I group this database?

CSM>> The GIS database model we are implementing is based on the Federal Trail Data Standards (FTDS) initiative. We want to be standards base so we can share data with many of the organizations that PATC already works with: NPS, Forest Service and state agencies. The Appalachian Trail GIS database is also in line with FTDS.  I am using the trail ids and segment breakdowns that the club has developed because it is the nomenclature that the club’s staff and volunteers are familiar with. 
The GPX files that are submitted can contain multiple tracks or contiguous tracks.  The burden should not be on the submitter to break up the tracks into segments.  We can break the submitted tracks using the ESRI software packages and then assign the proper trail segment ids.  I am asking that when GPX files our submitted that the submitter supplies the minimal information (attribution/metadata) so we can tie the data to the PATC trails organization structure.
The trail segments cataloged in the main GIS feature classes can be augmented by secondary tables that can organize the trail segments anyway we want: state, county or by PATC  Map.   The power of the ESRI software is that we can populate these secondary tables using ESRI Geo-processing functionality.


10) I wouldn't restrict the database to the PATC maintenance region.
CSM>> I certainly think we can have this as a long term goal.  Right now I am trying to stay focused on the PATC Maintained trails to start with.   In fact if someone is interested in taking this on as a project I would be happy to share the FTDS based feature classes I have created as well as the supporting Geo-processing scripts.

Chris