GPX Developers Mailing List and GPSXML Archive

GPX is an open standard, and anyone is welcome to participate in its development and evolution. Click to join the current GPX Developers Mailing List. If you will be exporting or outputting GPX data from your software, hardware, or website, you are *strongly encouraged* to join the mailing list, share samples of your validated GPX output, and ensure that your design follows best practices and will be compatible with all other GPX implementations.

From 2001 until 2019, the GPX Developers mailing list was hosted at the now-defunct Yahoo Groups. An archive of those early discussions and GPX design decisions is hosted below. (Click a subject line or scroll down for full text of all archived messages)

Representation of time in track logs
Re: [gpsxml] Representation of time in track logs
Re: Representation of time in track logs
Re: [gpsxml] Re: Representation of time in track logs
Optimizing the XML format
XML Format: The Basics
RE: [gpsxml] Optimizing the XML format
Re: Optimizing the XML format: Track Logs
Re: [gpsxml] Re: Optimizing the XML format: Track Logs
Re: Optimizing the XML format: Track Logs
Re: [gpsxml] Re: Optimizing the XML format: Track Logs
Re: Optimizing the XML format: Track Logs
Newbie question - format definition
Re: [gpsxml] Newbie question - format definition
Re: [gpsxml] Re: Optimizing the XML format: Track Logs
Re: [gpsxml] Optimizing the XML format: Track Logs
Re[2]: [gpsxml] Optimizing the XML format: Track Logs
Source field in waypoint
<point> definition
Re[2]: [gpsxml] <point> definition
Re: <point> definition
Re: <point> definition
Re: <point> definition
Re: [gpsxml] Re: <point> definition
Re: [gpsxml] Re: <point> definition
Re: [gpsxml] Re: <point> definition
<point> types debate
<point> types list
Re: [gpsxml] Source field in waypoint
Re: [gpsxml] Optimizing the XML format: Track Logs
Re: <point> types list
Re: [gpsxml] <point> definition
Re[2]: [gpsxml] <point> vs. <wpt>, <rtept>, etc.
Re: <point> vs. <wpt>, <rtept>, etc.
Re: [gpsxml] Re: <point> vs. <wpt>, <rtept>, etc.
XML examples - <wpt>
XML examples - <rte>
XML examples - <trk>
Re: XML examples - <trk>
Re: [gpsxml] Re: XML examples - <trk>
Things we can agree on?
Still being discussed...
Re: Things we can agree on?
Re[2]: [gpsxml] Things we can agree on?
Re[2]: [gpsxml] Still being discussed...
Re: [gpsxml] Re: Things we can agree on?
Tags we can agree on?
Re: Things we can agree on?
GPX Sample File: Hike.gpx
Re: GPX Sample File: Hike.gpx
Timestamp format?
Re[2]: [gpsxml] Timestamp format?
Re[2]: [gpsxml] GPX Sample File: Hike.gpx
point src and accuracy
Re: GPX Sample File: Hike.gpx
RE: [gpsxml] Re: GPX Sample File: Hike.gpx
XML Schema. The new new thing.
Trail mapping program demonstration of gpx format
Re: [gpsxml] Trail mapping program demonstration of gpx format
Re: My samples
GPX overview and marketing page
Re[2]: [gpsxml] Re: My samples
creator vs src
2 UTC or not to UTC
Re: GPX Sample File: Hike.gpx
New file uploaded to gpsxml
Schema - first go
Re: [gpsxml] Schema - first go
RE: [gpsxml] Schema - first go
Re: Schema - first go
Trail/Road type and usage tags
TopoGrafix apps now support GPX
Re: TopoGrafix apps now support GPX
RE: [gpsxml] Re: TopoGrafix apps now support GPX
RE: [gpsxml] TopoGrafix apps now support GPX
Re: [gpsxml] Re: TopoGrafix apps now support GPX
Re: TopoGrafix apps now support GPX
Re: TopoGrafix apps now support GPX
Drawing the line
Revised versions of EasyGPS and ExpertGPS for GPX
Schema Rel Candidate 1.0
New file uploaded to gpsxml
RE: [gpsxml] Schema Rel Candidate 1.0
sequences: please comment
New file uploaded to gpsxml
New file uploaded to gpsxml
Re: Schema Rel Candidate 1.0
Re: sequences: please comment
Re: [gpsxml] sequences: please comment
Re: Drawing the line
Re: Revised versions of EasyGPS and ExpertGPS for GPX
Re: Schema Rel Candidate 1.0
newbie
Re: newbie
Re: newbie
[gpsxml] Re: GPX Symbol Names
Mac GPS Pro
Wrapping up GPX 1.0 Specification
Are Schemas required in GPX?
Re: Are Schemas required in GPX?
Re: [gpsxml] Are Schemas required in GPX?
Re: Are Schemas required in GPX?
TopoGrafix software for GPX 0.4
GPX Overview Documentation
Re: Regarding the XML schema
Re: [gpsxml] Regarding the XML schema
Re: Regarding the XML schema
Re: [gpsxml] there is a problem...
Handheld limitations...
Re: [gpsxml] there is a problem...
GPX Schema 0.5 candidate
Re[2]: [gpsxml] GPX Schema 0.5 candidate
Structure, future elements in GPX
Re: [gpsxml] Structure, future elements in GPX
Re: Structure, future elements in GPX
gpsxml samples
Re: [gpsxml] gpsxml samples
Re[2]: [gpsxml] Structure, future elements in GPX
GPSml first public version posted.
GPSml corrected URL.
Re: gpsxml samples
Re: GPSml comments.....
A minor point....
Re: GPSml and GPX
Finishing up GPX 1.0
Re[2]: [gpsxml] Finishing up GPX 1.0
Re[3]: [gpsxml] Finishing up GPX 1.0
Re[3]: [gpsxml] Finishing up GPX 1.0
Real-time positioning in XML
Re: Finishing up GPX 1.0
Re: [gpsxml] Re: Finishing up GPX 1.0
Re: Finishing up GPX 1.0
[gpsxml] Re: Finishing up GPX 1.0
This is really cool
Re: [gpsxml] Real-time positioning in XML
Re: [gpsxml] This is really cool
GPX 0.6 schema
Information needed
Re: GPX 0.6 schema
Re: [gpsxml] Re: GPX 0.6 schema
Re: [gpsxml] GPX vs GPSml
[gpsxml] Streaming real time GPS data....discussion....
Top level data....
Curious about parsing....
Re: [gpsxml] Curious about parsing....
Re: Sequence numbers
Re: [gpsxml] Digest Number 55
RE: [gpsxml] Re: Sequence numbers
Re[2]: [gpsxml] Re: Sequence numbers
Routes and Routepoints
Re: [gpsxml] Real-time positioning in XML
Re: [gpsxml] Routes and Routepoints
documentation?
Re: Ver 0.6
GPS XML Contents to XHTML Transformation Demo
Re: [gpsxml] What are we waiting for?
Re: [gpsxml] What are we waiting for?
Re: What are we waiting for?
Intro
GPX 1.0
Re: [gpsxml] GPX 1.0
Re: GPX 1.0
Re: GPX 1.0
Re: [gpsxml] Re: GPX 1.0
Re: [gpsxml] GPX V1.0
Re: GPX V1.0
Possible issue with 1.0?
Re: [gpsxml] Possible issue with 1.0?
Re: Possible issue with 1.0?
GPX 1.0 Is Officially Complete!
validating gpx files
Re: [gpsxml] validating gpx files
Working with Stylesheets (Explorer 5.5 Incompatible)
Introduction
Waypoint Naming Convention
Re: Waypoint Naming Convention
Re: [gpsxml] Re: Waypoint Naming Convention
Re: Waypoint Naming Convention
Java API for using XML Schema?
Re: [gpsxml] Java API for using XML Schema?
Re: Waypoint Naming Convention
GPX considerations for publishers
[Ann] Mobile GPS Demonstration Platform project description posted....
Re: [gpsxml] GPX considerations for publishers
GPX "Publish to Web" feature in TopoGrafix software
Wissenbach Map announced on map_authors
XML Editor(?)
Re: XML Editor(?)
Re: Editing XML...
gps europe
GPX 1.0 questions: time format, etc.
Re: [gpsxml] GPX 1.0 questions: time format, etc.
Re: GPX 1.0 questions: time format, etc.
Re: GPX 1.0 questions: time format, etc.
Re: GPX 1.0 questions: time format, etc.
Re: Java API for using XML Schema?
Re: GPX 1.0 questions: time format, etc.
Including app specific data in <gpx>
Re: Including app specific data in <gpx>
Using GPX in USAPhotoMaps
Re: [gpsxml] Using GPX in USAPhotoMaps
More GPX publishing examples
Re: More GPX publishing examples
Re: [gpsxml] More GPX publishing examples
Re: Using GPX in USAPhotoMaps
Wordwrap after 58 characters
Re[2]: [gpsxml] More GPX publishing examples
Re: [gpsxml] Re: Using GPX in USAPhotoMaps
Re: Using GPX in USAPhotoMaps
Re: Re[2]: [gpsxml] More GPX publishing examples
Re: XML Editor(?) - XMLSpy comments
GPX ate my CD!
Re: [gpsxml] GPX ate my CD!
GPX drag/drop and cut/copy/paste
XML Waypoints for USAPhotoMaps
Preview of 3D Viewer For GPX Files
MapPoint & .gpx
RE: [gpsxml] MapPoint & .gpx
Re: [gpsxml] MapPoint & .gpx
Re: [gpsxml] MapPoint & .gpx
RE: [gpsxml] MapPoint & .gpx
Re: [gpsxml] MapPoint & .gpx
Re: [gpsxml] MapPoint & .gpx
Re: MapPoint & .gpx
RE: [gpsxml] Re: MapPoint & .gpx
Re: MapPoint & .gpx
Re: Sequence numbers
Re: MapPoint & .gpx
Re: Sequence numbers
.xsl demonstrating extracting track waypoints
Re: [gpsxml] .xsl demonstrating extracting track waypoints
Re: .xsl demonstrating extracting track waypoints
Re: [gpsxml] Re: MapPoint & .gpx
[ANN] pyGPX - python GPX library
Open Source C++ XML interface??
Re: [gpsxml] Open Source C++ XML interface??
Most famous site about GPS
Site about GPS from Brasil
ANN: a GPX reader/writer.
Re: ANN: a GPX reader/writer.
Re: [gpsxml] Re: ANN: a GPX reader/writer.
Re: [gpsxml] Re: ANN: a GPX reader/writer.
Re: [gpsxml] Re: ANN: a GPX reader/writer.
Re: [gpsxml] Re: ANN: a GPX reader/writer.
GPS Utility now imports/exports GPX files
Topo! file format
Documenting file formats
Re: [gpsxml] Documenting file formats
Re[2]: [gpsxml] Documenting file formats
Re: ANN: a GPX reader/writer.
New Garmin Rino GPS yahoo group!
Looking for guidance on how to incorporate extensions to GPX
Re: [gpsxml] Looking for guidance on how to incorporate extensions to GPX
EasyGPS xml to G7toWIN csv parser
Describing datum
Re: [gpsxml] Describing datum
SVG anyone? anyone SVG?
Re: [gpsxml] SVG anyone? anyone SVG?
Re: Describing datum
Re: SVG anyone? anyone SVG?
Re: SVG anyone? anyone SVG?
Decimal point as comma in coords?
Re: [gpsxml] Decimal point as comma in coords?
Map calibration (georeferencing images) in GPX
Re: Map calibration (georeferencing images) in GPX
Re: Map calibration (georeferencing images) in GPX
Extending the public definition of GPX
Re[2]: [gpsxml] Extending the public definition of GPX
Re: Extending the public definition of GPX
invisble trkseg tags?
Re: [gpsxml] invisble trkseg tags?, new GPX applications?
Add <type> element to <rte> and <trk>?
Re: [gpsxml] Add <type> element to <rte> and <trk>?
Sourceforge vs. Yahoo Groups
Re: [gpsxml] Add <type> element to <rte> and <trk>?
Re: [gpsxml] Sourceforge vs. Yahoo Groups
Re: Add <type> element to <rte> and <trk>?
enumerated types
RE: [gpsxml] enumerated types
Re: enumerated types
Re: [gpsxml] enumerated types
<region>
Change the GPX version number?
Re: [gpsxml] Change the GPX version number?
Re[2]: [gpsxml] Change the GPX version number?
Re: Re[2]: [gpsxml] Change the GPX version number?
Re: Re[2]: [gpsxml] Change the GPX version number?
Re: [gpsxml] Re: Add <type> element to <rte> and <trk>?
RE: [gpsxml] Re: Add <type> element to <rte> and <trk>?
RE: [gpsxml] Sourceforge vs. Yahoo Groups
RE: [gpsxml] Re: Add <type> element to <rte> and <trk>?
Re: <region>
Re: [gpsxml] Re: <region>
Public Namespaces
RE: [gpsxml] Re: <region>
RE: [gpsxml] Re: Add <type> element to <rte> and <trk>?
RE: [gpsxml] Re: Add <type> element to <rte> and <trk>?
Re: <region>
Re: Public Namespaces
Re: [gpsxml] Re: <region>
differences between <trk> and <rte>
Namespace, Tag and Metadata discussion
Re: [gpsxml] Re: <region>
Re: [gpsxml] Re: <region>
Redundancy of Rte and Trk?
Groups of waypoints
Re: [gpsxml] Groups of waypoints
TopoFusion, Call for GPS data (GPX format)
Importing Waypoint Cooridinates from formatted text files
Sample SVG with UTM Coordinates
Re: source code (C++, Qt)
SVG Sample
Re: SVG Sample
Re: SVG Sample (and CSS rules for type)
GML - Geography Markup Language
Validation error
GPX to OziExplorer
Re: Validation error
Re: [gpsxml] GPX to OziExplorer
Re: [gpsxml] GPX to OziExplorer
Re: [gpsxml] Validation error
Re: [gpsxml] GPX to OziExplorer
Re: GPX to OziExplorer
Validated file doesn't open
Re: [gpsxml] Validated file doesn't open
Re: Validated file doesn't open
Re: [gpsxml] Re: Validated file doesn't open
Re: Validated file doesn't open
Prelaunch Intro of GPXchange.com
GPX pages still lack richness(?)
Driving Directions and Expertgps
Re: [gpsxml] Driving Directions and Expertgps
NNEA to GML
The Commercialization of Exchanging GPS Data
Perl tools?
Re: [[gpsxml] Perl tools?]
Extra information
Re: [gpsxml] Extra information
Re: [gpsxml] Extra information
Re: [gpsxml] Extra information
Re: [gpsxml] Extra information
Re: [Re: [gpsxml] Extra information]
Nearly ready
Re: [gpsxml] Nearly ready
Re: [gpsxml] Nearly ready
Re: [gpsxml] Nearly ready
RE: [gpsxml] Nearly ready
Re: [gpsxml] Nearly ready
RE: [gpsxml] Nearly ready
RE: [gpsxml] Nearly ready
Re: [gpsxml] Nearly ready
RE: [gpsxml] Nearly ready
Hello
New file uploaded to gpsxml
New file uploaded to gpsxml
New file uploaded to gpsxml
Generatin of GPX from ColdFusion
(Mostly) working GPX download available at TrailRegistry.com
Re: [gpsxml] (Mostly) working GPX download available at TrailRegistry.com
Re: [gpsxml] (Mostly) working GPX download available at TrailRegistry.com
Extensions for route/track color, line width or map calibration
Re: [gpsxml] Extensions for route/track color, line width or map calibration
RE: [gpsxml] Extensions for route/track color, line width or map calibration
RE: [gpsxml] Extensions for route/track color, line width or map calibration
RE: [gpsxml] Extensions for route/track color, line width or map calibration
Re: Extensions for route/track color, line width or map calibration
[gpsxml] Re: Extensions for route/track color, line width, fonts
Re[2]: [gpsxml] Extensions for map calibration
RE: Re[2]: [gpsxml] Extensions for map calibration
MrGIS.com: AVL, GIS, GPS and GeoCaching discussion forums
RE: Re[2]: [gpsxml] Extensions for map calibration
RE: Re[2]: [gpsxml] Extensions for map calibration
RE: Re[2]: [gpsxml] Extensions for map calibration
Re: Re[2]: [gpsxml] Extensions for map calibration
RE: Re[2]: [gpsxml] Extensions for map calibration
RE: Re[2]: [gpsxml] Extensions for map calibration
RE: Re[2]: [gpsxml] Extensions for map calibration
RE: Re[2]: [gpsxml] Extensions for map calibration
Re: Extensions for route/track color, line width, fonts
Newbie
Re: [gpsxml] Newbie
Dan -- Re: Newbie
Dan -- Re: Newbie
Re: [gpsxml] Dan -- Re: Newbie
Dan -- Re: Newbie
Matt -- multiple URLs per WPT
Multiple URLs in GPX
Public namespace extensions
RE: [gpsxml] Public namespace extensions
Re: Multiple URLs in GPX
private elements
Re: private elements
Re: private elements
GPX-interface in GeoConv
Re: Describing datum
Re: [gpsxml] Re: Describing datum
Re: Describing datum
Re: [gpsxml] Re: geoidheight
Re: geoidheight
Kind attn: Openings in Java/XML for Pune
Re: ANN: a GPX reader/writer.
Re: ANN: a GPX reader/writer.
Re: [gpsxml] Re: ANN: a GPX reader/writer.
In case you're interested
Looking for Java/Interstage server professionals for Pune
Support for Polygon features
Looking for Freshers with good Java/XML background
Re: [gpsxml] Support for Polygon features
RE: [gpsxml] Support for Polygon features
Proposed schemas for specifying colors, fonts, and sizes for text and polygons on maps
Re: Proposed schemas for specifying colors, fonts, and sizes for text and polygons on maps
Looking for Java Professionals for Singapore
Re: [gpsxml] Proposed schemas for specifying colors, fonts, and sizes for text and polygons on maps
Re: Proposed schemas for specifying colors, fonts, and sizes for text and polygons on maps
Looking for Java/Perl professionals for India's top IT Co. for Bangalore
MrGIS.com: AVL, E911, GIS, and GPS discussion forums
Re: [gpsxml] MrGIS.com: AVL, E911, GIS, and GPS discussion forums
TrailRegistry now supports GPX uploads!
GPX and .NET?
Re: GPX and .NET?
GPX in HTML page
Re: [gpsxml] GPX in HTML page
Re: [gpsxml] GPX in HTML page
A change for the better?!
Lat/Lon Meta tags for web pages?
Re: [gpsxml] Lat/Lon Meta tags for web pages?
Re: [gpsxml] Lat/Lon Meta tags for web pages?
RE: [gpsxml] Re: GPX and .NET?
Re: [gpsxml] Re: GPX and .NET?
Re[2]: [gpsxml] Re: GPX and .NET?
New file uploaded to gpsxml
RE: [gpsxml] Re: GPX and .NET?
RE: [gpsxml] Re: GPX and .NET?
Cool site
For members, a site for reviewing dating sites
New file uploaded to gpsxml
Developer Tool?
Re: Developer Tool?
Re: [gpsxml] Developer Tool?
Re: [gpsxml] Developer Tool?
Re: [gpsxml] Developer Tool?
Re: GPX in HTML page
Street Address in GPX
Re: [gpsxml] Street Address in GPX
Re: [gpsxml] Street Address in GPX
Re: Street Address in GPX
programming language for XML?
Re: [gpsxml] programming language for XML?
Re: [gpsxml] Re: Street Address in GPX
Re: [gpsxml] Sample files don't validate
Re: GPX and .NET?
GPX namespace
National Geographic TOPO mac (CSV export 2 GPX) ?
RE: [gpsxml] National Geographic TOPO mac (CSV export 2 GPX) ?
RE: [gpsxml] National Geographic TOPO mac (CSV export 2 GPX) ?
Re: [gpsxml] National Geographic TOPO mac (CSV export 2 GPX) ?
Re[2]: [gpsxml] National Geographic TOPO mac (CSV export 2 GPX) ?
Re: National Geographic TOPO mac (CSV export 2 GPX) ?
Re: National Geographic TOPO mac (CSV export 2 GPX) ?
Re: [gpsxml] Re: National Geographic TOPO mac (CSV export 2 GPX) ?
Re: National Geographic TOPO mac (CSV export 2 GPX) ?
Fwd: TOPO! Interactive Maps
Site about GPS
Need clarification on gpx_style element
Re: [gpsxml] Need clarification on gpx_style element
Re: Need clarification on gpx_style element
Experiences with GPX version 1.0
Re: [gpsxml] Experiences with GPX version 1.0
Re: [gpsxml] Experiences with GPX version 1.0
Re[2]: [gpsxml] Experiences with GPX version 1.0
Copy/Paste GPX to clipboard in Windows programs
Re: Copy/Paste GPX to clipboard in Windows programs
Re: [gpsxml] Re: Copy/Paste GPX to clipboard in Windows programs
GPX corporate people. Can anyone help me out


RE: [gpsxml] (unknown)

Sample program
Re: [gpsxml] (unknown)
Looking For a Job?????
An Amazing Opportunity For All Part-Time Job Seekers!!!!
HURRY, GET FREE INFORMATION NOW... !!!!!
schema addition
Re: schema addition
Past discussion of <copyright> or <license> tags
Re: [gpsxml] Re: schema addition
RE: [gpsxml] Re: schema addition
Re[2]: [gpsxml] Re: schema addition
Re: [gpsxml] Re: schema addition
Re[2]: [gpsxml] Re: schema addition
Looking for contractor to help develop new application
RE: Re[2]: [gpsxml] Re: schema addition
Two additional GPX changes - email and url tags
copyright - GPX schema addition
Re: Two additional GPX changes - email and url tags
Re: copyright - GPX schema addition
RE: [gpsxml] Re: copyright - GPX schema addition
Re: [gpsxml] Re: Two additional GPX changes - email and url tags
REQUIREMENT FOR OUR INTERNET BASED COMPANY (DELHI) INDIA...Now Earn In FIVE FIG!
Maps On Us turn-by-turn to GPS
Maps On Us turn-by-turn to GPS
Re: [gpsxml] Maps On Us turn-by-turn to GPS
Re: [gpsxml] Digest Number 224
Relative vs Absolute URLs
Re: Relative vs Absolute URLs
Re: [gpsxml] Relative vs Absolute URLs
Status of GPX
Re: [gpsxml] Status of GPX
Re: Status of GPX
Re: [gpsxml] Re: Status of GPX
Re: Status of GPX
Street Address to GPX?
Re: [gpsxml] Street Address to GPX?
RE: [gpsxml] Street Address to GPX?
Re: [gpsxml] Street Address to GPX?
Re: Street Address to GPX?
my bills are gone!
Important Info for gpsxml Members
tab file to shape file
Important News for gpsxml Members

Wanted Perl resources for our Pune office
Re: Status of GPX
Looking for Perl resources with 6months to 1yr exp for Pune
Re: [gpsxml] Re: Status of GPX
GPX 1.1 metadata sample file
Re: [gpsxml] GPX 1.1 metadata sample file
Re[2]: [gpsxml] GPX 1.1 metadata sample file
Re: Re[2]: [gpsxml] GPX 1.1 metadata sample file
REQUIREMENT FOR PROJECT MANAGERS
GPS The Movie
RE: [gpsxml] GPS The Movie
RE: [gpsxml] GPS The Movie
RE: [gpsxml] GPS The Movie
Re[2]: [gpsxml] GPS The Movie
GPX formatting in .NET Web Service
Accuray 1A 2C
Important Information for gpsxml Members
Namespace (Version 1.0 & 1.1)
Re: [gpsxml] Namespace (Version 1.0 & 1.1)
Re: Namespace (Version 1.0 & 1.1)
Wissenbach Map3D 2.27 supports GPX1.1 Format
GPX 1.1 documentation
Re: GPX 1.1 documentation
Re: GPX 1.1 documentation
Re: GPX 1.1 documentation (corrected stylesheet P.I.)
GPX 1.1 schema released!
Changes From 1.0 ?
Re: [gpsxml] Changes From 1.0 ?
Re: [gpsxml] Changes From 1.0 ?
GPX to PostGIS
Re: Street Address to GPX?
Re: [gpsxml] GPX to PostGIS
Re: [gpsxml] GPX to PostGIS
Re: [gpsxml] GPX to PostGIS
important
Hi
Re: [gpsxml] Hi
Re: [gpsxml] Hi
Re: [gpsxml] Hi
Re: [gpsxml] Hi
Re[2]: [gpsxml] Hi
GPX Search Engine (was: Hi )
gpx format not valid??
Re: [gpsxml] gpx format not valid??
gpx file format
Re: gpx format not valid??
course and speed in <trkpt>, GPX 1.1 omission
Re: [gpsxml] Re: gpx format not valid??
Re: course and speed in <trkpt>, GPX 1.1 omission
Re: gpx format not valid??
Re: gpx format not valid??
Re: course and speed in <trkpt>, GPX 1.1 omission
Help this XML newbie
RE: [gpsxml] Help this XML newbie
Re: [gpsxml] Help this XML newbie
RE: [gpsxml] Help this XML newbie
Re: [gpsxml] Help this XML newbie
Re: Help this XML newbie
Re: [gpsxml] Help this XML newbie
gpsxml Members
Re: Help this XML newbie
Re: [gpsxml] Re: Help this XML newbie
Re: Help this XML newbie
Re: Help this XML newbie
Please help?
Ooops, forgot.
Re: [gpsxml] Please help?
Re: [gpsxml] Please help?
Re: [gpsxml] Please help?
Getting elevation data for GPX files without
Re: [gpsxml] Getting elevation data for GPX files without
Re: Getting elevation data for GPX files without
Re: Getting elevation data for GPX files without
Re: Getting elevation data for GPX files without
magvar?
Should all complexTypes have <extensions>?
Re: [gpsxml] Should all complexTypes have <extensions>?
Re[2]: [gpsxml] Should all complexTypes have <extensions>?
RE: Re[2]: [gpsxml] Should all complexTypes have <extensions>?
Re[4]: [gpsxml] Should all complexTypes have <extensions>?
GLOBAL LEADING CO REQURIED STRUTS,EJB,XML,UML PROFESSIONALS @ B'LORE.
Re: Getting elevation data for GPX files without
Verify this for me?
DO YOU STILL WANT A CHEAPER CALLING CARD?
Re: Hi
Re: <keywords>
RE: [gpsxml] Re: <keywords>
Smart reader for Mac
Re: encoding real-time position
Newbie question: decimal precision
Re: [gpsxml] Newbie question: decimal precision
Re: Newbie question: decimal precision
Re: [gpsxml] Newbie question: decimal precision
Re: [gpsxml] Another newbie question: tracks vs. routes
Re: [gpsxml] Another newbie question: tracks vs. routes
Real time encoding with GPX
mortgage too high to bear?
Re: Smart reader for Mac
Purpose of comments...
Re: [gpsxml] Re: Smart reader for Mac
Re: Smart reader for Mac
Re: [gpsxml] Re: Smart reader for Mac
Re: Purpose of comments...
Symbol Coding
Re: [gpsxml] Symbol Coding
Re: [gpsxml] Symbol Coding
Important Letter for gpsxml Members
mortgage too high to bear?
Important Letter for gpsxml Members
WOW! WHAT AN EXCELLANT SITE!WHY DID NOT TELL ME EARLIER DEAR
GET FREE CALLING CARDS AND MAKE LOCAL AND INTERNATIONAL
i did refinance for much less
Hey friends we do not know till now
FEEL FREE TO VISIT AND GET FREE CALLINGCARDS AS BONUS.
Creating a GPX XML File
Re: [gpsxml] Creating a GPX XML File
Track Point Structure
Hai Friends,this is MONIKA,
Re[2]: [gpsxml] Track Point Structure
RE: [gpsxml] Track Point Structure
RE: [gpsxml] Track Point Structure
Re: Track Point Structure
RE: [gpsxml] Re: Track Point Structure
Re[2]: [gpsxml] Re: Track Point Structure
RE: Re[2]: [gpsxml] Re: Track Point Structure
How do you escape double quotes?
Re: [gpsxml] How do you escape double quotes?
Re: Re[2]: [gpsxml] Re: Track Point Structure
Line Type Styles for Tracks
Re: [gpsxml] Line Type Styles for Tracks
Re: Line Type Styles for Tracks
Re: [gpsxml] Re: Line Type Styles for Tracks
Re: Track Point Structure
RE: [gpsxml] Re: Track Point Structure
RE: Re[2]: [gpsxml] Re: Track Point Structure
Course, speed, and all the other GPX changes
Re: [gpsxml] Course, speed, and all the other GPX changes
RE: [gpsxml] Course, speed, and all the other GPX changes
Re: [gpsxml] Course, speed, and all the other GPX changes
Re[2]: [gpsxml] Course, speed, and all the other GPX changes
Re: Hi
Re: [gpsxml] Re: Hi
Re: Hi
Re: Line Type Styles for Tracks
GPX support in MapSource 6.5 Beta
waypoints vs trackpoints
Re: GPX Search engine
Re: [gpsxml] waypoints vs trackpoints
Font sizes and line widths - units?
Re: Font sizes and line widths - units?
Re: GPX support in MapSource 6.5 Beta
Re: GPX Search engine
Mapping an entire area
Re: Font sizes and line widths - units?
RE: [gpsxml] Re: Font sizes and line widths - units?
Re: Font sizes and line widths - units?
Re[2]: [gpsxml] Re: Font sizes and line widths - units?
Re: [gpsxml] Mapping an entire area
Re: [gpsxml] Re: Font sizes and line widths - units?
Re: [gpsxml] Digest Number 299
Re: Font sizes and line widths - units?
Re: Mapping an entire area
Re: Font sizes and line widths - units?
schemaLocation required?
Re: schemaLocation required?
Re: GPX Search engine
Re: [gpsxml] schemaLocation required?
Re: schemaLocation required?
Re: schemaLocation required?
Fwd: GPX Translations
Re: Font sizes and line widths - units?
Re: schemaLocation required?
Re: schemaLocation required?
Re: schemaLocation required?
Re: [gpsxml] schemaLocation required? - current requirement?
Re: [gpsxml] schemaLocation required? - current requirement?
Re: schemaLocation required? - current requirement?
I am trying this from past 3 months and getting free calling cards
Representing shapes, lines, and text notes that aren't destined for the GPS
Re: [gpsxml] Representing shapes, lines, and text notes that aren't destined for the GPS
Re[2]: [gpsxml] Representing shapes, lines, and text notes that aren't destined for the GPS
Re[2]: [gpsxml] Representing shapes, lines, and text notes that aren't destined for the GPS
Re: [gpsxml] Representing shapes, lines, and text notes that aren't destined for the GPS
Re[2]: [gpsxml] Representing shapes, lines, and text notes that aren't destined for the GPS
Re: [gpsxml] Representing shapes, lines, and text notes that aren't destined for the GPS
GPX 2.0
Re: GPX 2.0
Re: [gpsxml] Re: GPX 2.0
Re: GPX 2.0
Confusion over the term "GPX"?
Re: Confusion over the term "GPX"?
Re: GPX 2.0
Re: GPX 2.0
Re: [gpsxml] Re: Confusion over the term "GPX"?
Re: [gpsxml] Re: GPX 2.0
GPS Receiver Data and Map Data Exchange
Re[2]: [gpsxml] Re: Confusion over the term "GPX"?
Re: Re[2]: [gpsxml] Re: Confusion over the term "GPX"?
Re: Representing shapes, lines, and text notes that aren't destined for the GPS
Re: Representing shapes, lines, and text notes that aren't destined for the GPS
Re: Representing shapes, lines, and text notes that aren't destined for the GPS
Re: GPX 2.0
[gpsxml]Data Presentation Determined By?
Re: [gpsxml]Data Presentation Determined By?
RE: [gpsxml]Data Presentation Determined By?
Re: "Map Styling" Modeling Language?
Re: [gpsxml] "Map Styling" Modeling Language?
Re: [gpsxml]Data Presentation Determined By?
Proximity Alarms
Iam enjoying this for the past 3 months
Iam enjoying this for the past 3 months
Re: [gpsxml] Proximity Alarms
Re: Proximity Alarms
Re: [gpsxml] "Map Styling" Modeling Language?
Re: [gpsxml]Data Presentation Determined By?
Re: Proximity Alarms
Need help with validation
Re: [gpsxml] Need help with validation
Re: [gpsxml] Re: Proximity Alarms
Re: [gpsxml] Re: Proximity Alarms
Re: Need help with validation
gpx_style extension schema
Re: gpx_style extension schema
Re: [gpsxml] Re: gpx_style extension schema
Re: gpx_style extension schema
The real thing is here
Re: [gpsxml] Re: gpx_style extension schema
Re: gpx_style extension schema
Re: [gpsxml] gpx_style extension schema
gpx_overlay extension schema
Re: gpx_overlay extension schema
Re: gpx_overlay extension schema
Re: gpx_overlay extension schema
Re: [gpsxml] Re: gpx_overlay extension schema
Re: [gpsxml] Re: gpx_overlay extension schema
Re: gpx_overlay extension schema
Re: gpx_overlay extension schema
Re: gpx_overlay extension schema
Re: gpx_overlay extension schema
"WOW!! WHAT A SITE!!! GOOD COLLECTIONS!!! GOOD FREE STUFF
[FYI] sXBL (XML Binding Language)
gpx_overlay (want label displacement in millimeters)
Why does gpx_style:text also have align and vertical-align?
Re: [gpsxml] Why does gpx_style:text also have align and vertical-align?
gpx_overlay - a better way to offset labels?
Re: gpx_overlay - a better way to offset labels?
Re: [gpsxml] Re: gpx_overlay - a better way to offset labels?
Label Orientation Example
Re: gpx_overlay - a better way to offset labels?
Magnetic variation
Re: [gpsxml] Magnetic variation
Re: parse track points
Re: elevation
Re: [gpsxml] Re: parse track points
Re: [gpsxml] Magnetic variation
Re: [gpsxml] Re: parse track points
Re: Magnetic variation
Symbols
Aviation Database Waypoint
Re: [gpsxml] Aviation Database Waypoint
Re: [gpsxml] Symbols
Re[2]: [gpsxml] Aviation Database Waypoint
Re: Symbols
Re: Aviation Database Waypoint
Re: [gpsxml] Re: Symbols
Re: Mapping an entire area
Re: Mapping an entire area
ExpertGPS modified files won't open in MapSource
Re: [gpsxml] ExpertGPS modified files won't open in MapSource
Re: ExpertGPS modified files won't open in MapSource
Re: [gpsxml] Re: ExpertGPS modified files won't open in MapSource
Re: [gpsxml] Re: ExpertGPS modified files won't open in MapSource
Re: [gpsxml] Re: ExpertGPS modified files won't open in MapSource
Re: ExpertGPS modified files won't open in MapSource
Re: [gpsxml] Re: ExpertGPS modified files won't open in MapSource
Re: [gpsxml] Re: ExpertGPS modified files won't open in MapSource
GPX 1.1 <extensions> allows broken GPX to validate
GPX Overlay and Style schema updated
Re: ExpertGPS modified files won't open in MapSource
Re: GPX 1.1 <extensions> allows broken GPX to validate
Re: Mapping an entire area
bounding boxes and hemisphere wraps
Re: [gpsxml] bounding boxes and hemisphere wraps
Re: [gpsxml] bounding boxes and hemisphere wraps
Re[2]: [gpsxml] bounding boxes and hemisphere wraps
Re: GPX Overlay and Style schema updated
More problems with GPX 1.1 and multiple namespaces
Re: [gpsxml] More problems with GPX 1.1 and multiple namespaces
Re: [gpsxml] More problems with GPX 1.1 and multiple namespaces
Re: More problems with GPX 1.1 and multiple namespaces
Re: [gpsxml] Re: More problems with GPX 1.1 and multiple namespaces
Re: GPX Overlay and Style schema updated
Re: [gpsxml] Re: GPX Overlay and Style schema updated
Re: More problems with GPX 1.1 and multiple namespaces
Re: [gpsxml] Re: More problems with GPX 1.1 and multiple namespaces
Re: More problems with GPX 1.1 and multiple namespaces
Re: More problems with GPX 1.1 and multiple namespaces
Re: [gpsxml] Re: More problems with GPX 1.1 and multiple namespaces
Re: ExpertGPS modified files won't open in MapSource
Re: [gpsxml] Re: ExpertGPS modified files won't open in MapSource
Re: ExpertGPS modified files won't open in MapSource
Re: [gpsxml] Re: ExpertGPS modified files won't open in MapSource
Re: More problems with GPX 1.1 and multiple namespaces
Re: More problems with GPX 1.1 and multiple namespaces
Re: [gpsxml] Re: More problems with GPX 1.1 and multiple namespaces
Re: More problems with GPX 1.1 and multiple namespaces
Re: [gpsxml] Re: More problems with GPX 1.1 and multiple namespaces
Re: [gpsxml] Re: More problems with GPX 1.1 and multiple namespaces
Re[2]: [gpsxml] Re: More problems with GPX 1.1 and multiple namespaces
Re: More problems with GPX 1.1 and multiple namespaces
Re: More problems with GPX 1.1 and multiple namespaces
Re[2]: [gpsxml] Re: More problems with GPX 1.1 and multiple namespaces
Re: More problems with GPX 1.1 and multiple namespaces
Re: Re[2]: [gpsxml] Aviation Database Waypoint
HELLO FRIEND'S!! THIS IS 4 YOU??
Check this awesome Online Directory
Track Color. How?
Re: [gpsxml] Track Color. How?
GPXchange.com is now available
Comments on gpx_style/0/2 Expert GPS Stow sample
Re: Track Color. How?
Additional Functionality in GPX_Overlay
Re: [gpsxml] Comments on gpx_style/0/2 Expert GPS Stow sample
Re: [gpsxml] Re: Track Color. How?
Re: [gpsxml] Additional Functionality in GPX_Overlay
useful link
DTD or RELAX NG schema for GPX
Re: [gpsxml] DTD or RELAX NG schema for GPX
Re: [gpsxml] DTD or RELAX NG schema for GPX
Re: Additional Functionality in GPX_Overlay
Re: Additional Functionality in GPX_Overlay
Re: [gpsxml] Copy/Paste GPX to clipboard in Windows programs
Spyware Removal
Spyware Removal
Re: Additional Functionality in GPX_Overlay
Re: Additional Functionality in GPX_Overlay
Information
RE: [gpsxml] Copy/Paste GPX to clipboard in Windows programs
Re: [gpsxml] MySQL schema for GPX 1.1
Conversion to GPX
Re: [gpsxml] Conversion to GPX
Re: Conversion to GPX
Garmin MapSource GPX 1.1 extensions
Re: Garmin MapSource GPX 1.1 extensions
Re: [gpsxml] Garmin MapSource GPX 1.1 extensions
Re: Garmin MapSource GPX 1.1 extensions
Re: [gpsxml] Garmin MapSource GPX 1.1 extensions
Re: Garmin MapSource GPX 1.1 extensions
GPX to KML conversion now available at GPXchange.com
LATEST PDA/MOBILE PHONES STOCKS
LATEST PDA/MOBILE PHONES STOCKS
Current News
Tired of Typing conversations? Meet REAL WOMEN in your area!
Hey gpsxml Whats up! I just Saved 500 bucks this month!
Re: Hey gpsxml Whats up! I just Saved 500 bucks this month! just SPAM!
Problem with GPSvisualizer files.
Re: [gpsxml] Problem with GPSvisualizer files.
Re: Problem with GPSvisualizer files.
Re: [gpsxml] Re: Problem with GPSvisualizer files.
course and speed - in or out?
Re: [gpsxml] course and speed - in or out?
Re: [gpsxml] course and speed - in or out?
Re: GPX to KML conversion now available at GPXchange.com
Re: GPX to KML conversion now available at GPXchange.com
Re: GPX to KML conversion now available at GPXchange.com
Re: [gpsxml] Re: GPX to KML conversion now available at GPXchange.com
Re: [gpsxml] course and speed - in or out?
Re: [gpsxml] Re: GPX to KML conversion now available at GPXchange.com
Question...
gps
Information
bug report: typo in GPX Schema 1.1
Re: [gpsxml] XSLT to convert GPX 1.0 to 1.1
RE: [gpsxml] MySQL schema for GPX 1.1
HTML in GPX fields
Re: HTML in GPX fields
Re: [gpsxml] Re: HTML in GPX fields
RE: [gpsxml] Re: HTML in GPX fields
GPX 1.1 compliance issue?
Re: [gpsxml] GPX 1.1 compliance issue?
Re[2]: [gpsxml] GPX 1.1 compliance issue?
Re: [gpsxml] GPX 1.1 compliance issue?
Re: GPX 1.1 compliance issue?
Re: GPX to KML conversion now available at GPXchange.com
Re: GPX to KML conversion now available at GPXchange.com
Re: GPX to KML conversion now available at GPXchange.com
Re: [gpsxml] Re: GPX to KML conversion now available at GPXchange.com
Re: GPX to KML conversion now available at GPXchange.com
Re: [gpsxml] Re: GPX to KML conversion now available at GPXchange.com
Re: [gpsxml] Re: GPX to KML conversion now available at GPXchange.com
Adding GPX to existing C++ project
Re: Adding GPX to existing C++ project
Re: Adding GPX to existing C++ project
Re: Adding GPX to existing C++ project
Re: Adding GPX to existing C++ project
Examples of complex GPX files
Re: [gpsxml] Examples of complex GPX files
GPX 1.0 to 1.1 to 1.0 XSLT sheets online (was Re: Examples of complex GPX files
GPX 1.0 to 1.1 to 1.0 XSLT sheets online (was Re: Examples of complex GPX files
newbie question to GPX 1.0 vs. GPX 1.1
Re: newbie question to GPX 1.0 vs. GPX 1.1
Robogeo Geocoded GPX/images to Google Earth KML XSLT transformation
Re: newbie question to GPX 1.0 vs. GPX 1.1
Re: Robogeo Geocoded GPX/images to Google Earth KML XSLT transformation
Documentation / Validation mismatch
Re: [gpsxml] Documentation / Validation mismatch
Creating GPX Files from Delphi
Re: [gpsxml] Creating GPX Files from Delphi
RE: [gpsxml] Creating GPX Files from Delphi
Re: [gpsxml] Creating GPX Files from Delphi
Re: Documentation / Validation mismatch
Simple GPX Track Example
Re: [gpsxml] Simple GPX Track Example
Basic XML, GPX and Delphi Help
RE: [gpsxml] Basic XML, GPX and Delphi Help
Virtual Earth GPX tracks visualizations
Re: Virtual Earth GPX tracks visualizations
Speaking of visualizations, Google Earth and GPX
Re: [gpsxml] Re: Virtual Earth GPX tracks visualizations
Re: [gpsxml] Speaking of visualizations, Google Earth and GPX
Re[2]: [gpsxml]name, cmt, desc, label_text, etc...
Re: [gpsxml]name, cmt, desc, label_text, etc...
Re: [gpsxml]name, cmt, desc, label_text, etc...
Re: Virtual Earth GPX tracks visualizations
Re: [gpsxml]name, cmt, desc, label_text, etc...
Re: Simple GPX Track Example
RE: [gpsxml] Re: Simple GPX Track Example
Re: Simple GPX Track Example
RE: [gpsxml] Re: Simple GPX Track Example
Re: Simple GPX Track Example
Computer & Internet Resources
India IT Weekly - It is FREE!
Symbology, ExpertGPS (beta)
Re: [gpsxml] Symbology, ExpertGPS (beta)
Re: Symbology, ExpertGPS (beta)
Re: Maps On Us turn-by-turn to GPS
GPX to KML to GPX transformations
GPX IFilter?
Re: GPX to KML to GPX transformations
GPX/XML From Delphi
What can I do with GPX on the web site?
Date/Time in a GPX File
Re: [gpsxml] Date/Time in a GPX File
RE: [gpsxml] Date/Time in a GPX File
Re: [gpsxml] Date/Time in a GPX File
Re: [gpsxml] Date/Time in a GPX File
Re: [gpsxml] Date/Time in a GPX File
RE: [gpsxml] Date/Time in a GPX File
Re: [gpsxml] Date/Time in a GPX File
Re[2]: [gpsxml] Date/Time in a GPX File
Re: [gpsxml] Date/Time in a GPX File
Re: Date/Time in a GPX File
Use Google Earth to search www.TravelByGPS.com
Invalid emailType definition.
Re: Invalid emailType definition.
54 Programs now support GPX - does yours?
Digging* for Travel by GPS related information?
Re: [gpsxml] Digging* for Travel by GPS related information?
Must see : Website of the week
Re: What can I do with GPX on the web site?
Introducting another GPX loader for Google Maps
Re: [gpsxml] Introducting another GPX loader for Google Maps
Simulated "real time" track playback??
Re: [gpsxml] Simulated "real time" track playback??
Validating GPX files online, documentation on GPX 1.0 format
Re: Simulated "real time" track playback??
Re: [gpsxml] Validating GPX files online, documentation on GPX 1.0 format
Re: Introducing another GPX loader for Google Maps
How do I get different colors for tracks to display from a .gpx file?
Re: How do I get different colors for tracks to display from a .gpx file?
Re: How do I get different colors for tracks to display from a .gpx file?
Re: How do I get different colors for tracks to display from a .gpx file?
Re: How do I get different colors for tracks to display from a .gpx file?
Re: [gpsxml] Re: How do I get different colors for tracks to display from a .gpx file?
mime type
Re: How do I get different colors for tracks to display from a .gpx file?
Re: Validating GPX files online, documentation on GPX 1.0 format
New file uploaded to gpsxml
New file uploaded to gpsxml
GPSr support for *Area* map features
Re: GPSr support for *Area* map features
What is CDATA?
Re: [gpsxml] What is CDATA?
Re: What is CDATA?
Re: [gpsxml] Re: What is CDATA?
Re: What is CDATA?
Re: [gpsxml] Re: What is CDATA?
Re: [gpsxml] Re: What is CDATA?
Re: [gpsxml] Re: What is CDATA?
Re: [gpsxml] Re: What is CDATA?
Re[2]: [gpsxml] Re: What is CDATA?
Re: Maps On Us turn-by-turn to GPS
Re: What is CDATA?
Re: What is CDATA?
Re: [gpsxml] Re: What is CDATA?
Re: [gpsxml] Re: What is CDATA?
GPX test suite
Speed and course
Re: Speed and course
Simple Question
Re: [gpsxml] Simple Question
ptsegType and ptType unused?
HELP IF U CAN
.xml file extension appended to downloaded .gpx files
Re: [gpsxml] HELP IF U CAN
Re: [gpsxml] HELP IF U CAN
Eliminating "bad" points from GPX tracks
Re: [gpsxml] Eliminating "bad" points from GPX tracks
Re: .xml file extension appended to downloaded .gpx files
Re: .xml file extension appended to downloaded .gpx files
Re: [gpsxml] .xml file extension appended to downloaded .gpx files
Re: .xml file extension appended to downloaded .gpx files
Re: [gpsxml] Re: .xml file extension appended to downloaded .gpx files
Re: .xml file extension appended to downloaded .gpx files
Re: .xml file extension appended to downloaded .gpx files
Re: Eliminating "bad" points from GPX tracks
Re: Eliminating "bad" points from GPX tracks
convert data to GPX
Re: [gpsxml] convert data to GPX
RE: [gpsxml] convert data to GPX
Re: [gpsxml] convert data to GPX
RE: [gpsxml] convert data to GPX
Re: [gpsxml] convert data to GPX
GPX schema validation using Visual studio 2003
Digital Degrees v Degrees and Digital Minutes file format
Re: [gpsxml] Digital Degrees v Degrees and Digital Minutes file
Re: [gpsxml] Digital Degrees v Degrees and Digital Minutes file format
Gpx in .NET 2.0
Re: [gpsxml] Gpx in .NET 2.0
RE: [gpsxml] Digital Degrees v Degrees and Digital Minutes file format
Re: Digital Degrees v Degrees and Digital Minutes file format
RE: [gpsxml] Re: Digital Degrees v Degrees and Digital Minutes file format
Re: [gpsxml] Re: Digital Degrees v Degrees and Digital Minutes file
Re: Digital Degrees v Degrees and Digital Minutes file format
RE: [gpsxml] Re: Digital Degrees v Degrees and Digital Minutes file format
Re: Digital Degrees v Degrees and Digital Minutes file format
Re: Digital Degrees v Degrees and Digital Minutes file format
Does fells_loop.gpx example validate in xmlspy?
Re: [gpsxml] Does fells_loop.gpx example validate in xmlspy?
Is GPX the right format for my application?
Re: [gpsxml] Is GPX the right format for my application?
Re: [gpsxml] Is GPX the right format for my application?
Re: Is GPX the right format for my application?
Re: Is GPX the right format for my application?
Re: [gpsxml] Re: Is GPX the right format for my application?
Re: Is GPX the right format for my application?
Re: [gpsxml] Re: Is GPX the right format for my application?
Re: [gpsxml] Re: Is GPX the right format for my application?
Re: [gpsxml] Re: Is GPX the right format for my application?
Re: Eliminating "bad" points from GPX tracks
Read message inbox
UTM co-ords and GPX
Re: [gpsxml] UTM co-ords and GPX
Exporting gpx from MS Access
Symbol and GPX
Re: [gpsxml] Symbol and GPX
Re: [gpsxml] Symbol and GPX
Re[2]: [gpsxml] Symbol and GPX
Convert GPS data to Street Address
Re: [gpsxml] Convert GPS data to Street Address
Re: Re: [gpsxml] Convert GPS data to Street Address
Re: Re: [gpsxml] Convert GPS data to Street Address
supporting both schemas
Re: [gpsxml] supporting both schemas
Viewing GPX files with Google Maps
Re: Viewing GPX files with Google Maps
Re: [gpsxml] Viewing GPX files with Google Maps
C# sample code for writing GPX
Re: [gpsxml] C# sample code for writing GPX
Re: C# sample code for writing GPX
Re: C# sample code for writing GPX
Re: [gpsxml] Re: C# sample code for writing GPX
Re: [gpsxml] Re: C# sample code for writing GPX
Re: [gpsxml] Re: C# sample code for writing GPX
Re: Viewing GPX files with Google Maps
Velocity and direction
RE: [gpsxml] Velocity and direction
Re: [gpsxml] Velocity and direction
GPX based route sharing
Re: [gpsxml] GPX based route sharing
Re: GPX based route sharing
Re: [gpsxml] GPX based route sharing
RE: [gpsxml] Velocity and direction
Re: Velocity and direction
Re: [gpsxml] Re: Velocity and direction
Google Earth and GPX elevation data
Re: [gpsxml] Google Earth and GPX elevation data
Re: [gpsxml] Google Earth and GPX elevation data
Re: [gpsxml] Google Earth and GPX elevation data
Re: [gpsxml] Google Earth and GPX elevation data
Re: Velocity and direction

Re: [gpsxml] (unknown)
Re: [gpsxml] Calculating slope or grade from gpx
Re: [gpsxml] (unknown)
Re: [gpsxml] (unknown)
Averaging Tracks
Fugawi now supports GPX
Re: [gpsxml] Fugawi now supports GPX
Tracklogs .trl to .gpx format conversion
recommend software viewer with local url support?
Re: recommend software viewer with local url support?
Re: recommend software viewer with local url support?
Re: Google Earth and GPX elevation data
Re: Calculating slope or grade from gpx
Re: recommend software viewer with local url support?
New file uploaded to gpsxml
Any ready compression method available for GPX?
Re: [gpsxml] Any ready compression method available for GPX?
Re[2]: [gpsxml] Any ready compression method available for GPX?
Re: Re[2]: [gpsxml] Any ready compression method available for GPX?
Re[3]: [gpsxml] Any ready compression method available for GPX?
Re: [gpsxml] Any ready compression method available for GPX?
Re: [gpsxml] Any ready compression method available for GPX?
Re: Any ready compression method available for GPX?
RE: [gpsxml] Re: Any ready compression method available for GPX?
Re: Yeah yeah, I know
Using GPX Data to plot AutoCAD points
Re: GPX based route sharing
Re: [gpsxml] it's a hardware problem
gpx for mobile?
RE: [gpsxml] gpx for mobile?
GPX from scanned image
GPX -> delimited file (for MS Access)
GPX Schema question
Ok, is this SAXCount's problem, or mine?
visit, join , forward http://www.studyjava.org/forums/
visit, join , forward http://www.studyjava.org/forums/
Using groundspeak schema in GPX 1.1
Re: [gpsxml] Using groundspeak schema in GPX 1.1
Additional Functionality in Overlays - Hotspots and Symbols
Re: [gpsxml] Using groundspeak schema in GPX 1.1
camera device - tagging compass direction
Re: [gpsxml] camera device - tagging compass direction
Re: camera device - tagging compass direction
Re: [gpsxml] Re: camera device - tagging compass direction
Re: [gpsxml] Re: camera device - tagging compass direction
GPX file and OpenOffice
Re:[gpsxml] camera device - tagging compass direction
Re:[gpsxml] camera device - tagging compass direction
Re: [gpsxml] camera device - tagging compass direction
IMMEDIATE ONSITE OPENING FOR J2EE PROFESSIONAL WITH 3+ YRS
Re: camera device - tagging compass direction
Re: [gpsxml] camera device - tagging compass direction
Re: camera device - tagging compass direction
Re: [gpsxml] Re: camera device - tagging compass direction
Re: camera device - tagging compass direction
Re: Tracklogs .trl to .gpx format conversion
Re: camera device - tagging compass direction
Re: [gpsxml] Re: camera device - tagging compass direction
RE: [gpsxml] Re: camera device - tagging compass direction
Noobie Questions
Re: camera device - tagging compass direction
Re: Noobie Questions
Re: [gpsxml] Using groundspeak schema in GPX 1.1
look what i found ?
How to validate uploaded GPX file with PHP
Re: [gpsxml] How to validate uploaded GPX file with PHP
Re: How to validate uploaded GPX file with PHP
New file uploaded to gpsxml
GPX Viewpoint schema proposal document
Re: [gpsxml] GPX Viewpoint schema proposal document
Newbie wants to write gpx file
Re: [gpsxml] GPX Viewpoint schema proposal document
Re: GPX Viewpoint schema proposal document
Re: [gpsxml] Newbie wants to write gpx file
Re: [gpsxml] Newbie wants to write gpx file
Re: [gpsxml] Newbie wants to write gpx file
Re[2]: [gpsxml] Newbie wants to write gpx file
Re: [gpsxml] Newbie wants to write gpx file
RE: Re[2]: [gpsxml] Newbie wants to write gpx file
Re: Re[2]: [gpsxml] Newbie wants to write gpx file
GML as transport agent for sdbms
Re: [gpsxml] GML as transport agent for sdbms
RE: Re[2]: [gpsxml] Newbie wants to write gpx file
mixing waypoints and tracks
Re: [gpsxml] mixing waypoints and tracks
Re: mixing waypoints and tracks
Re: mixing waypoints and tracks
Re: mixing waypoints and tracks
Re: [gpsxml] Re: mixing waypoints and tracks
Re: mixing waypoints and tracks
GPX creation vs modification times - proposed schema
Re: [gpsxml] GPX Viewpoint schema proposal document
Re: GPX creation vs modification times - proposed schema
Re: [gpsxml] Re: GPX creation vs modification times - proposed schema
Re: GPX creation vs modification times - proposed schema
Re: [gpsxml] Re: GPX creation vs modification times - proposed schema
Re: GPX creation vs modification times - proposed schema
Re: [gpsxml] Re: GPX creation vs modification times - proposed schema
schema vs manual
Re: [gpsxml] schema vs manual
Re: schema vs manual
Re: Velocity and direction
=?utf-8?Q?Extending_the_geocaching_=0BExtending_the_geocaching_=22cache=22_schema?=
Re: [gpsxml] Extending the geocaching "cache" schema
The Great Stock Market Secret
A Stock Market Investment Plan That Never Lets You Down
hi friends
A Guide to High-Yield, High-Risk Stocks
GPS photo tagger - http:// www.geotagger.co.uk
To find love or friends
I Will Show You The Way To Make Easy And Fast Money. Watch this!
Using the Stock Market to Plan for Retirement
How To Make It Big In The Stock Market!
[ANN] GPX parsing for ruby
Gpx style
Extensions for heart rate/cadence data?
Re: [gpsxml] Extensions for heart rate/cadence data?
Re: [gpsxml] Extensions for heart rate/cadence data?
GPX Beginner
Re: GPX Beginner
Re: GPX Beginner
Appilications using GPX data "on-the-fly"
POI/Waypoint Phone Number Attribute
Re: [gpsxml] POI/Waypoint Phone Number Attribute
Re: [gpsxml] POI/Waypoint Phone Number Attribute
Re: POI/Waypoint Phone Number Attribute
Re: [gpsxml] Re: POI/Waypoint Phone Number Attribute
Re: POI/Waypoint Phone Number Attribute
Re: [gpsxml] Re: POI/Waypoint Phone Number Attribute
Re: POI/Waypoint Phone Number Attribute
Re: [gpsxml] Re: POI/Waypoint Phone Number Attribute
Re: [gpsxml] Re: POI/Waypoint Phone Number Attribute
Re: [gpsxml] Re: POI/Waypoint Phone Number Attribute
Re: POI/Waypoint Phone Number Attribute
Re: POI/Waypoint Phone Number Attribute
Quintessential or index point
Re: POI/Waypoint Phone Number Attribute
Re: [gpsxml] Re: POI/Waypoint Phone Number Attribute
Re: [gpsxml] Quintessential or index point
Re: Quintessential or index point
Re: POI/Waypoint Phone Number Attribute
Beliefs of Successful Market Timers
Re: POI/Waypoint Phone Number Attribute
Re: POI/Waypoint Phone Number Attribute
Re: POI/Waypoint Phone Number Attribute
GPX program/Web site that generated circles, spirals, etc?
Re: [gpsxml] GPX program/Web site that generated circles, spirals, etc?
Re: POI/Waypoint Phone Number Attribute
Visual Basic development for geocaching utilities
Re: Visual Basic development for geocaching utilities
Re: [gpsxml] Re: Visual Basic development for geocaching utilities
Re: Extensions for heart rate/cadence data?
Re: [gpsxml] Re: Extensions for heart rate/cadence data?
RE: [gpsxml] Re: Extensions for heart rate/cadence data?
Re: [gpsxml] Re: Extensions for heart rate/cadence data?
Re: [gpsxml] Re: Extensions for heart rate/cadence data?
Re: POI/Waypoint Phone Number Attribute
Re: Proximity Alarms
Re: [gpsxml] Re: Proximity Alarms
Re: [gpsxml] Re: Proximity Alarms
Moderator
Re: [gpsxml] Moderator
Re: [gpsxml] Moderator
Re: [gpsxml] Moderator
Re: [gpsxml] Moderator
Re: Moderator
Re: Moderator
Re: [gpsxml] Expressing multilanguage text in GPX
Formal definition of GPX 1.0?
Re: Formal definition of GPX 1.0?
Re: [gpsxml] Formal definition of GPX 1.0?
Re: [gpsxml] Formal definition of GPX 1.0?
Re: [gpsxml] Formal definition of GPX 1.0?
Re: [gpsxml] Formal definition of GPX 1.0?
Re: [gpsxml] Formal definition of GPX 1.0?
Re[2]: [gpsxml] Formal definition of GPX 1.0?
Re: Re[2]: [gpsxml] Formal definition of GPX 1.0?
Re[2]: [gpsxml] Moderator
Re: mime type
Re: [gpsxml] Re: mime type
Re: [gpsxml] Re: mime type
Re: [gpsxml] Top 50 FREE eBooks for ASP.Net Available for FREE Download
Re: [gpsxml] Re: mime type
Re: [gpsxml] Top 50 FREE eBooks for ASP.Net Available for FREE Download
Associating geo-referenced photos with tracklogs in GPX
Re: mime type
Re: [gpsxml] Associating geo-referenced photos with tracklogs in GPX
Photos (images) as their own element in GPX (or an extension schema)
Re: Associating geo-referenced photos with tracklogs in GPX
Re: mime type
Re: mime type
Re: [gpsxml] Re: Associating geo-referenced photos with tracklogs in GPX
Re: mime type
Re: [gpsxml] Re: mime type
Re[2]: [gpsxml] Re: Associating geo-referenced photos with tracklogs in GPX
Re: [gpsxml] Re: mime type
Re: [gpsxml] Formal definition of GPX 1.0?
Re: Associating geo-referenced photos with tracklogs in GPX
Re: [gpsxml] Re: Associating geo-referenced photos with tracklogs in GPX
Re[2]: [gpsxml] Formal definition of GPX 1.0?
Re: Re[2]: [gpsxml] Formal definition of GPX 1.0?
Re[2]: [gpsxml] Re: POI/Waypoint Phone Number Attribute
RE: Re[2]: [gpsxml] Re: POI/Waypoint Phone Number Attribute
Re: [gpsxml] Re: mime type
Query about fields/format for Geocaching.Com GPX files
Re: [gpsxml] Expressing multilanguage text in GPX
Re: Query about fields/format for Geocaching.Com GPX files
Re: mime type
Re: [gpsxml] Re: mime type
Re: [gpsxml] Re: mime type
[gpsxml] Re: POI/Waypoint Phone Number Attribute
Re: mime type
Re: [gpsxml] Re: mime type
Re[4]: [gpsxml] Re: POI/Waypoint Phone Number Attribute
Re: [gpsxml] Re: mime type
Re: [gpsxml] Query about fields/format for Geocaching.Com GPX files
Re[2]: [gpsxml] Expressing multilanguage text in GPX
Re: Expressing multilanguage text in GPX
Re: mime type
Re: [gpsxml] Re: mime type
GPX supported in Google Mobile Web sitemaps?
Re: [gpsxml] GPX supported in Google Mobile Web sitemaps?
Import and export between GPS and Google Earth
RE: [gpsxml] GPX supported in Google Mobile Web sitemaps?
Re: [gpsxml] GPX supported in Google Mobile Web sitemaps?
GPX + Javascript problem
What Application-Type to use?
Re: [gpsxml] What Application-Type to use?
Re: [gpsxml] What Application-Type to use?
Re: [gpsxml] What Application-Type to use?
Re: POI/Waypoint Phone Number Attribute
Exporting GPX data from a JS DOM Object
GPX and GML options
Re: [gpsxml] GPX and GML options
Attaching Symbols to route and track segments?
explanation of <ele> is unclear
Re: [gpsxml] Attaching Symbols to route and track segments?
Re: [gpsxml] Attaching Symbols to route and track segments?
new member
GPS for SAHANA
help
Re: help
Does the Garmin POI loader have a maximum number of elements?
Re: Does the Garmin POI loader have a maximum number of elements?
GPS for SAHANA
Re: [gpsxml] Re: help
Simple example and validating
Re: [gpsxml] Simple example and validating
Re: Simple example and validating
Re: [gpsxml] Re: Simple example and validating
Waypoint Track and/or Route - What to plot?
Re: [gpsxml] Waypoint Track and/or Route - What to plot?
Re: Waypoint Track and/or Route - What to plot?
Re: [gpsxml] Re: Waypoint Track and/or Route - What to plot?
Can GPX define an image format
Info about cell ID and location?
Re: [gpsxml] Info about cell ID and location?
Re: Can GPX define an image format
Re: [gpsxml] Re: Can GPX define an image format
Sorry for being off topic re: cell phone location ...
Re: Info about cell ID and location?
NMEA file
RE: [gpsxml] NMEA file
Tranferring data from device
Re: [gpsxml] Tranferring data from device
Re: Tranferring data from device
Re: [gpsxml] Re: Tranferring data from device
Re: Eliminating "bad" points from GPX tracks
Re: [gpsxml] Re: Eliminating "bad" points from GPX tracks
Re: Eliminating "bad" points from GPX tracks
Re: Eliminating "bad" points from GPX tracks
Re: Eliminating "bad" points from GPX tracks
Re: Eliminating "bad" points from GPX tracks
parsing gpx with
Re: [gpsxml] parsing gpx with
gpx2png?
Re: [gpsxml] gpx2png?
Re: gpx2png?
"gpx2svg"
Error in GPX 1.0 schema definition of emailType
New to gpx
Re: [gpsxml] New to gpx
How to create GPX files.
Re: [gpsxml] How to create GPX files.
Bare Bones GPX for Operator Firefox extension
Re: [gpsxml] Bare Bones GPX for Operator Firefox extension
Cannot have a DOCTYPE declaration outside of a prolog
Learning XSL with GPX files
Re: mime type
Re: mime type
Error while writing gpx file on asp.net page
Re: [gpsxml] Error while writing gpx file on asp.net page
Re: Bare Bones GPX for Operator Firefox extension
Re: [gpsxml] Re: Bare Bones GPX for Operator Firefox extension
Using .NET 2.0 XMLWriter to create GPX file
Re: [gpsxml] Using .NET 2.0 XMLWriter to create GPX file
Re: Using .NET 2.0 XMLWriter to create GPX file
IS GPX outlining of buildings common practice?
Re: [gpsxml] IS GPX outlining of buildings common practice?
Re: [gpsxml] IS GPX outlining of buildings common practice?
Re[2]: [gpsxml] IS GPX outlining of buildings common practice?
Re: [gpsxml] IS GPX outlining of buildings common practice?
Re: IS GPX outlining of buildings common practice?
Can't figure out why Easy GPS doesn't like my GPX file
Re: [gpsxml] Can't figure out why Easy GPS doesn't like my GPX file
Re: [gpsxml] Can't figure out why Easy GPS doesn't like my GPX file
Re: [gpsxml] Can't figure out why Easy GPS doesn't like my GPX file
Re: [gpsxml] Can't figure out why Easy GPS doesn't like my GPX file
Re: Can't figure out why Easy GPS doesn't like my GPX file
Allowing accented characters in fields?
Re: [gpsxml] Allowing accented characters in fields?
Re: Allowing accented characters in fields?
Re: [gpsxml] Re: Allowing accented characters in fields?
Exporting a cave line plot as GPX
Re: Exporting a cave line plot as GPX
Re: [gpsxml] Re: Exporting a cave line plot as GPX
Re: Exporting a cave line plot as GPX
Re: [gpsxml] Re: Exporting a cave line plot as GPX
Re: [gpsxml] Re: Exporting a cave line plot as GPX
Re[2]: [gpsxml] Re: Exporting a cave line plot as GPX
Re: [gpsxml] Re: Exporting a cave line plot as GPX
GPX files validation with Ruby on Rails
hi
Re: [gpsxml] hi
Re: [gpsxml] hi
thanks
Re: hi
hi
Re: [gpsxml] hi
Re: [gpsxml] hi
Re: hi
Re: hi
Coding xsi:schemaLocation attribute?
Define a GPX extensions for MTK based GPS
Re: [gpsxml] Define a GPX extensions for MTK based GPS
Re[2]: [gpsxml] Define a GPX extensions for MTK based GPS
What version .GPX file
Help reading GPX files with PHP
Re: [gpsxml] Help reading GPX files with PHP
Re: Help reading GPX files with PHP
Re: Help reading GPX files with PHP
Re: Help reading GPX files with PHP
New to GPX - Questions about Garmin and Java Support
Gone in a Flash - Re: Help reading GPX files with PHP
Parsing GPX files with FLASH 8
Re: Parsing GPX files with FLASH 8
Re: [gpsxml] Re: Help reading GPX files with PHP
Re: Help reading GPX files with PHP
Re: Help reading GPX files with PHP
Re: [gpsxml] Re: Help reading GPX files with PHP
GPX Java/Javascript-XML/Json
GPX editor?
Tiny library for Java and Javascript with XML or Json in-output?
how to upload a gpx file with php?
RE: [gpsxml] GPX editor?
RE: [gpsxml] GPX editor?
Re: GPX editor?
Re: [gpsxml] Re: GPX editor?
Re: [gpsxml] Re: GPX editor?
Waypoints, Tracks, Routes
Re: [gpsxml] Waypoints, Tracks, Routes
Re: [gpsxml] Waypoints, Tracks, Routes
Re: Tiny library for Java and Javascript with XML or Json in-output?
Re: [gpsxml] Waypoints, Tracks, Routes
GPX Extensions for Trail Types?
Re: GPX editor?
Re: Waypoints, Tracks, Routes
Re: Waypoints, Tracks, Routes
Re: Waypoints, Tracks, Routes
Re: [gpsxml] GPX editor?
Re: [gpsxml] GPX Java/Javascript-XML/Json
Re: [gpsxml] GPX Java/Javascript-XML/Json
Re: [gpsxml] Re: Waypoints, Tracks, Routes
Re: GPX Java/Javascript-XML/Json
Best way to store people's home address / telephone in GPS?
Re: Best way to store people's home address / telephone in GPS?
Re: [gpsxml] Re: Best way to store people's home address / telephone
Re: [gpsxml] Waypoints, Tracks, Routes
Re: [gpsxml] Waypoints, Tracks, Routes
RE: [gpsxml] GPS velocity measurement (was: GPX Java/Javascript-X
Re: GPX 1.2
Re: [gpsxml] Re: GPX 1.2
Re: [gpsxml] Re: GPX 1.2
Re: [gpsxml] Re: GPX 1.2
Re: [gpsxml] Re: GPX 1.2
Re: GPX 1.2
Re: [gpsxml] Re: GPX 1.2
Extra track segments appear in GPX viewer
Garmin: your Colorado GPX files don't validate!
GPX in order to define areas?
Re: [gpsxml] GPX in order to define areas?
Re: GPX in order to define areas?
Re: [gpsxml] Re: GPX in order to define areas?
Introduction and question
Re: [gpsxml] GPX in order to define areas?
Re: GPX in order to define areas?
Tracker's MyWay Navigator products support GPX
Turn by turn instructions.
Re: Turn by turn instructions.
RE: [gpsxml] Re: Turn by turn instructions.
RE: [gpsxml] Re: Turn by turn instructions.
RE: [gpsxml] Re: Turn by turn instructions.
Why not multiple <trkseg>s in one <trk>?
Re: [gpsxml] Why not multiple <trkseg>s in one <trk>?
Re: Why not multiple <trkseg>s in one <trk>?
Re: [gpsxml] Why not multiple <trkseg>s in one <trk>?
Re[2]: [gpsxml] Why not multiple <trkseg>s in one <trk>?
Re: Why not multiple <trkseg>s in one <trk>?
Open source libs for parsing GPX and creating geometry objects
Re: Open source libs for parsing GPX and creating geometry objects
Does name have to be unique
Re: [gpsxml] Does name have to be unique
Re: [gpsxml] Does name have to be unique
Re: [gpsxml] Does name have to be unique
Re: [gpsxml] Does name have to be unique
Re: Does name have to be unique
Introduction of Java Programmer
Re: [gpsxml] Introduction of Java Programmer
RE: [gpsxml] Introduction of Java Programmer
Re: Introduction of Java Programmer
Question about the "cmt" element of a Waypoint.
Re: [gpsxml] Question about the "cmt" element of a Waypoint.
Re: [gpsxml] Question about the "cmt" element of a Waypoint.
Re: [gpsxml] Question about the "cmt" element of a Waypoint.
Re: [gpsxml] Question about the "cmt" element of a Waypoint.
wpt format question
Re: wpt format question
Re: [gpsxml] Re: wpt format question
Re: wpt format question
Re: wpt format question
Re: [gpsxml] wpt format question
Re: wpt format question
Re: wpt format question
GPS devices and custome web application.
GPX as formal standard
Symbology
Re: Symbology
RE: [gpsxml] Re: Symbology
Regarding the XML/GPX format used by Garmin GPS devices (Street Pilots & Nuvi's)
From Gene in Colorado
Re: [gpsxml] Re: Symbology
Re: From Gene in Colorado
Re: [gpsxml] Re: Symbology
Re: [gpsxml] Re: From Gene in Colorado
Re: [gpsxml] Re: Symbology
Re: [gpsxml] Format for quoting geolocation on the internet ?
Re: [gpsxml] Format for quoting geolocation on the internet ?
Re: [gpsxml] Format for quoting geolocation on the internet ?
Re: [gpsxml] Format for quoting geolocation on the internet ?
Re: Format for quoting geolocation on the internet ?
Re: [gpsxml] Re: Symbology
Re: [gpsxml] Format for quoting geolocation on the internet ?
Re: [gpsxml] Format for quoting geolocation on the internet ?
Re: [gpsxml] Format for quoting geolocation on the internet ?
Re: Format for quoting geolocation on the internet ?
GPX route for Garmin Nuvi 760
Re: [gpsxml] GPX route for Garmin Nuvi 760
Re: GPX route for Garmin Nuvi 760
Re: GPX route for Garmin Nuvi 760
Re: [gpsxml] Re: GPX route for Garmin Nuvi 760
Adding custom elements to wptType
Re: [gpsxml] Adding custom elements to wptType
Re: [gpsxml] Adding custom elements to wptType
Re: [gpsxml] Adding custom elements to wptType
Re: [gpsxml] Adding custom elements to wptType
Re: [gpsxml] Adding custom elements to wptType
Re: [gpsxml] Adding custom elements to wptType
Re: [gpsxml] Re: Symbology
Re: [gpsxml] Re: Symbology
History of GPXML, timeline
Re: History of GPXML, timeline
Re: [gpsxml] Re: History of GPXML, timeline
Re: History of GPXML, timeline
Re: [gpsxml] Re: History of GPXML, timeline
Re: [gpsxml] Re: History of GPXML, timeline
Re: [gpsxml] Re: History of GPXML, timeline
Re: History of GPXML, timeline
Re: History of GPXML, timeline
GPX & Database Integration
Re: [gpsxml] GPX & Database Integratio
Re: GPX & Database Integration
GPX format Uniform Type Identifier (UTI) for OS X
GPX-POI file generator
Re: GPX-POI file generator
Sending GPX routes to remote GPS devices
Re: Sending GPX routes to remote GPS devices
Re: [gpsxml] Re: Sending GPX routes to remote GPS devices
RE: [gpsxml] Re: Sending GPX routes to remote GPS devices
Re: [gpsxml] Re: Sending GPX routes to remote GPS devices
Re: Sending GPX routes to remote GPS devices
New version of GPX Editor - interactive Windows GPX editor (with source)
Re: Sending GPX routes to remote GPS devices
interactive GPX editor on Mac OS X
Re: interactive GPX editor on Mac OS X
SAXCount versus SAX2Count?
Re: interactive GPX editor on Mac OS X
Re: [gpsxml] Re: interactive GPX editor on Mac OS X
Re: interactive GPX editor on Mac OS X
Re: [gpsxml] Re: interactive GPX editor on Mac OS X
I have question about the frequency of recording
Re: interactive GPX editor on Mac OS X
Which extension for zip-compressed GPX? .gpxz, .gpz, .gpx.zip, other?
Re: [gpsxml] Which extension for zip-compressed GPX? .gpxz, .gpz, .gpx.zip, other?
Re: [gpsxml] Which extension for zip-compressed GPX? .gpxz, .gpz,
Re[2]: [gpsxml] Which extension for zip-compressed GPX? .gpxz, .gpz, .gpx.zip, other?
=?iso-8859-1?Q?Re=3A_=5Bgpsxml=5D_Which_extension_for_zip-compress?=
Re: [gpsxml] Which extension for zip-compressed GPX? .gpxz, .gpz, .gpx.zip, other?
Re: [gpsxml] Which extension for zip-compressed GPX? .gpxz, .gpz, .gpx.zip, other?
What is the current stable version of the GPX format ?
Re: [gpsxml] What is the current stable version of the GPX format ?
Re: [gpsxml] What is the current stable version of the GPX format ?
LGPL Java Library for GPX
Current status of the GPX file format ?
Re: [gpsxml] Current status of the GPX file format ?
New release of phpgpx + Flickr client/server for time coding a photo set
Re: New release of phpgpx + Flickr client/server for time coding a photo set
GPSXML with web service
Re: [gpsxml] climate and other extensions
Newbie, Hi everyone. Ignorance to follow.
Hello! Question about OpenStreetMap GPX
Re: [gpsxml] Hello! Question about OpenStreetMap GPX
Re: [gpsxml] Hello! Question about OpenStreetMap GPX
Re: explanation of <ele> is unclear
Re: [gpsxml] Re: explanation of <ele> is unclear
Re: [gpsxml] Re: explanation of <ele> is unclear
Re: [gpsxml] Re: explanation of <ele> is unclear
Re: [gpsxml] Re: explanation of <ele> is unclear
Re: [gpsxml] Re: explanation of <ele> is unclear
Re: [gpsxml] Re: explanation of <ele> is unclear
RE: [gpsxml] Re: explanation of <ele> is unclear
Re: explanation of <ele> is unclear
Re: explanation of <ele> is unclear
Re: explanation of <ele> is unclear
Re: explanation of <ele> is unclear
Re: [gpsxml] Re: explanation of <ele> is unclear
Re: [gpsxml] Re: explanation of <ele> is unclear
sym - minOccurs
Re: [gpsxml] sym - minOccurs
Re: sym - minOccurs
Re[2]: [gpsxml] sym - minOccurs
.NET 2.0 problems with gpx.xsd
Re: Re[2]: [gpsxml] sym - minOccurs
DGPS service for surveyors
project
Re: project
Re: project
What is the standard time interval a wpt tag is added to a gpx file?
Window Mobile Tracking
Windows Mobile Tracking
Re: [gpsxml] What is the standard time interval a wpt tag is added to
Converting rfx to gpx....
GPX 1.1 <speed> and <course>
Re: [gpsxml] GPX 1.1 <speed> and <course>
Re[2]: [gpsxml] GPX 1.1 <speed> and <course>
Re: Re[2]: [gpsxml] GPX 1.1 <speed> and <course>
Re: [gpsxml] GPX 1.1 <speed> and <course>
Re[2]: [gpsxml] GPX 1.1 <speed> and <course>
Re: [gpsxml] GPX 1.1 <speed> and <course>
Re: [gpsxml] GPX 1.1 <speed> and <course>
Re: [gpsxml] GPX 1.1 <speed> and <course>
How to move GPX extensions into the "holy" category
Sending GPX Files to Remote Devices
Converting Loran c to Lat Lon
GPX --> 3d curve/shape?
Creating a GPS System to track used cars that are Financed.
MySQL -> GPX
Re: [gpsxml] MySQL -> GPX
Re: MySQL -> GPX
Anyone have a GPX file from a Lowrance Endura GPS? I believe they are generating invalid GPX files
Re: [gpsxml] Anyone have a GPX file from a Lowrance Endura GPS? I
Extension for Photo Information in GPX?
Points with same coordinates.
Device information in GPX files
Re: [gpsxml] Device information in GPX files
Re: Device information in GPX files
Who gets the credit?
Re: Device information in GPX files
Re: [gpsxml] Device information in GPX files
Re: [gpsxml] Who gets the credit?
'Location-Based' Services in a mobile environment survey
Newbie GPS programmer needs help
Read and write Gpx files in vb .net
Read and write Gpx files in vb .net
Re: Read and write Gpx files in vb .net
Read & write ROUTES in gpx
Draft of proposed GPX 1.1 extensions
Re: [gpsxml] Draft of proposed GPX 1.1 extensions
Re: [gpsxml] Draft of proposed GPX 1.1 extensions
Reading Routes from the Nuvi 760.
Re: [gpsxml] Draft of proposed GPX 1.1 extensions
Re: [gpsxml] Draft of proposed GPX 1.1 extensions
Re: [gpsxml] Draft of proposed GPX 1.1 extensions
Re: [gpsxml] Reading Routes from the Nuvi 760.
Re: [gpsxml] Draft of proposed GPX 1.1 extensions
Re: [gpsxml] Draft of proposed GPX 1.1 extensions
Re: Draft of proposed GPX 1.1 extensions
Re[2]: [gpsxml] Draft of proposed GPX 1.1 extensions
Re: Draft of proposed GPX 1.1 extensions
Re: [gpsxml] Re: Draft of proposed GPX 1.1 extensions
Re: [gpsxml] Draft of proposed GPX 1.1 extensions
Re: [gpsxml] Draft of proposed GPX 1.1 extensions
Re: [gpsxml] Draft of proposed GPX 1.1 extensions
Re[2]: [gpsxml] Draft of proposed GPX 1.1 extensions
Re: Re[2]: [gpsxml] Draft of proposed GPX 1.1 extensions
Re: Draft of proposed GPX 1.1 extensions
Re: Draft of proposed GPX 1.1 extensions
Re: [gpsxml] Re: Draft of proposed GPX 1.1 extensions
Re: Draft of proposed GPX 1.1 extensions
Re: Draft of proposed GPX 1.1 extensions
Re: Draft of proposed GPX 1.1 extensions
Re: [gpsxml] Re: Draft of proposed GPX 1.1 extensions
Re: [gpsxml] Re: Draft of proposed GPX 1.1 extensions
Re: Draft of proposed GPX 1.1 extensions
Re: Draft of proposed GPX 1.1 extensions
Re: [gpsxml] Re: Draft of proposed GPX 1.1 extensions
Re: Draft of proposed GPX 1.1 extensions
Questions about waypoints
Re: [gpsxml] Questions about waypoints
Re: Questions about waypoints
Re: [gpsxml] Re: Questions about waypoints
Re: [gpsxml] Questions about waypoints
looking for a XSLT stylesheet for GPX 1.0 to GPX 1.1 transformation
Re: [gpsxml] looking for a XSLT stylesheet for GPX 1.0 to GPX 1.1
Re: [gpsxml] looking for a XSLT stylesheet for GPX 1.0 to GPX 1.1
Re: [gpsxml] looking for a XSLT stylesheet for GPX 1.0 to GPX 1.1
Re: looking for a XSLT stylesheet for GPX 1.0 to GPX 1.1 transformation
Re: [gpsxml] Re: looking for a XSLT stylesheet for GPX 1.0 to GPX 1.1
Re: looking for a XSLT stylesheet for GPX 1.0 to GPX 1.1 transformation
Re: [gpsxml] Re: looking for a XSLT stylesheet for GPX 1.0 to GPX 1.1
GPX Analyzer & Elevation Calculator
GPX file as input into Google Maps for a multi-point route
Re: [gpsxml] GPX file as input into Google Maps for a multi-point
Is <speed> supported in GPX 1.1?
Re: [gpsxml] Is <speed> supported in GPX 1.1?
Which "Style" should I use for Tracking
Re[2]: [gpsxml] Which "Style" should I use for Tracking
Re: Which "Style" should I use for Tracking
Re: [gpsxml] Which "Style" should I use for Tracking
Visualization help?
Re: [gpsxml] Visualization help?
GPX files
Re: [gpsxml] GPX files
Re: [gpsxml] GPX files
Re: [gpsxml] Visualization help?
Hi iam asp.net developer need to validate GPX AND KML files in c#.net
Re: Hi iam asp.net developer need to validate GPX AND KML files in c#.net
Update Map In GPS devices
Re: [gpsxml] Update Map In GPS devices
<time> not supported in GPX 1.1 ?
Re: [gpsxml] <time> not supported in GPX 1.1 ?
Re: [gpsxml] <time> not supported in GPX 1.1 ?
Re: [gpsxml] <time> not supported in GPX 1.1 ?
Re: [gpsxml] <time> not supported in GPX 1.1 ?
Are you seeing malformed GPX files coming from Garmin GPX-based receivers?
Re: [gpsxml] Are you seeing malformed GPX files coming from Garmin
UTC Offset capability?
Re: [gpsxml] UTC Offset capability?
RE: [gpsxml] UTC Offset capability?
Re: UTC Offset capability?
Re: [gpsxml] Re: UTC Offset capability?
getting started with GPX
Re: [gpsxml] getting started with GPX
Re: getting started with GPX
RE: [gpsxml] getting started with GPX
Re: getting started with GPX
Re: getting started with GPX
Re: getting started with GPX
Looking for an app
Re: [gpsxml] Looking for an app
Re: [gpsxml] Time stamps in GPX - decimal seconds
How to extend gpx.xsd
detecting pauses
Proposed Revisions to GPX 1.1 Schema Documentation
Create GPX File
Accuracy/Estimated Position Error
Re: [gpsxml] Create GPX File
Re: [gpsxml] Accuracy/Estimated Position Error
Re: [gpsxml] detecting pauses
Re: [gpsxml] Proposed Revisions to GPX 1.1 Schema Documentation
RE: [gpsxml] Proposed Revisions to GPX 1.1 Schema Documentation
Re: [gpsxml] Proposed Revisions to GPX 1.1 Schema Documentation
RE: [gpsxml] Proposed Revisions to GPX 1.1 Schema Documentation
Re: Accuracy/Estimated Position Error
RE: [gpsxml] Re: Accuracy/Estimated Position Error
Re: Accuracy/Estimated Position Error
Re: [gpsxml] Accuracy/Estimated Position Error
Re: Accuracy/Estimated Position Error
Validating existing GPX file after removing waypoints.
rtept verses trkseg
Working with .gpx files
RE: [gpsxml] Validating existing GPX file after removing waypoints.
Re: [gpsxml] rtept verses trkseg
RE: [gpsxml] Validating existing GPX file after removing waypoints.
RE: [gpsxml] Working with .gpx files
Re: Working with .gpx files
RE: [gpsxml] Validating existing GPX file after removing waypoints.
Re: rtept verses trkseg
Adding POI data to existing GPX based on distance
GPX Namespace Offline
What the use of segment and when device create new one?
Re: [gpsxml] What the use of segment and when device create new one?
Re: [gpsxml] What the use of segment and when device create new one?
Re: What the use of segment and when device create new one?
Re: [gpsxml] Re: What the use of segment and when device create new one?
Re: What the use of segment and when device create new one?
Re: [gpsxml] Re: What the use of segment and when device create new one?
gpx data in mysql - schema available
Pitch, tilt and heading now standard in GPX?
Need help in getting sample GPX files over 3MB
Re: [gpsxml] Pitch, tilt and heading now standard in GPX?
Re: [gpsxml] Need help in getting sample GPX files over 3MB
library or example for create gpx in actionscript 3
Some clarification needed on how to express routes and navigation
New folder in files
Re: [gpsxml] Some clarification needed on how to express routes and navigation
Re: Some clarification needed on how to express routes and navigation
Re: [gpsxml] Re: Some clarification needed on how to express routes
Re: Some clarification needed on how to express routes and navigation
Does anyone from Garmin still read this?
Android aircraft data logging app.
Re: [gpsxml] Android aircraft data logging app.
Re: Android aircraft data logging app.
how to read a garmin gpx Track without and existing program like google earth
Re: how to read a garmin gpx Track without and existing program like
how to read a garmin gpx Track without an existing program
Windows Phone 7 app- Looking for beta testers
loading Gpx file onto google earth
Re: [gpsxml] loading Gpx file onto google earth
Export GPX from Access
SYM (symbol) tag - define its contents
Re: [gpsxml] SYM (symbol) tag - define its contents
Re: [gpsxml] SYM (symbol) tag - define its contents
Re: [gpsxml] SYM (symbol) tag - define its contents
Introducing video trails -- Synching GPX data with video
Re: [gpsxml] Introducing video trails -- Synching GPX data with video
Re: Introducing video trails -- Synching GPX data with video
GPS receiver-to server protocol standardization
Re: [gpsxml] GPS receiver-to server protocol standardization
Course element
Re: [gpsxml] Course element
Re: [gpsxml] Course element
Re: Course element
Re: [gpsxml] Re: Course element
Re: Course element
Re: [gpsxml] Re: Course element
Re: Course element
complex course with more than 1 segment
Re: [gpsxml] Re: Course element
Re: Course element
GPX schema problem
Re: GPX schema problem
Re: GPX schema problem
Waypoint name, cmt and desc size
Re: [gpsxml] Waypoint name, cmt and desc size
Re: [gpsxml] Class Project
Re: Class Project
Re: Class Project
Re: Class Project
Example of adding a custom extension?
Re: [gpsxml] Example of adding a custom extension?
Re: Example of adding a custom extension?
Re: [gpsxml] Re: Example of adding a custom extension?
Re: Example of adding a custom extension?
Re: Example of adding a custom extension?
Re: [gpsxml] Re: Example of adding a custom extension?
Re: [gpsxml] Re: Example of adding a custom extension?
Typo in GPX 1.1 spec?
Re: [gpsxml] Typo in GPX 1.1 spec?
Validation GPX files with SAX2Count
Re: [gpsxml] Validation GPX files with SAX2Count
Adding generic attributes
Re: [gpsxml] Adding generic attributes
Re: Adding generic attributes
No official mimetype?
Re: [gpsxml] No official mimetype?
Re: [gpsxml] No official mimetype?
Running command line in Mac OSX
Re: [gpsxml] Running command line in Mac OSX
WPT vs RTEPT
[gpsxml] WPT vs RTEPT
RE: WPT vs RTEPT
[gpsxml] RE: WPT vs RTEPT
Routes vs. Tracks in GPX
RE: WPT vs RTEPT
Adding sensor data to .gpx
FW: Can I represent multiple attribute value pairs with gpx
[gpsxml] FW: Can I represent multiple attribute value pairs with gpx
[gpsxml] Adding sensor data to .gpx
[gpsxml] FW: Can I represent multiple attribute value pairs with gpx
Re: [gpsxml] FW: Can I represent multiple attribute value pairs with gpx
RE: [gpsxml] FW: Can I represent multiple attribute value pairs with gpx
Accurate GPX Data
[gpsxml] Accurate GPX Data
Re: Accurate GPX Data
Developer Wanted
Re: Developer Wanted
Re: [gpsxml] Developer Wanted
Re: [gpsxml] Developer Wanted
Re: [gpsxml] Developer Wanted
Re: [gpsxml] Developer Wanted
Re: [gpsxml] Developer Wanted
Spam on the GPX website?
Re: [gpsxml] Recent mailing-list changes (was: Developer Wanted)
RE: [gpsxml] Developer Wanted
Re: Developer Wanted
Re: [gpsxml] Spam on the GPX website?
Re: [gpsxml] Spam on the GPX website?
New User of .gpx, How to use .gpx to Google Map on our own website
Re: [gpsxml] Digest Number 891
<link> element's child elements
Re: [gpsxml] <link> element's child elements
Re: [gpsxml] <link> element's child elements
Re: [gpsxml] <link> element's child elements
Re: [gpsxml] <link> element's child elements
GPX problem with Garmin Monterra
Re: GPX problem with Garmin Monterra
Re: [gpsxml] Re: GPX problem with Garmin Monterra
Re: [gpsxml] Re: GPX problem with Garmin Monterra
Re: [gpsxml] Re: GPX problem with Garmin Monterra
Re: [gpsxml] Re: GPX problem with Garmin Monterra
Re: [gpsxml] Re: GPX problem with Garmin Monterra
Re: interactive GPX editor on Mac OS X
Re: [gpsxml] GPX file format
Re: [gpsxml] GPX file format
Re: [gpsxml] GPX file format
What is "Type" field for?
Re: [gpsxml] What is "Type" field for?
Extensions issue
Re: What is "Type" field for?
Re: [gpsxml] Re: What is "Type" field for?
Re: No official mimetype?
Re: No official mimetype?
Re: [gpsxml] Re: No official mimetype?
Re: [gpsxml] No official mimetype?
Re: No official mimetype?
Re: [gpsxml] Re: No official mimetype?
Re: No official mimetype?
Re: No official mimetype?
Re: No official mimetype?
Fields
Re: [gpsxml] Fields
Re: No official mimetype?
Bounds tag
Re: [gpsxml] Bounds tag
Re: [gpsxml] Bounds tag
Re: [gpsxml] Bounds tag
Re: [gpsxml] Bounds tag
Re: [gpsxml] Bounds tag
Re: [gpsxml] Bounds tag
Re: [gpsxml] Bounds tag
Re: [gpsxml] Bounds tag
Re: [gpsxml] Bounds tag
Re: [gpsxml] Bounds tag
Re: [gpsxml] Bounds tag
Re: [gpsxml] Bounds tag
Re: [gpsxml] Bounds tag
Re: [gpsxml] Bounds tag
Re: [gpsxml] Bounds tag
Set symbol of waypoint
Re: [gpsxml] Set symbol of waypoint
Thickness and color
Re: [gpsxml] Thickness and color
Re: [gpsxml] Thickness and color
KML/KMZ to GPX converter/editor
Re: [gpsxml] KML/KMZ to GPX converter/editor
Re: [gpsxml] KML/KMZ to GPX converter/editor
KML/KMZ to GPX converter/editor
Re: KML/KMZ to GPX converter/editor
Value of GPS reported COG for heading.
XML Style Sheet?
Re: [gpsxml] XML Style Sheet?
Re: Example of adding a custom extension?
Re: [gpsxml] Re: Example of adding a custom extension?
XML 1.0 vs XML 1.1 in GPX
Re: Example of adding a custom extension?
Re: XML 1.0 vs XML 1.1 in GPX
Re: [gpsxml] Re: XML 1.0 vs XML 1.1 in GPX
Re: [gpsxml] Re: Routes vs. Tracks in GPX
Re: [gpsxml] Re: Routes vs. Tracks in GPX
RE: [gpsxml] Re: Routes vs. Tracks in GPX
What are the rules for a GPX file to be valid?
Re: What are the rules for a GPX file to be valid?
Re: [gpsxml] Re: What are the rules for a GPX file to be valid?
Re: [gpsxml] Re: What are the rules for a GPX file to be valid?
Re: [gpsxml] Re: What are the rules for a GPX file to be valid?
Any GPX file fails validation
GPX version 2
Re: GPX version 2
Re: Any GPX file fails validation
Re: [gpsxml] Re: GPX version 2
Re: [gpsxml] Re: GPX version 2
Re: [gpsxml] GPX version 2
Re: [gpsxml] GPX version 2
Re: [gpsxml] GPX version 2
Re: [gpsxml] GPX version 2
Re: [gpsxml] GPX version 2
Re: [gpsxml] GPX version 2
Re: [gpsxml] GPX version 2
Re: [gpsxml] GPX version 2
Is there a standard GPX tag for velocity?
Re: Is there a standard GPX tag for velocity?
Re: [gpsxml] Re: Is there a standard GPX tag for velocity?
Re: [gpsxml] Re: Is there a standard GPX tag for velocity?
Re: [gpsxml] Re: Is there a standard GPX tag for velocity?
Re: [gpsxml] Re: Is there a standard GPX tag for velocity?
Re: [gpsxml] Re: Is there a standard GPX tag for velocity?
Re: [gpsxml] Re: Is there a standard GPX tag for velocity?
Re: [gpsxml] Re: Is there a standard GPX tag for velocity?
Re: [gpsxml] Re: Is there a standard GPX tag for velocity?
Re: [gpsxml] Re: Is there a standard GPX tag for velocity?
Re: [gpsxml] Re: Is there a standard GPX tag for velocity?
Re: [gpsxml] Re: Is there a standard GPX tag for velocity?
Re: [gpsxml] Re: Is there a standard GPX tag for velocity?
Re: [gpsxml] Re: Is there a standard GPX tag for velocity?
Are repeated timestamps against the standard?
Re: [gpsxml] Are repeated timestamps against the standard?
Re: [gpsxml] Are repeated timestamps against the standard?
RE: [gpsxml] Are repeated timestamps against the standard?
Re: [gpsxml] Are repeated timestamps against the standard?
Re: [gpsxml] Are repeated timestamps against the standard?
Emojis and GPX files
Re: [gpsxml] Emojis and GPX files
Re: [gpsxml] Are repeated timestamps against the standard?
Re: GPX version 2
Yahoo, Groups, and us
The future: GPX v2 or GeoJSON
Re: [gpsxml] The future: GPX v2 or GeoJSON
Re: [gpsxml] The future: GPX v2 or GeoJSON

Representation of time in track logs

davewissenbach+yahoo.com on Thu Sep 27 05:52:16 2001 (link)

- Time will be expressed in UTC, which seems to be expressed in XML 
like this: 20001108T093014Z (that's Nov 11, 2001, 09:30:14 UTC)
Reference: http://www.ietf.org/rfc/rfc2445.txt?number=2445

This guiding principle for the representation of time is OK for a 
waypoint, but I think that it lacks precision for a track log where 
someone desires to measure speed. So I suggest that this <date-time> 
element (or attribute?) be part of a waypoint, track header, and 
route, but that a track log be allowed an additional optional time 
element which is a decimal offset, in seconds, from the base time.


Re: [gpsxml] Representation of time in track logs

chris+wilder-smith.org on Thu Sep 27 14:24:46 2001 (link)

Dave,

I agree with the concept of using a time offset in the track logs.  It 
almost seems to me that there has to be a different waypoint element for 
use in tracklogs than in routes or as standalone waypoints if you want 
to have support for validating the XML.  The question is how would you 
handle this DTD-wise?  The easy way is to make it all optional, but that 
puts more requirements on the parser side.  I personally think that 
tracks are different enough from routes that they should be explicitly 
different elements.  Something like this:

<track>
    <point>  <!-- initial point -->
         <time>20010927T093014Z</time>
         <lat>42.34567</lat>
         <lon>-71.34567</lon>
         <alt>57.234</alt>
    </point>
    <track-point>
          <time-offset>12.34</time-offset>
          <lat>42.456789</lat>
          <lon>-71.456789</lon>
          <alt>57.234</alt>
    </track-point>
    ....
</track>

Where a route is built of all <point> elements.  You still run into the 
problem, DTD-wise where <time> should be optional in a route or waypoint 
and you need it in the track for the initial point.  You could make it a 
separate element of track for the initial time and deal with duplicate 
information where the optional time used in the initial <point> could be 
ignored by the parser.  That seems like it might be a better solution, 
DTD and parser wise.

What do you think?

Regards,

Chris

davewissenbach+yahoo.com wrote:

>- Time will be expressed in UTC, which seems to be expressed in XML 
>like this: 20001108T093014Z (that's Nov 11, 2001, 09:30:14 UTC)
>Reference: http://www.ietf.org/rfc/rfc2445.txt?number=2445
>
>This guiding principle for the representation of time is OK for a 
>waypoint, but I think that it lacks precision for a track log where 
>someone desires to measure speed. So I suggest that this <date-time> 
>element (or attribute?) be part of a waypoint, track header, and 
>route, but that a track log be allowed an additional optional time 
>element which is a decimal offset, in seconds, from the base time.
>
>
>
>To unsubscribe from this group, send an email to:
>gpsxml-unsubscribe+yahoogroups.com
>
> 
>
>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 
>
>
>



Re: Representation of time in track logs

randyday+yahoo.com on Thu Sep 27 18:47:58 2001 (link), replying to msg

Is the offset from the last point or from the initial point? When 
does it wrap? Wouldn't it be simpler to just use a time format that 
has adequate precision? This would make parsing much easier and track 
manipulation much easier...say for example turning a track into a 
back-track route.  It also makes each data element much more self-
describing, which is a worth-while goal.

--- In gpsxml+y..., Chris Wilder-Smith <chris+w...> wrote:
> Dave,
> 
> I agree with the concept of using a time offset in the track logs.  
It 
> almost seems to me that there has to be a different waypoint 
element for 
> use in tracklogs than in routes or as standalone waypoints if you 
want 
> to have support for validating the XML.  The question is how would 
you 
> handle this DTD-wise?  The easy way is to make it all optional, but 
that 
> puts more requirements on the parser side.  I personally think that 
> tracks are different enough from routes that they should be 
explicitly 
> different elements.  Something like this:
> 
> <track>
>     <point>  <!-- initial point -->
>          <time>20010927T093014Z</time>
>          <lat>42.34567</lat>
>          <lon>-71.34567</lon>
>          <alt>57.234</alt>
>     </point>
>     <track-point>
>           <time-offset>12.34</time-offset>
>           <lat>42.456789</lat>
>           <lon>-71.456789</lon>
>           <alt>57.234</alt>
>     </track-point>
>     ....
> </track>
> 
> Where a route is built of all <point> elements.  You still run into 
the 
> problem, DTD-wise where <time> should be optional in a route or 
waypoint 
> and you need it in the track for the initial point.  You could make 
it a 
> separate element of track for the initial time and deal with 
duplicate 
> information where the optional time used in the initial <point> 
could be 
> ignored by the parser.  That seems like it might be a better 
solution, 
> DTD and parser wise.
> 
> What do you think?
> 
> Regards,
> 
> Chris
> 
> davewissenbach+y... wrote:
> 
> >- Time will be expressed in UTC, which seems to be expressed in 
XML 
> >like this: 20001108T093014Z (that's Nov 11, 2001, 09:30:14 UTC)
> >Reference: http://www.ietf.org/rfc/rfc2445.txt?number=2445
> >
> >This guiding principle for the representation of time is OK for a 
> >waypoint, but I think that it lacks precision for a track log 
where 
> >someone desires to measure speed. So I suggest that this <date-
time> 
> >element (or attribute?) be part of a waypoint, track header, and 
> >route, but that a track log be allowed an additional optional time 
> >element which is a decimal offset, in seconds, from the base time.
> >
> >
> >
> >To unsubscribe from this group, send an email to:
> >gpsxml-unsubscribe+y...
> >
> > 
> >
> >Your use of Yahoo! Groups is subject to 
http://docs.yahoo.com/info/terms/ 
> >
> >
> >


Re: [gpsxml] Re: Representation of time in track logs

chris+wilder-smith.org on Fri Sep 28 04:32:33 2001 (link)

<html>
<head>
</head>
<body>
Randy,<br>
<br>
I think it might make sense to have a higher precision timestamp in some
cases.  At least a tenth of a second seems reasonable.  Offsets in the track
log are nice because you can easily determine leg speed and compute averages
without having to deal with a full timestamp each time. I would give the
offset from the previous point, versus as a cumulative value from the initial
point.  <br>
<br>
In my vision of things, a route wouldn't have times associated with it, but
if you were to go in that direction (for instance to give time estimates
for a back track, you'd have the offset associated with the point available).
 When you get down to it, all the manipulations will happen on data structures
in memory and whatever calculations are needed can be done as the document
is parsed and the object representation is built.  There are probably three
different rules you could use for making these decisions - what's easiest
for a program to output, what's easiest for a program to read in, or what's
easiest to use directly for whatever calculations are likely.   I guess that
my initial opinion was to optimize for the particular calculations that I
envisioned.  A question we need to ask is for which scenario should we optimize?
After we decide on that, and the follow on questions that answer implies,
we'll have an easier time on the design of the markup.<br>
<br>
Regards,<br>
<br>
Chris<br>
<br>
<a class="moz-txt-link-abbreviated" href="mailto:randyday+yahoo.com">randyday+yahoo.com</a> wrote:<br>
<blockquote type="cite" cite="mid:9p0ks9+2jou+eGroups.com">
  <pre wrap="">Is the offset from the last point or from the initial point? When <br>does it wrap? Wouldn't it be simpler to just use a time format that <br>has adequate precision? This would make parsing much easier and track <br>manipulation much easier...say for example turning a track into a <br>back-track route.  It also makes each data element much more self-<br>describing, which is a worth-while goal.<br><br>--- In gpsxml+y..., Chris Wilder-Smith <a class="moz-txt-link-rfc2396E" href="mailto:chris+w..."><chris+w...></a> wrote:<br></pre>
  <blockquote type="cite">
    <pre wrap="">Dave,<br><br>I agree with the concept of using a time offset in the track logs.  <br></pre>
    </blockquote>
    <pre wrap=""><!---->It <br></pre>
    <blockquote type="cite">
      <pre wrap="">almost seems to me that there has to be a different waypoint <br></pre>
      </blockquote>
      <pre wrap=""><!---->element for <br></pre>
      <blockquote type="cite">
        <pre wrap="">use in tracklogs than in routes or as standalone waypoints if you <br></pre>
        </blockquote>
        <pre wrap=""><!---->want <br></pre>
        <blockquote type="cite">
          <pre wrap="">to have support for validating the XML.  The question is how would <br></pre>
          </blockquote>
          <pre wrap=""><!---->you <br></pre>
          <blockquote type="cite">
            <pre wrap="">handle this DTD-wise?  The easy way is to make it all optional, but <br></pre>
            </blockquote>
            <pre wrap=""><!---->that <br></pre>
            <blockquote type="cite">
              <pre wrap="">puts more requirements on the parser side.  I personally think that <br>tracks are different enough from routes that they should be <br></pre>
              </blockquote>
              <pre wrap=""><!---->explicitly <br></pre>
              <blockquote type="cite">
                <pre wrap="">different elements.  Something like this:<br><br><track><br>    <point>  <!-- initial point --><br>         <time>20010927T093014Z</time><br>         <lat>42.34567</lat><br>         <lon>-71.34567</lon><br>         <alt>57.234</alt><br>    </point><br>    <track-point><br>          <time-offset>12.34</time-offset><br>          <lat>42.456789</lat><br>          <lon>-71.456789</lon><br>          <alt>57.234</alt><br>    </track-point><br>    ....<br></track><br><br>Where a route is built of all <point> elements.  You still run into <br></pre>
                </blockquote>
                <pre wrap=""><!---->the <br></pre>
                <blockquote type="cite">
                  <pre wrap="">problem, DTD-wise where <time> should be optional in a route or <br></pre>
                  </blockquote>
                  <pre wrap=""><!---->waypoint <br></pre>
                  <blockquote type="cite">
                    <pre wrap="">and you need it in the track for the initial point.  You could make <br></pre>
                    </blockquote>
                    <pre wrap=""><!---->it a <br></pre>
                    <blockquote type="cite">
                      <pre wrap="">separate element of track for the initial time and deal with <br></pre>
                      </blockquote>
                      <pre wrap=""><!---->duplicate <br></pre>
                      <blockquote type="cite">
                        <pre wrap="">information where the optional time used in the initial <point> <br></pre>
                        </blockquote>
                        <pre wrap=""><!---->could be <br></pre>
                        <blockquote type="cite">
                          <pre wrap="">ignored by the parser.  That seems like it might be a better <br></pre>
                          </blockquote>
                          <pre wrap=""><!---->solution, <br></pre>
                          <blockquote type="cite">
                            <pre wrap="">DTD and parser wise.<br><br>What do you think?<br><br>Regards,<br><br>Chris<br><br>davewissenbach+y... wrote:<br><br></pre>
                            <blockquote type="cite">
                              <pre wrap="">- Time will be expressed in UTC, which seems to be expressed in <br></pre>
                              </blockquote>
                              </blockquote>
                              <pre wrap=""><!---->XML <br></pre>
                              <blockquote type="cite">
                                <blockquote type="cite">
                                  <pre wrap="">like this: 20001108T093014Z (that's Nov 11, 2001, 09:30:14 UTC)<br>Reference: <a class="moz-txt-link-freetext" href="http://www.ietf.org/rfc/rfc2445.txt?number=2445">http://www.ietf.org/rfc/rfc2445.txt?number=2445</a><br><br>This guiding principle for the representation of time is OK for a <br>waypoint, but I think that it lacks precision for a track log <br></pre>
                                  </blockquote>
                                  </blockquote>
                                  <pre wrap=""><!---->where <br></pre>
                                  <blockquote type="cite">
                                    <blockquote type="cite">
                                      <pre wrap="">someone desires to measure speed. So I suggest that this <date-<br></pre>
                                      </blockquote>
                                      </blockquote>
                                      <pre wrap=""><!---->time> <br></pre>
                                      <blockquote type="cite">
                                        <blockquote type="cite">
                                          <pre wrap="">element (or attribute?) be part of a waypoint, track header, and <br>route, but that a track log be allowed an additional optional time <br>element which is a decimal offset, in seconds, from the base time.<br><br><br><br>To unsubscribe from this group, send an email to:<br>gpsxml-unsubscribe+y...<br><br><br><br>Your use of Yahoo! Groups is subject to <br></pre>
                                          </blockquote>
                                          </blockquote>
                                          <pre wrap=""><!----><a class="moz-txt-link-freetext" href="http://docs.yahoo.com/info/terms/">http://docs.yahoo.com/info/terms/</a> <br></pre>
                                          <blockquote type="cite">
                                            <blockquote type="cite">
                                              <pre wrap=""><br><br></pre>
                                              </blockquote>
                                              </blockquote>
                                              <pre wrap=""><!----><br><br>------------------------ Yahoo! Groups Sponsor ---------------------~--><br>Pinpoint the right security solution for your company- Learn how to add 128- bit encryption and to authenticate your web site with VeriSign's FREE guide!<br><a class="moz-txt-link-freetext" href="http://us.click.yahoo.com/yQix2C/33_CAA/yigFAA/2U_rlB/TM">http://us.click.yahoo.com/yQix2C/33_CAA/yigFAA/2U_rlB/TM</a><br>---------------------------------------------------------------------~-><br><br>To unsubscribe from this group, send an email to:<br><a class="moz-txt-link-abbreviated" href="mailto:gpsxml-unsubscribe+yahoogroups.com">gpsxml-unsubscribe+yahoogroups.com</a><br><br> <br><br>Your use of Yahoo! Groups is subject to <a class="moz-txt-link-freetext" href="http://docs.yahoo.com/info/terms/">http://docs.yahoo.com/info/terms/</a> <br><br><br><br></pre>
                                              </blockquote>
                                              <br>
                                              <pre class="moz-signature" cols="$mailwrapcol">-- 

           Misanthropist

N42 15.900 W071 21.069 Alt 56.7m/186'
</pre>
                                              <br>
                                              </body>
                                              </html>


Optimizing the XML format

egroups+topografix.com on Fri Sep 28 09:40:00 2001 (link), replying to msg

Hello,

Friday, September 28, 2001, 7:32:24 AM, Chris wrote:

CWS> ?When you get down to it, all the manipulations will happen on data structures
CWS> in memory and whatever calculations are needed can be done as the document
CWS> is parsed and the object representation is built. ?There are probably three
CWS> different rules you could use for making these decisions - what's easiest
CWS> for a program to output, what's easiest for a program to read in, or what's
CWS> easiest to use directly for whatever calculations are likely. ? I guess that
CWS> my initial opinion was to optimize for the particular calculations that I
CWS> envisioned. ?A question we need to ask is for which scenario should we optimize?
CWS> After we decide on that, and the follow on questions that answer implies,
CWS> we'll have an easier time on the design of the markup.

  I think Chris brings up a very important point.  Without an
  agreement on what scenario we're designing and optimizing the XML
  format for, we won't be able to reach consensus on questions about
  individual elements and attributes.

  In the initial mailing I sent out, I proposed that we focus on the
  *interchange* of data between apps, rather than on a native storage
  format or a format that mirrored our internal object models.  Some
  of us are writing new programs, and some of us have existing
  programs with much invested in our current objects.

  Everyone's going to be doing conversions of one sort or another to
  parse the text XML into binary objects in our applications.  My
  preference would be to keep the XML interchange format limited to a
  small number of base elements with a limited number of required
  attributes.  This will keep the work required to implement a 100%
  compliant parser to a minimum.  On top of that, we should layer
  optional attributes that some subset of us might be able to
  interchange.  If your application can't understand an optional
  attributes, no problem, you should just skip it.

  I don't know if everyone got the original message I sent out, so
  I'll post it again to the mailing list.
  
-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com


XML Format: The Basics

egroups+topografix.com on Fri Sep 28 09:43:12 2001 (link), replying to msg

Hello,

Before we get to the task of building a common XML format for GPS data
interchange, we need to agree on some basic principles and guidelines
for defining our format.  I've tried to express my thoughts and the
comments I received from others in the message below.  Please let me
know what you think of this proposal, especially if there are sections
you don't agree with.

------
Guiding principles:
 - A common XML data format for the exchange of GPS and
location-based information between computers benefits everyone.  It is
in our interests and the interests of our users to create a common
data exchange standard.

 - This is an open standard.  It is controlled by no one person, and
 it is free from copyright and other legal meddling.

 - This is a data exchange format, not a data storage format.
 Applications are free to implement as much of the format as needed,
 and ignore parts of the data stream.  The only requirement is that an
 application must be able to parse an arbitrary data stream without
 crashing.
 
 - This format allows for expansion.  Private elements and attributes
 can be added to the format.  To the extent possible, we will work
 together to define public structures that multiple applications can
 use, but any developer is free to add their own private data
 structures to any public element.

 - This standard is of no use unless people use it.  To that end, it
 should be lightweight, easy to implement, and flexible enough to
 accommodate new features as it matures.

 - This format is about data exchange, not data validation.
 Device-specific details like the number of characters in a waypoint
 name do not belong in the exchange format, they belong in the
 end applications.


On-disk representation:
This format needs a standard file representation on disk.  The
proposed file extension is .gpx (combining GPS and eXchange...).
Eventually, the format should have a common set of icons.


Standard Data Types:
The format will use standard data types (strings, floating point
numbers, integers, etc) to represent data.


Coordinate System and Units:
 - Coordinates will use WGS84 datum and signed decimal degrees
 format.

 - Time will be expressed in UTC, which seems to be expressed in XML
 like this: 20001108T093014Z (that's Nov 11, 2001, 09:30:14 UTC)
 Reference: http://www.ietf.org/rfc/rfc2445.txt?number=2445

 - The metric system will be used for other measures.  Elevations are
 in meters, for example.

 
Waypoint Symbols:
Most handheld GPS units associate an integer value with the waypoint
symbol.  This integer is useless without knowing what model of GPS is
being referenced since some integers map to different symbols
depending on the GPS model.  Instead of using the integer value, this
format will use the text associated with the waypoint symbol.
 - examples: Trail Head, Church, Diver Down
 

Public vs. Private Data Structures
To prevent collisions between publicly-adopted data structures and
private data, a simple naming convention will be used.
public names: short, generic words or abbreviations with no underscore
 - examples: ele, lat, id, name
private names: must begin with program/developer abbreviation and
underscore to prevent collisions with other private data.
 - examples: tg_userdata, tg_routecolor (TopoGrafix extensions)

 
-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com


RE: [gpsxml] Optimizing the XML format

kevin+synergysa.com.au on Fri Sep 28 10:01:19 2001 (link), replying to msg

Dan said

> Snip
>  In the initial mailing I sent out, I proposed that we focus on the
>  *interchange* of data between apps, rather than on a native storage
>  format or a format that mirrored our internal object models.  Some
>  of us are writing new programs, and some of us have existing
>  programs with much invested in our current objects.
> Snip

I certainly agree with this point.  If the final GPX specification promotes
the publicly-adopted data structures as a mandatory base for private usage,
I see no reason why other mini standars cannot be spawned that extend GPX
for other more specific requiremnets. i.e.

The obvious one to me is Geocaching.  Whilst the base spec satisfies most
data requirements, standard extensions to GPX can be employed to provide
additional geocache related information such as a narrative section for
cache descriptions or a reference to the geocache user who planted the
cache.

Another extension could be in the aviation field where additional tags can
be used for radio freqs and runway directions when route planning.

Whilst the each of the examples show that GPX will not satisfy ALL
requirements it does provide a great starting point for the base set of
tags/attributes and structure of the XML packet.  Perhaps a register can be
kept along side the GPX spec to record the extensions to the base format.

Kevin


Re: Optimizing the XML format: Track Logs

larrywjames+yahoo.com on Fri Sep 28 11:08:36 2001 (link), replying to msg

I would like to argue for track points as a separate element from waypoints. Most GPS applications, as well as storage within the GPS receiver, treat these as separate things. When you are importing from an exchange file to transfer to a GPS receiver, the software needs to know whether to send the point to the receiver as a track point or a waypoint. There is also the concept of whether the point starts a new track log or is a continuation of the same tracklog. One can imagine a real-time recorded file with a named waypoint which was marked in the middle of a bunch of unnamed track points.

The time for a tracklog point should be the absolute time to fractional second accuracy (how about 20011108T093014.673Z which might actually work in some current parsers), not a differential time from some other point. People regularly use text editors to remove some points or groups of points from track log files. If they remove the reference track point, then all the other differentially-timed points become useless.

Larry James
James Associates
303-258-0576


Re: [gpsxml] Re: Optimizing the XML format: Track Logs

egroups+topografix.com on Fri Sep 28 12:22:13 2001 (link), replying to msg

Hello,

Friday, September 28, 2001, 2:08:31 PM, Larry wrote:

lyc> I would like to argue for track points as a separate element from waypoints. Most GPS applications, as well as storage within the GPS receiver, treat these as separate things. When you are
lyc> importing from an exchange file to transfer to a GPS receiver, the software needs to know whether to send the point to the receiver as a track point or a waypoint. There is also the concept of
lyc> whether the point starts a new track log or is a continuation of the same tracklog. One can imagine a real-time recorded file with a named waypoint which was marked in the middle of a bunch of
lyc> unnamed track points.

Let me try to explain a reason for keeping trackpoints and waypoints
the same.  At the very simplest level, I think about these basic
elements in terms of their basic form.  I strip away everything that I
possibly can from waypoints and tracklogs while still keeping them
valid.  For example, a waypoint can still be a waypoint without
elevation.  Can it be a waypoint without latitude?  I don't believe so.
The very simplest waypoint is just a lat/lon pair.  A route is just a
bunch of lat/lon pairs in an ordered collection.  A tracklog is
identical to a route in its simplest form.  In my thinking, I treat
routes and tracks identically.  The fact that one is usually created
by adding waypoints to a list and the other is created by moving a
GPS around and recording data doesn't alter their common basic
structure.

But, as Larry points out, there are things that appear in tracklogs
that don't make much sense in waypoints.  Things like "begin new
track".    I can think of two ways to handle this, illustrated
below.  I'm going to use <point> and <path> to represent my "minimal"
waypoint and route/track elements.

1. make it an optional tag for all points, even though it only makes
sense for those points that are included in a tracklog.
<path name="example tracklog with two sections">
  <point lat="40.1" lon="-70.1" />
  <point lat="40.2" lon="-70.2" />
  <point lat="40.3" lon="-70.3" />
  <point lat="50.1" lon="-80.1" new_track="true" />
  <point lat="50.2" lon="-80.2" />
  <point lat="50.3" lon="-80.3" />
</path>

2. add a new element into <path>.  I'll make up a new element <link>
which describes the implied line segment connecting the two <point>
elements.
<path name="example tracklog with two sections">
  <point lat="40.1" lon="-70.1" />
  <point lat="40.2" lon="-70.2" />
  <point lat="40.3" lon="-70.3" />
  <link connected="false" />
  <point lat="50.1" lon="-80.1" />
  <point lat="50.2" lon="-80.2" />
  <point lat="50.3" lon="-80.3" />
</path>

I prefer the 2nd approach myself.  I can use this new <link> element
to describe a route, as well:
<path name="example route">
  <point lat="40.1" lon="-70.1" />
  <link description="US Route 40 East" />
  <point lat="40.2" lon="-70.2" />
  <link description="Highway 12" />
  <point lat="40.3" lon="-70.3" />
</path>

I believe that three basic elements <point> <path> and <link>, plus a
bunch of completely optional attributes are sufficient to describe the
things most of us would want to exchange between GPS and mapping
programs:
waypoints
routes
      routepoints
      legs (descriptions of the things that connect the routepoints)
tracks
      trackpoints
map annotations
    areas
    polygons
    text labels

Take the example of a user drawing a polygon on a map in one of our
programs (not mine - I don't support it!).   Perhaps this describes a
restricted area on a map.  The program writes out some XML data like
this:
<path foo_shape="poly" foo_color="blue">
  <point lat="40.1" lon="-70.1" />
  <point lat="40.2" lon="-70.2" />
  <point lat="40.3" lon="-70.3" />
</path>

My software has absolutely no idea what foo_shape and foo_color are,
but it knows to interpret <path> as a route by default.  So it brings
in the polygon as a route which shows up on my map where the user can
see it and edit it.

Contrast this against using separate elements to describe each
slightly different data type:
<private_poly foo_color="blue">
  <polypoint lat="40.1" lon="-70.1" />
  <polypoint lat="40.2" lon="-70.2" />
  <polypoint lat="40.3" lon="-70.3" />
</private_poly>

Here, my software doesn't know what a <private_poly> or a <polypoint>
is, so it ignores it.  Nothing shows up after the import.

I prefer reusing elements as much as possible, to maximize the amount
of data that can be successfully exchanged between applications with
varied purposes, while minimizing the size and complexity of our
parsers.

How do others feel about this issue?

lyc> The time for a tracklog point should be the absolute time to fractional second accuracy (how about 20011108T093014.673Z which might actually work in some current parsers), not a differential
lyc> time from some other point. People regularly use text editors to remove some points or groups of points from track log files. If they remove the reference track point, then all the other
lyc> differentially-timed points become useless.

I agree completely on this.

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com


Re: Optimizing the XML format: Track Logs

randyday+yahoo.com on Fri Sep 28 23:36:58 2001 (link), replying to msg

--- In gpsxml+y..., Dan Foster <egroups+t...> wrote:
> Hello,
> 
> Friday, September 28, 2001, 2:08:31 PM, Larry wrote:
> 
> lyc> I would like to argue for track points as a separate element 
from waypoints. Most GPS applications, as well as storage within the 
GPS receiver, treat these as separate things. When you are
> lyc> importing from an exchange file to transfer to a GPS receiver, 
the software needs to know whether to send the point to the receiver 
as a track point or a waypoint. There is also the concept of
> lyc> whether the point starts a new track log or is a continuation 
of the same tracklog. One can imagine a real-time recorded file with 
a named waypoint which was marked in the middle of a bunch of
> lyc> unnamed track points.
> 
> Let me try to explain a reason for keeping trackpoints and waypoints
> the same.  At the very simplest level, I think about these basic
> elements in terms of their basic form.  I strip away everything 
that I
> possibly can from waypoints and tracklogs while still keeping them
> valid.  For example, a waypoint can still be a waypoint without
> elevation.  Can it be a waypoint without latitude?  I don't believe 
so.
> The very simplest waypoint is just a lat/lon pair.  A route is just 
a
> bunch of lat/lon pairs in an ordered collection.  A tracklog is
> identical to a route in its simplest form.  In my thinking, I treat
> routes and tracks identically.  The fact that one is usually created
> by adding waypoints to a list and the other is created by moving a
> GPS around and recording data doesn't alter their common basic
> structure.
> 
> But, as Larry points out, there are things that appear in tracklogs
> that don't make much sense in waypoints.  Things like "begin new
> track".    I can think of two ways to handle this, illustrated
> below.  I'm going to use <point> and <path> to represent 
my "minimal"
> waypoint and route/track elements.
> 
> 1. make it an optional tag for all points, even though it only makes
> sense for those points that are included in a tracklog.
> <path name="example tracklog with two sections">
>   <point lat="40.1" lon="-70.1" />
>   <point lat="40.2" lon="-70.2" />
>   <point lat="40.3" lon="-70.3" />
>   <point lat="50.1" lon="-80.1" new_track="true" />
>   <point lat="50.2" lon="-80.2" />
>   <point lat="50.3" lon="-80.3" />
> </path>
> 
> 2. add a new element into <path>.  I'll make up a new element <link>
> which describes the implied line segment connecting the two <point>
> elements.
> <path name="example tracklog with two sections">
>   <point lat="40.1" lon="-70.1" />
>   <point lat="40.2" lon="-70.2" />
>   <point lat="40.3" lon="-70.3" />
>   <link connected="false" />
>   <point lat="50.1" lon="-80.1" />
>   <point lat="50.2" lon="-80.2" />
>   <point lat="50.3" lon="-80.3" />
> </path>
> 
> I prefer the 2nd approach myself.  I can use this new <link> element
> to describe a route, as well:
> <path name="example route">
>   <point lat="40.1" lon="-70.1" />
>   <link description="US Route 40 East" />
>   <point lat="40.2" lon="-70.2" />
>   <link description="Highway 12" />
>   <point lat="40.3" lon="-70.3" />
> </path>
> 
> I believe that three basic elements <point> <path> and <link>, plus 
a
> bunch of completely optional attributes are sufficient to describe 
the
> things most of us would want to exchange between GPS and mapping
> programs:
> waypoints
> routes
>       routepoints
>       legs (descriptions of the things that connect the routepoints)
> tracks
>       trackpoints
> map annotations
>     areas
>     polygons
>     text labels

I guess I need more explanation of a <link> element. I'm not sure I 
appreciate its purpose or usefulness. If a track has two different 
sections, why not something like:
<path name="section 1">
   <point lat="40.1" lon="-70.1" />
   <point lat="40.2" lon="-70.2" />
   <point lat="40.3" lon="-70.3" />
</path>
<path name="section 2">
   <point lat="50.1" lon="-70.1" />
   <point lat="50.2" lon="-70.2" />
   <point lat="50.3" lon="-70.3" />
</path>

 
> Take the example of a user drawing a polygon on a map in one of our
> programs (not mine - I don't support it!).   Perhaps this describes 
a
> restricted area on a map.  The program writes out some XML data like
> this:
> <path foo_shape="poly" foo_color="blue">
>   <point lat="40.1" lon="-70.1" />
>   <point lat="40.2" lon="-70.2" />
>   <point lat="40.3" lon="-70.3" />
> </path>
> 
> My software has absolutely no idea what foo_shape and foo_color are,
> but it knows to interpret <path> as a route by default.  So it 
brings
> in the polygon as a route which shows up on my map where the user 
can
> see it and edit it.
> 
> Contrast this against using separate elements to describe each
> slightly different data type:
> <private_poly foo_color="blue">
>   <polypoint lat="40.1" lon="-70.1" />
>   <polypoint lat="40.2" lon="-70.2" />
>   <polypoint lat="40.3" lon="-70.3" />
> </private_poly>
> 
> Here, my software doesn't know what a <private_poly> or a 
<polypoint>
> is, so it ignores it.  Nothing shows up after the import.
> 
> I prefer reusing elements as much as possible, to maximize the 
amount
> of data that can be successfully exchanged between applications with
> varied purposes, while minimizing the size and complexity of our
> parsers.
> 
> How do others feel about this issue?

The example of a poly as a <path> versus a <private_poly> is very 
well put.


> 
> lyc> The time for a tracklog point should be the absolute time to 
fractional second accuracy (how about 20011108T093014.673Z which 
might actually work in some current parsers), not a differential
> lyc> time from some other point. People regularly use text editors 
to remove some points or groups of points from track log files. If 
they remove the reference track point, then all the other
> lyc> differentially-timed points become useless.
> 
> I agree completely on this.
> 
> -- 
> Dan Foster
> TopoGrafix - GPS Software, Waypoints, and Maps
> http://www.topografix.com - mailto:egroups+t...


Re: [gpsxml] Re: Optimizing the XML format: Track Logs

egroups+topografix.com on Sun Sep 30 18:26:10 2001 (link), replying to msg

Hello,

Saturday, September 29, 2001, 2:36:56 AM, Randy wrote:

ryc> I guess I need more explanation of a <link> element. I'm not sure I 
ryc> appreciate its purpose or usefulness.

<link> would describe any additional information about the connection
between two <points> in a <path>.  Things like speed wouldn't go in
<link>, since they can be calculated directly from the two <points>.

Imagine converting driving directions from MapBlast into GPX format.
You'd have a list of <points>, but no place to store things like what
highway you're travelling on.  The highway isn't associated with point
A or point B, it's associated with the connection between point A and
point B.

For most "pure" GPS applications where you're just recording data in
and out of the GPS, <link> wouldn't get much use.  If you've looked at
the Garmin transfer protocol, you'll recall seeing link mentioned in
their route protocol.  They define things like "snap to road".  I
would add things like Larry's "start new track segment" to <link>,
since it describes the fact that the section between two <points> has
been broken due to a lost GPS signal.

[Just in case anyone isn't familiar with this "start new track"
situation, on a Garmin GPS if the user loses GPS signal or turns off
the GPS while recording a tracklog, and then restores the signal, the
GPS will keep the whole thing as one tracklog, but won't connect the
trackpoints across the dropout when it displays the tracklog on the
screen.  It reports "start new track" when you read back the
trackpoint where the signal was restored.]

ryc> If a track has two different sections, why not something like:
ryc> <path name="section 1">
ryc>    <point lat="40.1" lon="-70.1" />
ryc>    <point lat="40.2" lon="-70.2" />
ryc>    <point lat="40.3" lon="-70.3" />
ryc> </path>
ryc> <path name="section 2">
ryc>    <point lat="50.1" lon="-70.1" />
ryc>    <point lat="50.2" lon="-70.2" />
ryc>    <point lat="50.3" lon="-70.3" />
ryc> </path>

By making them into two separate <paths>, you've lost the fact that
they were part of the same track.

Maybe <link> isn't the best way to solve this particular case.  The
"start new track" situation comes about when the GPS loses lock (or
when the user turns the GPS off, etc).  Since people are going to want
to store accuracy and signal strength info for <points>, maybe this
problem can be addressed there.  Maybe through a "valid" flag or some
other mechanism.

Although, when I think about it more, in Larry's situation, the
<points> on either side of the "track dropout" are valid, and it's
really the "segment between the points" that needs to be marked as "no
data present".

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com


Re: Optimizing the XML format: Track Logs

randyday+yahoo.com on Tue Oct 02 23:10:47 2001 (link), replying to msg

--- In gpsxml+y..., Dan Foster <egroups+t...> wrote:

> <link> would describe any additional information about the 
connection
> between two <points> in a <path>.  Things like speed wouldn't go in
> <link>, since they can be calculated directly from the two <points>.
> 
> Imagine converting driving directions from MapBlast into GPX format.
> You'd have a list of <points>, but no place to store things like 
what
> highway you're travelling on.  The highway isn't associated with 
point
> A or point B, it's associated with the connection between point A 
and
> point B.

Ok, I see the functionality you are after. A construct like <link> is 
dependent on the <point> prior and after: should a track be edited, 
then there is potential for trouble.  Should a <link> have references 
to its endpoints?  Also, I'm not sure that I'd want to model driving 
directions in this manner...

> ryc> If a track has two different sections, why not something like:
> ryc> <path name="section 1">
> ryc>    <point lat="40.1" lon="-70.1" />
> ryc>    <point lat="40.2" lon="-70.2" />
> ryc>    <point lat="40.3" lon="-70.3" />
> ryc> </path>
> ryc> <path name="section 2">
> ryc>    <point lat="50.1" lon="-70.1" />
> ryc>    <point lat="50.2" lon="-70.2" />
> ryc>    <point lat="50.3" lon="-70.3" />
> ryc> </path>
> 
> By making them into two separate <paths>, you've lost the fact that
> they were part of the same track.

Is it important to retain the fact that they are part of the same 
track? (Serious question.) If a track is compossed of 1 or more 
sections, then why not model it as such?

<path>
<section>
<point blah.../>
<point blah.../>
</section>
<section>
<point blah.../>
<point blah.../>
</section>
</path>

Extrapolating this idea to the driving directions example, if a 
portion of the drive is along I-90, and we want to associate this 
with a set of points, then that information would be attributes of 
the <section> of the <path> in question. The next portion of the 
route that's along I-5 would be a new <section>, with new attributes.

This seems more general than the <link> construct in that it can 
apply to 2, 3, 4, or more points, not just two. It also solves the 
problem of making a <link> actually refer to the <points> in question.

> 
> Maybe <link> isn't the best way to solve this particular case.  The
> "start new track" situation comes about when the GPS loses lock (or
> when the user turns the GPS off, etc).  Since people are going to 
want
> to store accuracy and signal strength info for <points>, maybe this
> problem can be addressed there.  Maybe through a "valid" flag or 
some
> other mechanism.

Yes, I agree that accuracy and signal strength and number of stats 
used for the fix are things that people will want.

> 
> Although, when I think about it more, in Larry's situation, the
> <points> on either side of the "track dropout" are valid, and it's
> really the "segment between the points" that needs to be marked 
as "no
> data present".
> 
> -- 
> Dan Foster
> TopoGrafix - GPS Software, Waypoints, and Maps
> http://www.topografix.com - mailto:egroups+t...


Newbie question - format definition

jfmezei+videotron.ca on Fri Oct 12 00:55:51 2001 (link)

Ok, I have gone to the http://www.topografix.com/xml.asp page.

I have seen the general idea of the XML format for waypoints. But the 
page talks about being THE place for the actual format definition, but 
I can't see to find the actual format definition.

Is there some text document or must I run some of those windows 
applications to generate some sample XML format to see what the 
definitions are ?



Re: [gpsxml] Newbie question - format definition

chris+wilder-smith.org on Fri Oct 12 04:02:32 2001 (link)

jfmezei+videotron.ca wrote:

>Ok, I have gone to the http://www.topografix.com/xml.asp page.
>
>I have seen the general idea of the XML format for waypoints. But the 
>page talks about being THE place for the actual format definition, but 
>I can't see to find the actual format definition.
>
>Is there some text document or must I run some of those windows 
>applications to generate some sample XML format to see what the 
>definitions are ?
>

Hi,

As far as I know, there's no DTD yet.  When some of the details are 
firmed up, a DTD should be created.  Before that happens, the best you 
can do is to read the discussions and look at the example xml source.

Regards,

Chris



Re: [gpsxml] Re: Optimizing the XML format: Track Logs

egroups+topografix.com on Sun Oct 14 10:05:24 2001 (link), replying to msg

Hello,

Wednesday, October 03, 2001, 2:10:44 AM, Randy wrote:

ryc> --- In gpsxml+y..., Dan Foster <egroups+t...> wrote:

>> <link> would describe any additional information about the 
ryc> connection
>> between two <points> in a <path>.  Things like speed wouldn't go in
>> <link>, since they can be calculated directly from the two <points>.
>> 
>> Imagine converting driving directions from MapBlast into GPX format.
>> You'd have a list of <points>, but no place to store things like 
ryc> what
>> highway you're travelling on.  The highway isn't associated with 
ryc> point
>> A or point B, it's associated with the connection between point A 
ryc> and
>> point B.

ryc> Ok, I see the functionality you are after. A construct like <link> is 
ryc> dependent on the <point> prior and after: should a track be edited, 
ryc> then there is potential for trouble.  Should a <link> have references 
ryc> to its endpoints?

I think the implied order of the file takes care of this.  For
example, it's clear that the following three points are connected in
order:
<path>
      <point> ... </point>
      <point> ... </point>
      <point> ... </point>
</path>

ryc> Also, I'm not sure that I'd want to model driving
ryc> directions in this manner...

I'm also struggling to find a good solution here.  It may be that the
<link> element I proposed to store the "per-leg" information I keep in
my software doesn't have universal-enough appeal to make it into the
spec.  Fine by me...

>> ryc> If a track has two different sections, why not something like:
>> ryc> <path name="section 1">
>> ryc>    <point lat="40.1" lon="-70.1" />
>> ryc>    <point lat="40.2" lon="-70.2" />
>> ryc>    <point lat="40.3" lon="-70.3" />
>> ryc> </path>
>> ryc> <path name="section 2">
>> ryc>    <point lat="50.1" lon="-70.1" />
>> ryc>    <point lat="50.2" lon="-70.2" />
>> ryc>    <point lat="50.3" lon="-70.3" />
>> ryc> </path>
>> 
>> By making them into two separate <paths>, you've lost the fact that
>> they were part of the same track.

ryc> Is it important to retain the fact that they are part of the same
ryc> track? (Serious question.)

I think so.  But I don't think it's so important that it requires a
new element.  I prefer inserting an optional attribute into the first
point of the new segment to indicate that GPS lock was lost earlier.

ryc> If a track is compossed of 1 or more
ryc> sections, then why not model it as such?

ryc> <path>
ryc> <section>
ryc> <point blah.../>
ryc> <point blah.../>
ryc> </section>
ryc> <section>
ryc> <point blah.../>
ryc> <point blah.../>
ryc> </section>
ryc> </path>

I'd simplify things even more, and allow <path> to optionally contain other
<path> elements.  Here are some examples - the last one is the
interesting one.

<path type="rte" desc="Route">
        <point type="wpt" lat="42.1" lon="-71.2"/>
        <point type="wpt" lat="42.2" lon="-71.2"/>
        <point type="wpt" lat="42.3" lon="-71.2"/>
        <point type="wpt" lat="42.4" lon="-71.2"/>
</path>

<path type="trk" desc="Garmin Tracklog No Breaks">
        <point type="wpt" lat="42.1" lon="-71.2"/>
        <point type="wpt" lat="42.2" lon="-71.2"/>
        <point type="wpt" lat="42.3" lon="-71.2"/>
        <point type="wpt" lat="42.4" lon="-71.2"/>
</path>

<path type="trk" desc="Garmin Tracklog No Breaks - Another Valid Version">
        <path type="trk">
                <point type="wpt" lat="42.1" lon="-71.2"/>
                <point type="wpt" lat="42.2" lon="-71.2"/>
                <point type="wpt" lat="42.3" lon="-71.2"/>
                <point type="wpt" lat="42.4" lon="-71.2"/>
        </path>
</path>

<path type="trk" desc="Garmin Tracklog With Breaks">
        <path type="trk">
                <point type="wpt" lat="42.1" lon="-71.2"/>
                <point type="wpt" lat="42.2" lon="-71.2"/>
        </path>
        <path type="trk">
                <point type="wpt" lat="42.3" lon="-71.2"/>
                <point type="wpt" lat="42.4" lon="-71.2"/>
        </path>
</path>


Thoughts?
-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com


Re: [gpsxml] Optimizing the XML format: Track Logs

alan+computerweekly.net on Tue Oct 16 15:29:33 2001 (link)

I've just joined this new list and read the previous postings on the web site.  I sent an e-mail to the link on the Topografix site and received a reply.

I commentated that I thought the file format (as seen in the sample) was very wasteful in that too much was duplicated in the file and that it is very bloated with non-information padding.

I was asked to "suggest ways to make our example file less wordy?"

I suggested the use a single, or pair of characters to define a type of line.


Dan Foster <egroups+topografix.com> replying to Randy wrote in [gpsxml]:-

>>> Imagine converting driving directions from MapBlast into GPX format.  You'd have a list of <points>, but no place to store things like what highway you're travelling on.  The highway isn't associated point A or point B, it's associated with the connection between point A and point B.


> I'm also struggling to find a good solution here.  It may be that the <link> element I proposed to store the "per-leg" information I keep in my software doesn't have universal-enough appeal to make it into the spec.  Fine by me...

It depends on how one expects to use the data.  I use my Garmin 75 when on holiday.  I live in the UK and went to Germany as the example.  At the end of each day, or when the track memory filled; I saved my GPS log onto my Psion 5.

I can now plot each days travel onto a map (also on my Psion 5) of Germany.  By editing this file, I could add extra details like places of interest or campsites used.  This could then appear as waypoints on my maps.  At present the waypoints are downloaded separately and converted into 'overlay' files, which are similar to Microsoft AutoRoute pushpin files (but unlike MS files can be exported !)

When my photographs are returned from processing, I use the date/time printing on the back (APS film) with the GPS log, to tell me which town building is on any print.  I could use this to make an overlay file of all photos taken and even include a text description of certain prints.

Others would want to keep details of a future route where the road number and description between points of change in the route occur.

By having one single file format with a pair of characters defining the line type it would be very easy for application software to use or discard any line of information.

Any 'non-proprietary' like information could be added by having a 'comment' character ( ; ) start to that line.  A later version could possibly incorporate that line type into the standard specification.
-- 
Alan R Morris, G4ENS.
Bury St Edmunds, Suffolk, UK.
No HTML, using a Psion 5mx & Nokia 6210e at 9.6Kb.


Re[2]: [gpsxml] Optimizing the XML format: Track Logs

egroups+topografix.com on Tue Oct 16 15:47:34 2001 (link), replying to msg

Hello Alan,

Tuesday, October 16, 2001, 7:28:40 PM, you wrote:

AMG> I commentated that I thought the file format (as seen in the sample) was very wasteful in that too much was duplicated in the file and that it is very bloated with non-information padding.
...
AMG> By having one single file format with a pair of characters defining the line type it would be very easy for application software to use or discard any line of information.

AMG> Any 'non-proprietary' like information could be added by having a 'comment' character ( ; ) start to that line.  A later version could possibly incorporate that line type into the standard
AMG> specification.

  I'd need to see an example, but what you're describing sounds like a
  flat file format, and not an XML file.  XML, while being rather
  wordy, has the advantage that it's self describing, and can be
  easily transformed into many other forms.

  There are already several "standard" flat file formats for
  describing GPS data.  This group was formed to develop an XML
  format.

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com


Source field in waypoint

jfmezei+videotron.ca on Wed Oct 17 04:01:16 2001 (link)

I would like to see a field in waypoints added (optional, of course) to 
include text describing the source of the waypoint.

example: 
I would like to provide a list of waypoints for a bike trip across 
australia. Some of these waypoints come from my GPS , some come from 
AUSLIG and some come from Auslig's predecessor (MAN200R at erin.gov.au)

Since each of these have their own precision (or lack thereof), if 
someone is to rely on that list I provide, it would be nice for them to 
be able to know which waypoints might be more precice (taken by GPS) 
and which might be off by some distance (MAN200R).

Not sure there would be a need to defide the contents of that field. 
One could expect each provider of XML data sets to provide a 
description of that "source" field if it is to be used.

comments ?



<point> definition

egroups+topografix.com on Wed Oct 17 14:10:48 2001 (link), replying to msg

Hello,

I'd like to start putting together a list of attributes that might be
included in the public version of the <point> element.  Please add
anything you think your application might use, or that you think
others would benefit from.  My take on this is that <point> should
have a bare minimum of required attributes, and everything else should
be optional.

Here's a starting list.  Please add your suggestions.  For now, let's
not debate what anything means or whether it should be on the list.
Once we get a full list, we can combine similar items as needed and
debate whether things belong as required, optional, or private.

The format for the list below is:
attribute, short description, format, units, example|example2

required for point:
lat, latitude, double, WGS84 degrees, 45.1
lon, longitude, double, WGS84 degrees, -71.22344
type, what type of <point> element, text,, wpt|icon

optional for point:
ele, elevation, double, meters, 150.0
time, timestamp, text, 20001108T093014Z.120 (That's Nov 08, 2000 at
9:30:14.120 GMT)
sym, waypoint symbol, text,, Trail Head
wpt, waypoint id for GPS, text,, NEWYRK
com, waypoint comment for GPS, text,, NEW YORK CITY
desc, user's description, text,, Park your car here.
map, user's map, text,, USGS 7.5 Boston North
url, link to web, text,, http://www.weather.com/weather/local/USNY0996
hyp, text for url, text,, Weather Forecast for NYC
kind, kind of waypoint, text,, Shopping Center
src, source of data, text,, MAN200R at erin.gov.au
hdop, Horiz Dilution of Precision, double,, 2.0
vdop, Vert Dilution of Precision, double,, 6.0
fix, Type of GPS Fix, text,, 2D|3D|no

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com


Re[2]: [gpsxml] <point> definition

egroups+topografix.com on Wed Oct 17 19:42:34 2001 (link), replying to msg

Hello,

Wednesday, October 17, 2001, 10:10:21 PM, Henry wrote:

HCS> Dan -

HCS> This looks pretty good.  A few things come to mind when I look at this:

HCS> First, why only 3 or 4 character tags?  I thought the point in XML was to
HCS> have descriptive tags.  For instance: <hyp> - I had to think for a minute
HCS> to realize this means <hypertext>.

I was trying to find a balance between readability and wordiness.  For
things that aren't obvious from the short form (I think lat="42.134"
is pretty clear) the tags should be as long as needed to make it
readable.

HCS> Proximity waypoints - I don't use these myself but some people do.  How about:
HCS> proximity, proximity alarm distance, double, (See next comment), 50.0

sounds good.

HCS> Why are units (and format) specified?  I think these should be attributes:
HCS> <latitude datum="WGS84" format="DMS" direction="N">40 25 23.9</latitude>
HCS> <longitude datum="WGS84" format="degrees">-79.919467</longitude>
HCS> <elevation unit="feet" base="MSL">1150</elevation>

HCS> Can we even generalize this to handle UTM and Maidenhead Grid references?
HCS> How about:
HCS> <northing format="UTM">4475301</northing>
HCS> <easting>0591663</easting>
HCS> <zone>17T</zone>

HCS> (is the attribute format="UTM" necessary, or is it implied by having a
HCS> northing or easting tag?)

HCS> and:
HCS> <grid datum="maidenhead">FN00ak</grid>

We discussed this in some of the earlier e-mails (archives are at
http://groups.yahoo.com/group/gpsxml/messages)  See the thread about
XML Format: The Basics for some of the discussion.

This is an interchange format, so it's designed to be easy for you to
read my data with a minimal amount of work.  If we passed the datum as
an attribute, I could send you a bunch of waypoints in Qatar National
Datum.  Would you be able to convert it correctly?  By standardizing
on WGS84, decimal degrees, you're guaranteed that you'll be able to
deal with incoming data.  As long as you can convert to and from WGS84
deg.deg format into your preferred internal format, you can handle any
GPSXML file coming your way.

HCS> Of course, this necessitates defining what to do if an application doesn't
HCS> understand an attribute.  This could also be used to handle vendor specific
HCS> information:
HCS> <symbol garmin-icon="10/0">House</symbol>

It's really up to the application to determine what to do with data it
doesn't understand.  For optional attributes you don't understand, you
should ignore them.  I'd ignore your proximity attributes, even though
they are part of the public spec, since my app doesn't deal with
proximity waypoints.

The format allows for private attributes as well, so
you'll need to be able to successfully parse this:
<point type="wpt" lat="42.1" lon="-71.23" tg_active="true"/>

Each of us as program writers will have to decide how to handle
missing attributes that our programs might be expecting.  For example,
most GPS units want a waypoint to have an id, but it's currently an
optional attribute in the spec.  I'd handle that by keeping a counter
and naming the waypoint WPT001, WPT002, etc, but this is really a
program implementation issue and not part of the XML spec.
-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com


Re: <point> definition

davewissenbach+yahoo.com on Wed Oct 17 21:03:42 2001 (link), replying to msg

--- In gpsxml+y..., Dan Foster <egroups+t...> wrote:

I think that we should also consider a method of including an image 
with a type of point which is a landmark. I'm thinking here of the 
gpx format being used as a sort of a trail guide. But who knows how 
this will be used? One of the users of my unreleased freeware is 
using this to log Canoe trips. Who knew?

I'm not too happy about the idea of the <point> element being all 
things too all people, although if the group agrees on this approach 
I'll deal with it. I suggest as an alternative something like the 
following, where a simple point is embedded in a more complicated 
landmark or waypoint. Or instead of embedding, we could define other 
elements which are kinds of points with different sets of attributes 
or included elements.


<landmark id="L101">
<point lat="45.0" lon="-116" alt="800" date-time="whenever">
<name>Foote House</name>
<description>This is the cabin of Mary Hallock Foote, whose diary was 
featured in Wallace Stegner's book, Angle of Repose
</description>
<image> image data goes here </image>
</landmark>
> Hello,
> 
> I'd like to start putting together a list of attributes that might 
be
> included in the public version of the <point> element.  Please add
> anything you think your application might use, or that you think
> others would benefit from.  My take on this is that <point> should
> have a bare minimum of required attributes, and everything else 
should
> be optional.
> 
> Here's a starting list.  Please add your suggestions.  For now, 
let's
> not debate what anything means or whether it should be on the list.
> Once we get a full list, we can combine similar items as needed and
> debate whether things belong as required, optional, or private.
> 
> The format for the list below is:
> attribute, short description, format, units, example|example2
> 
> required for point:
> lat, latitude, double, WGS84 degrees, 45.1
> lon, longitude, double, WGS84 degrees, -71.22344
> type, what type of <point> element, text,, wpt|icon
> 
> optional for point:
> ele, elevation, double, meters, 150.0
> time, timestamp, text, 20001108T093014Z.120 (That's Nov 08, 2000 at
> 9:30:14.120 GMT)
> sym, waypoint symbol, text,, Trail Head
> wpt, waypoint id for GPS, text,, NEWYRK
> com, waypoint comment for GPS, text,, NEW YORK CITY
> desc, user's description, text,, Park your car here.
> map, user's map, text,, USGS 7.5 Boston North
> url, link to web, text,, 
http://www.weather.com/weather/local/USNY0996
> hyp, text for url, text,, Weather Forecast for NYC
> kind, kind of waypoint, text,, Shopping Center
> src, source of data, text,, MAN200R at erin.gov.au
> hdop, Horiz Dilution of Precision, double,, 2.0
> vdop, Vert Dilution of Precision, double,, 6.0
> fix, Type of GPS Fix, text,, 2D|3D|no
> 
> -- 
> Dan Foster
> TopoGrafix - GPS Software, Waypoints, and Maps
> http://www.topografix.com - mailto:egroups+t...


Re: <point> definition

jfmezei+videotron.ca on Wed Oct 17 22:59:16 2001 (link), replying to msg

A few comments:

re: WGS84.  

I tend to agree that the interchange format should be standardized. 
Since my GPS unit wants units in WGS84 during data transfers, I am 
biased towards that standard.

However, if this is to be a long term flexible standard, shouldn't 
there be a way to define the datum used in the header ? WGS84 could be 
defined as the default datum if not specified.

for instance:
<loc version="1.0" src="EasyGPS" datum="WSG84">

----

One "problem" I have with the definitions/terminology is the ability to 
provide different names to a waypoint.

on the web site, a construct such as:
<waypoint><name id="CACHE">FellsFolly Geocache</name>  is used.

id= would probably correspond to the "wpt" field in your list. (so 
perhaps "wpt" should be renamed to "ID".  

Would "FellsFolly Geocache" be considered the "com" (comment) ? The 
Garmin basic waypoint contains the indent X(6) and a "comment" field 
X(40).  But in practice, I am not sure that the "comment" name is 
appropriate. I would rather call it "full name".

-----

Is there a reason why "type" would be a required field ?

------

What is the use for "url" and "hyp" ???? 

-----------

Garmin has a new waypoint type, described at:
http://www.garmin.com/support/pdf/d109.txt

I find it interesting that they differentiate between depth and 
altitude.



Re: <point> definition

jfmezei+videotron.ca on Wed Oct 17 23:02:06 2001 (link), replying to msg

General question:

should the XML definition provide a "basic" lowest common denominator 
for data interchange, or should its definition be comprehensive to 
allow any/all vendors to use that format to store all of the data that 
their units are capable of ?

For instance, should all of the fields used by Garmin, Trimble, 
Magellan etc etc be combined into one large definition (with most 
fields optional, of course) or should the definition be fairly simple 
where the XML format would be seen only as a basic import/export format 
?



Re: [gpsxml] Re: <point> definition

egroups+topografix.com on Thu Oct 18 06:38:14 2001 (link), replying to msg

Hello,

Thursday, October 18, 2001, 12:03:38 AM, Dave wrote:

dyc> --- In gpsxml+y..., Dan Foster <egroups+t...> wrote:

dyc> I think that we should also consider a method of including an image 
dyc> with a type of point which is a landmark. I'm thinking here of the 
dyc> gpx format being used as a sort of a trail guide. But who knows how 
dyc> this will be used? One of the users of my unreleased freeware is 
dyc> using this to log Canoe trips. Who knew?

I do this with my products, but I don't embed the image in the file.
I use the hyperlink_text and url fields to link to an image on the
Internet.  This obviously requires that the images be available on the
Internet, but it saves having to put 100KB or more data directly into
the file.

dyc> I'm not too happy about the idea of the <point> element being all 
dyc> things too all people, although if the group agrees on this approach 
dyc> I'll deal with it. I suggest as an alternative something like the 
dyc> following, where a simple point is embedded in a more complicated 
dyc> landmark or waypoint. Or instead of embedding, we could define other 
dyc> elements which are kinds of points with different sets of attributes 
dyc> or included elements.

Sounds like it's time to start another discussion thread.  Look for my
<point> types message to follow...

dyc> <landmark id="L101">
dyc> <point lat="45.0" lon="-116" alt="800" date-time="whenever">
dyc> <name>Foote House</name>
dyc> <description>This is the cabin of Mary Hallock Foote, whose diary was 
dyc> featured in Wallace Stegner's book, Angle of Repose
dyc> </description>
dyc> <image> image data goes here </image>
dyc> </landmark>

I'd code this as:
<point type="landmark" lat="45.0" lon="-116" id="L101" alt="800" date-time="whenever">
<name>Foote House</name>                                             
<description>This is the cabin of Mary Hallock Foote, whose diary was
featured in Wallace Stegner's book, Angle of Repose                  
</description>                                                       
<image> image data goes here </image>                                
</point>


-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com


Re: [gpsxml] Re: <point> definition

egroups+topografix.com on Thu Oct 18 06:48:06 2001 (link), replying to msg

Hello jfmezei,

Thursday, October 18, 2001, 1:59:11 AM, you wrote:

jvc> A few comments:

jvc> re: WGS84.  

jvc> I tend to agree that the interchange format should be standardized. 
jvc> Since my GPS unit wants units in WGS84 during data transfers, I am 
jvc> biased towards that standard.

Me too.

jvc> However, if this is to be a long term flexible standard, shouldn't 
jvc> there be a way to define the datum used in the header ? WGS84 could be 
jvc> defined as the default datum if not specified.

jvc> for instance:
jvc> <loc version="1.0" src="EasyGPS" datum="WSG84">

Why put it there?
 - in case WGS84 is replaced by WGS2002.  (okay, I can understand that.)
 - in case I want to specify a different datum. (not everyone will be
 able to accept that datum.
 - other reason?
 
jvc> One "problem" I have with the definitions/terminology is the ability to 
jvc> provide different names to a waypoint.

jvc> on the web site, a construct such as:
jvc> <waypoint><name id="CACHE">FellsFolly Geocache</name>  is used.

jvc> id= would probably correspond to the "wpt" field in your list. (so 
jvc> perhaps "wpt" should be renamed to "ID".  

There's no reason to stick with the names I used for my internal 1.0
spec.

jvc> Would "FellsFolly Geocache" be considered the "com" (comment) ?
It would be the "desc" (description).  The comment would probably be
something like FELLSFOLLYGEOCACHE

jvc> The
jvc> Garmin basic waypoint contains the indent X(6) and a "comment" field 
jvc> X(40).  But in practice, I am not sure that the "comment" name is 
jvc> appropriate. I would rather call it "full name".

Agreed.

jvc> Is there a reason why "type" would be a required field ?

See the new "<point> types" e-mail.

jvc> What is the use for "url" and "hyp" ???? 

To specify a url, and the Text for the url, which leads to some
information the user has associated with the waypoint.  The example I
usually use is the weather forecast for the area, on weather.com
Others might link to a digital photo they took at the waypoint.

jvc> Garmin has a new waypoint type, described at:
jvc> http://www.garmin.com/support/pdf/d109.txt

jvc> I find it interesting that they differentiate between depth and 
jvc> altitude.

I still haven't figured out why they did this.  My code looks
something like:

if altitude is negative,
   d109_depth = 0-altitude
otherwise
   d109_altitude = altitude

Makes no sense to me.  Ideas?

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com


Re: [gpsxml] Re: <point> definition

egroups+topografix.com on Thu Oct 18 07:08:08 2001 (link), replying to msg

Hello,

Thursday, October 18, 2001, 2:02:03 AM, you wrote:

jvc> General question:

jvc> should the XML definition provide a "basic" lowest common denominator 
jvc> for data interchange

The required tags provide a basic lowest common denominator for data
interchange.

jvc>  or should its definition be comprehensive to
jvc> allow any/all vendors to use that format to store all of the data that 
jvc> their units are capable of ?

The optional tags and the private tags provide the comprehensiveness.

This format should be a higher level of abstraction than the binary
representation used by the GPS vendors.  Example:
Garmin GPS symbol: 8210
GPSXML encoding sym="Movie Theater"  NOT sym="8210" NOT
<sym src="garmin">8210</sym>

jvc> For instance, should all of the fields used by Garmin, Trimble, 
jvc> Magellan etc etc be combined into one large definition (with most 
jvc> fields optional, of course) or should the definition be fairly simple 
jvc> where the XML format would be seen only as a basic import/export format 
jvc> ?

There are some formats that do this.  Here's an example of what
they're doing at http://acro.harvard.edu/JL/XML/

...
<ids id3="STR" id5="STRLN" id6="STRLNG" id10="Sterling" CAI="Sterling" FAA="3b3" />
...

They've got waypoints (ids) defined for every possible length
(although they missed the 8-characters used by Lowrance and others).
They probably did this because in their competitions, having exact
names for airports is important.  I don't think it's that way for us.

If I send you a waypoint from my eTrex Legend, the waypoint id will be
"NEWYORKCTY".  If you need a 6 character waypoint id for your Magellan
GPS, it's up to you to determine how that gets chopped down.

My direct answer to your question is that we should try to find the
best combination of usable and meaningful tags that allows us to express
the data we'd like to move between applications.  There's a tradeoff
to make.  The fewer tags we pick, the more likely it is that your data
will be understood by my application.  The more tags we pick, the more
data can be expressed.

That's why we're making a list of the tags that each of our
applications would use.  If a few of us can agree on a definition of a
certain tag that our apps could exchange, we'll include it in the XML
spec.

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com


<point> types debate

egroups+topografix.com on Thu Oct 18 07:23:09 2001 (link), replying to msg

Hello,

Thursday, October 18, 2001, 9:31:18 AM, Dave wrote:

dyc>> I'm not too happy about the idea of the <point> element being all
dyc>> things too all people, although if the group agrees on this approach 
dyc>> I'll deal with it. I suggest as an alternative something like the 
dyc>> following, where a simple point is embedded in a more complicated 
dyc>> landmark or waypoint. Or instead of embedding, we could define other 

I've proposed having <point> contain a required tag "type" which would
distinguish between higher-level constructs like "waypoint",
"landmark", "text_annotation_on_map", etc.

Dave suggests that perhaps <point> should be embedded inside these
higher constructs like:
<text_annotation_on_map>
  <point lat="42.1" lon="-71.2">
  <text>This is a caption on the map<text>
</text_annotation_on_map>

Here's how I'd encode it:
<point type="text_annotation_on_map" lat="42.1" lon="-71.2" text="This
is a caption on the map">

If my app understood the text_annotation_on_map tag, it would know
exactly what to do with the <point> data.  If it didn't know what
text_annotation_on_map meant, it has two choices for handling the
unknown type tag:
 - ignore the point
 - fall back on some default behavior

The app might bring in the point as a default waypoint, so when the
user looked on the map, instead of a caption, he'd see a waypoint
called "This is a caption on the map".

I think this is a benefit to using the <point> type scheme.

---
<text_annotation_on_map>
  <point lat="42.1" lon="-71.2">
  <text>This is a caption on the map<text>
</text_annotation_on_map>

In Dave's construct, I don't feel good about parsing into an element
that I don't recognize.  So the data gets ignored, even though it
contains a perfectly good <point> element that I could import into my
app.

Thoughts?

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com


<point> types list

egroups+topografix.com on Thu Oct 18 07:34:48 2001 (link), replying to msg

Hello,

Let's start a list of point-specific concepts that might be useful to
share between GPS or mapping applications.  I think having such a list
will be helpful when we discuss what tags and elements to include in
the XML spec.

GPS Waypoint:
a <point> that's intended to be sent to a GPS and used as a navigation
aide.

GPS Trackpoint:
a <point> marking a position along a path.

Map Annotation:
a <point> on a map with some formatted text or a symbol.

Map Calibration Point:
a <point> on a map that ties a lat/lon <point> to an x/y pixel
location.

Destination:
a <point> to which you are navigating.

Others?


-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com


Re: [gpsxml] Source field in waypoint

alan+computerweekly.net on Thu Oct 18 14:49:59 2001 (link)

jfmezei+videotron.ca wrote:-

> Since each of these have their own precision (or lack thereof), if someone is to rely on that list I provide, it would be nice for them to be able to know which waypoints might be more precice (taken by GPS) and which might be off by some distance (MAN200R).

> Not sure there would be a need to defide the contents of that field. One could expect each provider of XML data sets to provide a description of that "source" field if it is to be used.

> comments ?

This is a subject that I have been giving much thought to for some time now.  I have a few years of collected waypoints from various sources and the precision of the posit cannot be recorded in existing file formats that I have seen.

Three methods come to mind.

1.	A field with the possible error in miles, Km or metres - disadvantages: needs to be worked-out & takes up more space.  Useful for items such as campsite posits taken from printed guides that often are a mile or more in error of an actual GPS fix.

2.	A single byte indicator.  This could be added to any posit at the end, just like a programming variable. $,#,!,% etc.  No indicator would indicate unknown precision.  Different characters could also indicate a different source for the data, with a key table earlier in the file, so #2 could indicate a different source to #49.

3.	Reduce the number of significant digits from the right.  The receiving software would need to take this into account.  This is the method used by radio hams when transmitting their posit, which is displayed in real time on maps.  Allows any required lack of precision. ie for privacy.

This method could also be used with the time field.

> 20001108T093014Z.120 (Nov 08, 2000 at 9:30:14.120 GMT)

allowing 200011 to indicate the month of Nov 2000.
-- 
Alan R Morris, G4ENS.
Bury St Edmunds, Suffolk, UK.
No HTML, using a Psion 5mx & Nokia 6210e at 9.6Kb.


Re: [gpsxml] Optimizing the XML format: Track Logs

alan+computerweekly.net on Thu Oct 18 14:50:05 2001 (link)

Dan Foster <egroups+topografix.com> wrote:-

> I'd need to see an example, but what you're describing sounds like a flat file format, and not an XML file.  XML, while being rather wordy, has the advantage that it's self describing, and can be easily transformed into many other forms.

> There are already several "standard" flat file formats for describing GPS data.  This group was formed to develop an XML format.

I accept the function of this group, but does all data have to be bracketed between wordy keywords ?  Would it be acceptable to have line entries within certain sections of the XML file ?

As well as being wordy (and therefore files being significantly larger) the format style would suggest to me, a much slower rate for any application reading that data, which ever method of file reading (char, line or disk sector) is used.  I would have thought that implementing an efficient parsing procedure would also be much slower, but I'm willing to learn if this is not the case.

Is the function of this group to produce a very pure XML file in preference to a possibly more efficient and practical file.  I'm not being awkward here, only asking for the ground rules.  If I'm out of step, then let me know.

I'm also involved with another group that is just about to start producing a common exchange file for campsite data which also incorporates GPS data.  As those with motorhomes, or RVs as Americans call them, would want to send these files by e-mail from other countries; file size is very important when using a mobile phone and palm size computing devices.

As palm size computers are used by an increasing number of GPS users, should this not be taken into account ?  Or does this belong elsewhere ?
-- 
Alan R Morris, G4ENS.
Bury St Edmunds, Suffolk, UK.
No HTML, using a Psion 5mx & Nokia 6210e at 9.6Kb.


Re: <point> types list

davewissenbach+yahoo.com on Fri Oct 19 05:45:57 2001 (link), replying to msg

--- In gpsxml+y..., Dan Foster <egroups+t...> wrote:
> Hello,
> 
> Let's start a list of point-specific concepts that might be useful 
to
> share between GPS or mapping applications.  I think having such a 
list
> will be helpful when we discuss what tags and elements to include in
> the XML spec.
> 
> GPS Waypoint:
> 
> GPS Trackpoint:

> Map Annotation:

> Map Calibration Point:

> Destination:

I don't think that destination is a type of point. I think that 
origin and destination are required elements contained in every path 
or sub-path. The origin and destination should be named points, which 
means to me what the wpt/id attribute is required for origin and 
destination.

> Others?
> 
> 
> -- 
> Dan Foster
> TopoGrafix - GPS Software, Waypoints, and Maps
> http://www.topografix.com - mailto:egroups+t...


Re: [gpsxml] <point> definition

alan+computerweekly.net on Fri Oct 19 14:42:38 2001 (link)

"Henry C. Schmitt" <Henry+Schmitt.org> wrote:-

>  <grid datum="maidenhead">FN00ak</grid>

Maidenhead is not a datum, it is a special format for displaying Lat/Long in one short code.  It is used by radio hams and replaced an earlier system known as 'QRA' locator, (I was at ZL08d) which only covered Europe.  Whereas Maidenhead is world wide.

The format was finalised in the UK town of Maidenhead, hence it's name, and at that time the use of a datum was never concidered (or even known about).  Today, WGS84 is the accepted datum for Maidenhead.
-- 
Alan R Morris, G4ENS.
Bury St Edmunds, Suffolk, UK.
No HTML, using a Psion 5mx & Nokia 6210e at 9.6Kb.


Re[2]: [gpsxml] <point> vs. <wpt>, <rtept>, etc.

egroups+topografix.com on Mon Oct 22 08:06:09 2001 (link), replying to msg

Hello,

Friday, October 19, 2001, 5:45:41 AM, Kjeld wrote:

KJ> In order to follow up on my previous comments I would suggest that instead
KJ> of requiring a <type> for each <point> (which actually makes the "point"
KJ> information redundant) then let us use different names for each type of
KJ> points.

KJ> This way we can distinguish between the relevant data for each point type
KJ> but still merge all info into one dtd.

KJ> For instance:

KJ> <wpt>[relevant tags for a waypoint]</wpt>
KJ> <trkpt>[relevant tags for a track point]</trkpt>
KJ> <rtept>[relevant tags for a route point]</rtept>

I can see that this approach makes it easier to validate with a DTD,
and if we're going to stick with a small number of <point> types, it
may be the better way to go.
-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com


Re: <point> vs. <wpt>, <rtept>, etc.

davewissenbach+yahoo.com on Mon Oct 22 21:01:30 2001 (link), replying to msg

I really like the compact coding of attributes in the point element. 

We need to decide what information is coded as attributes and what 
information is contained in other elements. 

I'm now emitting the following for a trackpoint:

<point type="trackpoint" lat="43.1234" lon="-116.2354" alt="894" 
time="20011021T142002Z"/>

although I prefer the following:

<trkpt lat="43... />

I think that for a waypoint, additional information such as 
description should be coded as elements rather than attributes, to 
keep from getting absurdly long tags.

The way I currently parse is to look ahead at the next tag to decide 
what the next element will be, and then let that element parse 
itself. That's why I prefer knowing from the tag what kind of element 
I'll be parsing.

I wonder if we could get farther, faster by working on some specific 
use cases and nailing down the coding for these, and then extending 
the format as necessary to converge on a workable standard?

--- In gpsxml+y..., Dan Foster <egroups+t...> wrote:
> Hello,
> 
> Friday, October 19, 2001, 5:45:41 AM, Kjeld wrote:
> 
> KJ> In order to follow up on my previous comments I would suggest 
that instead
> KJ> of requiring a <type> for each <point> (which actually makes 
the "point"
> KJ> information redundant) then let us use different names for each 
type of
> KJ> points.
> 
> KJ> This way we can distinguish between the relevant data for each 
point type
> KJ> but still merge all info into one dtd.
> 
> KJ> For instance:
> 
> KJ> <wpt>[relevant tags for a waypoint]</wpt>
> KJ> <trkpt>[relevant tags for a track point]</trkpt>
> KJ> <rtept>[relevant tags for a route point]</rtept>
> 
> I can see that this approach makes it easier to validate with a DTD,
> and if we're going to stick with a small number of <point> types, it
> may be the better way to go.
> -- 
> Dan Foster
> TopoGrafix - GPS Software, Waypoints, and Maps
> http://www.topografix.com - mailto:egroups+t...


Re: [gpsxml] Re: <point> vs. <wpt>, <rtept>, etc.

egroups+topografix.com on Mon Oct 22 21:18:48 2001 (link), replying to msg

Hello davewissenbach,

Tuesday, October 23, 2001, 12:01:25 AM, you wrote:

dyc> I really like the compact coding of attributes in the point element. 

dyc> We need to decide what information is coded as attributes and what 
dyc> information is contained in other elements. 

dyc> I'm now emitting the following for a trackpoint:

dyc> <point type="trackpoint" lat="43.1234" lon="-116.2354" alt="894" 
dyc> time="20011021T142002Z"/>

dyc> although I prefer the following:

dyc> <trkpt lat="43... />

dyc> I think that for a waypoint, additional information such as 
dyc> description should be coded as elements rather than attributes, to 
dyc> keep from getting absurdly long tags.

Let's try to keep things predictable, though.  Can we agree on a
scheme like:
attributes: tags with finite (< 20 characters?) data length
elements: tags with no restrictions on data length (text)

dyc> The way I currently parse is to look ahead at the next tag to decide 
dyc> what the next element will be, and then let that element parse 
dyc> itself. That's why I prefer knowing from the tag what kind of element 
dyc> I'll be parsing.

dyc> I wonder if we could get farther, faster by working on some specific 
dyc> use cases and nailing down the coding for these, and then extending 
dyc> the format as necessary to converge on a workable standard?

Sounds good.  Everyone should take a chunk of representative data from
their application and try to encode it in XML.  Let's see if we can
reach a consensus on some of the basic elements and tags.

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com


XML examples - <wpt>

egroups+topografix.com on Tue Oct 23 14:29:59 2001 (link), replying to msg

Hello,

Tuesday, October 23, 2001, 12:01:25 AM, Dave wrote:

dyc> I wonder if we could get farther, faster by working on some specific 
dyc> use cases and nailing down the coding for these, and then extending 
dyc> the format as necessary to converge on a workable standard?

Here are some examples of the waypoint data I'd be emitting from my software.
Key to the abbreviated tags I'm using in the examples below:

Attributes:
lat - latitude (required)
lon - longitude (required)
id - waypoint id, waypoint name
cmt - waypoint comment (older Garmins, Magellan GPS)
sym - waypoint symbol
ele - elevation (meters)

Elements:
desc - user description of waypoint
type - user category of waypoint
url - hyperlink associated with waypoint

1. Waypoint showing most fields from my software:
<wpt lat="44.27053" lon="-71.30417" ele="1919.6" id="WASHINGTON" sym="Summit">
<desc>Mount Washington, highest peak in New Hampshire</desc>
<type>Summit</type>
<url text="Mount Washington Observatory: Home Page">http://www.mountwashington.org/</url>
</wpt>

2. Waypoint showing basic fields from Magellan 315 GPS:
<wpt lat="44.21932" lon="71.3695" id="MIZPAH" cmt="MIZPAH HUT" sym="Filled Circle"/>

3. Waypoint with only required data:
<wpt lat="44.21932" lon="71.3695"/>

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com


XML examples - <rte>

egroups+topografix.com on Tue Oct 23 14:52:12 2001 (link), replying to msg

Hello,

Here are some examples of the route data I'd be emitting from my software.

1.Route showing most fields from my software:
<rte id="TOWER HIKE">
 <desc>Hike to the tower at the top of Bear Hill</desc>
 <url text="Middlesex Fells Reservation">http://www.state.ma.us/mdc/fells.htm</url>
 <rtept lat="42.43091" lon="-71.1079" ele="30.5" id="PARK" cmt="PARKING LOT" sym="Car">
  <desc>Parking Lot</desc>
  <type>Parking</type>
 </rtept>
 <rtept lat="42.43091" lon="-71.10763" ele="36.6" id="POND" cmt="POND" sym="Fishing Area">
  <desc>Bellevue Pond</desc>
  <type>Water</type>
 </rtept>
 <rtept lat="42.43272" lon="-71.1051" ele="61" id="TOWER" cmt="STONE TOWER" sym="House">
  <desc>Stone Tower</desc>
  <type>Tower</type>
 </rtept>
</rte>

2. Route showing basic fields from Magellan 315 GPS:
<rte id="TOWER HIKE">
 <rtept lat="42.43091" lon="-71.1079" id="PARK" cmt="PARKING LOT" sym="Car"/>
 <rtept lat="42.43091" lon="-71.10763" id="POND" cmt="POND" sym="Fishing Area"/>
 <rtept lat="42.43272" lon="-71.1051" id="TOWER" cmt="STONE TOWER" sym="House"/>
</rte>

3. Route with only required data:
<rte>
 <rtept lat="42.43091" lon="-71.1079"/>
 <rtept lat="42.43091" lon="-71.10763"/>
 <rtept lat="42.43272" lon="-71.1051"/>
</rte>

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com


XML examples - <trk>

egroups+topografix.com on Tue Oct 23 15:08:18 2001 (link), replying to msg

Hello,

Here are some examples of the track data I'd be emitting from my software.

1.Track showing most fields from my software:
<trk id="TOWER TRACK">
 <desc>Tracklog from hike to the tower at the top of Bear Hill</desc>
 <url text="Middlesex Fells Reservation">http://www.state.ma.us/mdc/fells.htm</url>
 <trkpt lat="42.43091" lon="-71.1079" ele="30.5" time="20011021T142002Z.1"/>
 <trkpt lat="42.43091" lon="-71.10763" ele="36.6" time="20011021T142003Z.293"/>
 <trkpt lat="42.43272" lon="-71.1051" ele="61" time="20011021T142004Z"/>
</trk>

2. Track showing basic fields from GPS (and a track with two segments):
<trk id="TOWER TRACK">
 <desc>Tracklog from hike to the tower at the top of Bear Hill</desc>
 <url text="Middlesex Fells Reservation">http://www.state.ma.us/mdc/fells.htm</url>
 <trkpt lat="42.43091" lon="-71.1079" ele="30.5" time="20011021T142002Z.1"/>
 <trkpt lat="42.43091" lon="-71.10763" ele="36.6" time="20011021T142003Z.293"/>
 <trkpt lat="42.43272" lon="-71.1051" ele="61" time="20011021T142004Z"/>
 <trkpt lat="42.43285" lon="-71.10124" ele="1000" time="20011021T142215Z" new_track="true"/>
 <trkpt lat="42.43285" lon="-71.10125" ele="1001" time="20011021T142216Z"/>
</trk>

3. Track with only required data:
<trk>
 <trkpt lat="42.43091" lon="-71.1079"/>
 <trkpt lat="42.43091" lon="-71.10763"/>
 <trkpt lat="42.43272" lon="-71.1051"/>
</trk>


I'm not completely satisfied with the representation of time.  Maybe
fractional seconds should be their own tag:
 <trkpt lat="42.43091" lon="-71.10763" ele="36.6" time="20011021T142003Z" millisecs="293"/>

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com


Re: XML examples - <trk>

davewissenbach+yahoo.com on Tue Oct 23 21:17:07 2001 (link), replying to msg

--- In gpsxml+y..., Dan Foster <egroups+t...> wrote:
> 
> I'm not completely satisfied with the representation of time.  Maybe
> fractional seconds should be their own tag:
>  <trkpt lat="42.43091" lon="-71.10763" ele="36.6" 
time="20011021T142003Z" millisecs="293"/>
> 

I was asking for more precision in time a while back, but I was way 
off base. The garmin unit doesn't even give fractional time, and I 
have no plans to support anything other GPS unit. I like using the 
international standard, and this was relatively easy for me to both 
generate and parse in my MFC Windows application.

I would agree that we shouldn't corrupt a known standard. I think 
that millisecs would be a much better way extend the time field where 
greater precision is required.

The examples look great. I'll try to generate something like these 
within the next week or so. I've taken down my old Web site because 
I've changed internet service providers. The new one will try to 
conform to our emerging standard as much as possible.

One thing I do wonder about is the url element, though. I'll confess 
that I know almost nothing about XML, but my reference, "XML in a 
Nutshell", by Harold and Means, publisher O'Reilly, talks about xlink 
attributes in an element, rather than URL's.

I will probably never get so sophisticated in my application as to 
use a URL. But I think that we've tended to agree that existing 
standards and precedent are important.

I would also like clarification on the difference between a waypoint 
and a routepoint. I've used these interchangeably. Is a waypoint a 
landmark which is not part of a route? Or does a routepoint contain 
all the information of a waypoint, plus turning instructions "Go left 
when you see the white rabbit?"


Re: [gpsxml] Re: XML examples - <trk>

egroups+topografix.com on Wed Oct 24 07:38:21 2001 (link), replying to msg

Hello davewissenbach,

Wednesday, October 24, 2001, 12:17:05 AM, you wrote:

dyc> --- In gpsxml+y..., Dan Foster <egroups+t...> wrote:
>> 
>> I'm not completely satisfied with the representation of time.  Maybe
>> fractional seconds should be their own tag:
>>  <trkpt lat="42.43091" lon="-71.10763" ele="36.6" 
dyc> time="20011021T142003Z" millisecs="293"/>
>> 

dyc> I was asking for more precision in time a while back, but I was way 
dyc> off base. The garmin unit doesn't even give fractional time, and I 
dyc> have no plans to support anything other GPS unit. I like using the 
dyc> international standard, and this was relatively easy for me to both 
dyc> generate and parse in my MFC Windows application.

Garmin GPS will put out fractional time if you're logging an NMEA data
stream.  The waypoint timestamps are rounded to the nearest second.

dyc> I would agree that we shouldn't corrupt a known standard. I think 
dyc> that millisecs would be a much better way extend the time field where 
dyc> greater precision is required.

Unless anyone objects, let's adopt this as the new time format.  Maybe
shorten millisecs to msecs?
time="20011021T142003Z" msecs="293"
time="20011021T142003Z" msecs="1" (note: this means 0.001 millisecs,
not 1/10th of a second!)
time="20011021T142003Z" msecs="100" (note: 1/10th of a second)

dyc> The examples look great. I'll try to generate something like these 
dyc> within the next week or so. I've taken down my old Web site because 
dyc> I've changed internet service providers. The new one will try to 
dyc> conform to our emerging standard as much as possible.

dyc> One thing I do wonder about is the url element, though. I'll confess 
dyc> that I know almost nothing about XML, but my reference, "XML in a 
dyc> Nutshell", by Harold and Means, publisher O'Reilly, talks about xlink 
dyc> attributes in an element, rather than URL's.

I'm fairly ignorant of xlink, but I thought it was a way to link to
other XML data.  The URL field I use is just a link to some web data
the user wants to associate with a waypoint or route (a .jpg photo, a
trip report, a website, etc).

dyc> I will probably never get so sophisticated in my application as to 
dyc> use a URL. But I think that we've tended to agree that existing 
dyc> standards and precedent are important.

If someone proposes a standard way of expressing it, I'm all for it.
I admit very little knowledge of either xlink or DTDs.

dyc> I would also like clarification on the difference between a waypoint 
dyc> and a routepoint. I've used these interchangeably. Is a waypoint a 
dyc> landmark which is not part of a route? Or does a routepoint contain 
dyc> all the information of a waypoint, plus turning instructions "Go left 
dyc> when you see the white rabbit?"

I've also used them interchangably in my applications and in my prior
XML format.  The reason to make them different elements was to make it
easier to validate with a DTD, as someone stated earlier.

<rtept> will end up containing all the valid tags for <wpt>, and
probably add some additional ones.

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com


Things we can agree on?

egroups+topografix.com on Mon Oct 29 15:03:10 2001 (link), replying to msg

Hello,

I think we're getting close to a consensus on some aspects of the new
GPS exchange format.  I'd like to start listing things we can agree
on, so that people who want to start using the format can begin
coding, and so we can document our progress.

Here's a list of things I haven't heard any objections to in a few
weeks.  If you don't agree with something listed here, please speak
up.  Also, feel free to add things that I've left out.  Anything that
survives on this list for a week will become part of the standard.

I'll start a second list of things that are still being debated, and
we'll try to bring those to a consensus soon.

Things we can agree on:

1. This is an XML interchange format.

2. It's called GPX, or GPS Exchange Format.  The file extension is .gpx.

3. All data in GPX is between the <gpx></gpx> tags.

4. There are three "first-level" tags defined so far, which are valid
within <gpx></gpx>.  They are:
<wpt> a waypoint
<rte> a route
<trk> a tracklog

5. Within <rte>, there is one "second-level" tag defined so far.  It
is <rtept>.

6. Within <trk>, there is one "second-level" tag defined so far.  It
is <trkpt>.

7. The only required tags for <wpt>, <rtept>, and <trkpt> are "lat"
and "lon".  These are attributes.

8. "lat" and "lon" are specified in decimal degrees, WGS84 only.

9. Private tags are allowed at any point within the XML file.  Private
tags must begin with an abbreviation of the application or company
name followed by an underscore, to prevent collisions with other
private tags and public tags.  (Example: tg_active, tg_src for private
tags defined by TopoGrafix.)

10. To be a "compliant GPX application", a program must only be able to
read any GPX file without crashing.  There is no requirement to
actually parse and import any or all of the data in the file.  Any tag
can be ignored by the application.  However, any program that produces
an error on well-formed GPX data is not compliant.   We'll have a
suite of test files from various applications for everyone to test
against for compliance.

11. The Metric system is to be used for all applicable units. (meters
for altitude, for example).

12. Time is expressed in UTC.

...others?...

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com


Still being discussed...

egroups+topografix.com on Mon Oct 29 15:14:50 2001 (link), replying to msg

Hello,

Here's a list of things that we haven't reached agreement on.  Please
add additional items to the list.  Let's see if we can reach consensus
on any of these items in the near future.

Things we're still discussing:

1. How to best represent time, including the treatment of fractional
seconds?
   Proposals so far:
   1. time="20011021T142003Z" msecs="293"
   2. time="20011021T142003.293Z"

2. How to decide between elements and attributes?
   Proposals so far:
   1. required tags == attributes; optional tags == elements
   2. based on length: elements for anything over 20 characters
   
3. How to deal with breaks in tracklogs?

...others?...

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com


Re: Things we can agree on?

davewissenbach+yahoo.com on Tue Oct 30 05:07:27 2001 (link), replying to msg

--- In gpsxml+y..., Dan Foster <egroups+t...> wrote:
> Hello,
> 
> I think we're getting close to a consensus on some aspects of the 
new
> GPS exchange format.  I'd like to start listing things we can agree
> on, so that people who want to start using the format can begin
> coding, and so we can document our progress.
> 
> Things we can agree on:
> 
>
I agree with all points except for 9 and 10.

I apologize for my earlier silence on the subject of private tags. 
I'd like to suggest an alternative for you all to consider.

I think that number 9 and 10 here go together. If we are going to 
write a DTD for the format, and I think that we should, number 10 
should also include the requirement that the document validate 
against the DTD. My first published format did validate against the 
DTD. I went to the trouble of validating the format by downloading 
the xerces XML parser and running one of their test applications 
which also validates. I think that requiring an application to 
validate against the DTD would go a long way towards ensuring that 
other gpx-aware applications which parse the data output by a rogue 
application don't crash!

Allowing private tags anywhere in the XML format might make it 
impossible to write a DTD, or at least one that has any meaning. So I 
would suggest that vendor-unique data be encapsulated in a specific 
tag, which can be inserted in any element. We might also go a step 
further and use namespaces for the private tags.

Each elements which allows for private data could then allow one or 
more of the specific private tag, which would then use the ANY syntax 
in the DTD for the elements. (The vendor tag would be required!). 
This scheme does not allow for private attributes, however. 

Such as
<trk>
<trkpt>
<trkpt>
<private vendor="DaveWissenbach">
<overlay layer="plan"/>
</private>
<trk>

In other words, encapsulate all of the "anything goes" stuff.

> 9. Private tags are allowed at any point within the XML file.  
Private
> tags must begin with an abbreviation of the application or company
> name followed by an underscore, to prevent collisions with other
> private tags and public tags.  (Example: tg_active, tg_src for 
private
> tags defined by TopoGrafix.)
> 
> 10. To be a "compliant GPX application", a program must only be 
able to
> read any GPX file without crashing.  There is no requirement to
> actually parse and import any or all of the data in the file.  Any 
tag
> can be ignored by the application.  However, any program that 
produces
> an error on well-formed GPX data is not compliant.   We'll have a
> suite of test files from various applications for everyone to test
> against for compliance.
> 
> 
> -- 
> Dan Foster
> TopoGrafix - GPS Software, Waypoints, and Maps
> http://www.topografix.com - mailto:egroups+t...


Re[2]: [gpsxml] Things we can agree on?

egroups+topografix.com on Tue Oct 30 19:48:29 2001 (link), replying to msg

Hello,

Tuesday, October 30, 2001, 12:58:30 AM, Kjeld wrote:

KJ> Hi,

>>I think we're getting close to a consensus on some aspects of the new
>>GPS exchange format.  I'd like to start listing things we can agree
>>on, so that people who want to start using the format can begin
>>coding, and so we can document our progress.

KJ> Good idea... mayby you could take this a bit farther by proposing examples
KJ> for waypoints, tracks and routes?

KJ> I would also like to get started asap, maybe we should focus on just the
KJ> waypoints, tracks and routes at first?

KJ> I am ready to implement the XML standard we may agree on in this forum.
KJ> Perhaps we should consider making a "beta" release in order to test it
KJ> thoroughly before agreeing on the "1.0" standard?

I'm also ready to start implementing GPX for test purposes in my apps, and
don't mind changing things if we change things.  Let's try to start a
list of tags that we already agree upon so we can get the basics
implemented.  Things like tracklogs and timestamps aren't ready yet,
but lat, lon, ele, id, and others are probably okay to start using.
I'll start a new message with a proposed list.

KJ> Some apps (like Cetus GPS for now :-) only write .gpx files. I would say
KJ> that any app that writes wellformed XML in the .gpx format but do not read
KJ> .gpx is also a compliant app.

Agreed.

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com


Re[2]: [gpsxml] Still being discussed...

egroups+topografix.com on Tue Oct 30 19:53:21 2001 (link), replying to msg

Hello,

Tuesday, October 30, 2001, 1:06:03 AM, Kjeld wrote:

KJ> Hi,

>>Here's a list of things that we haven't reached agreement on.  Please
>>add additional items to the list.  Let's see if we can reach consensus
>>on any of these items in the near future.

>>1. How to best represent time, including the treatment of fractional
>>seconds?
>>   Proposals so far:
>>   1. time="20011021T142003Z" msecs="293"
>>   2. time="20011021T142003.293Z"

KJ> I haven't seen the 20011021T142003Z standard before but if it is a well
KJ> known standard I don't think we should tamper with it hence I would vote
KJ> for 1.

KJ> On the other hand if it isn't that well known I would say 2. as it is
KJ> simpler and in my eyes also better.

KJ> Somebody... make a decission here :-)

I'm interested to see whether either of these two formats can be
easily expressed in the DTD, or transformed with XSL.

I'll try to research whether there's any consensus on the Net about
representing timestamps in XML.

>>2. How to decide between elements and attributes?
>>   Proposals so far:
>>   1. required tags == attributes; optional tags == elements
>>   2. based on length: elements for anything over 20 characters

KJ> As said before I am not that religious about this issue. One thing I like
KJ> about 1 though is that it makes a strict seperation between when to use
KJ> elements and when to use attributes.

KJ> I may foresee some problems with 2 due to differences of the apps that
KJ> support .gpx say for instance that an element in one app should really be
KJ> an attribute in another app if rules are to be followed.

KJ> A good thing about elements is that they are very easy to read on a small
KJ> display like for instance a Palm... but then again they tend to occupy more
KJ> space in al limited environment.

I initially proposed #2, and now you've convinced me to support #1.
Everything you wrote makes sense to me.

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com


Re: [gpsxml] Re: Things we can agree on?

egroups+topografix.com on Tue Oct 30 19:58:24 2001 (link), replying to msg

Hello,

Tuesday, October 30, 2001, 8:07:20 AM, Dave wrote:

dyc> I agree with all points except for 9 and 10.

dyc> I apologize for my earlier silence on the subject of private tags. 
dyc> I'd like to suggest an alternative for you all to consider.

dyc> I think that number 9 and 10 here go together. If we are going to 
dyc> write a DTD for the format, and I think that we should, number 10 
dyc> should also include the requirement that the document validate 
dyc> against the DTD. My first published format did validate against the 
dyc> DTD. I went to the trouble of validating the format by downloading 
dyc> the xerces XML parser and running one of their test applications 
dyc> which also validates. I think that requiring an application to 
dyc> validate against the DTD would go a long way towards ensuring that 
dyc> other gpx-aware applications which parse the data output by a rogue 
dyc> application don't crash!

dyc> Allowing private tags anywhere in the XML format might make it 
dyc> impossible to write a DTD, or at least one that has any meaning. So I 
dyc> would suggest that vendor-unique data be encapsulated in a specific 
dyc> tag, which can be inserted in any element. We might also go a step 
dyc> further and use namespaces for the private tags.

dyc> Each elements which allows for private data could then allow one or 
dyc> more of the specific private tag, which would then use the ANY syntax 
dyc> in the DTD for the elements. (The vendor tag would be required!). 
dyc> This scheme does not allow for private attributes, however. 

dyc> Such as
dyc> <trk>
dyc> <trkpt>
dyc> <trkpt>
dyc> <private vendor="DaveWissenbach">
dyc> <overlay layer="plan"/>
dyc> </private>
dyc> <trk>

You've convinced me.  Having a format that can be validated by a DTD
is a good reason to make this change.

As I've said before, DTDs aren't my strong suit, so I hope you'll help
define the DTD for GPX once we start putting the pieces together.

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com


Tags we can agree on?

egroups+topografix.com on Wed Oct 31 18:41:09 2001 (link), replying to msg

Hello,

Here are some tags that I haven't heard debated recently.   Any
objections, or can we start using these in early GPX implementations?

lat
type: required; attribute
valid in: <wpt>, <rtept>, <trkpt>
meaning: latitude of the point
units: decimal degrees, WGS84 datum
format: number
example: lat="42.1234"

lon
type: required; attribute
valid in: <wpt>, <rtept>, <trkpt>
meaning: longitude of the point
units: decimal degrees, WGS84 datum
format: number
example: lon="-71.1234"

ele
type: optional; element
valid in: <wpt>, <rtept>, <trkpt>
meaning: elevation of the point
units: meters
format: number
example: <ele>123.45</ele>

id
type: optional; element
valid in: <wpt>, <rtept>
meaning: GPS Waypoint name; short identifier for point
units: n/a
format: text
example: <id>NEWYRK</id>

cmt
type: optional; element
valid in: <wpt>, <rtept>
meaning: GPS Waypoint comment; long identifier for point
units: n/a
format: text
example: <cmt>NEW YORK CITY</cmt>

desc
type: optional; element
valid in: <wpt>, <rtept>
meaning: User's description of the point
units: n/a
format: text
example: <desc>New York City is also known as the Big Apple.</desc>

sym
type: optional; element
valid in: <wpt>, <rtept>
meaning: GPS Symbol for the point
units: n/a
format: text
example: <sym>Building</sym>

others?
-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com


Re: Things we can agree on?

davewissenbach+yahoo.com on Fri Nov 02 05:34:01 2001 (link), replying to msg

--- In gpsxml+y..., Dan Foster <egroups+t...> wrote:

I think that we're all XML novices here, but I'll write a DTD and 
validate output (yours and mine) just as soon as we can code some 
samples. I actually had finished converting my program to write your 
last sample formats, without the DTD, but I'm going to spend a little 
time to code the optional attributes as elements, per the most recent 
discussions here.

One thing that won't be covered by the DTD is a design decision that 
I had to make--that I would only separately output waypoints which 
are not part of routes.

The Garmin GPSs give us the waypoints twice, but I see no reason to 
encode all of these twice, once as a routepoint, and once as a 
waypoint.
> 
> As I've said before, DTDs aren't my strong suit, so I hope you'll 
help
> define the DTD for GPX once we start putting the pieces together.
> 
> -- 
> Dan Foster
> TopoGrafix - GPS Software, Waypoints, and Maps
> http://www.topografix.com - mailto:egroups+t...


GPX Sample File: Hike.gpx

egroups+topografix.com on Wed Nov 07 20:08:48 2001 (link), replying to msg

Hello,

Here's a sample GPX file containing some waypoints and a route from a
hike I took recently.  Comments?  Anyone else have sample data at this
point?  Eventually, we should have a set of GPX files to validate
against.

Hike.gpx

<?xml version="1.0"?>
<gpx version="1.0" src="EasyGPS">
<wpt lat="42.723617" lon="-71.912150">
 <id>BINNEYPOND</id>
 <desc>Binney Ponds</desc>
 <type>Pond</type>
 <sym>Fishing Area</sym>
</wpt>
<wpt lat="42.730400" lon="-71.918250">
 <id>LUNCH</id>
 <desc>Lunch Rocks</desc>
 <ele>517.300000</ele>
 <type>Summit</type>
 <sym>Picnic Area</sym>
</wpt>
<wpt lat="42.696767" lon="-71.892517">
 <id>WATATIC</id>
 <desc>Mount Watatic</desc>
 <ele>568.500000</ele>
 <type>Summit</type>
 <sym>Summit</sym>
</wpt>
<wpt lat="42.711233" lon="-71.898167">
 <id>STATELINE</id>
 <desc>NH-MA State Line</desc>
 <ele>485.600000</ele>
 <type>Intersection</type>
 <sym>Dot</sym>
</wpt>
<wpt lat="42.696850" lon="-71.904567">
 <id>PARKING</id>
 <desc>Parking Lot</desc>
 <ele>417.300000</ele>
 <type>Parking</type>
 <sym>Car</sym>
</wpt>
<wpt lat="42.733017" lon="-71.919000">
 <id>PRATTMOUNT</id>
 <desc>Pratt Mountain</desc>
 <type>Summit</type>
 <sym>Summit</sym>
</wpt>
<wpt lat="42.720267" lon="-71.912383">
 <id>STREAM</id>
 <desc>Stream Crossing</desc>
 <type>Stream</type>
 <sym>Dot</sym>
</wpt>
<rte>
<rtept lat="42.696850" lon="-71.904567">
 <id>PARKING</id>
 <desc>Parking Lot</desc>
 <ele>417.300000</ele>
 <type>Parking</type>
 <sym>Car</sym>
</rtept>
<rtept lat="42.696767" lon="-71.892517">
 <id>WATATIC</id>
 <desc>Mount Watatic</desc>
 <ele>568.500000</ele>
 <type>Summit</type>
 <sym>Summit</sym>
</rtept>
<rtept lat="42.711233" lon="-71.898167">
 <id>STATELINE</id>
 <desc>NH-MA State Line</desc>
 <ele>485.600000</ele>
 <type>Intersection</type>
 <sym>Dot</sym>
</rtept>
<rtept lat="42.720267" lon="-71.912383">
 <id>STREAM</id>
 <desc>Stream Crossing</desc>
 <type>Stream</type>
 <sym>Dot</sym>
</rtept>
<rtept lat="42.723617" lon="-71.912150">
 <id>BINNEYPOND</id>
 <desc>Binney Ponds</desc>
 <type>Pond</type>
 <sym>Fishing Area</sym>
</rtept>
<rtept lat="42.730400" lon="-71.918250">
 <id>LUNCH</id>
 <desc>Lunch Rocks</desc>
 <ele>517.300000</ele>
 <type>Summit</type>
 <sym>Picnic Area</sym>
</rtept>
<rtept lat="42.733017" lon="-71.919000">
 <id>PRATTMOUNT</id>
 <desc>Pratt Mountain</desc>
 <type>Summit</type>
 <sym>Summit</sym>
</rtept>
</rte>
</gpx>




-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com


Re: GPX Sample File: Hike.gpx

davewissenbach+yahoo.com on Wed Nov 07 21:16:56 2001 (link), replying to msg

--- In gpsxml+y..., Dan Foster <egroups+t...> wrote:
> Hello,
> 
> Here's a sample GPX file containing some waypoints and a route from 
a
> hike I took recently.  Comments?  Anyone else have sample data at 
this
> point?  Eventually, we should have a set of GPX files to validate
> against.
> 
> Hike.gpx
> 

I've posted sample data at my incomplete web site. Deep link to the 
URL

www.cableone.net/cdwissenbach/FileFormat.gpx

The document is not valid against the DTD because I did not define 
the tags contained in the <private> element. The ANY keyword does not 
absolve one from the responsibility of defining the other elements. 
My reading of the XML specification indicates that we should be able 
to have both an external DTD and inline portion. I'll let you know if 
this works. Also, although my application outputs gpx format, the 
application doesn't read its own output! That's next week's job.

I've not finished the DTD. I'll Add  K.J.'s stuff and the attributes 
of gpx, version and src, and correct any other omissions.



Timestamp format?

egroups+topografix.com on Thu Nov 08 07:21:47 2001 (link), replying to msg

Hello,

Tuesday, October 30, 2001, 10:47:28 PM, I wrote:

>>>1. How to best represent time, including the treatment of fractional
>>>seconds?
>>>   Proposals so far:
>>>   1. time="20011021T142003Z" msecs="293"
>>>   2. time="20011021T142003.293Z"

Do a google search for "XML timestamp" and you'll find references to
the ISO 8601 spec, which gives a way to represent timestamps:

ccyy-mm-ddThh:mm:ss.fffffffffZ        (Z means this is UTC)
ccyy-mm-ddThh:mm:ss.fffffffff+HH:MM   (local time with UTC offset)

The example time above: Oct 21, 2000 at 14:20:03 and 293 milliseconds
UTC would be expressed as follows:

2001-10-21T14:20:03.293Z
2001-10-21T14:15:03.293-05:00   (US East coast at UTC-5)

Most of the punctuation is optional, but I'd suggest requiring it for
readability.  I'd also suggest only supporting the UTC version.  I
can't think of any reason why it would be important to know the
timezone where the point was recorded, especially on every point in
the file.

Any objections to this as the timestamp format?
ccyy-mm-ddThh:mm:ss.fffffffffZ
2001-10-21T14:20:03.293Z

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com


Re[2]: [gpsxml] Timestamp format?

egroups+topografix.com on Thu Nov 08 07:53:00 2001 (link), replying to msg

Hello,

Thursday, November 08, 2001, 9:37:08 AM, Kjeld wrote:

KJ> I (myself) can also live without the timezone information. But every time I
KJ> try to do something in UTC only, I get a mailstorm from my users who
KJ> complaints that if you have a rather big offset it also influences the date
KJ> for instance in the evening. Hence it may be a little confusing without, if
KJ> you go for a walk and manually add some waypoints along the trip.

KJ> I would therefore like to be able to add an optional <utc> element to solve
KJ> this problem. For a normal waypoint there's not much usage of millisecs, if
KJ> the local time can have an offset of several hours :-)

Isn't this just a display issue for your software?  For example, in my
software, I store all timestamps in UTC, and I have a preference that
lets the user choose how to display dates and times:
 - local 12 hr
 - local 24 hour
 - UTC

If they want to see data in local time, I do the conversion to/from UTC
using the time zone information on their computer.  (I don't know if
this is available on Palm - you can always ask the user for a UTC offset)

To me, this is like feet vs. meters.  Nobody here in the US knows what a
meter is, but we can still use meters in the GPX format because the
software applications can convert to whatever format the user wants to
use to display information on the screen.

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com


Re[2]: [gpsxml] GPX Sample File: Hike.gpx

egroups+topografix.com on Thu Nov 08 08:36:03 2001 (link), replying to msg

Hello,

Thursday, November 08, 2001, 3:21:05 AM, Kjeld wrote:

KJ> Hi....

KJ> A few comments...

KJ> The owerall format looks great and mine is very similar to it. I am not
KJ> sure if we have to put a </xml> tag at the bottom in order to "close" the
KJ> <?xml....> tag?

None of the XML files I've seen do this.

KJ> I would consider src="EasyGPS" as optional which by your current format
KJ> should then be coded as an element?

We haven't talked about this yet, and I just put it in my example file
because it was already in my old XML format.  I think it would be good
to have some indication of the application used to create the file,
for the following reasons:
 - if you find a non-conforming GPX file, you know who to alert.
 - if someone who's never heard of GPX gets a file, they might be able
 to figure out that they can open it with the application listed.

Making this optional info is fine with me, although that makes it
harder to track down bad file generators.

KJ> Perhaps we should save the <id> tag for numbering of tracks and routes and
KJ> then use <name> instead for the name?

Agreed.  Use <name> for the waypoint name.

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com


point src and accuracy

egroups+topografix.com on Thu Nov 08 09:22:40 2001 (link), replying to msg

Hello,

Thursday, November 08, 2001, 11:03:21 AM, Kjeld wrote:

KJ> I see your point, but my idea with the <src> was somewhat different.

KJ> I haven't thought about the "who created this file" issue. My idea was
KJ> something like a "Who created this waypoint" element.

KJ> Knowing from where the data originates you may be able to tell something
KJ> about the accuracy. I for instance lists <src>App name and version
KJ> (detected GPS receiver)</src>.

KJ> If the .gpx file comes from a database changing the <src> to the database
KJ> name causes this information to disappear, and if you maintain a
KJ> compilation of several waypoints it would be nice to know which app and GPS
KJ> did create each waypoint.

KJ> Maybe we need both? something like....

KJ> <gpx version="0.1" creator="myWptDb">
KJ> <wpt lat="10.000" lon="10.000" >
KJ> ...
KJ> <src>theNameOfMyAppOrGPS</src>
KJ> </wpt>
KJ> </gpx>

KJ> Comments please...

  I agree that there can be a need for both.  "who created this file?"
  and "who created this waypoint?" and "how accurate is this
  waypoint?" are all valid questions that GPX should be able to
  answer.

  So how do we answer the questions?
  1. who created this file?
  A text string identifying the app or DB that created the file:
  <gpx creator="MyApp v1.23 http://www.myapp.com/">

  2. who created this point?
  How do you answer this question?  How do you answer it such that
  another app can interpret the answer?
  Possible answers:
   - Retrieved from GPS.
   - Retrieved from Garmin eTrex.
   - Retrieved from Magellan GPS in DGPS mode.
   - User entered coordinates.
   - Digitized from map.
   - others?

  3. how accurate is this point?
  How do you answer this question?  How do you answer it such that
  another app can interpret the answer?
  Possible answers:
   - <hdop>2.0</hdop>
   - <fix>3D</fix> (or 2D, DGPS, etc)
   - others?

   Questions 2 and 3 are difficult to answer in a standardized way.  I
   know some of you were thinking about data averaging and accuracy in
   your apps.  Any thoughts on how to represent this in GPX?
   
-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com


Re: GPX Sample File: Hike.gpx

davewissenbach+yahoo.com on Thu Nov 08 21:36:07 2001 (link), replying to msg

--- In gpsxml+y..., Kjeld Jensen <gps+c...> wrote:
> Hi....
> 
> A few comments...
> 
> 
> Perhaps we should save the <id> tag for numbering of tracks and 
routes and
> then use <name> instead for the name?
> 
> 

Why is ID a required attribute of a trkpt and a rtpte? (Remember that 
we have previously agreed that required attributes of an element 
would be coded with the XML attribute syntax, and that optional data 
would be coded as elements.) Have we changed this rule while I was 
offline? If so, I'd suggest that we use id in the XML sense of the 
word, as a special kind of attribute that must be unique from all 
other attributes. The Garmin GPS requires that all waypoints be 
unique, and the ID is used for display purposes. Usability would be 
improved if the source application could control the ID which is 
displayed on the Garmin unit, which therefore implies that all 
waypoints have a Unique ID. And because routes are composed of 
waypoints, routepoints must also have unique ID's. But I'd make these 
optional.

So my view of the GPS/GPX world is in conflict with the numbered ID 
sequence which you propose below. Or is what I'm referring to above 
as an ID now to be called a name?

What is the purpose of sequentially numbering points within a track 
or route? If the purpose is just to detect loss of lock on the GPS, 
or a break in a track, can we code this in some other way?

> <wpt lat="42.723617" lon="-71.912150"> (no id necessary)
> ...
> </wpt>
> 
> <route>
> <rtept id="1" lat="42.723617" lon="-71.912150">
> ...
> </rtept>
> <rtept id="2" lat="42.723617" lon="-71.912150">
> ...
> </rtept>
> <rtept id="3" lat="42.723617" lon="-71.912150">
> ...
> </rtept>
> </route>
> 
> <track>
> <trkpt id="1" lat="42.723617" lon="-71.912150">
> ...
> </trkpt>
> <trkpt id="2" lat="42.723617" lon="-71.912150">
> ...
> </trkpt>
> <trkpt id="3" lat="42.723617" lon="-71.912150">
> ...
> </trkpt>
> </track>
> 
> 
> I will make a few changes to the Cetus GPS software today in order 
to adapt
> some of the features in your sample file. Then I will then post the 
result
> here..
> 
> Kjeld
> 
> 
> ______________________
> Kjeld Jensen
> N 55� 22' E 10� 24'
> Email: gps+c...
> http://www.cetus.dk/gps


RE: [gpsxml] Re: GPX Sample File: Hike.gpx

kevin+synergysa.com.au on Thu Nov 08 22:07:53 2001 (link), replying to msg


I agree somewhat....

rather than "id" for trackpoints perhaps a sequence is inferred here
instead.

taking the sample this would equate to

> <route>
> <rtept seq="1" lat="42.723617" lon="-71.912150">
> ...
> </rtept>
> <rtept seq="2" lat="42.723617" lon="-71.912150">
> ...
> </rtept>
> <rtept seq="3" lat="42.723617" lon="-71.912150">
> ...
> </rtept>
> </route>

this would allow for an application to confidently sort the route/track
using DOM or XSLT for purposes such as track reversal

Kevin

 -----Original Message-----
From: davewissenbach+yahoo.com [mailto:davewissenbach+yahoo.com]
Sent: Friday, 9 November 2001 4:06 PM
To: gpsxml+yahoogroups.com
Subject: [gpsxml] Re: GPX Sample File: Hike.gpx


  --- In gpsxml+y..., Kjeld Jensen <gps+c...> wrote:
  > Hi....
  >
  > A few comments...
  >
  >
  > Perhaps we should save the <id> tag for numbering of tracks and
  routes and
  > then use <name> instead for the name?
  >
  >

  Why is ID a required attribute of a trkpt and a rtpte? (Remember that
  we have previously agreed that required attributes of an element
  would be coded with the XML attribute syntax, and that optional data
  would be coded as elements.) Have we changed this rule while I was
  offline? If so, I'd suggest that we use id in the XML sense of the
  word, as a special kind of attribute that must be unique from all
  other attributes. The Garmin GPS requires that all waypoints be
  unique, and the ID is used for display purposes. Usability would be
  improved if the source application could control the ID which is
  displayed on the Garmin unit, which therefore implies that all
  waypoints have a Unique ID. And because routes are composed of
  waypoints, routepoints must also have unique ID's. But I'd make these
  optional.

  So my view of the GPS/GPX world is in conflict with the numbered ID
  sequence which you propose below. Or is what I'm referring to above
  as an ID now to be called a name?

  What is the purpose of sequentially numbering points within a track
  or route? If the purpose is just to detect loss of lock on the GPS,
  or a break in a track, can we code this in some other way?

  > <wpt lat="42.723617" lon="-71.912150"> (no id necessary)
  > ...
  > </wpt>
  >
  > <route>
  > <rtept id="1" lat="42.723617" lon="-71.912150">
  > ...
  > </rtept>
  > <rtept id="2" lat="42.723617" lon="-71.912150">
  > ...
  > </rtept>
  > <rtept id="3" lat="42.723617" lon="-71.912150">
  > ...
  > </rtept>
  > </route>
  >
  > <track>
  > <trkpt id="1" lat="42.723617" lon="-71.912150">
  > ...
  > </trkpt>
  > <trkpt id="2" lat="42.723617" lon="-71.912150">
  > ...
  > </trkpt>
  > <trkpt id="3" lat="42.723617" lon="-71.912150">
  > ...
  > </trkpt>
  > </track>
  >
  >
  > I will make a few changes to the Cetus GPS software today in order
  to adapt
  > some of the features in your sample file. Then I will then post the
  result
  > here..
  >
  > Kjeld
  >
  >
  > ______________________
  > Kjeld Jensen
  > N 55? 22' E 10? 24'
  > Email: gps+c...
  > http://www.cetus.dk/gps


        Yahoo! Groups Sponsor
              ADVERTISEMENT




  To unsubscribe from this group, send an email to:
  gpsxml-unsubscribe+yahoogroups.com



  Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.


------=_NextPart_000_0002_01C1693C.D626B620

XML Schema. The new new thing.

davewissenbach+yahoo.com on Sun Nov 11 20:57:23 2001 (link)

Periodically we post a digest of things that we've agreed on, and I 
attempted, about a week ago, to encode these in a DTD. I ran into 
trouble when I attempted to validate this DTD against my own private 
elements, as the private elements aren't known to the DTD.

One way to solve this problem might be to use both an internal and 
external DTD subset, but I think instead that we should switch to 
using XML Schema, which is a new recommendation from the WWW3 
consortiom. A variant of this is already supported by Internet 
Explorer.

The advantage is that the XML-Schema is open. The existence of 
private elements, such as my overlay data, need not be documented in 
the DTD for validity. Another advantage is that the XML-schema 
provides a better description of data types. Dan Foster in his 
excellent digests always provides units and format, and we should not 
lose this information.

So I withdraw my previous offer to maintain a DTD, an already 
obsolete version of which is part of the preamble to my sample format 
at www.cableone.net/cdwissenbach/FileFormat.gpx.

I'll be updating the file format to change "id" to "name", and to 
include punctuation - - : : to dates to improve readability, as was 
previously suggested here. I'd like to keep the specification as 
formal as possible, in order to avoid a proliferation of programs 
which speak slightly different dialects and are therefore all 
incompatible.

Do we have a listener who knows something about XML-Schema who is 
willing to provide a first draft?


Trail mapping program demonstration of gpx format

davewissenbach+yahoo.com on Sun Nov 18 06:54:35 2001 (link)

I've completed the conversion of my trail mapping program to our 
evolving gpx format. I read both <id> and <name> tags, but output 
<name> for names of all tracks, routes, and waypoints.

My previously published sample used waypt instead of <wpt>, and I 
have corrected that error. I output first-level elements in the order 
<wpt>,<rte>,<trk>.

I have successfully read Dan Foster's previously posted snippet of 
data from EasyGPS, which contains a route only. We need to reach 
agreement on a set of names for symbols, though. Dan uses "Fishing 
Area" but I use "Fish", so his "Fishing Area" comes out on my program 
as a dot.

I have used the <private> tag encapsulating layer information for my 
maps. I originally proposed the usage of this tag to encapsulate 
private data, but if we go away from a rigid DTD in favor of using 
XML Schema, this encapsulation is no longer necessary. I think that 
we should go back a variant of Dan's original proposal for private 
tags--He proposed wissenbach_layer, or yourprogram_display as a means 
of distinguishing tags. I'd use XML namespace syntax instead, and say
wissenbach:layer or foster:display or jensen:precision for our 
favorite private tags. I think that ignoring the contents of 
<private> tags other than our own will add too much complexity to the 
parsing.

The sample program and data files are available at the URL

http://www.cableone.net/cdwissenbach

Please do not share this link, as the file format is of course 
rapidly changing!!


Re: [gpsxml] Trail mapping program demonstration of gpx format

egroups+topografix.com on Mon Nov 19 09:33:18 2001 (link), replying to msg

Hello,

Sunday, November 18, 2001, 9:54:26 AM, Dave wrote:

dyc> I've completed the conversion of my trail mapping program to our 
dyc> evolving gpx format. I read both <id> and <name> tags, but output 
dyc> <name> for names of all tracks, routes, and waypoints.

Looks great!  I'm going to spend the next day or so adding GPX support
to my apps, and testing with your sample data.

dyc> My previously published sample used waypt instead of <wpt>, and I 
dyc> have corrected that error. I output first-level elements in the order 
dyc> <wpt>,<rte>,<trk>.

dyc> I have successfully read Dan Foster's previously posted snippet of 
dyc> data from EasyGPS, which contains a route only. We need to reach 
dyc> agreement on a set of names for symbols, though. Dan uses "Fishing 
dyc> Area" but I use "Fish", so his "Fishing Area" comes out on my program 
dyc> as a dot.

I think this is fine.  This problem was brought on us by the GPS
vendors, and I don't know a great way to solve it without getting them
to all agree.  As long as we use the exact names of the waypoint
symbols as given by the GPS vendors, exact matches will always work.
If apps want to have a second level of matching, that's even better.

dyc> I have used the <private> tag encapsulating layer information for my 
dyc> maps. I originally proposed the usage of this tag to encapsulate 
dyc> private data, but if we go away from a rigid DTD in favor of using 
dyc> XML Schema, this encapsulation is no longer necessary. I think that 
dyc> we should go back a variant of Dan's original proposal for private 
dyc> tags--He proposed wissenbach_layer, or yourprogram_display as a means 
dyc> of distinguishing tags. I'd use XML namespace syntax instead, and say
dyc> wissenbach:layer or foster:display or jensen:precision for our 
dyc> favorite private tags. I think that ignoring the contents of 
dyc> <private> tags other than our own will add too much complexity to the 
dyc> parsing.

I like this.  I'll be using topografix:private from now on.

dyc> The sample program and data files are available at the URL

dyc> http://www.cableone.net/cdwissenbach

One thing I noticed was that Internet Explorer saved the .gpx file as
.gpx.xml  Is anyone else seeing this happen?  I've seen cases of IE
"sniffing" the contents of files before...

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com


Re: My samples

davewissenbach+yahoo.com on Tue Nov 20 16:16:33 2001 (link), replying to msg

--- In gpsxml+y..., Kjeld Jensen <gps+c...> wrote:
> Here are some samples which were created using the current beta 
release og
> Cetus GPS and Cetus TrackLog available at http://www.cetus.dk/gps
> 
> To the tracklog I have added a few elements which we need to 
discuss.
> 
> <mag> is the magnetic deviation measured at the beginning of the 
track sample.
>

What are the units? Looks like radians, not degrees.

> <speed> and <course> are the values provided by the GPS. They are 
relevant
> for users who wants to perform simple analysis using for instance 
Excel and
> I belive we should support them as optional elements. Anyone who 
does not
> need them could just trash the information.
>

I think that we could have lots of optional elements, but that's OK. 
Once we introduce any optional element, our parsers can probably 
handle all optional elements. To make these optional elements 
usable, we should describe them in the Schema/DTD.

> Maybe we should Dan talk him into concluding on the current status 
of our
> format description - not as a DTD but a simple description of the 
things we
> have agreed on.
> 

Until we know how to write a DTD, or schema, I agree. Once we (or I) 
learn how to write a Schema, I think that we should go that route, 
or go with a web page which describes the format. I'm having a bit 
of trouble sorting through all 74 messages and keeping them straight.


> We need to make a decission about the versioning of gps. I suggest 
that we
> create a "sloppy" version "0.2" or so for practical testing 
purposes.
> It could be based on Dan's description, when we have agreed on 
this.
>

We can probably go with the sloppy version once we know that we 
successfully exchange data. I think that will be within the next few 
weeks. We still have a few things to iron out. For instance, Dan's 
last sample used id instead of name. In my last sample, I used <ele> 
to describe both the elevation of a waypoint, and the altitude of a 
trackpoint. I see that you are using a strict interpretation of the 
words, but I recently switched to <ele> in both to conform to Dan's 
hand-written samples. Can we switch to <ele> in both? Or should we 
allow eacher. Until then no data exchange is possible. (Actually it 
is if we treat both as optional elements). That's what I've done 
with our switch from <id> to <name>.

> I suggest we use it for let say a few months in which our programs 
support
> it officially. Then we should have enough experience to go to a 
more strict
> format description "1.0".
>

The format still needs a lot of work. There were lots of good ideas 
about routes and links expressed early on in the newsgroup, and I 
think that we need to express these ideas in the format. That might 
require some significant change.

I'd like some assurance that the data which I produce in the interim 
period will still be valid once we go to "1.0", if this is possible.

> Another issue is how do we extend the use of gpx to other than us 
here on
> the list? I plan to add a page on my homepage dedicated to 
avertising for
> all apps that are capable of importing data from my apps using 
gpx, but
> what do you guys have in mind regarding this?
> 

I'm not going to push my application very much, so no thanks. I 
think that we need to pay more attention to how we publish the 
trails. One thing that I'm a bit worried about is how we keep from 
distributing copywrited data on our web sites (illegal in the United 
States of America, once people convert to this format. I think that 
we should have a required copywrite/data ownership field in every 
gpx file.

I'll begin publishing all of the trails in the Boise, Idaho area in 
GPX format once we agree on the format, in copyleft format. (No 
copyright). I'd like to be able to ensure that this work to be 
freely available. (Lots of the map data originated with government 
data in the US but is controlled and distributed by just a few map 
companies.) I'd like to break this paradigm and produce data which 
is publicly owned!

> 
Format deleted. I'll parse both ele and alt for now and try to read 
this.
> ______________________
> Kjeld Jensen
> N 55� 22' E 10� 24'
> Email: gps+c...
> http://www.cetus.dk/gps


GPX overview and marketing page

egroups+topografix.com on Wed Nov 21 12:55:31 2001 (link), replying to msg

Hello ,

Wednesday, November 21, 2001, 1:05:40 PM, Kjeld wrote:

KJ> I was just a little curious about what you plan to do and would like to
KJ> hear some suggestions on how we can market the GPX format. Perhaps a nice
KJ> homepage with a detailed technical description of the format (the sloppy
KJ> description we talked about) along with a general description of the ideas
KJ> behind GPX would be a good idea (Dan.... :-)

I will update http://www.topografix.com/xml.asp to reflect the current
version of the GPX project, and provide a technical overview for
interested developers, as well as a "what's this and why should I
care?" section for users.  I'll also provide links to any program or
developer who uses GPX and wants to be listed.

In one of the past emails, someone asked what requirements we should
put on the use of GPX by other developers.  My thoughts are that GPX
should be available for use by anyone who agrees to the following
points:
 - make sure your implementation works well with other
 implementations.
 - don't "steal" the file-type extension .gpx for your application
 without asking the user first.  (for Windows developers)
 - participate in the GPX development forum (this mailing list).
 - identify yourself or your application in a <src> tag in the GPX
 header, so we can track you down if something is broken.


-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com


Re[2]: [gpsxml] Re: My samples

egroups+topografix.com on Wed Nov 21 13:12:30 2001 (link), replying to msg

Hello,

Wednesday, November 21, 2001, 1:05:40 PM, Dave and Kjeld, wrote:

Dave:
>>I'll begin publishing all of the trails in the Boise, Idaho area in
>>GPX format once we agree on the format, in copyleft format. (No
>>copyright). I'd like to be able to ensure that this work to be
>>freely available. (Lots of the map data originated with government
>>data in the US but is controlled and distributed by just a few map
>>companies.) I'd like to break this paradigm and produce data which
>>is publicly owned!

Kjeld:
KJ> Perhaps we should include the optional element <license> in the <wpt> and
KJ> <trk> (before the first <trkpt>) in order to be able to add copyright
KJ> information. Then if your parser sees this element, you know it is
KJ> copyrighted, and you cannot use/distribute the data unless you get an exact
KJ> match on the element data with some copyright strings you are allowed to
KJ> distribute.

KJ> <license>Copyright by Kjeld Jensen, free distribution allowed</license>

KJ> No <license> equals copyfree.

I won't be writing out the <license> tag, for the following reasons:
1. I don't put any restrictions on the use of data generated by my
programs.
2. At the same time, I can't write <license>free</license>
arbitrarily, because someone may be bringing licensed data into my app
and then exporting it.

As far as reading the <license> tag, I'm torn between actually doing
something with the data, and ignoring it completely.  If I did read
it, it seems like I ought to show the license restriction to the user,
and that bothers me.  Because I know some of my data providers would
like nothing better than a chance to pop up their legal statements
everytime someone opens one of their files.

Maybe I'll end up with an "About this file" command that shows
everything in the GPX header (created by, license, etc).

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com


creator vs src

egroups+topografix.com on Wed Nov 21 13:25:15 2001 (link), replying to msg

Hello,

Wednesday, November 21, 2001, 3:15:49 PM, Kjeld wrote:

>> - identify yourself or your application in a <src> tag in the GPX
>> header, so we can track you down if something is broken.

KJ> I thought we had changed that one to creator="   " and use <src>  as an
KJ> optional element for where the data originates from. If it is just me who
KJ> had that thought, I want to suggest that we do :-)

KJ> For instance:

KJ> <?xml version="1.0" standalone="yes"?>
KJ> <gpx version="0.1" creator="Cetus GPS 1.0b15">
KJ> <wpt lat="63.4267483" lon="10.4106717">
KJ> <ele>67.40</ele>
KJ> <name>Test1</name>
KJ> <desc>Some text here</desc>
KJ> <time>2001-11-18T18:38:57.000Z</time>
KJ> <fix>3D</fix>
KJ> <sat>7</sat>
KJ> <hdop>2.1</hdop>
KJ> <src>GARMIN GPS</src>
KJ> </wpt>
KJ> </gpx>

Kjeld is right.  I was sloppy when I wrote that.  Another reason why I
need to get an updated list of the elements we've agreed upon posted
on the website.

A quick recap:
creator - the app that made the file
src - the source of the data (GPS, map, etc)
ele - elevation
name - waypoint name

No longer used:
alt - use ele for elevation
id - use name for waypoint name

By the way, I've updated my software to read the sample GPX files produced
by Dave and Kjeld.  I'll get the new software, my sample files, and
the website updated and available in the next week.

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com


2 UTC or not to UTC

adrius42+hotmail.com on Sun Nov 25 12:49:28 2001 (link)

I am concerned that all the implications of the UTC question have not
been hammered out. As its late I will simply say that....
Time and UTC implicates veracity of date.
For individuals that cross date and timezones are there not, likely 
to be implications, as yet not fully explored, of ignoring "local" 
time.

"In the spirit of XML" was used as a comment earlier, my sense of 
that spirit requires UNDERSTANDABLE, accurate, reliable & reasonably 
comprehensive means of transferring data. For me the understandable 
is key, removing/ignoring data that simply impacts "comprehensive" is 
defensible, but were the lack of data impacts understanding there is 
clearly an issue.

I can be argued both ways but I fear we may be missing key data by 
ignoring the possibility of requiring timezone offsets.

Adrian


Re: GPX Sample File: Hike.gpx

adrius42+hotmail.com on Sun Nov 25 13:15:39 2001 (link), replying to msg

--- In gpsxml+y..., Kjeld Jensen <gps+c...> wrote:
> Hi,
> 
> >Why is ID a required attribute of a trkpt and a rtpte? (Remember 
that
> >we have previously agreed that required attributes of an element
> >would be coded with the XML attribute syntax, and that optional 
data
> >would be coded as elements.) Have we changed this rule while I was
> >offline?
> 
> No :-)
> 
>  If so, I'd suggest that we use id in the XML sense of the
> >word, as a special kind of attribute that must be unique from all
> >other attributes. The Garmin GPS requires that all waypoints be
> >unique, and the ID is used for display purposes. Usability would be
> >improved if the source application could control the ID which is
> >displayed on the Garmin unit, which therefore implies that all
> >waypoints have a Unique ID. And because routes are composed of
> >waypoints, routepoints must also have unique ID's. But I'd make 
these
> >optional.
> 
> >So my view of the GPS/GPX world is in conflict with the numbered ID
> >sequence which you propose below. Or is what I'm referring to above
> >as an ID now to be called a name?
> 
> >What is the purpose of sequentially numbering points within a track
> >or route? If the purpose is just to detect loss of lock on the GPS,
> >or a break in a track, can we code this in some other way?
> 
> The id was changed to name yes, and I thought id could be a 
sequential
> numbering of all track/route records.
> ****************
****************
Having read to the end ( A great body of work) the only concern I 
have ((after the Time Zone question)) is the question of uniqueness 
of NAME (See below)
I believe this one will bite if Name is not required to be Unique 
within each .GPX file, or am I missing a trick?
Am I the only paranoid thinking this?
***************
***************
> But to me the name is not necessarily unique. I see the requirement 
for a
> unique id (for the purpose you describe) the same way as 
limitations on
> string lengths and so on. Limitations that may be convenient for one
> application should not cause limitations in the gpx standard.  If 
you for
> instance export let say 100 waypoints from a database it is quite 
difficult
> to make sure that each name is unique at least in some applications.
> 
> If we define that trackpoints must follow in a sequence, then I 
guess the
> id="" is not that necessary. Actually I like the element name 
seq="" better
> because it tells more about what it is, so if we are to include a
> sequential number for tracks and routes, then I think it should be 
called
> seq rather than id.
> 
> Kjeld
> 
> ______________________
> Kjeld Jensen
> N 55� 22' E 10� 24'
> Email: gps+c...
> http://www.cetus.dk/gps

Adrian 
Email: adrius42+hotmail.com


New file uploaded to gpsxml

gpsxml+yahoogroups.com on Sun Nov 25 22:04:25 2001 (link)


Hello,

This email message is a notification to let you know that
a file has been uploaded to the Files area of the gpsxml 
group.

  File        : /Schema/gpx1.xsd 
  Uploaded by : kevin+synergysa.com.au 
  Description : Draft 1 GPX XSD 

You can access this file at the URL

http://groups.yahoo.com/group/gpsxml/files/Schema/gpx1.xsd 

To learn more about file sharing for your group, please visit

http://help.yahoo.com/help/us/groups/files

Regards,

kevin+synergysa.com.au
 





Schema - first go

kevin+synergysa.com.au on Sun Nov 25 23:52:37 2001 (link)

Hi All

Here's a quick first draft of the XSD for .gpx - I have also placed it
in the files section of yahoogroups.com

A few more sample XML packets would be good perhaps members of the list
can put some of their sample GPS xml packets up also



<?xml version="1.0" encoding="utf-8"?>
<xsd:schema id="gpx"
targetNamespace="http://groups.yahoo.com/group/gpsxml"
xmlns="http://groups.yahoo.com/group/gpsxml"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:msdata="urn:schemas-microsoft-com:xml-msdata"
attributeFormDefault="qualified" elementFormDefault="qualified">
  <xsd:element name="gpx">
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element name="wpt" minOccurs="0" maxOccurs="unbounded">
          <xsd:complexType>
            <xsd:sequence>
              <xsd:element name="ele" type="xsd:string" minOccurs="0"
msdata:Ordinal="0" />
              <xsd:element name="name" type="xsd:string" minOccurs="0"
msdata:Ordinal="1" />
              <xsd:element name="sym" type="xsd:string" minOccurs="0"
msdata:Ordinal="2" />
              <xsd:element name="desc" type="xsd:string" minOccurs="0"
msdata:Ordinal="6" />
            </xsd:sequence>
            <xsd:attribute name="lat" form="unqualified"
type="xsd:string" />
            <xsd:attribute name="lon" form="unqualified"
type="xsd:string" />
            <xsd:attribute name="gpx_Id" type="xsd:int" use="prohibited"
/>
          </xsd:complexType>
        </xsd:element>
        <xsd:element name="rte" minOccurs="0" maxOccurs="unbounded">
          <xsd:complexType>
            <xsd:sequence>
              <xsd:element name="rtept" minOccurs="0"
maxOccurs="unbounded">
                <xsd:complexType>
                  <xsd:sequence>
                    <xsd:element name="name" type="xsd:string"
minOccurs="0" msdata:Ordinal="0" />
                    <xsd:element name="sym" type="xsd:string"
minOccurs="0" msdata:Ordinal="1" />
                    <xsd:element name="ele" type="xsd:string"
minOccurs="0" msdata:Ordinal="5" />
                    <xsd:element name="desc" type="xsd:string"
minOccurs="0" msdata:Ordinal="6" />
                  </xsd:sequence>
                  <xsd:attribute name="lat" form="unqualified"
type="xsd:string" />
                  <xsd:attribute name="lon" form="unqualified"
type="xsd:string" />
                  <xsd:attribute name="rte_Id" type="xsd:int"
use="prohibited" />
                </xsd:complexType>
              </xsd:element>
            </xsd:sequence>
            <xsd:attribute name="rte_Id" msdata:AutoIncrement="true"
type="xsd:int" msdata:AllowDBNull="false" use="prohibited" />
            <xsd:attribute name="gpx_Id" type="xsd:int" use="prohibited"
/>
          </xsd:complexType>
        </xsd:element>
        <xsd:element name="trk" minOccurs="0" maxOccurs="unbounded">
          <xsd:complexType>
            <xsd:sequence>
              <xsd:element name="name" type="xsd:string" minOccurs="0"
msdata:Ordinal="0" />
              <xsd:element name="desc" type="xsd:string" minOccurs="0"
msdata:Ordinal="1" />
              <xsd:element name="trkpt" minOccurs="0"
maxOccurs="unbounded">
                <xsd:complexType>
                  <xsd:sequence>
                    <xsd:element name="ele" type="xsd:string"
minOccurs="0" msdata:Ordinal="0" />
                    <xsd:element name="time" type="xsd:dateTime"
minOccurs="0" msdata:Ordinal="4" />
                  </xsd:sequence>
                  <xsd:attribute name="lat" form="unqualified"
type="xsd:string" />
                  <xsd:attribute name="lon" form="unqualified"
type="xsd:string" />
                  <xsd:attribute name="trk_Id" type="xsd:int"
use="prohibited" />
                </xsd:complexType>
              </xsd:element>
            </xsd:sequence>
            <xsd:attribute name="trk_Id" msdata:AutoIncrement="true"
type="xsd:int" msdata:AllowDBNull="false" use="prohibited" />
            <xsd:attribute name="gpx_Id" type="xsd:int" use="prohibited"
/>
          </xsd:complexType>
        </xsd:element>
      </xsd:sequence>
      <xsd:attribute name="gpx_Id" msdata:AutoIncrement="true"
type="xsd:int" msdata:AllowDBNull="false" use="prohibited" />
      <xsd:attribute name="version" form="unqualified" type="xsd:string"
/>
      <xsd:attribute name="creator" form="unqualified" type="xsd:string"
/>
    </xsd:complexType>
  </xsd:element>
  <xsd:element name="NewDataSet" msdata:IsDataSet="true"
msdata:Locale="en-AU">
    <xsd:complexType>
      <xsd:choice maxOccurs="unbounded">
        <xsd:element ref="gpx" />
      </xsd:choice>
    </xsd:complexType>
    <xsd:unique name="rte_Constraint1"
msdata:ConstraintName="Constraint1" msdata:PrimaryKey="true">
      <xsd:selector xpath=".//rte" />
      <xsd:field xpath="+rte_Id" />
    </xsd:unique>
    <xsd:unique name="trk_Constraint1"
msdata:ConstraintName="Constraint1" msdata:PrimaryKey="true">
      <xsd:selector xpath=".//trk" />
      <xsd:field xpath="+trk_Id" />
    </xsd:unique>
    <xsd:unique name="Constraint1" msdata:PrimaryKey="true">
      <xsd:selector xpath=".//gpx" />
      <xsd:field xpath="+gpx_Id" />
    </xsd:unique>
    <xsd:keyref name="gpx_trk" refer="Constraint1"
msdata:IsNested="true">
      <xsd:selector xpath=".//trk" />
      <xsd:field xpath="+gpx_Id" />
    </xsd:keyref>
    <xsd:keyref name="trk_trkpt" refer="trk_Constraint1"
msdata:IsNested="true">
      <xsd:selector xpath=".//trkpt" />
      <xsd:field xpath="+trk_Id" />
    </xsd:keyref>
    <xsd:keyref name="gpx_rte" refer="Constraint1"
msdata:IsNested="true">
      <xsd:selector xpath=".//rte" />
      <xsd:field xpath="+gpx_Id" />
    </xsd:keyref>
    <xsd:keyref name="rte_rtept" refer="rte_Constraint1"
msdata:IsNested="true">
      <xsd:selector xpath=".//rtept" />
      <xsd:field xpath="+rte_Id" />
    </xsd:keyref>
    <xsd:keyref name="gpx_wpt" refer="Constraint1"
msdata:IsNested="true">
      <xsd:selector xpath=".//wpt" />
      <xsd:field xpath="+gpx_Id" />
    </xsd:keyref>
  </xsd:element>
</xsd:schema>

Kevin Read
S Y N E R G Y   S A
Phone. 08 8278 6296
Fax. 08 8278 6296
Mobile. 0419 61 7100
Email. kevin+synergysa.com.au
Web. http://www.synergysa.com.au

syn.er.gy.
The interaction of two or more agents or forces so that their combined
effect is greater than the sum of their individual effects. 
Cooperative interaction among groups that creates an enhanced combined
effect.



Re: [gpsxml] Schema - first go

egroups+topografix.com on Mon Nov 26 11:43:47 2001 (link), replying to msg

Hello,

Monday, November 26, 2001, 2:52:02 AM, Kevin wrote:

KR> Here's a quick first draft of the XSD for .gpx - I have also placed it
KR> in the files section of yahoogroups.com

KR> A few more sample XML packets would be good perhaps members of the list
KR> can put some of their sample GPS xml packets up also

Thanks Kevin!!!  This looks really good!  I can follow most of it, but
I'm having trouble with some of the *_Id and *_Constraint syntax
towards the bottom.  Can you post a sample GPX file that uses the
schema?

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com



RE: [gpsxml] Schema - first go

kevin+synergysa.com.au on Mon Nov 26 14:43:37 2001 (link), replying to msg


The _id etc are auto generated to allow for template processing in XSLT
as well as DOM manipulation - consider them a place holder for the
processor to assign unique keys.  The schema tells the processor to auto
create them.  Makes it a little more efficient.
 
I took a copy of David Wissenbach's XML -from his site.  I took out his
extensions and processed that.
 
I would love other exampls to play with also.  Do you have any ?
 
Kevin
 

-----Original Message-----
From: Dan Foster [mailto:egroups+topografix.com] 
Sent: Tuesday, 27 November 2001 6:07 AM
To: Kevin Read
Subject: Re: [gpsxml] Schema - first go


Hello,

Monday, November 26, 2001, 2:52:02 AM, Kevin wrote:

KR> Here's a quick first draft of the XSD for .gpx - I have also placed
it
KR> in the files section of yahoogroups.com

KR> A few more sample XML packets would be good perhaps members of the
list
KR> can put some of their sample GPS xml packets up also

Thanks Kevin!!!  This looks really good!  I can follow most of it, but
I'm having trouble with some of the *_Id and *_Constraint syntax
towards the bottom.  Can you post a sample GPX file that uses the
schema?

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com




Yahoo! Groups Sponsor	
 
<http://rd.yahoo.com/M=212180.1701098.3252983.1269402/D=egroupweb/S=1706
030390:HM/A=812074/R=0/*http://www.verisign.com/cgi-bin/go.cgi?a=b153340
270003000> 	
 
<http://us.adserver.yahoo.com/l?M=212180.1701098.3252983.1269402/D=egrou
pmail/S=1706030390:HM/A=812074/rand=570797438> 	

To unsubscribe from this group, send an email to:
gpsxml-unsubscribe+yahoogroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
<http://docs.yahoo.com/info/terms/> . 



------=_NextPart_000_0006_01C17723.AE1B7400

Re: Schema - first go

davewissenbach+yahoo.com on Tue Nov 27 05:45:32 2001 (link), replying to msg

--- In gpsxml+y..., "Kevin Read" <kevin+s...> wrote:
> Hi All
> 
> Here's a quick first draft of the XSD for .gpx - I have also 
placed it
> in the files section of yahoogroups.com
> 
> A few more sample XML packets would be good perhaps members of the 
list
> can put some of their sample GPS xml packets up also
> 

I've been trying to evaluate my own XML with a similar schema and 
have run into a few problems. One problem is getting the order of 
the elements straight. I didn't strictly follow the order of Dan's 
first examples when I wrote my XML, probably because we didn't have 
a schema! One construct in the schema which I found can allow a 
flexible order of elements in the waypoint is this:

By putting in the "choice" element, and allowing many choices, this 
loosens the schema to allow the elements to occur in any order. I 
would recommend that we adopt this more flexible aproach, if the 
other participating applications can also parse elements in any 
order.


while tag != "/wpt"
{
  if(tag == "ele")
  else if(tag == "name")
  else if(tag == "src")
  else if(tag ==
}

    <complexType>
     <sequence>
      <choice minOccurs="0" maxOccurs="unbounded">
       <element name="ele" type="decimal" minOccurs="0"/>
       <element name="time" type="string" minOccurs="0"/><!-- Use 
dateTime -->
       <element name="name" type="string" minOccurs="0"/>
       <element name="cmt" type="string" minOccurs="0"/>
       <element name="desc" type="string" minOccurs="0"/>
       <element name="src" type="string" minOccurs="0"/>
       <element name="type" type="string" minOccurs="0"/>
       <element name="sym" type="string" minOccurs="0"/>
      </choice>
      <any namespace="other" minOccurs="0" maxOccurs="unbounded"/>
     </sequence>
     <attribute name="lat" type="decimal" use="required"/>
     <attribute name="lon" type="decimal" use="required"/>
    </complexType>






Trail/Road type and usage tags

davewissenbach+yahoo.com on Sat Dec 01 10:08:56 2001 (link)

I recently purchased a trail map for an area of interest, the trails 
of the Boise Front, so that I can use the proper trail names when 
coding in XML format. A couple of features of this map that we are 
missing in current format are the ability to describe the type of 
road or trail, such as Roads, Streets, Gravel Roads, Primitive 
Roads, Dual-track trails, ATV trails, single-track trails, and also 
the ability to describe the modes of travel allowed (or possible). 
Such as 4-WD, Motorized, Non-Motorized, pedestrian only, horse and 
pedestrian only (Mountain Bike excluded), etc.

I think that this is something like a link, where in a route between 
waypoints we might want all of these properties. I think that for a 
trail we would also want all of these properties.

With this added data, I could post a trail or route without 
misleading a person into the type of travel possible.

We could use tags such as <way>, one only, for air, road, street, 
trail, etc, and <mode>, multiple allowed, for modes of travel.

What do you all think?


TopoGrafix apps now support GPX

egroups+topografix.com on Tue Dec 11 10:02:54 2001 (link), replying to msg

Hello,

I've added support for GPX to all three of my products.  You can use
the Open and Save As dialogs to read and write GPX data, or convert
between GPX and my native LOC file format.

I've got a group of testers who may be interested in passing data
between my programs and some of the other software out there (Cetus
GPS, for example).  If you've got a GPX-enabled program that's ready
to have some testing, let me know, and I'll mention it in my next beta
software mailing.

Download the new software:

EasyGPS: http://www.easygps.com/beta.asp

PanTerra: http://www.topografix.com/beta.asp

ExpertGPS: http://www.expertgps.com/beta.asp

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com



Re: TopoGrafix apps now support GPX

davewissenbach+yahoo.com on Tue Dec 11 21:43:55 2001 (link), replying to msg

--- In gpsxml+y..., Dan Foster <egroups+t...> wrote:

I downloaded ExpertGPS beta, read from my GPS, wrote to .gpx file 
format, and attempted to input to my Map program, at 
http://www.cableone.net/cdwissenbach. I had to manually edit the end 
tag of a track to get the gpx file to load. Bug report--GPX outputs 
the format control %s instead of /trk. Easily fixable, I assume. 
Other than this minor glitch, a successful transfer of 2000 
trackpoints.

However, the reverse direction, from file
http://www.cableone.net/cdwissenbach/FileFormat.gpx or other Map.exe 
output to ExpertGPX input does not work. ExpertGPS can read its own 
gpx file output. (I have changed my sample file slightly and may 
have broken something, or added unexpected attributes and tags.)


> Hello,
> 
> I've added support for GPX to all three of my products.  You can 
use
> the Open and Save As dialogs to read and write GPX data, or convert
> between GPX and my native LOC file format.
> 
> I've got a group of testers who may be interested in passing data
> between my programs and some of the other software out there (Cetus
> GPS, for example).  If you've got a GPX-enabled program that's 
ready
> to have some testing, let me know, and I'll mention it in my next 
beta
> software mailing.
> 
> Download the new software:
> 
> EasyGPS: http://www.easygps.com/beta.asp
> 
> PanTerra: http://www.topografix.com/beta.asp
> 
> ExpertGPS: http://www.expertgps.com/beta.asp
> 
> -- 
> Dan Foster
> TopoGrafix - GPS Software, Waypoints, and Maps
> http://www.topografix.com - mailto:egroups+t...


RE: [gpsxml] Re: TopoGrafix apps now support GPX

kevin+synergysa.com.au on Tue Dec 11 23:47:49 2001 (link), replying to msg


I assume that the EasyGPS output (minus the little bug) is the release
candidate for the GPX format
 
If so, i'll update/rewrite the schema to this and post it for all to
see.
 
Can we lock this in then as RC1 ????????
 
Kevin

-----Original Message-----
From: davewissenbach [mailto:davewissenbach+yahoo.com] 
Sent: Wednesday, 12 December 2001 4:14 PM
To: gpsxml+yahoogroups.com
Subject: [gpsxml] Re: TopoGrafix apps now support GPX


--- In gpsxml+y..., Dan Foster <egroups+t...> wrote:

I downloaded ExpertGPS beta, read from my GPS, wrote to .gpx file 
format, and attempted to input to my Map program, at 
http://www.cableone.net/cdwissenbach. I had to manually edit the end 
tag of a track to get the gpx file to load. Bug report--GPX outputs 
the format control %s instead of /trk. Easily fixable, I assume. 
Other than this minor glitch, a successful transfer of 2000 
trackpoints.

However, the reverse direction, from file
http://www.cableone.net/cdwissenbach/FileFormat.gpx or other Map.exe 
output to ExpertGPX input does not work. ExpertGPS can read its own 
gpx file output. (I have changed my sample file slightly and may 
have broken something, or added unexpected attributes and tags.)


> Hello,
> 
> I've added support for GPX to all three of my products.  You can 
use
> the Open and Save As dialogs to read and write GPX data, or convert
> between GPX and my native LOC file format.
> 
> I've got a group of testers who may be interested in passing data
> between my programs and some of the other software out there (Cetus
> GPS, for example).  If you've got a GPX-enabled program that's 
ready
> to have some testing, let me know, and I'll mention it in my next 
beta
> software mailing.
> 
> Download the new software:
> 
> EasyGPS: http://www.easygps.com/beta.asp
> 
> PanTerra: http://www.topografix.com/beta.asp
> 
> ExpertGPS: http://www.expertgps.com/beta.asp
> 
> -- 
> Dan Foster
> TopoGrafix - GPS Software, Waypoints, and Maps
> http://www.topografix.com - mailto:egroups+t...


To unsubscribe from this group, send an email to:
gpsxml-unsubscribe+yahoogroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
<http://docs.yahoo.com/info/terms/> . 



------=_NextPart_000_0047_01C18339.269FB5A0

RE: [gpsxml] TopoGrafix apps now support GPX

kevin+synergysa.com.au on Wed Dec 12 02:52:22 2001 (link), replying to msg


Hi dan
 
Did a test and found a small issue, consider the following snippet of a
LOC file saved as GPX:
 
<wpt lat="-27.519783" lon="153.022617">
 <name>GC8E2</name>
 <desc>drewgong moogsie & Spider by Drewgong Moogsie & Spider</desc>
 <type>geocache</type>
 <sym>Waypoint</sym>
</wpt>
 
The & char in a text area needs to be either escaped or be part of a
CDATA section.  & is invalid in this location.
 
It should be: 
 
<wpt lat="-27.519783" lon="153.022617">
 <name>GC8E2</name>
 <desc>drewgong moogsie & Spider by Drewgong Moogsie &
Spider</desc>
 <type>geocache</type>
 <sym>Waypoint</sym>
</wpt>
 
While you're there you may as well check for all these too.
 
Char, Replacewith
<, <
&, &
>, >
", "
', '

Kevin
 

-----Original Message-----
From: Dan Foster [mailto:egroups+topografix.com] 
Sent: Wednesday, 12 December 2001 4:30 AM
To: gpsxml+yahoogroups.com
Subject: [gpsxml] TopoGrafix apps now support GPX


Hello,

I've added support for GPX to all three of my products.  You can use
the Open and Save As dialogs to read and write GPX data, or convert
between GPX and my native LOC file format.

I've got a group of testers who may be interested in passing data
between my programs and some of the other software out there (Cetus
GPS, for example).  If you've got a GPX-enabled program that's ready
to have some testing, let me know, and I'll mention it in my next beta
software mailing.

Download the new software:

EasyGPS: http://www.easygps.com/beta.asp

PanTerra: http://www.topografix.com/beta.asp

ExpertGPS: http://www.expertgps.com/beta.asp

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com




Yahoo! Groups Sponsor	

ADVERTISEMENT
 
<http://rd.yahoo.com/M=215002.1711356.3237013.1261774/D=egroupweb/S=1706
030390:HM/A=847665/R=0/*http://ads.x10.com/?bHlhaG9vbW9uc3RlcjcuZGF0=100
8093775%3eM=215002.1711356.3237013.1261774/D=egroupweb/S=1706030390:HM/A
=847665/R=1> 	
 
<http://us.adserver.yahoo.com/l?M=215002.1711356.3237013.1261774/D=egrou
pmail/S=1706030390:HM/A=847665/rand=441025301> 	

To unsubscribe from this group, send an email to:
gpsxml-unsubscribe+yahoogroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
<http://docs.yahoo.com/info/terms/> . 



------=_NextPart_000_0060_01C18352.22A35150

Re: [gpsxml] Re: TopoGrafix apps now support GPX

egroups+topografix.com on Wed Dec 12 09:23:13 2001 (link), replying to msg

Hello,

Wednesday, December 12, 2001, 12:43:51 AM, Dave wrote:

d> --- In gpsxml+y..., Dan Foster <egroups+t...> wrote:

d> I downloaded ExpertGPS beta, read from my GPS, wrote to .gpx file 
d> format, and attempted to input to my Map program, at 
d> http://www.cableone.net/cdwissenbach. I had to manually edit the end 
d> tag of a track to get the gpx file to load. Bug report--GPX outputs 
d> the format control %s instead of /trk. Easily fixable, I assume. 
d> Other than this minor glitch, a successful transfer of 2000 
d> trackpoints.

d> However, the reverse direction, from file
d> http://www.cableone.net/cdwissenbach/FileFormat.gpx or other Map.exe 
d> output to ExpertGPX input does not work. ExpertGPS can read its own 
d> gpx file output. (I have changed my sample file slightly and may 
d> have broken something, or added unexpected attributes and tags.)

Thanks for pointing out the broken </trk> tag - I've fixed this.  I'm
working on making my parser read Dave's FileFormat.gpx sample.  Dave -
you've got the same illegal characters that my programs have (see
Kevin's email).

I'd prefer to use the CDATA[] method to wrap strings, rather than
parse all strings for escaped characters.  Any other thoughts?  Do we
need to support both ways?

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com



Re: TopoGrafix apps now support GPX

davewissenbach+yahoo.com on Thu Dec 13 04:55:55 2001 (link), replying to msg

--- In gpsxml+y..., "Kevin Read" <kevin+s...> wrote:
> I assume that the EasyGPS output (minus the little bug) is the 
release
> candidate for the GPX format
>  
> If so, i'll update/rewrite the schema to this and post it for all 
to
> see.
>  
> Can we lock this in then as RC1 ????????
>  
> Kevin

Kevin, 

When you rewrite the schema, please look at my version at
www.cableone.net/cdwissenbach/gpx.xsd. The features of interest
are the use of choice, to allow elements in any order, and also
the use of the any element, restricted to other namespace. This
allows validation of the wissenbach:layer, and other private tags
while still rejecting addiditional tags. (I'm validating with
the Xerces 1_5_2 parser, which only seems to support the
noNamespace Schema location.

Dave


Re: TopoGrafix apps now support GPX

davewissenbach+yahoo.com on Thu Dec 13 05:18:38 2001 (link), replying to msg

--- In gpsxml+y..., Dan Foster <egroups+t...> wrote:
> Hello,
> 
> you've got the same illegal characters that my programs have (see
> Kevin's email).
> 
> I'd prefer to use the CDATA[] method to wrap strings, rather than
> parse all strings for escaped characters.  Any other thoughts?  Do 
we
> need to support both ways?
> 

Yikes. Thanks for pointing this out. I guess that's a good reason 
for using an XML-compliant parser. Right now, I've got an extremely 
simple parser. But given that we're calling our format an XML 1.0 
format, we'd better be able to parse both to be in compliance with 
the XML1.0 standard. Which means that we need to parse both methods.

But for now, I'll use CDATA as well, to postpone the problem of
unwrapping those pesky escaped characters.

> -- 
> Dan Foster
> TopoGrafix - GPS Software, Waypoints, and Maps
> http://www.topografix.com - mailto:egroups+t...


Drawing the line

kevin+synergysa.com.au on Thu Dec 13 05:57:41 2001 (link)


Hi Guys
 
Can you email to me (via the list if you like) a full sample of the
GPXML you are producing.
 
I need some sample to test against the schema, I'll also be creating
some Java classes to handle the packets as well if any one is
interested.
 
At this stage, i'll ignore other namespace extensions and concentrate on
the base schema for:
 
Waypoints, Tracks and Routes
 
I'm especially interested in locking down (in my mind) the mandatory and
optional elements alomg with the constraints for each type.
 
If you can send some files, I'll be able to get the next schema done
over the weekend.
 
Dan:  How's the revised beta of EasyGPS going?
 
Kevin
 

Kevin Read
S Y N E R G Y   S A
Phone. 08 8278 6296
Fax. 08 8278 6296
Mobile. 0419 61 7100
Email. kevin+synergysa.com.au
Web. http://www.synergysa.com.au <http://www.synergysa.com.au/> 
 Synergy SA Logo <http://www.synergysa.com.au/images/sml_logo.jpg> 

syn.er.gy.

	
1.	The interaction of two or more agents or forces so that their
combined effect is greater than the sum of their individual effects. 

2.	Cooperative interaction among groups that creates an enhanced
combined effect.

  _____  

 
 

------=_NextPart_001_007F_01C18435.FBA56C20

Revised versions of EasyGPS and ExpertGPS for GPX

egroups+topografix.com on Fri Dec 14 10:23:39 2001 (link), replying to msg

Hello,

Thursday, December 13, 2001, 8:56:32 AM, Kevin wrote:

KR> Dan:  How's the revised beta of EasyGPS going?

I fixed all the problems that were found in my previous GPX
implementation, and wrapped description strings in CDATA.

  http://www.easygps.com/beta.asp
  http://www.expertgps.com/beta.asp

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com



Schema Rel Candidate 1.0

kevin+synergysa.com.au on Fri Dec 14 18:05:37 2001 (link)

Hi All

here it is:

Draft #2 of the Release candidate for the Schema

I'll Upload it to the site as well.

<?xml version="1.0" encoding="utf-8"?><xsd:schema
xmlns="http://groups.yahoo.com/group/gpsxml"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" id="gpx"
targetNamespace="http://groups.yahoo.com/group/gpsxml/1.0/GPX">
  <xsd:element name="gpx">
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element name="wpt" minOccurs="0" maxOccurs="unbounded">
          <xsd:complexType>
            <xsd:sequence>
              <xsd:element name="ele" type="xsd:string" minOccurs="0"
use="optional"/>
              <xsd:element name="name" type="xsd:string" minOccurs="0"
use="optional"/>
              <xsd:element name="sym" type="xsd:string" minOccurs="0"
use="optional"/>
              <xsd:element name="desc" type="xsd:string" minOccurs="0"
use="optional"/>
            </xsd:sequence>
            <xsd:attribute name="lat" type="xsd:decimal"
use="required"/>
            <xsd:attribute name="lon" type="xsd:decimal"
use="required"/>
          </xsd:complexType>
        </xsd:element>
        <xsd:element name="rte" minOccurs="0" maxOccurs="unbounded">
          <xsd:complexType>
            <xsd:sequence>
              <xsd:element name="rtept" minOccurs="0"
maxOccurs="unbounded">
                <xsd:complexType>
                  <xsd:sequence>
                    <xsd:element name="name" type="xsd:string"
minOccurs="0" use="optional"/>
                    <xsd:element name="sym" type="xsd:string"
minOccurs="0" use="optional"/>
                    <xsd:element name="ele" type="xsd:string"
minOccurs="0" use="optional"/>
                    <xsd:element name="desc" type="xsd:string"
minOccurs="0" use="optional"/>
                  </xsd:sequence>
                  <xsd:attribute name="seq" type="xsd:decimal"
use="optional"/>
                  <xsd:attribute name="lat" type="xsd:decimal"
use="required"/>
                  <xsd:attribute name="lon" type="xsd:decimal"
use="required"/>
                </xsd:complexType>
              </xsd:element>
            </xsd:sequence>
          </xsd:complexType>
        </xsd:element>
        <xsd:element name="trk" minOccurs="0" maxOccurs="unbounded">
          <xsd:complexType>
            <xsd:sequence>
              <xsd:element name="name" type="xsd:string" minOccurs="0"
use="optional"/>
              <xsd:element name="desc" type="xsd:string" minOccurs="0"
use="optional"/>
              <xsd:element name="trkpt" minOccurs="0"
maxOccurs="unbounded">
                <xsd:complexType>
                  <xsd:sequence>
                    <xsd:element name="ele" type="xsd:string"
minOccurs="0" use="optional"/>
                    <xsd:element name="time" type="xsd:dateTime"
minOccurs="0" use="optional"/>
                  </xsd:sequence>
                  <xsd:attribute name="seq" type="xsd:decimal"
use="optional"/>
                  <xsd:attribute name="lat" type="xsd:decimal"
use="required"/>
                  <xsd:attribute name="lon" type="xsd:decimal"
use="required"/>
                </xsd:complexType>
              </xsd:element>
            </xsd:sequence>
          </xsd:complexType>
        </xsd:element>
      </xsd:sequence>
      <xsd:attribute name="version" type="xsd:string" use="optional"/>
      <xsd:attribute name="creator" type="xsd:string" use="optional"/>
    </xsd:complexType>
  </xsd:element>

</xsd:schema>

Kevin Read
S Y N E R G Y   S A
Phone. 08 8278 6296
Fax. 08 8278 6296
Mobile. 0419 61 7100
Email. kevin+synergysa.com.au
Web. http://www.synergysa.com.au

syn.er.gy.
The interaction of two or more agents or forces so that their combined
effect is greater than the sum of their individual effects. 
Cooperative interaction among groups that creates an enhanced combined
effect.



New file uploaded to gpsxml

gpsxml+yahoogroups.com on Fri Dec 14 18:07:03 2001 (link)


Hello,

This email message is a notification to let you know that
a file has been uploaded to the Files area of the gpsxml 
group.

  File        : /Schema/gpsxml_1.0.xsd 
  Uploaded by : kevin_read2001 <kevin+synergysa.com.au> 
  Description : GPS XML Schema RC 1.0 

You can access this file at the URL

http://groups.yahoo.com/group/gpsxml/files/Schema/gpsxml_1.0.xsd 

To learn more about file sharing for your group, please visit

http://help.yahoo.com/help/us/groups/files

Regards,

kevin_read2001 <kevin+synergysa.com.au>
 





RE: [gpsxml] Schema Rel Candidate 1.0

kevin+synergysa.com.au on Fri Dec 14 18:15:56 2001 (link), replying to msg

Bugger - uploaded too soon.

I made a quick change to the targetNamespace attribute to match the
storage on Yahoo.

Its now:

http://groups.yahoo.com/group/gpsxml/files/Schema

Or should it be:

http://groups.yahoo.com/group/gpsxml/files/Schema/gpsxml_1.0.xsd

Who knows (or cares )

Kevin


-----Original Message-----
From: Kevin Read [mailto:kevin+synergysa.com.au] 
Sent: Saturday, 15 December 2001 12:35 PM
To: gpsxml+yahoogroups.com
Subject: [gpsxml] Schema Rel Candidate 1.0


Hi All

here it is:

Draft #2 of the Release candidate for the Schema

I'll Upload it to the site as well.

<?xml version="1.0" encoding="utf-8"?><xsd:schema
xmlns="http://groups.yahoo.com/group/gpsxml"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" id="gpx"
targetNamespace="http://groups.yahoo.com/group/gpsxml/1.0/GPX">
  <xsd:element name="gpx">
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element name="wpt" minOccurs="0" maxOccurs="unbounded">
          <xsd:complexType>
            <xsd:sequence>
              <xsd:element name="ele" type="xsd:string" minOccurs="0"
use="optional"/>
              <xsd:element name="name" type="xsd:string" minOccurs="0"
use="optional"/>
              <xsd:element name="sym" type="xsd:string" minOccurs="0"
use="optional"/>
              <xsd:element name="desc" type="xsd:string" minOccurs="0"
use="optional"/>
            </xsd:sequence>
            <xsd:attribute name="lat" type="xsd:decimal"
use="required"/>
            <xsd:attribute name="lon" type="xsd:decimal"
use="required"/>
          </xsd:complexType>
        </xsd:element>
        <xsd:element name="rte" minOccurs="0" maxOccurs="unbounded">
          <xsd:complexType>
            <xsd:sequence>
              <xsd:element name="rtept" minOccurs="0"
maxOccurs="unbounded">
                <xsd:complexType>
                  <xsd:sequence>
                    <xsd:element name="name" type="xsd:string"
minOccurs="0" use="optional"/>
                    <xsd:element name="sym" type="xsd:string"
minOccurs="0" use="optional"/>
                    <xsd:element name="ele" type="xsd:string"
minOccurs="0" use="optional"/>
                    <xsd:element name="desc" type="xsd:string"
minOccurs="0" use="optional"/>
                  </xsd:sequence>
                  <xsd:attribute name="seq" type="xsd:decimal"
use="optional"/>
                  <xsd:attribute name="lat" type="xsd:decimal"
use="required"/>
                  <xsd:attribute name="lon" type="xsd:decimal"
use="required"/>
                </xsd:complexType>
              </xsd:element>
            </xsd:sequence>
          </xsd:complexType>
        </xsd:element>
        <xsd:element name="trk" minOccurs="0" maxOccurs="unbounded">
          <xsd:complexType>
            <xsd:sequence>
              <xsd:element name="name" type="xsd:string" minOccurs="0"
use="optional"/>
              <xsd:element name="desc" type="xsd:string" minOccurs="0"
use="optional"/>
              <xsd:element name="trkpt" minOccurs="0"
maxOccurs="unbounded">
                <xsd:complexType>
                  <xsd:sequence>
                    <xsd:element name="ele" type="xsd:string"
minOccurs="0" use="optional"/>
                    <xsd:element name="time" type="xsd:dateTime"
minOccurs="0" use="optional"/>
                  </xsd:sequence>
                  <xsd:attribute name="seq" type="xsd:decimal"
use="optional"/>
                  <xsd:attribute name="lat" type="xsd:decimal"
use="required"/>
                  <xsd:attribute name="lon" type="xsd:decimal"
use="required"/>
                </xsd:complexType>
              </xsd:element>
            </xsd:sequence>
          </xsd:complexType>
        </xsd:element>
      </xsd:sequence>
      <xsd:attribute name="version" type="xsd:string" use="optional"/>
      <xsd:attribute name="creator" type="xsd:string" use="optional"/>
    </xsd:complexType>
  </xsd:element>

</xsd:schema>

Kevin Read
S Y N E R G Y   S A
Phone. 08 8278 6296
Fax. 08 8278 6296
Mobile. 0419 61 7100
Email. kevin+synergysa.com.au
Web. http://www.synergysa.com.au

syn.er.gy.
The interaction of two or more agents or forces so that their combined
effect is greater than the sum of their individual effects. 
Cooperative interaction among groups that creates an enhanced combined
effect.




To unsubscribe from this group, send an email to:
gpsxml-unsubscribe+yahoogroups.com

 

Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/ 





sequences: please comment

kevin+synergysa.com.au on Fri Dec 14 20:12:30 2001 (link)


Hi All
 
 
Proposal:  Change the Sequence attribute to be required - was optional.
 
Currently the Schema defines the "seq" attribute of tracks and routes to
be optional, given that processing of an XML file can, in theory, be
done in any order by the processor, i do believe that we should change
seq to required to ensure processing is done in the correct order when
required.
 
Change would be:
 
    <xsd:attribute name="seq" type="xsd:decimal" use="optional"/>
 
to:
 
    <xsd:attribute name="seq" type="xsd:decimal" use="required"/>
 
this change would be for both tracks and routes - if you app is unable
to supply a sequence order - just populate with 0's (zeros) - but
1-2-3-4-5-6-7 would be great.  This also means I can use order-by
select="+seq" desc in the XSLT to display the reverse track in one easy
swoop.
 
Kevin

 

Kevin Read
S Y N E R G Y   S A
Phone. 08 8278 6296
Fax. 08 8278 6296
Mobile. 0419 61 7100
Email. kevin+synergysa.com.au
Web. http://www.synergysa.com.au <http://www.synergysa.com.au/> 
 Synergy SA Logo <http://www.synergysa.com.au/images/sml_logo.jpg> 

syn.er.gy.

	
1.	The interaction of two or more agents or forces so that their
combined effect is greater than the sum of their individual effects. 

2.	Cooperative interaction among groups that creates an enhanced
combined effect.

  _____  

 
 

------=_NextPart_001_0019_01C18576.B0EDBC90

New file uploaded to gpsxml

gpsxml+yahoogroups.com on Fri Dec 14 21:02:50 2001 (link)


Hello,

This email message is a notification to let you know that
a file has been uploaded to the Files area of the gpsxml 
group.

  File        : /Sample XML Files/Kevin Read Untitled.gpx 
  Uploaded by : kevin_read2001 <kevin+synergysa.com.au> 
  Description : KR: Sample GPX file 

You can access this file at the URL

http://groups.yahoo.com/group/gpsxml/files/Sample%20XML%20Files/Kevin%20Read%20Untitled.gpx 

To learn more about file sharing for your group, please visit

http://help.yahoo.com/help/us/groups/files

Regards,

kevin_read2001 <kevin+synergysa.com.au>
 





New file uploaded to gpsxml

gpsxml+yahoogroups.com on Fri Dec 14 21:04:00 2001 (link)


Hello,

This email message is a notification to let you know that
a file has been uploaded to the Files area of the gpsxml 
group.

  File        : /Misc/gpx xslt.zip 
  Uploaded by : kevin_read2001 <kevin+synergysa.com.au> 
  Description : XSLT Stylesheet to transform and view GPX files 

You can access this file at the URL

http://groups.yahoo.com/group/gpsxml/files/Misc/gpx%20xslt.zip 

To learn more about file sharing for your group, please visit

http://help.yahoo.com/help/us/groups/files

Regards,

kevin_read2001 <kevin+synergysa.com.au>
 





Re: Schema Rel Candidate 1.0

davewissenbach+yahoo.com on Sat Dec 15 16:55:02 2001 (link), replying to msg

--- In gpsxml+y..., "Kevin Read" <kevin+s...> wrote:
> 
> http://groups.yahoo.com/group/gpsxml/files/Schema/gpsxml_1.0.xsd
> 
> Who knows (or cares )
> 
> Kevin
> 
> 
> -----Original Message-----
> From: Kevin Read [mailto:kevin+s...] 
> Sent: Saturday, 15 December 2001 12:35 PM
> To: gpsxml+y...
> Subject: [gpsxml] Schema Rel Candidate 1.0
> 
> 
> Hi All
> 
> here it is:
> 
...
<xsd:element name="ele" type="xsd:string" minOccurs="0" 
use="optional"/>

I've played with this and have a few nits to pick:

The xerces 1_5_2 parser (which I'm not using in my applications but 
am using to validate samples) complains about the use attribute in 
this and other element declarations. I believe that this is because 
the use attribute is a contstraint valid for attributes, not 
elemements.

Also, in my samples I am using the element src in wpt, trk, and rte, 
for a line of text such as "logged by Dave Wissenbach with Garmin 
GPS". I believe that this usage is consistent with our previous 
discussion on the group, and that therefore src should be valid and 
added to the schema. My newer sample FileFormat.gpx adds the src 
element after desc. This tag wasn't in my original FileFormat.gpx.

For some reason having to do with the target namespace, I wasn't 
able to even attempt to validate with an unmodified schema. But I 
believe that this is a limitation of the xerces parser. How do you 
validate XML and test the schema? I think that if I can use the same 
reference parser I'll be way ahead. (I'd validate only sample files 
produced by my application-- I'm using my own parsing internally 
which will not validate.

Thanks for posting the latest Schema,

Dave

And of course there's still the question of providing a method for 
the private tags.





Re: sequences: please comment

davewissenbach+yahoo.com on Sat Dec 15 16:59:42 2001 (link), replying to msg

--- In gpsxml+y..., "Kevin Read" <kevin+s...> wrote:
> Hi All
>  
>  
> Proposal:  Change the Sequence attribute to be required - was 
optional.
>  
> Currently the Schema defines the "seq" attribute of tracks and 
routes to
> be optional, given that processing of an XML file can, in theory, 
be
> done in any order by the processor, i do believe that we should 
change
> seq to required to ensure processing is done in the correct order 
when
> required.
>  
> Change would be:
>  
>     <xsd:attribute name="seq" type="xsd:decimal" use="optional"/>
>  
> to:
>  
>     <xsd:attribute name="seq" type="xsd:decimal" use="required"/>
>  
> this change would be for both tracks and routes - if you app is 
unable
> to supply a sequence order - just populate with 0's (zeros) - but
> 1-2-3-4-5-6-7 would be great.  This also means I can use order-by
> select="+seq" desc in the XSLT to display the reverse track in one 
easy
> swoop.
>  
> Kevin
> 

This might also be useful for people who for whatever reason want to 
manually edit, and is easy to do. So I'm not opposed to this change--
but I'd like to see comments from others before agreeing.


Re: [gpsxml] sequences: please comment

egroups+topografix.com on Sun Dec 16 15:24:37 2001 (link), replying to msg

Hello,

Friday, December 14, 2001, 11:12:10 PM, Kevin wrote:

KR> Proposal:  Change the Sequence attribute to be required - was optional.
 
KR> Currently the Schema defines the "seq" attribute of tracks and routes to
KR> be optional, given that processing of an XML file can, in theory, be
KR> done in any order by the processor, i do believe that we should change
KR> seq to required to ensure processing is done in the correct order when
KR> required.

Are there any known examples of XML parsers that exhibit this
behavior?  Is this a problem in theory, or in practice?

KR> Change would be:
 
KR>     <xsd:attribute name="seq" type="xsd:decimal" use="optional"/>
 
KR> to:
 
KR>     <xsd:attribute name="seq" type="xsd:decimal" use="required"/>
 
KR> this change would be for both tracks and routes - if you app is unable
KR> to supply a sequence order - just populate with 0's (zeros) - but
KR> 1-2-3-4-5-6-7 would be great.
 
I have a hard time imagining how an application would be able to
handle this correctly for cases other than 1-2-3...

Have you considered all the strange sequences you'll now be accepting?
7-2-5-4...
1-2-3-7-8-9...
1-2-3-2-3-4-5...

KR> This also means I can use order-by
KR> select="+seq" desc in the XSLT to display the reverse track in one easy
KR> swoop.

One of the first decisions we made was that we would optimize GPX for
*transferring* data, and that *transforming* data would take a
secondary role in the format.

At this point, I don't see a significant benefit in requiring the
"seq" element that would offset the additional parsing and processing
burden on all GPX-enabled applications.  But I'm completely open to
further discussions.  What do others think?

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com



Re: Drawing the line

davewissenbach+yahoo.com on Sun Dec 16 18:01:17 2001 (link), replying to msg

--- In gpsxml+y..., "Kevin Read" <kevin+s...> wrote:
> Hi Guys
>  
> Can you email to me (via the list if you like) a full sample of the
> GPXML you are producing.
>  

Latest version of gpsxml provided by Map 1.2 is at my web page
http://www.cableone.net/cdwissenbach/FileFormat.gpx

This version, Map 1.2, inserts CDATA sections only when special 
characters are detected.


Re: Revised versions of EasyGPS and ExpertGPS for GPX

davewissenbach+yahoo.com on Tue Dec 18 06:23:30 2001 (link), replying to msg

--- In gpsxml+y..., Dan Foster <egroups+t...> wrote:
> Hello,
> 
> Thursday, December 13, 2001, 8:56:32 AM, Kevin wrote:
> 
> KR> Dan:  How's the revised beta of EasyGPS going?
> 
> I fixed all the problems that were found in my previous GPX
> implementation, and wrapped description strings in CDATA.
> 
>   http://www.easygps.com/beta.asp
>   http://www.expertgps.com/beta.asp
> 

Contact! ExpertGPS can now read the gpx format output from my 
program, Map, and Map can read the output of ExpertGPS. By the way, 
I really like the automatic downloading of map data from the 
internet provided by ExpertGPS and the user interface for trail 
selection and display. This is a really nice program.


> -- 
> Dan Foster
> TopoGrafix - GPS Software, Waypoints, and Maps
> http://www.topografix.com - mailto:egroups+t...


Re: Schema Rel Candidate 1.0

davewissenbach+yahoo.com on Tue Jan 01 15:31:25 2002 (link), replying to msg

I've switched to Xerces-C++ parser version 1.6.0, for schema 
validation. This parser now provides full support for schema.

On my web site, the file

http://www.cableone.net/cdwissenbach/FileFormat.gpx

now references two schemas,
http://www.cableonenet/cdwissenbach/gpsxml_0.3.xsd

and 

http://www.cableone.net/cdwissenbach/wissenbach.xsd

for validating public and private namespaces, respectively. This 
example is fully valid using the sample SAXCount application 
provided with the xerces parser. In the gpsxml_0.3.xsd I experiment 
with the derivation of wpt, trkpt, and rtept from a basic point 
type, and the definition of a modelGroup for descriptive data about 
tracks, waypoints, and routes. However, doing this required a slight 
modification of the order, as elements from the base type need to 
always come first! I also added partial annotation, because I thing 
that a usable schema needs to explain itself.

I believe that this new approach to the Schema provides better 
clarity and maintainability than the Russian Doll design previously 
used--I learned this from the book,

Professional XML Schemas by Duckett, Griffin et Al. Wrox Press.
ISBN 1-861005-47-4.

Comments? If this approach is further acceptable I'll add better 
examples to the annotation.



newbie

carsten.kurz+toma.de on Thu Jan 03 10:25:38 2002 (link)

Hi there,

I am a dedicated user of Palm PDA GPS applications (and I am doing 
some businiess with Palm/PDA-GPS interfacing). I started an initiative 
among Palm/PDA GPS application programmers to develop a standard for 
exchange of waypoints/poi among different palm applications. The Palm 
PDA has user definable address book fields, and my idea was to store 
location information in one of those fields to add geo locations to an 
address. Some programmers suggested using an XML tag like synthax.
Kjeld Jensen then pointed me towards GPX. Well, here I am now.

Our goal is, of course, much simpler than that of GPX - so far we only 
need some kind of waypoint definition.

What people suggested were lat/lon, elevation, timestamp, 
IconID, datum, etc.. With XML I guess this is open for any kind of 
extension.

A few people came up with the limited memory ressources on PDA 
platforms. Kjeld told me that GPX has quite short tag names, and I 
liked what I saw from his CETUS GPX examples.

My questions now: 

-Is there a simple, text-like definition of GPX? I found some files in 
the file area, but it seems there is no tag definition or something.

-Some programmers want to use IconIDs. I browsed the archive and found 
that GPX doesn't like IconIDs, probably because there is no standard 
for them, and IDs are too abstract. I can understand that, but if an 
application want's to store/exchange an Icon, it would have to 
maintain a full text table of all Icons, and there would have to be at 
least a minimum recommended Icon text table somewhere? Can someone 
please clear this up for me?
At first I thought it would be the easiest to simply adopt Garmins 
symbol table. There is a Palm Waypoint Tool for Garmins (GPilotS) 
which stores and displays the GII+ icon set. This would certainly be 
no problem until other manufacturers get on board.
Any ideas how to handle this?

- Are you sure you do not want a <datum> tag? I know WGS84 is widely 
used for navigation end enduser apps, but there are still a lot of 
scientific applications with different reference systems

- Though the GPX tags are short, space in those address fields is 
limited to 255bytes. What do you think about simply using the basic 
type tag, and not the full XML header for storage, like simply writing 

<wpt lat="50.9789900" lon="6.7845000"> </wpt>

into the data field? The sample GPX Waypoint including the full 
header from CETUS written to a memopad is already more than 260 chars.
Any suggestions?


Re: newbie

davewissenbach+yahoo.com on Thu Jan 03 20:28:30 2002 (link), replying to msg

--- In gpsxml+y..., "c_kurz" <carsten.kurz+t...> wrote:
> Hi there,
> 
> I am a dedicated user of Palm PDA GPS applications (and I am doing 
> some businiess with Palm/PDA-GPS interfacing). I started an 
initiative 
> among Palm/PDA GPS application programmers to develop a standard 
for 
> exchange of waypoints/poi among different palm applications. The 
Palm 
> PDA has user definable address book fields, and my idea was to 
store 
> location information in one of those fields to add geo locations 
to an 
> address. Some programmers suggested using an XML tag like synthax.
> Kjeld Jensen then pointed me towards GPX. Well, here I am now.
> 
> Our goal is, of course, much simpler than that of GPX - so far we 
only 
> need some kind of waypoint definition.
> 
> What people suggested were lat/lon, elevation, timestamp, 
> IconID, datum, etc.. With XML I guess this is open for any kind of 
> extension.
> 
> A few people came up with the limited memory ressources on PDA 
> platforms. Kjeld told me that GPX has quite short tag names, and I 
> liked what I saw from his CETUS GPX examples.
> 
> My questions now: 
> 
> -Is there a simple, text-like definition of GPX? I found some 
files in 
> the file area, but it seems there is no tag definition or 
something.
> 

Eventually, we'll get around to fully annotating the Schema.
See the schema at www.cableone.net/cdwissenbach/gpsxml_0.3.xsd for 
an example of annotation.

> -Some programmers want to use IconIDs. I browsed the archive and 
found 
> that GPX doesn't like IconIDs, probably because there is no 
standard 
> for them, and IDs are too abstract. I can understand that, but if 
an 
> application want's to store/exchange an Icon, it would have to 
> maintain a full text table of all Icons, and there would have to 
be at 
> least a minimum recommended Icon text table somewhere? Can someone 
> please clear this up for me?
> At first I thought it would be the easiest to simply adopt Garmins 
> symbol table. There is a Palm Waypoint Tool for Garmins (GPilotS) 
> which stores and displays the GII+ icon set. This would certainly 
be 
> no problem until other manufacturers get on board.
> Any ideas how to handle this?
> 

What I support in my Map application is the subset of Garmin symbols 
which are supported by the eTrex Summit. Unknown symbols just 
default to the flag symbol.

> - Are you sure you do not want a <datum> tag? I know WGS84 is 
widely 
> used for navigation end enduser apps, but there are still a lot of 
> scientific applications with different reference systems
> 
> - Though the GPX tags are short, space in those address fields is 
> limited to 255bytes. What do you think about simply using the 
basic 
> type tag, and not the full XML header for storage, like simply 
writing 
> 
> <wpt lat="50.9789900" lon="6.7845000"> </wpt>
> 
> into the data field? The sample GPX Waypoint including the full 
> header from CETUS written to a memopad is already more than 260 
chars.

Only the attributes are required, so the above example conforms to 
the gpsxml standard, such as it is.

> Any suggestions?


Re: newbie

carsten.kurz+toma.de on Fri Jan 04 10:04:01 2002 (link), replying to msg


> What I support in my Map application is the subset of Garmin symbols 
> which are supported by the eTrex Summit. Unknown symbols just 
> default to the flag symbol.

But how do you match the symbol/icon entries in an GPX file to those 
of your application or to those of a specific receiver? By full string 
matching? 
Excuse me, I'm not that familiar with GPX right now - I saw a few GPX 
samples with 'summit' in them. Does GPX also contain data to identify 
a specific receivers Icon table?
 
I will try to find my way through this schema, though I don't know 
much about XML.


- Carsten


[gpsxml] Re: GPX Symbol Names

egroups+topografix.com on Fri Jan 04 10:24:00 2002 (link), replying to msg

Hello,

Friday, January 04, 2002, 1:04:02 PM, Carsten wrote:


>> What I support in my Map application is the subset of Garmin symbols 
>> which are supported by the eTrex Summit. Unknown symbols just 
>> default to the flag symbol.

c> But how do you match the symbol/icon entries in an GPX file to those 
c> of your application or to those of a specific receiver? By full string 
c> matching? 

Exactly.  If your application has a symbol called "Summit" available,
you use that symbol.  If it doesn't, you use the default symbol, as
defined by your program.

The user will understand this.  If he's exchanging data with another
user who has the same GPS, the symbols will always match.  If he's
exchanging data with someone using a different manufacturer's GPS, he
should expect that the symbols won't come across.  He may even get
lucky: if Garmin and Magellan both have a "House" symbol, it will come
through intact, even though Garmin uses a 16 bit integer, and Magellan
uses a letter to represent House.

To make this work, you should use the exact name of the symbol as
shown on the GPS.  For example, "Trail Head" (Garmin eTrex), and not
"Trailhead" or "trail head".

If you're writing a Palm app to act as a GPS, you should consider
naming your symbols in a way that will allow compatibility with the
named symbols used by Garmin, Magellan, etc.  If I was doing this, I'd
consider adopting the Garmin eTrex symbol set, which is likely the most
popular one in use.

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com



Mac GPS Pro

carsten.kurz+toma.de on Mon Jan 07 12:43:15 2002 (link)

Does anyone know wether there is demo of Mac GPS Pro available 
somewhere? I can't find any hint on the Mac GPS Pro site, but I keep 
hearing about a demo.

- Carsten


Wrapping up GPX 1.0 Specification

egroups+topografix.com on Thu Jan 10 13:59:38 2002 (link), replying to msg

Hello,

 I'm going to spend some time this week documenting our work on GPX,
 and trying to wrap up some unfinished decisions, so we can start
 deploying GPX 1.0 applications.  To keep it easier to follow the
 conversations, I'll post each issue as a separate e-mail with a
 relevant subject line.

 I encourage you, if you have remaining questions or concerns about
 GPX, to share your ideas or questions now.

 Best wishes in 2002 to all of you!

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com



Are Schemas required in GPX?

egroups+topografix.com on Thu Jan 10 14:04:18 2002 (link), replying to msg

Hello,

Are Schemas required in GPX?

Dave proposed a method for specifying a public and a private schema
for GPX validation.  It looks good, and I haven't heard any
counter-proposals.  But we haven't discussed whether schemas are:
A. required?
B. optional?
C. forbidden?

B is the default answer.  Anyone care to argue for A or C?

Assuming we go with A or B, it seems like we should all refer to a
master public schema.  I'd be happy to host it (and the rest of the
GPX documentation) here at http://www.topografix.com/gpx/  Or we can
use the http://groups.yahoo.com/group/gpsxml/ file area, but that
isn't accessible without logging in.

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com



Re: Are Schemas required in GPX?

davewissenbach+yahoo.com on Fri Jan 11 21:53:34 2002 (link), replying to msg

Kjeld,

I don't think that the schema is necessary, but I think that it can 
make the format a lot easier to figure out. The sample schema 
gpsxml_0.3.xsd on my web site also includes annotations, which 
ultimately could be extended to also provide examples. But there is 
the downside to the schema in that it enforces a particular order on 
elements, which is not actually enforced by the applications. Right 
now my program, which I'm calling Wissenbach Map, interoperates well 
with ExpertGPS with beta gpsxml support, even though ExpertGPS 
doesn't exactly conform to the schema. (It can't, because I changed 
the element order after Dan published!). The problem right now is 
the order of elements, which I arbitrarily changed in order to use 
the principle of inheritance in the schema. (Allowing arbitrary 
element order would make the schema very complicated, which is a 
downside to using a schema.)

But the schema can provide a central place to insert documentation, 
including a recommendation that applications which conform to the 
GPS standard should be written with a high degree of tolerance for 
such things as order and unexpected tags.

So I'd say that applications should attempt to conform to the 
schema, but not to validate against the schema. (I validate my own 
output at development time, but I don't validate yours at run time.) 
Then, when you add new tags, with explanation, such as hdop and vdop 
to the schema, you alter the schema to include these new tags, with 
examples and annotation.

I'll accept Dan's offer to maintain and explain, or at least host, 
the schema. I found that I had to put a copy on my personal web page 
in order to see it and validate. Without the support of an authoring 
program such as ExpertGPS and a reading program such as EasyGPS the 
gpsxml format won't reach critical mass.

In the long run the presence of a well-documented, professionally 
presented schema, with sample output which corresponds exactly to 
that schema, will be the only way to enable others to interoperate 
with our applications. The 100-odd messages in this discusssion 
group have become way too complex for any of us to follow. Remember 
that standards are what made the World Wide Web possible in the 
first place.

Dave


--- In gpsxml+y..., Kjeld Jensen <gps+c...> wrote:
> 
> >Dave proposed a method for specifying a public and a private 
schema
> >for GPX validation.  It looks good, and I haven't heard any
> >counter-proposals.  But we haven't discussed whether schemas are:
> >A. required?
> >B. optional?
> >C. forbidden?
> 
> Well let me try arguing for C (for GPX version 1.0)
> 
> The way I see it we nee to publish a version "1.0" of GPX in order 
to gain
> some experience. In my opinion this format should be quite simple 
to
> implement which will have the following advantages:
> 
> - for people who haven't participated in the discussions it is 
easier to
> get the idea without having to focus on schemes which requires 
some degree
> of XML knowledge.
> 
> - we will probably get more people to support it as it is easier to
> implement (everybody have to start from scratch)
> 
> - it will be easier for us to implement
> 
> I therefore suggest, that we publish this first version of GPX 
without
> support for XML schemes. Instead it should be based on a number of 
simple
> XML compliant directives (authored by Dan and supported by the 
rest of us)
> published on a dedicated GPX homepage. The homepage should also 
maintain a
> list of applications which supports the GPX 1.0 format (measured 
on that
> all the directives are followed).
> 
> This will definitely cause problems, but it is the only way to...
> 
> - move to "working release" as soon as possible (January)
> - gain some valuable experience
> 
> When we discover problems - probably mostly due to the lack of 
strict
> directives, we discuss them and implement them in 1.01 and so on.
> 
> Along with this we should start focusing on version 1.1 which I 
believe
> should contain optional use of XML schemes.
> 
> My five (euro) cents
> 
> Kjeld
> 
> ______________________
> Kjeld Jensen
> N 55� 22' E 10� 24'
> Email: gps+c...
> http://www.cetus.dk/gps


Re: [gpsxml] Are Schemas required in GPX?

egroups+topografix.com on Wed Jan 16 11:15:36 2002 (link), replying to msg

Hello,

Thursday, January 10, 2002, 5:01:32 PM, I wrote:

DF> Are Schemas required in GPX?

I didn't hear anyone argue that we should *never* support schemas.
(Kjeld argued that we should support them at a later date).  So it
sounds like there's consensus that schemas are a good thing, and GPX
should eventually support them.

Unfortunately, if we're to have backwards compatibility, we need to
make some decisions now (like the order of elements) so that we'll be
able to apply a reasonable schema to GPX in the future.

As I sat down to start writing documentation, it became clear that the
detail I was putting into each element description was really just a
schema in English.  Also, I started thinking about how we were going
to "certify" new GPX developers (to make sure their GPX output was
valid).  Having a schema is a very fast way to write a validation
checker - just see if the new files validate against the schema!

So, here are my recommendations:
 1. We should create an official schema before releasing GPX 1.0.
 2. We should agree on an official validation tool and method for
     certifying that GPX files are valid.
 3. We should adopt a namespace versioning method so that new versions
     of GPX each have a new schema.
 4. I should write some documentation to accompany the GPX schema,
     since reading schemas is a bit tricky.  (But the schema is still
     the official definition of GPX.)

I've read through the schemas proposed by Kevin and Dave, and created
a new version 0.4 schema which draws on both ideas.  Strangely, I
found that the great documentation in Dave's latest schema actually
made it harder to read, so I've stuck with inline comments.  I stuck
with Dave's element ordering, but used the flat format of Kevin's
schema to make it easier (to my mind) to determine what tags are
allowed for each object.

To support versioning, I've created sub-folders at
http://www.topografix.com/GPX/ for the major and minor versions of the
standard, so version 0.4 lives at
http://www.topografix.com/GPX/0/4/gpx.xsd

As far as validation goes, I've started using the Xerces 1.6.0 parser
as suggested by Dave, and suggest that we adopt it as our validation
tool.  I'll put together some instructions for validating GPX files if
we choose to go this route.  (Dave: I'm using the following options:
"saxcount -n -s -f -v=always test_gpx_file.gpx")

I've updated my software to reference this schema, and have created a
private schema for testing purposes.
http://www.topografix.com/GPX/Private/TopoGrafix/0/1/topografix.xsd

I'll post later tonight once new beta versions of my software are
available for use.

Please give some thought to the recommendations I've proposed, and
share your comments.
--
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com



Re: Are Schemas required in GPX?

davewissenbach+yahoo.com on Wed Jan 16 21:34:45 2002 (link), replying to msg

--- In gpsxml+y..., Dan Foster <egroups+t...> wrote:
> Hello,
> 
...
> 
> I've read through the schemas proposed by Kevin and Dave, and 
created
> a new version 0.4 schema which draws on both ideas.  Strangely, I
> found that the great documentation in Dave's latest schema actually
> made it harder to read, so I've stuck with inline comments.  I 
stuck
> with Dave's element ordering, but used the flat format of Kevin's
> schema to make it easier (to my mind) to determine what tags are
> allowed for each object.
> 

Yes, as I was writing the 0.3 schema I came to the same realization, 
and my intention was to patch it up with examples in the annotation. 
And of course you recognize that some of the documentation in that 
schema was lifted straight out of your own posts. What I was doing 
was experimenting with the idea of inheritance in the schema.

I think that going back to the anonymous type method proposed by 
Kevin Read is OK. The schema will probably be slightly more 
difficult to maintain and extend, but much easier to read.

> To support versioning, I've created sub-folders at
> http://www.topografix.com/GPX/ for the major and minor versions of 
the
> standard, so version 0.4 lives at
> http://www.topografix.com/GPX/0/4/gpx.xsd
> 

I think that versioning will work well. I assume that a version 0.5 
schema will validate a 0.4 document--or that we'll try to keep 
backward compatibility as the schema is extended to include more 
concepts.

> As far as validation goes, I've started using the Xerces 1.6.0 
parser
> as suggested by Dave, and suggest that we adopt it as our 
validation
> tool.  I'll put together some instructions for validating GPX 
files if
> we choose to go this route.  (Dave: I'm using the following 
options:
> "saxcount -n -s -f -v=always test_gpx_file.gpx")
> 
I used the same command line but left off the -v=always.

> I've updated my software to reference this schema, and have 
created a
> private schema for testing purposes.
> http://www.topografix.com/GPX/Private/TopoGrafix/0/1/topografix.xsd
> 
> I'll post later tonight once new beta versions of my software are
> available for use.
> 
> Please give some thought to the recommendations I've proposed, and
> share your comments.
> --
> Dan Foster
> TopoGrafix - GPS Software, Waypoints, and Maps
> http://www.topografix.com - mailto:egroups+t...


TopoGrafix software for GPX 0.4

egroups+topografix.com on Fri Jan 18 10:43:35 2002 (link), replying to msg

Hello,

I've updated my beta software to read/write GPX 0.4.

The new software can be downloaded from:
EasyGPS:   http://www.easygps.com/beta.asp
PanTerra:  http://www.topografix.com/beta.asp
ExpertGPS: http://www.expertgps.com/beta.asp

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com



GPX Overview Documentation

egroups+topografix.com on Fri Jan 18 17:35:09 2002 (link), replying to msg

Hello,

I've written several GPX documents to provide an overview of GPX (for
developers and for GPS users).  I still need to write a developer's
document explaining the specifics of writing a GPX.

Please feel free to comment on the documentation.  Offline comments
can be sent to gpx+topografix.com

Overview: http://www.topografix.com/gpx.asp
Links to:
  GPX for GPS Users
  GPX for Developers
  Validating your GPX output
  GPX Resources
  GPX Schema 0.4

If you'd like your GPX application or webpage listed on the GPX
Resources page, send me your URL.  I won't list your app unless you
request it, since we're all still in development.

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com



Re: Regarding the XML schema

davewissenbach+yahoo.com on Sun Jan 20 21:03:00 2002 (link), replying to msg

--- In gpsxml+y..., Kjeld Jensen <gps+c...> wrote:

...

> They are added below the <type> element definition. <fix> should 
be either
> "2D" or "3D" but I don't know how to specify this (Dave?)
> 

Here's an equivalent example from my private elements, which I 
tested and found to work. (This is from the schema which evaluates 
my private elements. Because nobody else will use the layer element, 
this element fits into the any wildcard slot from the output of my 
GPS program, which I vainly call "Wissenbach Map". I think that the 
type definition can be anywhere in the schema, but I'm not sure 
about this.

<xs:simpleType name="LayerType">
  <xs:restriction base="xs:string">
    <xs:enumeration value="plan_log"/>
    <xs:enumeration value="trailmap"/>
  </xs:restriction>
</xs:simpleType>

<xs:element name = "layer" type="LayerType"/>


> 
> What do you think of all this?
> 
> Best regards
> Kjeld Jensen
> 
> ______________________
> Kjeld Jensen
> N 55� 22' E 10� 24'
> Email: kjeld+C...
> http://www.CetusGPS.dk


Re: [gpsxml] Regarding the XML schema

egroups+topografix.com on Tue Jan 22 09:19:39 2002 (link), replying to msg

Hello,

I've got a few questions about units for some of the new GPX tags.

Also, any objections to adding the <src> tag to <rte> and <trk> in
addition to <rtept> and <trkpt>?  For many tracks, I'd just tag the
source of the <trk> element since the source doesn't change for any of
the <trkpt> elements.

Sunday, January 20, 2002, 6:32:14 AM, Kjeld wrote:

KJ> <fix> should be either
KJ> "2D" or "3D"

Can we also add a representation for "no fix"?  Many GPS will allow you to
write a new trackpoint at a set time interval, and if this occurs when
no satellite lock is present, you'll get a trackpoint with no fix.

There are at least two ways to express this.  What do you think of the
following:
  <fix>None</fix>
or:
  <sat>0</sat>

I prefer <fix>None</fix> - it seems to me to be more explicit.

For the elements below, we need to agree on units.  Here's what NMEA
uses:
KJ> <xsd:element name="course"      type="gpx:course"       minOccurs="0"/>
degrees, true.  Is this what you intended?

KJ> <xsd:element name="speed"       type="xsd:decimal"      minOccurs="0"/>
NMEA: knots (nautical miles per hour).
GPX:  we agreed to use metric.  meters/second would be the obvious
choice.  Thoughts?

KJ> <xsd:element name="fix" type="xsd:string"       minOccurs="0"/>
type="xsd:string" gets replaced with an enum, as per Dave's email.
There are two NMEA messages that report fix, and they use different
values:
GSA:
  1 = fix not available
  2 = 2D
  3 = 3D
GGA:
  0 = fix not available
  1 = GPS SPS Mode
  2 = Differential GPS, SPS Mode
  3 = PPS Mode (military signal)

KJ> <xsd:element name="sat" type="xsd:positiveInteger"      minOccurs="0"/>
non-negative integer if we allow <sat>0</sat>

KJ> <xsd:element name="hdop"        type="xsd:decimal"      minOccurs="0"/>
KJ> <xsd:element name="vdop"        type="xsd:decimal"      minOccurs="0"/>
KJ> <xsd:element name="pdop"        type="xsd:decimal"      minOccurs="0"/>
I've never been able to find an exact definition of these terms which
includes units.  We'll just use the raw numbers from the GPS.

KJ> Since memory is limited on a Palm I will probably remove the schema
KJ> reference from the waypoint gpx files generated by Cetus GPS when we reach
KJ> 1.0. But as long as we still make modifications to the schema I will leave
KJ> it there.

I think this is a bad idea.  A GPX file without a reference to the schema won't
validate.  The reference does take up some space in the file, but no
more than one or two waypoints or tracks in the file.  I'd expect that
the entire GPX header including schema reference adds less than 1% to the average
GPX file.



-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com



Re: Regarding the XML schema

davewissenbach+yahoo.com on Tue Jan 22 21:02:39 2002 (link), replying to msg

--- In gpsxml+y..., Dan Foster <egroups+t...> wrote:
> Hello,
> 
> I've got a few questions about units for some of the new GPX tags.
> 
> Also, any objections to adding the <src> tag to <rte> and <trk> in
> addition to <rtept> and <trkpt>?  For many tracks, I'd just tag the
> source of the <trk> element since the source doesn't change for 
any of
> the <trkpt> elements.
> 

That's a difference between the content model of my unofficial 0.3 
schema and the official 0.4 revision. My Wissenbach Map program 
failed validation against the 0.4 schema only because I used <src> 
in both <rte> and <trk>, so of course I heartily endorse this change!

> -- 
> Dan Foster
> TopoGrafix - GPS Software, Waypoints, and Maps
> http://www.topografix.com - mailto:egroups+t...


Re: [gpsxml] there is a problem...

hamish+travellingkiwi.com on Wed Jan 23 04:35:45 2002 (link)

Kjeld Jensen wrote:

>  ... with the
>
> <fix>none</fix>
>
> If this (optional) element is found in the <wpt>, <trk> or <rte>
> element
> this means that all navigation related information is invalid...
>
> That includes lat and lon.
>
> I didn't think of this before but if we allow the "none" option it
> implies
> a rather complex evaluation of each record:
>
> 1. is there a <fix> element included?
> 2. is it "none"
> 3. if it is then we have to dischard all information...
>
> It would be much easier if all records inherently contains valid data.
>
> Based on this I recommend that we only allow  <wpt>, <trk> and <rte>
> elements with a valid fix i.e. we do not allow the "none" option.
>

Then how do you specify waypoints created by point & click on a map?

--

I don't suffer from Insanity...         | Linux User #237369
        I enjoy every minute of it...   |
                                        |
http://www.travellingkiwi.com/          |




Handheld limitations...

andrzej+chaeron.com on Wed Jan 23 06:41:34 2002 (link)

Kjeld said:

> I see your point, but it is not that easy to overcome the size limitations
> on handheld units.

That does apply to the current crop of Palm devices, and your suggestion of 
using a compressed (non-XML) format for track storage is the way to go for 
the moment.

However, Moore's law does appy to PDA's, and the next wave of Palm 
devices will likely be 32/64MB units (and more with SD or CF slots) running on 
200mhz+ ARM processors.

I believe that within a year or so, the extra storage will be a non-issue even on 
PDA's (mobile phone devices might still not be there though).

The beauty of XML is it's portability and human-readability.  I can see some 
users editing the XML directly to change/fix their waypoints.  You don't want to 
sacrifice the strengths/benefits of XML due to a (short term) limitation of 
handheld devices.

Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com


Re: [gpsxml] there is a problem...

hamish+travellingkiwi.com on Wed Jan 23 07:41:27 2002 (link)

Kjeld Jensen wrote:

>  >Then how do you specify waypoints created by point & click on a map?
>
> Well they are inherently valid and in my opinion such a waypoint
> specified
> aa <wpt></wpt> should not include any of the optional elements:
>
> <fix>
> <sat>
> <hdop>
> <vdop>
> <pdop>

Right. No problem. Thanks. I missed that... Sorry about that... Doh!!
(Hammer goes my head on the desk)...


--

I don't suffer from Insanity...         | Linux User #237369
        I enjoy every minute of it...   |
                                        |
http://www.travellingkiwi.com/          |




GPX Schema 0.5 candidate

egroups+topografix.com on Wed Jan 23 10:47:40 2002 (link), replying to msg

Hello,

I gathered up all the feedback on the 0.4 schema, and created a
candidate 0.5.  Take a look, and suggest any changes you'd like to see
it in before we lock it down as the official 0.5

 http://www.topografix.com/GPX/0/5

Changes made:
added fix, sat, hdop, vdop, pdop to wpt, trkpt, rtept
added src to trk, rte
added fix enumerations
bumped version number and namespace to 0.5

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com



Re[2]: [gpsxml] GPX Schema 0.5 candidate

egroups+topografix.com on Thu Jan 24 11:36:15 2002 (link), replying to msg

Hello,

Wednesday, January 23, 2002, 3:33:58 PM, Kjeld wrote:

KJ> You did not include the <course> and <speed> elements in the <trk> element.

KJ> Regarding the <fix> we need to figure out a principle for validation of
KJ> each record if we are to include the "none" option.

KJ> lat and lon are required and for all other options of any element they hold
KJ> a valid position. But when a <fix>none</fix> element is present this is not
KJ> the case.

KJ> Should we requre the  lat/lon values to be set to "" then or should the
KJ> import feature simply disregard the value?

KJ> I vote for the exclusion of the "none" option as it complicates the format
KJ> and it should be fairly easy for a programmer to avoid adding records for
KJ> positions that are not valid .

I've updated the 0.5 spec to include <course> and <speed> in <trkpt>.

This <fix> discussion is bringing us back to one of our earliest
debates, which was "how to represent a tracklog where GPS lock was
lost between two points?"

Fix isn't a good way to solve this, since at point A and at point B,
the GPS has a good fix.  However, between A and B the GPS lost the
fix, and many GPS and mapping programs show this by not connecting the
line segment between A and B.  How can we express this in GPX?

I proposed an element to describe the connecting segment (called
<link> or <leg>).  I still think that this is an important concept
that's missing from GPX now.

Any other ideas or suggestions?

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com



Structure, future elements in GPX

egroups+topografix.com on Thu Jan 24 13:36:59 2002 (link), replying to msg

Hello,

Thursday, January 24, 2002, 4:02:32 PM, Kjeld wrote:

KJ> I don't know how important this is, but since the elements must appear in
KJ> order, maybe we should consider structuring this a little?

KJ> It might be an idea to for instance define a structure like...

KJ> <trkpt>(or waypt or rtept)
KJ> navigation data retrieved from the gps (elevation, time, course, speed)
KJ> data precision info from the gps (fix, sat, hdop, vdop, pdop)
KJ> other info (name, cmt, desc, src, sym, type)
KJ> </trkpt>

KJ> It is not important to me which order the groups have, but I think we
KJ> should at least regroup them a little.

KJ> Comments?

  I'm starting to get uneasy about the lack of structure, as well.
  We're backing ourselves into a wall with the current rules:
   1. all optional tags are attributes.
   2. tags must be listed in order.

  I like the idea of arranging all the navigation data together, but
  what happens when we add a new navigation tag?  It has to go at the
  end to be compatible with the older schemas.

  I'm also worried that we have no way to address Kjeld's earlier
  question: what happens when the data in one tag (fix=none) means
  that other tags aren't allowed to exist?
  
  Maybe we should discuss turning some of these "groups of related
  tags" into their own elements.  Just an example:

  <trkpt>
    <position lat="42.1" lon="-71.2" ele="300.0" time="..."\>
    <nav_info course="45" speed="20.4" cross_track_error="-345.0"\>
    <precision fix="3d" sats="7" hdop="2.3" vdop="2.3"\>
    <name>TRKPT3</name>
    <src>Garmin eTrex</src>
  </trkpt>

Thoughts?  It might be helpful to start thinking about additional data
that might be included in future versions of GPX, and how those
concepts would be broken down into elements.  Some ideas off the top
of my head:
 NMEA or real-time positioning data (nav_info above)
 how data should be displayed on a map (Dave's layers, my route color)
 statistical data for waypoint averaging
 map calibration data

 Others?

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com



Re: [gpsxml] Structure, future elements in GPX

hamish+travellingkiwi.com on Thu Jan 24 15:45:11 2002 (link)

Dan Foster wrote:

>  Hello,
>
> Thursday, January 24, 2002, 4:02:32 PM, Kjeld wrote:
>
> KJ> I don't know how important this is, but since the elements must
> appear in
> KJ> order, maybe we should consider structuring this a little?
>
> KJ> It might be an idea to for instance define a structure like...
>
> KJ> <trkpt>(or waypt or rtept)
> KJ> navigation data retrieved from the gps (elevation, time, course,
> speed)
> KJ> data precision info from the gps (fix, sat, hdop, vdop, pdop)
> KJ> other info (name, cmt, desc, src, sym, type)
> KJ> </trkpt>
>
> KJ> It is not important to me which order the groups have, but I think
> we
> KJ> should at least regroup them a little.
>
> KJ> Comments?
>
>   I'm starting to get uneasy about the lack of structure, as well.
>   We're backing ourselves into a wall with the current rules:
>    1. all optional tags are attributes.
>    2. tags must be listed in order.
>

Umm... I wondered about this... Why must all tags be in order? (Besides
that's the way the spec is written, is the a really really cool reason
I've overlooked?)

--

I don't suffer from Insanity...         | Linux User #237369
        I enjoy every minute of it...   |
                                        |
http://www.travellingkiwi.com/          |




Re: Structure, future elements in GPX

davewissenbach+yahoo.com on Thu Jan 24 20:17:24 2002 (link), replying to msg

--- In gpsxml+y..., Hamish Marson <hamish+t...> wrote:
> >
> >   I'm starting to get uneasy about the lack of structure, as 
well.
> >   We're backing ourselves into a wall with the current rules:
> >    1. all optional tags are attributes.
> >    2. tags must be listed in order.
> >
> 

> Umm... I wondered about this... Why must all tags be in order? 
(Besides
> that's the way the spec is written, is the a really really cool 
reason
> I've overlooked?)
> 
The only reason for this is that the schema is easy to write. In my 
one bootleg version of the schema, 0.3, I made parameter groups, and 
it was difficult to do this without enforcing an order. However, 
there is a way out, which I have tested (and even published in this 
forum.) Now that we have a flat schema, we can wrap the entire 
content model of each element in a choice block, and allow multiple 
occurences of that choice. This construct prevents us from 
disallowing that an element occur more than once, while freeing us 
from the constraint that elements have to occur in a particular 
order!

I'd recommend that all applications code to a rigid sequence that 
follows the schema but allow any order of elements when parsing. I 
believe that's what the topografix applications do, and that's what 
my application does.



gpsxml samples

davewissenbach+yahoo.com on Fri Jan 25 13:44:54 2002 (link)

I have updated my Boise area trail map web site to the 0.5 gpsxml 
standard. All of the maps reference the 0/5/gpx.xsd schema at the 
topografix web site, and sample output from Wissenbach Map 1.4 
validated, so I assume that all of the maps on the site are valid. A 
copy of Wissenbach Map 1.4 is also downloadable from the map web 
site at the URL below:

http://www.cableone.net/cdwissenbach


Re: [gpsxml] gpsxml samples

egroups+topografix.com on Fri Jan 25 16:40:34 2002 (link), replying to msg

Hello,

Friday, January 25, 2002, 1:48:36 AM, Dave wrote:

d> I have updated my Boise area trail map web site to the 0.5 gpsxml 
d> standard. All of the maps reference the 0/5/gpx.xsd schema at the 
d> topografix web site, and sample output from Wissenbach Map 1.4 
d> validated, so I assume that all of the maps on the site are valid. A 
d> copy of Wissenbach Map 1.4 is also downloadable from the map web 
d> site at the URL below:

d> http://www.cableone.net/cdwissenbach

I found some errors in my XML parser after opening Dave's
BoiseFront.gpx file.  It's a good stress test - over half a megabyte
of trails!

Dave, I noticed that some of your waypoint symbols aren't being
recognized by my software.  I use the exact spelling of the symbol
name as listed on the GPS, so there's a mismatch between some of your
"compressed" names (WaypointDot, BoatRamp, FirstAid, etc) and my names
(Waypoint, Boat Ramp, First Aid, etc).  I actually found a few
mistakes in my symbol list as I checked this.  (I had one called
Boat/Boat Ramp which is now just Boat Ramp.)

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com



Re[2]: [gpsxml] Structure, future elements in GPX

egroups+topografix.com on Fri Jan 25 17:04:30 2002 (link), replying to msg

Hello,

Friday, January 25, 2002, 4:21:35 AM, Kjeld wrote:

>>   2. tags must be listed in order.

KJ> 2. I suppose that's because of the schema as dave said, but why is this a
KJ> limitation.

KJ> Suppose an application supports GPX 1.0 (structured as in the current 0.5)
KJ> and you create a lot of GPX files with it. Then you upgrade to GPX 1.1
KJ> which contains more elements inserted at different places. The new GPX 1.1
KJ> will be able to read the 1.0 files without any problems as the elements are
KJ> optional and the old files just don't contain any of them.

KJ> So I can't follow you when you say that the order is a problem and that
KJ> this prevents us from regrouping the elements now as I suggested?

Suppose I write my app to import GPX 1.0 files, and I strictly enforce
the order that is specified in the schema, but allow unknown element
at the end of each element (like the schema currently permits).

You upgrade your app to write GPX 1.1 files, which have a new element
inserted between two of the old 1.0 elements.  You send this GPX file
to my 1.0 app.  It won't work.

Old 1.0 files would validate against the 1.1 schema, but 1.1 files
wouldn't validate against the 1.0 schema.

We should be able to specify things so that new files can be validated
against the old schema.

[As Dave points out in an earlier email, most of us aren't enforcing
the order when we parse documents, so this isn't much of an issue in
practice...]

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com



GPSml first public version posted.

andrzej+chaeron.com on Mon Jan 28 18:58:54 2002 (link)

Hi all:

I decided to post an early release of the GPSml XMLSchema for GPS 
information to allow some feedback.

GPSml V0.5 is now up at http://www.chaeron.com/gps

The design goals for GPSml are:

- Be an XML format for all GPS-generated data, both real-time position related 
data and collections (such as waypoints, tracks, routes)

- Be easy to generate in software, even apps without XML understanding.

= Be easy for modern XML parsers to parse and feed in to applications.

- Let a single file contain real-time position information and arbitrary collections 
(such as waypoints, tracks, routes)

- Scale gracefully to handle both simple and complex requirements

- Be flexible and extensible since the GPS arena is evolving rapidly

- Follow current XMLSchema best practices (where known)

The distribution contains a detailed readme file, XMLSpy generated 
documentation and the full GPSml schema.

Be sure to read the Design Notes in the readme and keep in mind that this is a 
very early draft and so is a bit rough around the edges and not complete yet.

Any/all feedback is much appreciated.

Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com


GPSml corrected URL.

andrzej+chaeron.com on Mon Jan 28 19:21:46 2002 (link)

The correct URL for GPSml V0.5 (and the Java GPS Access Library V 0.96 
beta) is 

http://www.chaeron.com/gps.html

Sorry!

Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com


Re: gpsxml samples

davewissenbach+yahoo.com on Tue Jan 29 05:43:24 2002 (link), replying to msg

--- In gpsxml+y..., Dan Foster <egroups+t...> wrote:
> Hello,
> 
> 
> I found some errors in my XML parser after opening Dave's
> BoiseFront.gpx file.  It's a good stress test - over half a 
megabyte
> of trails!
> 
> Dave, I noticed that some of your waypoint symbols aren't being
> recognized by my software.  I use the exact spelling of the symbol
> name as listed on the GPS, so there's a mismatch between some of 
your
> "compressed" names (WaypointDot, BoatRamp, FirstAid, etc) and my 
names
> (Waypoint, Boat Ramp, First Aid, etc).  I actually found a few
> mistakes in my symbol list as I checked this.  (I had one called
> Boat/Boat Ramp which is now just Boat Ramp.)
> 
The next version of Wissenbach Map will match the symbols used by 
ExpertGPS (I've tested this already). When I publish Wissenbach Map 
1.5 and update the web site I'll also update the samples to use the 
new symbol names. Right now my ftp connection is down, so this will 
have to wait.
> -- 
> Dan Foster
> TopoGrafix - GPS Software, Waypoints, and Maps
> http://www.topografix.com - mailto:egroups+t...


Re: GPSml comments.....

andrzej+chaeron.com on Wed Jan 30 08:20:42 2002 (link)

Kjeld Jensen wrote:

> First of all I am a little surprised to see your posting here. This
> mailing list was created to support the development of a generic GPS
> position exchange format which yours is not.

GPSml can encode all of the data that GPX allows (or will very shortly if 
something is missing) but also allows a lot more GPS-related data to be 
encoded.  You can add arbitrary tags (in the <other/> blocks) so that 
applications developers can extend their data output/input capabilities without 
breaking other programs use of the main data.  Much more detail is also 
allowed for waypoints and such, but most of these tags are optional, so an 
application program is free to ignore the tags it is not interested in, just as a 
program need only specify a very small number of mandatory tags (which are 
very few in number). GPSml also allows for inclusion of real-time position 
information.

So from this perspective, GPSml is a superset (sematically) of GPX and 
provides a much higher degree of flexibility and extensibility (a stated goal of 
GPSml).

Why are you surprised?  I posted the notice here because GPSml might be of 
interest to the group.  Because I promised Dan Foster that I would.  Because 
the techniques used in the GPSml schema (based on current industry best 
practices) might help improve GPX.  Because you might find that GPX does 
not meet future requirements and a more flexible/extensible markup dialect is 
required.  These all sound like good reasons to post here.

> Your format apparantly supports all data that one may retrieve from a GPS
> receiver. This is, however, not that relevant for the exchange of data
> between several applications/databases.

That is correct.  In the documentation that comes with GPSml I specifically 
state:

"GPSml is a markup language (and XMLSchema) that meets a growing 
requirement for a standard way of sharing GPS (Global Position System) 
location information between disparate systems, devices and users."

and...

"Be an XML format for all GPS-generated data, both real-time position related 
data and collections (such as waypoints, tracks, routes)"

GPSml would allow you to share what you currently share, plus allow for 
distribution of location information as well.  Again as the docs state:

"For example, to transmit location data from a GPS-enabled client application 
(possibly running on a handheld device) to a central server running location-
aware Web Services."

Which is something that GPX cannot do, but there is a growing interest in and 
need for (In fact, I am building an application that does just that in conjunction 
with some hardware vendors).

The intention of GPSml is also to be comprehensive and flexible enough to 
allow various GPS hardware manufacturers, major mapping application 
developers, GIS users (eg. City Urban planners), etc. to all be able to use a 
common markup to handle position information and exchange this information 
across many disparate applications.

> For exchange of information you need to focus on the applications that the
> data information be used for rather than the information itself. This is
> why the GPX format is superior to GPSml.

I disagree with this statement as it binds your thinking into a very small and 
narrow world definited by a single or a few applications.  That is not always a 
bad thing, when a number of application developers/vendors band together to 
facilitate data sharing.  But it does eventually limit the ability to add new 
vendors to the mix....or to use or extend the data in novel ways that the initial 
applications did not consider.

On of XML's strengths is  to decouple information encoding from the often 
parochial interests of application programs, and this theme continues even 
more strongly with XMLSchemas.  

Quoting from an XMLSchema Best Practices document:

"Too often schemas are designed in a static, fixed, rigid fashion.  Everything is 
hardcoded when the schema is designed.  There is no variability.  This is not 
reflective of nature [or the real world...ajt].  Nature constantly changes and 
evolves. Nothing is fixed.  As a general rule of thumb: more dynamic capability 
= better schema.....Definition of Dynamic: the ability of a shcema to change at 
run-time (ie. schema validation time).  Contrast this with rigid, fixed, static 
schemas where everything is predetermined and unchanging".

GPX is already beginning to suffer from this approach.  Handling of track 
segments has been recently discussed here, but the solutions proposed are 
tending towards a rigid approach that is being "hacked" on top of GPX.  There 
is no over-arching information-design paradigm that allows such things to be 
easily incorporated in GPX without breaking existing programs.  There has 
also been talk of adding real-time GPS data support.  Again, it looks like it will 
be grafted onto the existing GPX schema....and eventually you may end up 
with a mess on your hands.  By spending more time up front on structure, 
extensibility and design issues, GPSml is trying to avoid this trap.

The whole world of GPS/Position-enabled systems is evolving extremely 
rapidly right now.  I do not presume to know where it will end up, so it seems 
prudent to me to design schemas in this domain to take this rate of change 
into account.

Furthermore, GPSml is trying to address a much larger, more dynamic and 
difficult requirement that might have the potential to unite the whole 
marketplace, not just facilitate waypoint exchange (which is a much smaller 
and easier problem to handle).

> I also find your GPSml format quite complex and cumbersome as you support
> writing the same data in different ways, which makes it unnecessary
> complex and hence difficult to implement for developers 

Unfortunately, with flexibility and extensibility does come some level of 
increased complexity.  I believe (for reasons stated above) that this tradeoff is 
worth it.  But that is just my NSHO.  

I'm not sure what you are referring to when you state "writing the same data in 
different ways".  Yes, you can write lat/longs or distances with different units of 
measure (degrees, radians, feet, meters).  But that provides a lot more 
flexibility to interface with existing systems (like GIS applications for example) 
and makes it a lot easier to output valid XML.  

Yes, this does make importing the data a bit more effort.  However, I believe 
that we will eventually see packaged components/libraries that do this for you 
automatically (a good case in point is my own open source java-based GPS 
Access Library).  So a developer will not have to do their own parsing of 
GPSml....but will use a much higher level API that gives them the benefit of the 
flexibility/extensibility and a wider range of applications they can "talk" to with 
less work.

It is also possible to use a subset of GPSml, by convention/agreement, by 
layering a restricting schema on top of GPSml (to eliminate the formats you 
don't wish to support), or by writing a XSLT transform that will convert a more 
flexible/generic format into a more specific one your application wants.  Many 
ways to skin that cat.

Also keep in mind that I clearly stated that this release of GPSml is a "rough 
cut" first draft.  As it evolves, redundancies will be eliminated where it makes 
sense to do so.  It is by no means perfect or even close to it. I am VERY open 
to suggestions as to how it could be improved (I did notice you did not offer 
any such suggestions and you also stuck to very general statements that you 
have not chosen to back up with concrete examples).

> difficult for the applications which runs on low capacity platforms like
> the Palm.

Again, the GPSml docs make my position on this quite clear...to whit:

"XML is a "verbose" format regardless. If you want the ultimate in small 
filesizes then use a proprietary binary storage format instead. It is debatable, 
even with short forms for tag names and maximal use of attributes, if XML is 
currently suitable for devices with limited resources, such as mobile phones, 
Palm PDA's, though Moore's law will probably make GPSml practical at the 
small device level sooner rather than later."

The rate of evolution of small devices might make your design decisions 
obsolete within a year.  GPSml is being designed to have a long life span, 
taking account this technological rate of change and increase in capability.

In fact, I would suggest that if you don't want to use a binary format on a small 
devices, that you create an extremely stripped down and cryptic schema for 
such devices and supply an XSLT transform to "inflate" the data into a more 
flexible/readable form on larger platforms.

BTW....my GPS access library code runs on palms and even smaller devices.  
Howerver, I do not recommend that users use the XML features on such 
platforms at this time.

> In my opinion your work clearly shows that this is a product of one man's
> (or company's) idea, rather than the product of a co-operation between
> several developers which needs and ideas covers a much broader area of
> applications.

You must pardon me, Kjeld, if this statement of yours made me laugh (which it 
did).  GPSml handles everything that GPX can currently do plus is designed 
for much broader applicability, extensibility and flexibility.  Your definition of 
"broader" is amusing indeed.

As for one man versus design by committee, I have a lot of thoughts on that, 
which will probably make you upset.   That is not my intention.  However, since 
you brought it up:

Design by committee is too slow (GPX suffers from this syndrome).  And a 
committee process rarely comes up with a "great" design (though it may be 
adequate). Better to have a much smaller group (possible only one or two 
people, if they have the right skill sets) design the core, and make it simple, 
extensible, based on best practices and comprehensive enough so that a 
proper foundation is laid for future evolution.  GPX does not seem to have a 
solid enough foundation to accomplish this, in the context of the larger problem 
space that GPSml is attempting to address (and which GPX is not by your own 
admissions).

> My conclusion is that you have probably created a good standard for
> storing GPS generic data, but it is not suitable for exchange of
> waypoint/track/route information between different applications. Here the
> GPX format does a much better job.

You have not provided any conclusive reasons nor backup information to 
warrant such a conclusion and in fact, I believe I have refuted most of your 
generalisms earlier in this email.  Furthermore, "better" is a subjective 
label....better in what way and why?  I'm sure that the other readers of this 
forum would very much appreciate elaboration as to why and for what reasons 
you think GPX is "better"...in detail.

I'll kick this off by noting some of my observations about GPX:

1) The tags are too cryptic and short in GPX.  One of the key benefits of XML 
is human readability.  This is compromised by the choice of short forms for 
tags (eg. lat instead of latitude, though that is probably one of the poorer 
examples).  You could argue that handhelds are too memory constrained to 
allow for more natural and descriptive terms, but I believe that Moore's law and 
rapid increasing handheld capability will make this a moot point very quickly, 
and so to maximize future capability and readability, I think longer tags make 
more sense. 

2) The GPX schema design is rather simplistic and does not follow current 
best practices.  GPSml adheres to current best practices in schema design, 
yet provides for simple markup syntax for instance documents.

3) The GPX schema is not currently designed to be extensible and flexible, 
which will limit it's ability to evolve and encompass new location-based 
semantics (which is a growing market and interest area on the part of many 
vendors).

4) Some design choices are not very ideal from an information architecture 
perspective (eg. lat/long as attributes instead of sub-elements).  These 
choices will cause some problems in the future as new requirements need to 
be adopted.

5) I don't believe the GPX group has a very indepth knowledge of XML 
technologies (especially schema design issues).  It seems more a group of 
hobbyists to me.  That is not a bad thing in and of itself....just incompatible with 
and unlikely to produce what I think the market needs/wants/will accept.

All of the above are just MNSHO's.....so don't get your nose out of joint about 
it.  I just wanted to make my thoughts on the whole subject (and GPX) clear.

> I have therefore no plans of supporting your proposed GPSml format.

<with tongue firmly planted in cheek>

I do not recall asking you to, Kjeld.  Many of your comments strike me as 
stemming from a childish "it's my toy and how dare you criticize it or try to 
invade my sandbox" view.  Then again, I might be reading something into your 
post that is not there, and if that is the case, my apologies.

</with tongue firmly planted in cheek>

GPSml is still in a rough state.  I have released this early version to solicit 
comments/feedback that might make a closer fit to it's stated goals (and 
maybe improve other such efforts in the process).  It may just be the 
"bootstrap" the industry needs to define the "real" standard for future position 
data exchange.  Or it might help improve GPX.  I have no problem with that.

I believe that users/developers benefit from having, and understanding many 
different alternatives, so they can make an educated choice about what 
tools/standards/schemas they should use for the task that faces them.  Life 
and such decisions are about compromise.  For specific requirements, GPX 
may well be more suitable than GPSml.  But how can a developer determine 
that if they don't know the design foundations, the directions, and the tradeoffs 
that are inherent in any specific solution?

Anyway, to conclude, I believe that a dialog on this issue will result in benefits 
to all constituencies (you, me, GPX, GPSml and the position-enabled 
application space in general) which is why I have taken the time to reply in 
some length and detail.

If GPX evolves into a flexible, comprehensive shema for position-information 
then great. If it stays as a simple/lightweight waypoint transfer protocol (which 
is not necessarily a bad thing...simplicity has it's virtues) then great.  If the 
GPSml becomes a standard then great.  If both are supported then great 
(hopefully with XSLT's for easy conversions back and forth).  If the industry 
comes up with some other standard for position-info exchange then great.

GPS and position-enabled technology and applications are so nascent and 
evolving so fast that no-one can forsee where the space will end up.  
However, if GPX and/or GPSml can help address some of these evolving 
requirements and "show the way" for whatever comes then it will have been 
worth the effort.

Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com


A minor point....

andrzej+chaeron.com on Wed Jan 30 08:28:56 2002 (link)

....for those that have been curious and have visited the GPSml web page 
(http://www.chaeron.com/gps.html), you might have noticed that I do have a 
link there to GPX.  Also links to other Schemas that are related (eg. GIS, 
NVML, etc.).  

I believe that it is beneficial for users/developers to see all the alternatives, 
regardless of their final choice, and putting my money where my mouth is, I 
included links to "competing" and "related" schemas as a convenience to 
people looking for such beasties.

I wonder if the "official custodians of GPX" will respond in kind?

The answer to that question will be rather illuminating regardless of what it is, 
n'est-ce pas?  <grins>


Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com


Re: GPSml and GPX

andrzej+chaeron.com on Thu Jan 31 18:59:52 2002 (link)

Kjeld said:

> Based on your work I have no doubt that you know much about XML, and GPX
> could probably benefit a lot from your insight. But apparantly you have no
> interest in contributing to the ideas behind GPX, as you rather want to
> create a "competing" standard.

I have put GPSml into the public domain...doing so could easily contribute to 
the ideas that GPX incorporates, since you are free to copy and use any part 
or idea of GPSml.  As I told Dan, I think that GPX does not have a solid 
enough foundation (design, flexibility or extensibility) to make it worth building 
on top of.  You have not said anything as to why you think GPX is a better 
"foundation".

GPSml is designed and intended to handle a much broader range of data 
sharing requirements and a larger target "market" than GPX, so it does not 
really compete.

> Competing standards are not what the world of GPS enabled applications
> (hereby I mean databases, programs for different platforms and so on) needs
> by now. There are already plenty of them and yet you propose another
> standard well knowing that other people already work on this across the
> world.

I don't know of any other GPS-targetted markup languages other than GPSml 
and GPX.  That is precious little competition for what bodes to be a huge 
market.  GPX has taken a fair amount of time and has produced very little so 
far...so it's not like there is much of a legacy to worry about.

> I can't say that I disagree with you when reagarding the slow progres of
> the GPX definition. I takes a long time and I have several times asked if
> we could speed this up by releasing a simple version, so we could get som
> practical experience.

Bingo!  I do not see GPX development going any faster any time soon.  
Another good reason to support a more comprehensive, flexible, extensible 
standard that is evolving really fast.

> But instead of publishing "your" idea you could have suggested to
> contribute to the development of the GPX work

Why?  That would take too much time and effort and has a poor chance of 
succeeding, given the weak foundation and difficulties of "design by 
committee".

. I for one would be willing
> to adopt many ideas from one with a high level of XML experience. But it
> seems to me that you are not interested in this because the GPX is not your
> idea.

Whether GPX is my idea or not is not at issue.  I could care less.  I said as 
much in my last post.  Offering GPSml, it's design ideas and the schema itself 
to the public domain, easily contributes to GPX if others want it to.  I have 
never said that I will not participate in the GPX discussion.  Maybe knowing 
that there is some strong competition around the corner might help GPX by 
lighting a fire under the groups collective butts (though from the lack of 
response from anyone but yourself, I would not hold my breath about this if I 
were you).

Your comments make too many assumptions about my intentions, and are 
rather arrogant and insulting on your part.

> And this seems very unprofessional to me. A while ago I myself suggested
> the definition of a common exchange format on the sci.geo.satellite-nav.
> When I learned that Dan Foster was alreay some steps ahead of me I
> immediately teamed up and since that I have put into this forum what I feel
> that I could contribute with.

And your point is?  I looked at GPX very closely....even considered making 
GPSml an "extension" of GPX.  But I found it to be lacking some fundamentals 
and believe it would not be a good foundation for the intent behind GPSml. 
I am participating in this forum (and if anyone else steps in with 
questions/comments
about GPX or GPSml I shall be happy to participate if I have anything valuable 
to add). 

What is unprofessional about that?  Why should I bow to what I feel is an 
inferior design, with slower progress and other problems?  It's not like GPX is 
a world standard or even close to it.  My considered judgement was that it was 
not worth it.  

Evaluate all the alternatives (which I did), see if you can avoid "re-inventing the 
wheel" (which I did), make sure you have your goals and targets clear (which I 
did), and then make a decision and run with it (which I also did). That, I would 
submit, is the mark of a "true" professional. 

> You refer to us as hobbyists even though you don't know anything about us.

I said "It seems more a group of hobbyists to me".  Just like you said I "seem 
unprofessional".  These are opinions, and nothing has been said to change 
mine as of yet.  There is nothing wrong with hobbyists. I just don't think that a 
group of "hobbyists" will be able to create a global industry GPS data 
exchange standard, which is the intent behind GPSml.  That may be the intent 
behind GPX, but the progress has been rather less than inspiring.

> One thing I have learned over the years is that data integrity and format
> simplicty goes above almost all other requirements.

True....but real world applications typically come with complexity.  Being too 
simplistic about requirements is also not a good thing.

> Being able to express the same generic data in several formats is
> definitely not a good idea, as it interently leads to complexity and hence
> probable errors. Naturally there are good arguments for the use, but they
> all fall apart when software bugs start to emerge...

I disagree.  There is good reason for having different units of measure 
available to applications.  This was a feature added to GPSml after much 
thought and deliberation.  You will notice that the defaults have been 
implemented in such a way to make the most common cases easy.  The 
format is also quite simple in that regard.  Writing a XSLT transform that 
converts a GPSml-compliant instance document to a "common" uom would be 
a rather simple matter, and would handle the situation of applications that can 
only handle the "simple" case. Data integrity is another issue all together and 
is not compromised by adding flexibility.

> There is no doubt to me that using decimal degrees referred to WGS-84 and
> Syst? International d'Unit?(SI) unuts for lenght, time and deriative
> units are the best way to ensure integrity and simplicty.

There are many situations where this is NOT the case.  Many GIS and 
mapping programs do not use WGS-84.  Many Urban Planners that I have 
spoken to want more flexibilty in co-ordinate specification and conversions. On 
smaller devices, it is also less processing and code to write out data in a native 
format/uom, and let other more powerful machines (servers, pc's etc) or 
translation processes (XSLT, et al) do conversion to whatever units they 
require and can accept.

> Also simplicity is an inherent property which all platform would benefit
> from. Even though it almost seems that the computing and storage capacity
> tends to infinity as time goes, it does not mean that creating a complex
> structure is better than a simpler structure with the same generic
> properties.

It depends on what problem space you are trying to tackle and your definition 
of simplicity.  The instance document format for GPSml is quite simple and 
easy to understand (it is also more consistent in it's use of elements vs. 
attributes than GPX).  Sure the schema is complex....but that is transparent to 
most programmers and users so it does not matter.

> The most obvious problem is the ties I see between your
> company and the GPSml format. 

Since GPSml has been put into the public domain for people to do as they like 
with, your argument does not make sense.  

> The second most obvious problem with GPSml is
> the unnecessary complexity due to the allowance of different formats of the
> same generic data.

We shall have to disagree on this point.  I see this as a valuable feature (which 
is also optional as noted above) based on my industry contacts and 
knowledge.

> I hope this clears up some of your questions. If you continue this debate
> using expressions like in the previous email we have nothing further to
> discuss.

You mean like accusing me of not being professional?  Try getting a sense of 
humour, Kjeld and lightening up a bit.  This stuff is not life and death nor even 
a way of making a living for most of us.  It is supposed to be fun.  Life is too 
short for it not to be.

> If you agree that joining forces into defining one common standard would be
> better than two different competing standards, then maybe this could be a
> platform to start at. 

You might be well served to take your own advice and thus look forward to 
your assistance with GPSml.  <grins>

> But you have to realize that this also means that you
> have to listen to ideas and arguments and accept compromises just like the
> rest of os have been doing for some time now. 

I have been listening.....but have not yet heard anything that leads me to 
believe that my approach is wrong (again given the larger scope that GPSml is 
trying to address).   As for compromises, sometimes they lead to inferior 
solutions, which is something I am not willing to put my name and reputation 
to.

> I for one have no problem tearing the current GPX format apart if it would
> result in a more flexible and extensible format based on best practice as
> you mention. But simplicity *is* an important issue - and so is time.

Life is rarely that simple.  GPSml is designed so that developers can use just 
the parts of it that make sense for them.  What could be more simple than 
that?  But it can also encompass much more complex problems, which are 
already surfacing in the GPS world.

> If you would rather continue your work on GPSml by yourself 

I specifically asked for ideas and feeback and I am happy to debate the 
directions and constructs in GPSml and evolve it to suit real requirements.  
That is not exaclty "working by myself".   

You  might also keep in mind that the most successful open source projects 
around (Linux, Apache, etc.) all have a very experienced "gatekeeper" that has 
final say over what goes in or out of the release.  Design by committee and 
pure compromise never works, in my experience.  Someone has to be the final 
arbiter of the product.

> then I cannot
> see why this discussion should continue on this mailing list. 

Because maybe GPX can benefit from the work I am doing on the public 
domain GPSml?

I> As stated before I will not support your work on GPSml and to be frankly I
> don't think you will get much response as many developers will see this as
> "just another format created by a single company".

Kjeld....your unsubstatiated opinions grow tiresome.  What part of "IT'S IN THE 
PUBLIC DOMAIN" don't you understand?

> I know it is only three
> days ago that you posted the same info on sci.geo.satellite-nav. But the
> response so far aren't exactly overwhelming at least not in the usenet
> group.

I posted there as a courtesy to the few people that are interested in such 
things.  Most posters on that group seem to be consumers that want to know 
what GPS to buy....where to find a cable....and the like.  I did not expect much 
response from that forum.  I have received a lot of private interest however.

> But I would certainly support you if you decide to team up with the
> rest of us under the conditions listed below. 

Your implied conditions are unacceptable.  I intend to continue to work on 
GPSml.  If I have something to offer GPX discussion I will do that as well. If 
GPX comes up with some interesting ideas, I will happily incorporate them in 
GPSml.

> Adding your XML experience to
> the idea of a generic standard free from individual interest would be an
> advantage.

GPX is NOT a generic standard at this time, and with it's current base and 
slow speed of development is likely never to be.  It is, by your own words, 
intended as a way to share waypoint, route and track data.  GPSml is intended 
to be a comprehensive standard for all forms of GPS data.

> Please notice that these comments states my personal opinion only. There
> are currently 42 subscribers to the mailing list...

And it would be nice to hear from some of them. ;-)

> Guiding principles:
> - A common XML data format for the exchange of GPS and
> location-based information between computers benefits everyone. It is
> in our interests and the interests of our users to create a common
> data exchange standard.

Exactly the purpose of GPSml, except that I believe GPSml has a better 
chance of getting there in a reasonable period of time than GPX and has more 
likelyhood of evolving gracefully over an extended time without breaking prior 
applications that use it.

> - This is an open standard. It is controlled by no one person, and
> it is free from copyright and other legal meddling.

As is GPSml. 

> - This is a data exchange format, not a data storage format.

GPSml and GPX could be used for both.  Though the primary purpose for both 
is exchange and not storage.  What's your point?

> Applications are free to implement as much of the format as needed,
> and ignore parts of the data stream. The only requirement is that an
> application must be able to parse an arbitrary data stream without
> crashing.

Sounds like GPSml to me. ;-)

> - This format allows for expansion. Private elements and attributes
> can be added to the format. To the extent possible, we will work
> together to define public structures that multiple applications can
> use, but any developer is free to add their own private data
> structures to any public element.

Which will break validating parsers the way GPX is evolving.  GPSml is 
designed already to allow such expansion almost anywhere, while still allowing 
for full schema validation.  Shall we discuss your vaunted data integrity in this 
light? ;-)

> - This standard is of no use unless people use it. To that end, it
> should be lightweight, easy to implement, and flexible enough to
> accommodate new features as it matures.

Preaching to the converted are we?

> - This format is about data exchange, not data validation.

Just a while back you were talking about data integrity.  That is a key role of 
data validation. When you do validation is debatable (compile time or runtime) 
though, especially on limited devices. Are you now saying that data integrity is 
not required? ;-)

> Device-specific details like the number of characters in a waypoint
> name do not belong in the exchange format, they belong in the
> end applications.

No argument there.  But the "format" should be flexible enough to handle a 
wide variety of application requirements.  

In any case, I am not finding this discussion very productive.  I will not be 
responding to any more such emails in public.  If you want to continue this 
discussion, Kjeld, then feel free to email me privately.

If you wish to discuss technical issues of GPX or GPSml, how they might 
compare in various implementation details, or how to best to implement a 
specific feature/requirement, I shall continue to respond to such here, since it 
might be of interest to others on the group.


Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com


Finishing up GPX 1.0

egroups+topografix.com on Fri Feb 01 08:20:59 2002 (link), replying to msg

Hello,

As best I can tell, there are five things yet to do before we finalize
GPX 1.0:
 1. rearrange the order of elements (Kjeld's proposal).
 2. write a user document (my job).
 3. agree on any last-minute element additions (see below).
 4. make any structural changes to the schema.
 5. agree we're done, and freeze the 1.0 spec.

My contributions:
 2. I'll write the user document next week.
 3. I'd like to see the following elements added to the spec:
 <number> - integer - valid for <rte>, <trk> - Many GPS models
 identify routes and tracks by number instead of name.
 <number>5</number>
 <url> - text string - valid for all elements - specifies a URL
 associated with the object.
 <url>http://www.trail.com/traildesc.html</url>,
 e.g.
 <url_name> - text string - valid for all elements - specifies the
 text for a URL associated with the object.  <url_name>Link to Trail
 Description</url_name>, e.g.

The other tasks:
 1. Kjeld, do you want to propose a new order for the elements?
 4. Anyone?
 5. I'm as anxious to wrap this up as everyone else.  My apps are
 about 2 weeks away from the next release, so I hope we can get this
 finalized soon.

Is there anything I've missed that needs to be done before we can
release a 1.0 version of GPX?
-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com



Re[2]: [gpsxml] Finishing up GPX 1.0

egroups+topografix.com on Fri Feb 01 09:16:04 2002 (link), replying to msg

Hello,

Friday, February 01, 2002, 11:51:30 AM, Kjeld wrote:

KJ> <urlname> would be fine with me
Fine with me too.

KJ> I have looked at the NMEA data and there are a few others which we might as
KJ> well include as optional elements. I see no reason to leave anything out
KJ> which is a part of the most used NMEA sentences RMC, GGA, GSA. That would
KJ> be:

KJ> <mag> magnetic variation in degrees
KJ> <geoidheight> Height of geoid (mean sea level) above WGS84 ellipsoid
KJ> <dgpsupdate> time in seconds since last DGPS update
KJ> <dgpsid> DGPS station ID number

KJ> And then we can state that GPX supports these three sentences.

Without disrupting the work on GPX 1.0, I'd like to spin off a new
discussion topic about the syntax for real-time positioning
information and NMEA.

>>The other tasks:
>> 1. Kjeld, do you want to propose a new order for the elements?

KJ> Well yes, I just want to propose that we group them. The order within the
KJ> group is not that important I think. If we use the three groups Position,
KJ> Accuracy and Information we would get this for the track element:

KJ> Position related data
KJ> <xsd:element name="ele" type="xsd:decimal"      minOccurs="0"/>
KJ> <xsd:element name="time"        type="xsd:dateTime" minOccurs="0"/>
KJ> <xsd:element name="course"      type="gpx:degreesType"  minOccurs="0"/>
KJ> <xsd:element name="speed"       type="xsd:decimal"      minOccurs="0"/>
KJ> <mag>
KJ> <geoidheight>

KJ> Accuracy related
KJ> <xsd:element name="fix" type="gpx:fixType"      minOccurs="0"/>
KJ> <xsd:element name="sat" type="xsd:nonNegativeInteger"   minOccurs="0"/>
KJ> <xsd:element name="hdop"        type="xsd:decimal"      minOccurs="0"/>
KJ> <xsd:element name="vdop"        type="xsd:decimal"      minOccurs="0"/>
KJ> <xsd:element name="pdop"        type="xsd:decimal"      minOccurs="0"/>
KJ> <dgpsupdate>
KJ> <dgpsid>

KJ> Information related
KJ> <xsd:element name="name"        type="xsd:string"       minOccurs="0"/>
KJ> <number>
KJ> <xsd:element name="desc"        type="xsd:string"       minOccurs="0"/>
KJ> <xsd:element name="cmt" type="xsd:string"       minOccurs="0"/>
KJ> <xsd:element name="src" type="xsd:string"       minOccurs="0"/>
KJ> <xsd:element name="sym" type="xsd:string"       minOccurs="0"/>
KJ> <xsd:element name="type"        type="xsd:string"       minOccurs="0"/>
KJ> <url>
KJ> <urlname>

Thanks.

KJ> We still have the problem with fix = "none".

Take another look at the GPGGA sentance - it allows fix=none, so if
we're going to mirror NMEA for real-time positioning, we need
something like this, outside of tracklogs.

KJ> Should we disallow this option
KJ> and instead go for the

KJ> <trkbkn><cause>nofix</cause><time>datetimetype</time></trkbkn>
This only makes sense for tracklogs.


KJ> Any other ideas?

KJ> Second we are starting to get problems with the tag names. I noticed that
KJ> Andrzej format is more readable and I think we should consider copying the
KJ> the use of capital letters where appropriate like for instance: <URLname>,
KJ> <Fix>, <Time>, <GeoidHeight>, <DGPSId>, <DgpsUpdate>, <HDOP> and so on. Any
KJ> comments on this?

I see at least three different capitalization schemes in your
examples!

I prefer capitalizing the first letter of every word, and
all letters in acronyms:
URLName
Fix
Time
GeoidHeight
DGPSID
DGPSUpdate
HDOP

I also like all lowercase, with_underscores_between words.
url_name
fix
time
geoid_height
dgps_id
dgps_update
hdop



-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com



Re[3]: [gpsxml] Finishing up GPX 1.0

egroups+topografix.com on Fri Feb 01 09:51:04 2002 (link), replying to msg

Hello,

Friday, February 01, 2002, 12:25:10 PM, we wrote:

KJ> Hi

>>Without disrupting the work on GPX 1.0, I'd like to spin off a new
>>discussion topic about the syntax for real-time positioning
>>information and NMEA.

KJ> I agree but should I take this as you do not think we should implement
KJ> those optional elements also?

No, I don't have any problem with basic navigation elements like those
in GPX 1.0.

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com



Re[3]: [gpsxml] Finishing up GPX 1.0

egroups+topografix.com on Fri Feb 01 09:51:04 2002 (link), replying to msg

Hello,

Friday, February 01, 2002, 12:25:10 PM, Kjeld wrote:


>>Take another look at the GPGGA sentance - it allows fix=none, so if
>>we're going to mirror NMEA for real-time positioning, we need
>>something like this, outside of tracklogs.

KJ> You are right... but the problem is that we use attributes for the lat/lon
KJ> and naturally they become invalid. We could actually solve the problem by
KJ> allowing "none" and omitting the use of attributes in GPX (let <lat></lon>
KJ> simply be elements instead). This way it makes sense in all three cases I
KJ> suppose (a track entry without position corresponds to your earlier
KJ> link/leg idea or my trkbkn idea)

[this applies to all <pt> elements...]
I think it's perfectly reasonable to have a lat/lon point even though
fix=none.  All my GPS act this way, and NMEA does too.  When the GPS
doesn't have a fix, it outputs the last known point.  Some systems do
a "dead reckoning" solution by maintaining the current speed/heading.
Since you know that fix=none, you can treat the data as suspect.  Most
systems flash the display to indicate a loss of GPS lock.

I'd prefer the following:
lat/lon are always required.  You're welcome to set them to zero if
you like.
when fix=none, behavior is application dependent.

[now back to the problem of breaks in tracklogs...]
fix=none isn't the right thing to do here.  As an example, take the
[extremely short] trip from A to B to C to D, with automatic track
point recording every 5 minutes.  There's a tunnel between B and C.
I get valid fixes at A, B, C, and D, so fix=none never occurs.  But
the track is discontinuous between B and C due to the tunnel.
How you you represent this in GPX?

I like the concept of a track segment in GPSml.  So...
<Trk>
 <TrkSegment>
  <Trkpt A>
  <Trkpt B>
 </TrkSegment>
 <TrkSegment>
  <Trkpt C>
  <Trkpt D>
 </TrkSegment>
</Trk>

Other solutions?

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com



Real-time positioning in XML

egroups+topografix.com on Fri Feb 01 10:11:03 2002 (link), replying to msg

Hello,

  I'd like to start a general discussion about representing real-time positioning
  and navigation info in XML.  There are some interesting issues that
  don't have anything to do with GPX or GPSml, but might have bearing
  on our future development.

  I'd love to be able to sit at work and watch somebody with a
  wireless Internet connection out mapping trails and sending back an
  XML stream of GPS data!  Better yet, I'd volunteer to collect the
  data while you all sit at work!
  
  Existing applications:
  Does anyone know of a service or website that is currently offering
  real-time navigation info over a public web connection?  DGPS
  corrections?  APRS?  hurricane tracks?  others?

  Here's one example (not XML):
  http://208.139.198.171/AVLDemo/ (tracking the bus in Boulder, CO)
  
  Real-time considerations:
  Data needs to be organized intelligently so that it arrives quickly.
  As an example of a bad way to do things, you could decide to group
  everything together by common timestamp, but then you wouldn't send
  an XML packet until a new timestamp showed up in your source NMEA
  stream, which would introduce a time delay.

  Backwards compatibility with NMEA:
  It seems like a good goal that any XML stream should be able to be
  transformed into a valid NMEA stream using XSL.

  Streaming:
  So how do you stream XML, anyway?  It's not valid XML until that
  final tag closes...

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com



Re: Finishing up GPX 1.0

davewissenbach+yahoo.com on Fri Feb 01 13:19:23 2002 (link), replying to msg

--- In gpsxml+y..., Dan Foster <egroups+t...> wrote:
> Hello,
> 
> As best I can tell, there are five things yet to do before we 
finalize
> GPX 1.0:
>  1. rearrange the order of elements (Kjeld's proposal).
>  2. write a user document (my job).
>  3. agree on any last-minute element additions (see below).

I have a last-minute addition to propose, related to trail 
publishing. If we add <name> <src> (or author) and <desc> as top-
level elements in the root element, then the gpx file will be self-
describing. The way I would use these elements is to extract the 
description as the opening paragraph in an html document which 
describes the trail. I have already written and tested a style sheet 
which extracts this data from tracks, routes, waypoints, and 
routepoints, and produces an html document which describes the trail.
(I'd probably create a dialog box in the Mapping program to also 
display this data, although that isn't really necessary, as the 
information can just as easily be manually inserted into the GPX 
file with a text editor.)

The style sheet could be applied to the .gpx file on the server with 
a style sheet processor. (I'm using apache xalan right now, and 
tested this with data on my web site.) The proposed new elements at 
the top level would then tranform into the html title, primary 
heading/map name, and introductory paragraph.

The sample style sheet (not including the transformation for the 
proposed new elements but for all of the other top level elements) 
is at

http://www.cableone.net/cdwissenbach/GPXContents.xsl

Other than that proposal, my approach to the rest of the changes 
here will be to follow as quickly as I can with a compatible 
application. GPX should be ready for the next backpacking season! I 
prefer TitleCase to title_case, by the way.

>  4. make any structural changes to the schema.
>  5. agree we're done, and freeze the 1.0 spec.
> 
...
> -- 
> Dan Foster
> TopoGrafix - GPS Software, Waypoints, and Maps
> http://www.topografix.com - mailto:egroups+t...


Re: [gpsxml] Re: Finishing up GPX 1.0

egroups+topografix.com on Fri Feb 01 13:48:45 2002 (link), replying to msg

Hello,

Friday, February 01, 2002, 4:19:16 PM, Dave wrote:

d> I have a last-minute addition to propose, related to trail
d> publishing. If we add <name> <src> (or author) and <desc> as top-
d> level elements in the root element, then the gpx file will be self-
d> describing. The way I would use these elements is to extract the 
d> description as the opening paragraph in an html document which 
d> describes the trail.

I'd like to see the following (optional) in the top-level <gpx>:
<Name> Descriptive name of File
<Desc> File description
<Author> File author name
<Email> File Author email
<URL> File URL
<Creator> File Creator Program
<Time> File Creation Timestamp
<Keywords> File keywords
<BoundsLatMin> Extents of the data in the file
<BoundsLatMax> (these should probably be a complex struct)
<BoundsLonMin> ...
<BoundsLonMax>

Picture an app that can search a central database for all GPX files
describing mountain bike rides within 20 miles of Boise!

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com



Re: Finishing up GPX 1.0

davewissenbach+yahoo.com on Fri Feb 01 15:14:51 2002 (link), replying to msg

--- In gpsxml+y..., Dan Foster <egroups+t...> wrote:
> 
> I'd like to see the following (optional) in the top-level <gpx>:
> <Name> Descriptive name of File
> <Desc> File description
> <Author> File author name
> <Email> File Author email
> <URL> File URL
> <Creator> File Creator Program
> <Time> File Creation Timestamp
> <Keywords> File keywords
> <BoundsLatMin> Extents of the data in the file
> <BoundsLatMax> (these should probably be a complex struct)
> <BoundsLonMin> ...
> <BoundsLonMax>
> 

Thanks for accepting this idea. I look forward to seeing it in the 
next revision of the schema. (GPX format 1.0?).

> Picture an app that can search a central database for all GPX files
> describing mountain bike rides within 20 miles of Boise!
> 

That won't be easy! I've only logged about a quarter of the trail 
miles near Boise on my GPS. Tomorrow I'll go log a ski trail up 
North at Ponderosa State Park in McCall.

By the way, I'm still gainfully employed and working on Wissenbach 
Map just as a hobby. I'm home today because of equipment problems at 
my workplace! 

> -- 
> Dan Foster
> TopoGrafix - GPS Software, Waypoints, and Maps
> http://www.topografix.com - mailto:egroups+t...


[gpsxml] Re: Finishing up GPX 1.0

kevin+synergysa.com.au on Fri Feb 01 17:34:20 2002 (link), replying to msg

Hi All

Thought I'd jump back in at this stage (just got out of hospital).  I
have been reading some of the many emails for the group since I was last
infront of the PC.

One really quick first.

Somehow Capitalisation has crept in again for tags.

Trust me, we DON'T want this is the long term, as most parsers and
translators are case-sensitive, its important that the consumer knows
what each element is called and hows its spelt and the case used.

After quite some time developing enterprise solutions using SOAP and XML
most of my "bugs" seem to be in stupid things like typing "HundredOf"
instead of "Hundredof" in Xpath and XSLT.

Of all the XML content we have to deal with all my programmers agree
that capatialisation is a bitch.

All of our internal schemas are lower case for good reason.

The original GPX schemas that I produced upto 1.1 has lowercase tags.

My 2 cents worth.

Now back to the rest of the emails :-)



Kevin




This is really cool

jlinsche+hotmail.com on Sun Feb 03 21:32:32 2002 (link)

I must say that today has been a day of exciting discoveries for me.

First, when my father showed me his new Garmin receiver I made a 
comment as to the lack of quality software available for my Magellan 
GPS 315, he turned my on to EasyGPS.  I downloaded it and it was 
exactly what I've been looking for.

I then perused the EasyGPS web site for all of the goodness it could 
provide and came upon this project. This is an awesome idea guys! I 
just wonder why it hasn't been done before. I guess it makes too much 
sense :)

I realize that you are not quite ready to release a final spec yet, 
but I do have a couple of questions:

1.	Are there specified field widths for elements such as cmt and 
desc? From the proposed schema I figured that there probably isn't, 
but I thought I'd ask anyway.
2.	I noticed that waypoints are redefined in their entirety if 
included in a route. Will the spec specify which has priority? In 
other words, if they are different, which waypoint would be written 
back to the receiver? Or is this up to the developer?

Also, will there be a version of free version EasyGPS supporting the 
final .gpx format? I almost hate asking, sort of like looking a gift 
horse in the mouth!

I hope you find widespread acceptance of this file exchange format. 
Any chance that the GPS makers, and the GIS community will embrace it 
as well? At the very least it will provide an invaluable aid to 
everyone who does use it.

I'm primarily interested in importing .gpx files into my own 
applications. I collect fossils as a hobby and have found the GPS 
data collection to database connection to be very cumbersome. It 
appears that will no longer be the case.

Good work!

James Linscheid
Lake Oswego, Oregon USA



Re: [gpsxml] Real-time positioning in XML

hamish+travellingkiwi.com on Mon Feb 04 05:40:41 2002 (link)

Dan Foster wrote:

>  Hello,
>
>   I'd like to start a general discussion about representing real-time
> positioning
>   and navigation info in XML.  There are some interesting issues that
>   don't have anything to do with GPX or GPSml, but might have bearing
>   on our future development.
>
>   I'd love to be able to sit at work and watch somebody with a
>   wireless Internet connection out mapping trails and sending back an
>   XML stream of GPS data!  Better yet, I'd volunteer to collect the
>   data while you all sit at work!
>
>   Existing applications:
>   Does anyone know of a service or website that is currently offering
>   real-time navigation info over a public web connection?  DGPS
>   corrections?  APRS?  hurricane tracks?  others?

DGPS is available over the Internet... Sorry. Most of my files are
offline from here... But if noone else volunteers I can provide the
address tomorrow maybe...

>
>
>   Here's one example (not XML):
>   http://208.139.198.171/AVLDemo/ (tracking the bus in Boulder, CO)
>
>   Real-time considerations:
>   Data needs to be organized intelligently so that it arrives quickly.
>
>   As an example of a bad way to do things, you could decide to group
>   everything together by common timestamp, but then you wouldn't send
>   an XML packet until a new timestamp showed up in your source NMEA
>   stream, which would introduce a time delay.
>
>   Backwards compatibility with NMEA:
>   It seems like a good goal that any XML stream should be able to be
>   transformed into a valid NMEA stream using XSL.
>
>   Streaming:
>   So how do you stream XML, anyway?  It's not valid XML until that
>   final tag closes...
>
> --
> Dan Foster
> TopoGrafix - GPS Software, Waypoints, and Maps
> http://www.topografix.com - mailto:egroups+topografix.com
>
>
>
>                    Yahoo! Groups Sponsor
                        ADVERTISEMENT


>
> To unsubscribe from this group, send an email to:
> gpsxml-unsubscribe+yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

--

I don't suffer from Insanity...         | Linux User #237369
        I enjoy every minute of it...   |
                                        |
http://www.travellingkiwi.com/          |




Re: [gpsxml] This is really cool

egroups+topografix.com on Mon Feb 04 06:49:40 2002 (link), replying to msg

Hello,

Monday, February 04, 2002, 12:32:28 AM, James wrote:

j> I do have a couple of questions:

j> 1.      Are there specified field widths for elements such as cmt and 
j> desc?

No.  While your GPS might impose a maximum width, GPX has no
restrictions.

j> 2.      I noticed that waypoints are redefined in their entirety if 
j> included in a route. Will the spec specify which has priority? In 
j> other words, if they are different, which waypoint would be written 
j> back to the receiver? Or is this up to the developer?

GPX doesn't specify this.  Presumably, if you were including the same
point as a waypoint and as a route point, it would have identical
data.

j> Also, will there be a version of free version EasyGPS supporting the 
j> final .gpx format? I almost hate asking, sort of like looking a gift 
j> horse in the mouth!

Yes.  You can get an advance copy at http://www.easygps.com/beta.asp

j> I'm primarily interested in importing .gpx files into my own
j> applications. I collect fossils as a hobby and have found the GPS 
j> data collection to database connection to be very cumbersome. It 
j> appears that will no longer be the case.

Let us know how things work out!

Best wishes,

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com



GPX 0.6 schema

egroups+topografix.com on Mon Feb 04 14:03:43 2002 (link), replying to msg

Hello,

Friday, February 01, 2002, 11:18:12 AM, I wrote:

DF> Hello,

DF> As best I can tell, there are five things yet to do before we finalize
DF> GPX 1.0:
DF>  1. rearrange the order of elements (Kjeld's proposal).
DF>  2. write a user document (my job).
DF>  3. agree on any last-minute element additions (see below).
DF>  4. make any structural changes to the schema.
DF>  5. agree we're done, and freeze the 1.0 spec.

I've created a 0.6 GPX schema at
http://www.topografix.com/gpx/0/6/gpx.xsd

This should have all the new elements that were suggested.  Please
take a look and propose any changes now so we can finalize the spec.

I added the <trkseg> element to wrap sections of <trkpt>s and solve
the "broken tracklog" problem.  Here's an example:
<gpx>
 <trk>
  <trkseg>
    <trkpt A>
    <trkpt B>
  </trkseg>
  <trkseg>
    <trkpt C>
    <trkpt D>
  </trkseg>
 </trk>
</gpx>


I've updated my software to read/write
the proposed 0.6 schema, so feel free to use them for testing:
http://www.easygps.com/beta.asp
http://www.expertgps.com/beta.asp

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com



Information needed

syeameha+yahoo.com on Mon Feb 04 15:18:29 2002 (link)

Hi: 
Iam a novice in the field of GPS so i need some information regarding 
GPS system.
1). How these Devices work.
2). Does these devices work with Palm Pc.
3). I want to use this device in my town, can i use it ?.
           Waiting for u ppl's response.
                  Bilgrami



Re: GPX 0.6 schema

davewissenbach+yahoo.com on Mon Feb 04 17:02:59 2002 (link), replying to msg

--- In gpsxml+y..., Dan Foster <egroups+t...> wrote:
> Hello,
> 
> 
> I added the <trkseg> element to wrap sections of <trkpt>s and solve
> the "broken tracklog" problem.  Here's an example:
> <gpx>
>  <trk>
>   <trkseg>
>     <trkpt A>
>     <trkpt B>
>   </trkseg>
>   <trkseg>
>     <trkpt C>
>     <trkpt D>
>   </trkseg>
>  </trk>
> </gpx>
> 

This is great!

I notice that you've added an optional sequence attribute, so I 
intend to write this attribute, as others (Kevin) have indicated 
that it might be useful. But I need clarification on usage. I assume 
that we will start the <seq> at 1 with the beginning of each <trk>, 
and continue the sequence number from <trkseg> to <trkseg>, rather 
than starting over.

I'll change Wissenbach Map to conform to the new schema and update 
my samples as soon as possible. By the way, I've GPL'd Wissenbach 
Map and provided the source code on my web site. (Because in this 
case I am indeed a "hobby" programmer.)

> 
> I've updated my software to read/write
> the proposed 0.6 schema, so feel free to use them for testing:
> http://www.easygps.com/beta.asp
> http://www.expertgps.com/beta.asp
> 
> -- 
> Dan Foster
> TopoGrafix - GPS Software, Waypoints, and Maps
> http://www.topografix.com - mailto:egroups+t...


Re: [gpsxml] Re: GPX 0.6 schema

egroups+topografix.com on Tue Feb 05 06:15:07 2002 (link), replying to msg

Hello,

Monday, February 04, 2002, 8:02:24 PM, Dave wrote:

d> I notice that you've added an optional sequence attribute, so I 
d> intend to write this attribute, as others (Kevin) have indicated 
d> that it might be useful. But I need clarification on usage. I assume 
d> that we will start the <seq> at 1 with the beginning of each <trk>, 
d> and continue the sequence number from <trkseg> to <trkseg>, rather 
d> than starting over.

Is anyone planning to use this?  I thought we'd decided to remove
<seq>, based on some emails that went around about parsing any
sequence other than 1,2,3.  My software won't handle <seq> correctly -
will anyone else's?

I had actually seen and removed <seq> when I made the 0.6 schema, but
it slipped back in as I corrected some errors when I tried to validate
the document.

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com



Re: [gpsxml] GPX vs GPSml

andrzej+chaeron.com on Tue Feb 05 07:31:11 2002 (link)

Kjeld said:

> Besides our verbal controversies I must say that I have to agree with you
> on many of your ideas and arguments. I believe this discussion could become
> rewarding so I think we should continue it here for a while. It is not like
> there's so much email trafic here anyway :-)

Agreed.

> - As far as I can see the XML data below constitutes the lowest common
> denominator when regards to information for a waypoint or a track. Am I
> right in this? Probably not as I don't see information about the units used
> (meters/feet for altitude and so on).

Units default to degrees (lat/long), WGS84 (Datum) and Meters (distance) so if those 
defaults are acceptable, you don't need to specify them in your XML.

> - As we have agreed time is an important issue here. When would we as
> developers be able to use a full featured version "1.0" of GPSml for our
> purposes?

By end of February I would think, but it depends on how much feedback I receive of course.

> - I don't know that much about XML. Would I be able to incorporate
> additional "cetus" tags like for instance if I wanted to express the
> calculated variance in a waypoint determined by averaging and if so then
> how would I do it?

yes.  You can add a construct like the following:

<Other>
  <CetusTag1>my data 1</CetusTag1>
  <CetusTa21>my data 1</CetusTag2>
  etc...
</Other>

You can include Other blocks at the end of almost any type in GPSml.  So you can have 
one inside your Waypoint specification and/or in the Position or Identification blocks.  
Another (possibly with a different structure) inside a Track or Route, one at the end of a 
Collection, etc.

Using your waypoint example, you could do this (admittedly a bit overboard, but it does 
show the flexibility in extending GPSml formats).

(XML header removed)
<GPSData>
 <Collection>
  <Waypoint>
   <Position>
    <Latitude>-45.707661705091596</Latitude>
    <Longitude>80.33008656464517</Longitude>
    <Altitude>210.41272</Altitude>
    <Other>
      <CetusPosition>where Kjeld is sitting</CetusPosition>
      <CetusVelocity>how fast Kjeld is typing</CetusVelocity>>
    </Other>
   </Position>
   <Identification>
    <Identifier>AMBUSH</Identifier>
     <Other>
      <CetusID>Jensen</CetusCetusID>
    </Other>
   </Identification>
   <Other>
     <CetusWaypoint>Custom Cetus Waypoint data</CetusWaypoint>
   </Other>
  </Waypoint>
  <Other>
    <CetusWaypointCollection>Kjeld's Waypoints</CetusWaypointCollection>
  </Other>
 </Collection>
</GPSData>

> mentioned XLT's how does this work? 

XSLT will let your write a transformation that can be applied to an XML document to turn it 
into something else.  Another XML document (ie. GPX -> GPSml transform), into HTML 
that a browser can render, SVG graphic, or just about anything you want to imagine.  It is 
my intent to deliver a simple GPX<=>GPSml XSLT transform with my next release (time 
allowing), since that would be very useful to people that already have GPX implemented or 
need to talk to a GPX-enabled app but would rather implement GPSml (for whatever 
reason).

> More important do you see any way that
> we can make GPSml usable for programmers who have written a simple GPS
> application or database which only handles for instance the WGS84 datum,
> decimal minutes and knots/nautical miles/feet units.

The GPSml default units for datum and lat/long are already WGS84 and decimal minutes, 
so you don't have to specify them in your XML.  I did this deliberately to make the encoding 
easier for the simple cases.  As for distance, I've been using meters as the default since 
that seems to be the common output from a GPS unit (I could be wrong on that).  I will be 
adding the ability to specify units overrides at higher levels.....say for a whole collection, so 
that if you want to override the default consistently for all waypoints (for example) you 
would only have to specify the value once.  Something like this.....

<GPSData>
 <Collection distanceUOMDefault="feet">
  <Waypoint>...</Waypoint>
  <Waypoint>...</Waypoint>
  <Waypoint>...</Waypoint>
 </Collection>
</GPSData>

This is raising some interesting validation issues though...which I have not yet resolved.

> With usable I mean
> able to exchange data with a database on the net which is also built by a
> programmer with limited knowledge of XML.

XML is pretty easy to learn, especially since there are pre-written parsers out there (I'll be 
using a modified Java SAX parser that will run on smaller devices like the Palm for my GPS 
Access Library code base).  Not sure what you mean by this?

> I know you have written a Java library to handle this, but it should also
> be possible for a programmer/web database designer to do without the
> library.

Which means they would have to/should use a prewritten parser to convert their XML into a 
format that they can then manipulate with their code (DOM/JDOM trees or SAX 
events)....that is if they are not storing the XML directly in their DBMS.

> By the way have you considered the precision to which you store lat/lon
> data in your example? It may be a little out of bounds to illustrate them
> using a precision of less than one nanometer.

Yes.  I found that to convert Garmin semicircles to degrees and back again exactly (ie. no 
rounding errors or changes), I had to use a double precision value.  Otherwise if you did the 
conversion back and forth a few times, the value would change from the original.  Granted 
that lat/longs are not that accurate, but I felt it was not a good thing to add to that 
inaccuracy because of mathematical precision issues.

------------------------------------------------------

Dan suggests:

>  prefer capitalizing the first letter of every word, and
> all letters in acronyms:
> URLName
> Fix
> Time
> GeoidHeight
> DGPSID
> DGPSUpdate
> HDOP

I agree with Dan's approach here....and need to review the tags used in GPSml to ensure 
that they stick to this appoach (I think they do for the most part).  There are some tags that 
are a bit problematic.  Trackpoint....is this one word or two?  I chose to treat it as one word, 
since most people write Waypoint (not WayPoint) and Trackpoint seemed to be akin to that.

> I like the concept of a track segment in GPSml.  So...

Thanks!  See....releasing GPSml HAS helped GPX!  <grins....it's a joke, Kjeld>


Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com


[gpsxml] Streaming real time GPS data....discussion....

andrzej+chaeron.com on Tue Feb 05 07:31:16 2002 (link)

Dan opens an interesting area of discussion:

> I'd like to start a general discussion about representing real-time positioning
>   and navigation info in XML.  There are some interesting issues that
>   don't have anything to do with GPX or GPSml, but might have bearing
>   on our future development.

Yup...I've been thinking about this very issue.

>   I'd love to be able to sit at work and watch somebody with a
>   wireless Internet connection out mapping trails and sending back an
>   XML stream of GPS data!  Better yet, I'd volunteer to collect the
>   data while you all sit at work!

Funny...I'm working on a JavaOne demo where a Radio Shack RC (Radio 
Controlled) 4x4 toy truck will have a GPS unit mounted on it.  That will be 
connected to a Systronix board (embedded Java chip application...way kewl 
stuff) and have a GPRS wireless connection.  We'll be streaming the trucks 
position over the wireless to a back end J2EE server that will be logging the 
data, and displaying it on a console (probably using a simple moving map 
display).  We're also considering a quick implementation of the "messages 
posted in the air" idea (see: 
http://www.newscientist.com/hottopics/phones/phones.jsp?id=23194900  ) 
where the truck can pick up messages posted at various locations.  Of course, 
a key aspect of this demo is sending and receiving a stream of GPS data.  

>   Existing applications:
>   Does anyone know of a service or website that is currently offering
>   real-time navigation info over a public web connection?  DGPS
>   corrections?  APRS?  hurricane tracks?  others?

Let me know if you find one.  We're building one for the demo...but likely will 
not go public with the server side stuff.

>   Data needs to be organized intelligently so that it arrives quickly.
>   As an example of a bad way to do things, you could decide to group
>   everything together by common timestamp, but then you wouldn't send
>   an XML packet until a new timestamp showed up in your source NMEA
>   stream, which would introduce a time delay.

I am thinking along the lines of having the application generate the timestamp 
using it's internal clock and differentiating that timestamp from the one that is 
transmitted by the GPS unit (which would be included using a different tag).  
This gives you sequential ordering of the data based on when the remote 
application got the info from the GPS.  In fact, 0.6 of GPSml will use this 
approach to tag the Trackpoint entries with a timestamp (using an optional 
<TimeStamp> tag) rather than putting this data into a <Time> object (which I 
want to reserve for the return of GPS time info....UTC time, etc.).

>   Backwards compatibility with NMEA:
>   It seems like a good goal that any XML stream should be able to be
>   transformed into a valid NMEA stream using XSL.

That should not be very difficult.  However, one XML fragment might need to 
generate multiple NMEA sentences depending on the structure of the XML 
document (which may not and probably should not mirror the NMEA sentence 
structure exactly). GPSml also allows an application to "pass through" the 
original NMEA sentence into the event stream as a convenience.  This way 
you can capture exactly what the GPS unit has sent to the app.  Good for 
testing your code base if you don't have a GPS unit attached or can't get a 
lock (ie indoors).

>   Streaming:
>   So how do you stream XML, anyway?  It's not valid XML until that
>   final tag closes...

There are a few ways to handle this that I have thought of:

1) You drop the requirement for validation and just transmit XML fragments.  
Basically one fragment per event transmitted.  If the receiving app needs to 
collate all the fragments into a valid document, all it would need to do is add 
the XML header info, opening tag, all the fragments and finally the closing tag.  
The GPSml schema is designed to allow such an approach.  In fact, you could 
probably validate each fragment using a similar approach, but why bother?

I'm considering using a wrapper tag for each event, sort of like the following:

<GPSEvent>
  <TimeStamp>system clock</TimeStamp>
  <Position>....</Position>
</GPSEvent>
<GPSEvent>
  <TimeStamp>system clock</TimeStamp>
  <Accuracy>....</Accuracy>
</GPSEvent>
<GPSEvent>
  <TimeStamp>system clock</TimeStamp>
  <NMEASentence>$GPGLL,....</NMEASentence>
</GPSEvent>

This might give you an insight into why some of the structures in GPSml (like 
Position, Accuracy, etc.) are defined the way they are.  They can be reused 
easily inside points (Waypoints, Trackpoints and allow data that is not 
intrinsically part of a point (accuracy) to be added from GPS events, if the GPS 
does not include this in a point for you)....and can be used as "standalone" 
events to model the stream of data coming in from the GPS.  To illustrate:

<GPSData>
 <Collection>
  <Waypoint>
   <Position>
    <Latitude>-45.707661705091596</Latitude>
    <Longitude>80.33008656464517</Longitude>
    <Altitude>210.41272</Altitude>
   </Position>
  </Waypoint>
 </Collection>
 <GPSEvent>
  <TimeStamp>system clock</TimeStamp>
  <Position>
    <Latitude>-46.3333333333333</Latitude>
    <Longitude>79.6666666666666</Longitude>
    <Altitude>200.000</Altitude>
   </Position>
 </GPSEvent>
</GPSData>

Note how the same Position structure is used for both the Waypoint and the 
GPS event.  This allows an application developer to write a single parsing 
method for Position info, and thus reuse it for handling collections of points 
and also real time data feeds.  I'm trying to "genericize" the data structures so 
that you don't end up with multiple ways to specify common domain entities 
(like Position in this case) for different uses.  This may not always be possible, 
but so far seems to make sense and is working out.

2) Each event could be a fully formed XML document......including header and 
start/end tags.   Sounds like a lot of overhead for no good reason though.

As a side note, the demo (4x4 RC truck) I mentioned earlier will be using 
SOAP over HTTP as the transport protocol.  Embedding fragments of XML (so 
long as they are well formed) is not a big deal in this case since we won't be 
storing the data in XML form at the server side.

Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com


Top level data....

andrzej+chaeron.com on Tue Feb 05 07:31:22 2002 (link)

Dan suggests:

> I'd like to see the following (optional) in the top-level <gpx>:

> <Name> Descriptive name of File
> <Desc> File description
> <Author> File author name
> <Email> File Author email
> <URL> File URL
> <Creator> File Creator Program
> <Time> File Creation Timestamp
> <Keywords> File keywords
> <BoundsLatMin> Extents of the data in the file
> <BoundsLatMax> (these should probably be a complex struct)
> <BoundsLonMin> ...
> <BoundsLonMax>
> 
> Picture an app that can search a central database for all GPX files
> describing mountain bike rides within 20 miles of Boise!

Great idea....I'll been planning to add something similar to GPSml, and your list 
looks good.  Most (if not all) such tags should be optional though.  I'll probably 
add a <Description/> wrapper for such stuff and make it optional at the top 
level.


Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com


Curious about parsing....

andrzej+chaeron.com on Tue Feb 05 07:39:50 2002 (link)

Writing GPS XML data is pretty easy.....best way is usually to just hardcode 
the tag generation in a few method, so there really is no issue there.

The difficulty comes in when you try to read in XML data.  The parsing issue is 
non-trivial and tends to push one towards using an already written parser 
(probably using SAX rather than DOM/JDOM for efficiency reasons).

However, smaller devices do not always provide the I/O library support 
required to use a standard parser (like Xerces or some such)....and do not 
need the full "power/complexity" of a validating parser.

Just wondering what approach others are using to read in XML data?  
Hardcoded logic?  Commonly available parser?  Customized parser code?

I'm working on a stripped down SAX parser (based on an open source 
implementation) to use for my Java GPS Access Library.
Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com


Re: [gpsxml] Curious about parsing....

egroups+topografix.com on Tue Feb 05 07:55:47 2002 (link), replying to msg

Hello,

Tuesday, February 05, 2002, 10:38:30 AM, Andrzej wrote:

AJT> Just wondering what approach others are using to read in XML data?  
AJT> Hardcoded logic?  Commonly available parser?  Customized parser code?

 I'm using a generic parser I wrote in C++.  It's a state machine with
 around 15 states, and is able to tokenize XML docs in one pass,
 without backtracking.  Once the document has been tokenized, I've got
 GPX-specific code which looks for tokens it recognizes, and ignores
 the rest.

 I tried a number of other parsers, but rejected them for being too
 slow or too bulky for my needs.

 I don't validate the XML before parsing, but use the Xerces SAXCount
 app to validate any files that don't parse correctly.
 
-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com



Re: Sequence numbers

andrzej+chaeron.com on Tue Feb 05 14:44:51 2002 (link)

> I had actually seen and removed <seq> when I made the 0.6 schema, but
> it slipped back in as I corrected some errors when I tried to validate
> the document.

Sequence numbers seem rather redundant to my thinking.  The track points 
are in logical sequence anyway in the XML (or should be since there is not 
really any reason to transmit them in anything but chronological sequence).  A 
timestamp makes more sense, since it provides an explicit sequencing, but 
one that can provide additional value.  eg.  You can calculate velocities, 
accel/decel and such across many points.


Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com


Re: [gpsxml] Digest Number 55

andrzej+chaeron.com on Tue Feb 05 14:44:51 2002 (link)

Dan:

> I'm using a generic parser I wrote in C++.  It's a state machine with
>  around 15 states, and is able to tokenize XML docs in one pass,
>  without backtracking.  Once the document has been tokenized, I've got
>  GPX-specific code which looks for tokens it recognizes, and ignores
>  the rest.

Thanks for the insight. 

>  I tried a number of other parsers, but rejected them for being too
>  slow or too bulky for my needs.

There are some rather fast SAX parsers out there (I would stay away from 
DOM/JDOM since they need to store the whole parse tree in memory...not 
good for something like a tracklog or large collection of waypoints, especially 
on handheld devices).  Aelfred seems to be a good Java-based one I am 
evaluating.

My thinking is that XML parsers are becoming a standard "toolbox" item, so it's 
probably not worth writing one from scratch.  It also facilitates incorporation of 
newer W3C XML standards, since it's easier (typically) to upgrade a parser 
that is being used rather than rejig your own, and also enhances one's ability 
to react to schema changes (eg GPX or GPSml changes).


>  I don't validate the XML before parsing, but use the Xerces SAXCount
>  app to validate any files that don't parse correctly.

I agree.  Validation should probably be a development time (or problem 
determination) activity.  Not a runtime thing.

Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com


RE: [gpsxml] Re: Sequence numbers

kevin+synergysa.com.au on Wed Feb 06 01:58:16 2002 (link), replying to msg

Strongly disagree

I use XPATH extensively to manage waypoints.  Most of my XNL comes from
a native XML DB so I'm dealing with XML only not a prog specific class
that is loaded via XML.

Sequencing is used to sort and re-order waypoints as well as routes and
tracks trather than manipulating the timestamp and modifying the base
data.

For example:

<.....  Sort-by='trk[seq] desc'>

If I want to re-order a planned route all I need do is change the
sequence and viola.  Leaving the orginal track info intact so point to
point time caculations can still be made based on the orginal sequence.

Seq - I'll be using it regardless, remember those of us using XSLT and
XML:DBs please

Kevin

-----Original Message-----
From: Andrzej Jan Taramina [mailto:andrzej+chaeron.com] 
Sent: Wednesday, 6 February 2002 9:14 AM
To: gpsxml+yahoogroups.com
Subject: [gpsxml] Re: Sequence numbers


> I had actually seen and removed <seq> when I made the 0.6 schema, but
> it slipped back in as I corrected some errors when I tried to validate
> the document.

Sequence numbers seem rather redundant to my thinking.  The track points

are in logical sequence anyway in the XML (or should be since there is
not 
really any reason to transmit them in anything but chronological
sequence).  A 
timestamp makes more sense, since it provides an explicit sequencing,
but 
one that can provide additional value.  eg.  You can calculate
velocities, 
accel/decel and such across many points.


Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com



To unsubscribe from this group, send an email to:
gpsxml-unsubscribe+yahoogroups.com

 

Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/ 






Re[2]: [gpsxml] Re: Sequence numbers

egroups+topografix.com on Wed Feb 06 05:43:11 2002 (link), replying to msg

Hello Kevin,

Wednesday, February 06, 2002, 4:57:42 AM, you wrote:

KR> Strongly disagree

KR> I use XPATH extensively to manage waypoints.  Most of my XNL comes from
KR> a native XML DB so I'm dealing with XML only not a prog specific class
KR> that is loaded via XML.

KR> Sequencing is used to sort and re-order waypoints as well as routes and
KR> tracks trather than manipulating the timestamp and modifying the base
KR> data.

KR> For example:

KR> <.....  Sort-by='trk[seq] desc'>

KR> If I want to re-order a planned route all I need do is change the
KR> sequence and viola.  Leaving the orginal track info intact so point to
KR> point time caculations can still be made based on the orginal sequence.

KR> Seq - I'll be using it regardless, remember those of us using XSLT and
KR> XML:DBs please

KR> Kevin

Does that mean you'll be producing XML files with out-of-order
sequences?

Do you have any reply to my earlier statement that I can't correctly
parse an out-of-order sequence?  (I assume this is the case for
other apps as well.)

Since <seq> is optional, what do you do about all the files we're
producing without <seq>?

<seq> isn't defined for waypoints.  I can see the usefulness of
sorting a list of waypoints by various criteria (elevation,
timestamp).  Other than reversing a route, why would you want to
sort a route/track?

Can you make a small example GPX and XSLT file to demonstrate how
you'd use <seq>?

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com



Routes and Routepoints

murphy+enterprise.net on Wed Feb 06 06:17:44 2002 (link)

Hi All,

On 5 Feb 2002 04:09:36 -0000,  "jlinscheid2000" <jlinsche+hotmail.com>
wrote:
>2.	I noticed that waypoints are redefined in their entirety if 
>included in a route. Will the spec specify which has priority? In 
>other words, if they are different, which waypoint would be written 
>back to the receiver? Or is this up to the developer?
>
It is important to specify what happens when a route contains
duplicate waypoint identifiers, but different coordinates, symbols,
comments etc. Are they to be treated as
1. Distinct and separate waypoints, but then what happens when the
user wishes to pick one of these to go into a route? 
2. The second waypoint overwrites the first
3. The second waypoint is ignored
4. What does identical mean? The same coordinate, but different
symbol, or the same symbol and different coordinate, everything
identical including the comment including upper/lower case etc etc.. ?

This can get quite messy.

I have not followed all your discussions, but I do feel it is
important to allow routes to be defined just in terms of waypoint IDs
- that is without any coordinate, routepoint comment, symbol etc. 
This would get over some of the above problems. 

Thus:
<rte>
<name>A via B twice to F</name>
<rtept>  <name>A</name> </rtept>
<rtept>  <name>B</name> </rtept>
<rtept>  <name>C</name> </rtept>
<rtept>  <name>D</name> </rtept>
<rtept>  <name>B</name> </rtept>
<rtept>  <name>F</name> </rtept>
</rte>

However, this does assume that the waypoints have either 
1. already been transmitted earlier in the file 
or
2. are pre-known by the recipient of the data. This might be the case
in when for some reason the waypoint coordinates or other descriptive
information (symbols, comments etc.) are not available, or for
security/copyright reasons they should or could not be transmitted.  

The format should support the transmission of Routes which contain
only waypoint identifiers.

Of course this does raise a few subsequent questions. e.g.
1. the treatment of 'orphaned' routepoints (when the waypoint ID is
not known at the receiver)  
2. What happens when the receiving system does have duplicate waypoint
IDs in its database? - which one to pick?

The answers to these questions are not as difficult as the previous
set and they can probably be simply left to the implementer. 

An alternative format for ID only route points could be something
like:

<rtept name="A"> </rtept>

As I said I have not followed all your discussions and apologies if
this has already been covered and/or I have not understood some of
your aims.


Alan Murphy

  
http://www.gpsu.co.uk/
at approx N51�00' W001�22' 

Re: [gpsxml] Real-time positioning in XML

hamish+travellingkiwi.com on Wed Feb 06 08:25:04 2002 (link)

Hamish Marson wrote:

>  Dan Foster wrote:
>
> >  Hello,
> >
> >   I'd like to start a general discussion about representing
> real-time
> > positioning
> >   and navigation info in XML.  There are some interesting issues
> that
> >   don't have anything to do with GPX or GPSml, but might have
> bearing
> >   on our future development.
> >
> >   I'd love to be able to sit at work and watch somebody with a
> >   wireless Internet connection out mapping trails and sending back
> an
> >   XML stream of GPS data!  Better yet, I'd volunteer to collect the
> >   data while you all sit at work!
> >
> >   Existing applications:
> >   Does anyone know of a service or website that is currently
> offering
> >   real-time navigation info over a public web connection?  DGPS
> >   corrections?  APRS?  hurricane tracks?  others?
>
> DGPS is available over the Internet... Sorry. Most of my files are
> offline from here... But if noone else volunteers I can provide the
> address tomorrow maybe...
>

OK.. I found it. (Took about 3 secs through google searching for "dgps
internet"

<http://www.wsrcc.com/wolfgang/gps/dgps-ip.html>

Includes sources for the server and client, docs etc...



>
> >
> >
> >   Here's one example (not XML):
> >   http://208.139.198.171/AVLDemo/ (tracking the bus in Boulder, CO)
> >
> >   Real-time considerations:
> >   Data needs to be organized intelligently so that it arrives
> quickly.
> >
> >   As an example of a bad way to do things, you could decide to group
>
> >   everything together by common timestamp, but then you wouldn't
> send
> >   an XML packet until a new timestamp showed up in your source NMEA
> >   stream, which would introduce a time delay.
> >
> >   Backwards compatibility with NMEA:
> >   It seems like a good goal that any XML stream should be able to be
>
> >   transformed into a valid NMEA stream using XSL.
> >
> >   Streaming:
> >   So how do you stream XML, anyway?  It's not valid XML until that
> >   final tag closes...
> >
> > --
> > Dan Foster
> > TopoGrafix - GPS Software, Waypoints, and Maps
> > http://www.topografix.com - mailto:egroups+topografix.com
> >
> >
> >
> >                    Yahoo! Groups Sponsor
>                         ADVERTISEMENT
>
>
> >
> > To unsubscribe from this group, send an email to:
> > gpsxml-unsubscribe+yahoogroups.com
> >
> >
> >
> > Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
>
> --
>
> I don't suffer from Insanity...         | Linux User #237369
>         I enjoy every minute of it...   |
>                                         |
> http://www.travellingkiwi.com/          |
>
>
>
>
>                    Yahoo! Groups Sponsor
                        ADVERTISEMENT


>
> To unsubscribe from this group, send an email to:
> gpsxml-unsubscribe+yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

--

I don't suffer from Insanity...         | Linux User #237369
        I enjoy every minute of it...   |
                                        |
http://www.travellingkiwi.com/          |




Re: [gpsxml] Routes and Routepoints

egroups+topografix.com on Wed Feb 06 09:49:57 2002 (link), replying to msg

Hello,

Wednesday, February 06, 2002, 8:18:50 AM, Alan wrote:

AM> It is important to specify what happens when a route contains
AM> duplicate waypoint identifiers, but different coordinates, symbols,
AM> comments etc.

This is something that should be left up to the program receiving the
information, and not part of GPX.  Early on, we made the decision that
GPX would be free of GPS-receiver-imposed limitations.  Things like
waypoint length, waypoint naming restrictions, and duplicate
identifiers are the responsibility of the receiving program.
Otherwise, GPX would be forced to limit everything to the least common
denominator, and we'd never be able to transfer anything that my old Garmin
GPX 38 couldn't understand.

AM> I have not followed all your discussions, but I do feel it is
AM> important to allow routes to be defined just in terms of waypoint IDs
AM> - that is without any coordinate, routepoint comment, symbol etc. 
AM> This would get over some of the above problems. 

I can see one benefit to have this, but several reasons to keep it out.
Yes, it's shorter.  Now for the counter-arguments:

1. Waypoint IDs aren't guaranteed unique in GPX. (again, that would be
a GPS-restriction, but even then only in the case where the whole data
file is transferred to the GPS at once.  USA.gpx might contain two
waypoints called SMITHFIELD, for example. )

2. It creates two different ways to say the same thing.  Added
complexity; added work for GPX parsers...

3. It breaks the 'self-containedness' of GPX.  Imagine a XSLT that
strips out everything but the routes.  It creates a valid GPX file
if the route points are specified explicitly, but breaks if it only
has a reference to the waypoints in the route.


Even if your software uses a "referenced-waypoint" model for creating
routes, you should be able to create and receive valid GPX files.
When creating GPX, simply look up the waypoint, and write out all the
data in routepoint.  When reading GPX, it's entirely up to you how you
treat the routepoints.  You could create new waypoints for each
routepoint, or try to do some intelligent matching using the lat/lon
and the name.

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com



documentation?

blalor+yahoo.f6bdbf+ithacabands.org on Thu Feb 07 07:26:43 2002 (link)

Hey all.  I found out about gpx a couple of days ago.  I've hacked
together a quick script in python using pygarmin and xml.dom.minidom to
dump the waypoints, routes and tracks in my eTrex out to a gpx document.  
Looks like a pretty solid document description!

Is there any documentation, outside of the mailing list, about what each 
of the fields means and how to best use them?  I also don't see anything 
in the .xsd for 0.6 that says anything about units or datums (I'm assuming 
wgs84).

Thanks,
B

--
Brian Lalor
blalor+ithacabands.org



Re: Ver 0.6

davewissenbach+yahoo.com on Sun Feb 10 14:43:22 2002 (link), replying to msg

--- In gpsxml+y..., Kjeld Jensen <gps+c...> wrote:
> Works fine with me as it is. Saxcount has not problems validating 
my tracks
> and waypoints.
> 
> 0.6 support is now implemented into the latest public Cetus GPS 
for Palm
> beta and GPS TrackLog beta for Windows.
> 

I've finally got sample GPX 0.6 data, with supporting application 
Wissenbach Map. I've tested the samples against the latest ExpertGPS 
beta with good results. My sample data now includes the descriptive 
bounds data, and I'll soon modify the GPX-to-XHTML stylesheet to 
extract the descriptive data.

For GPX samples see

http://www.cableone.net/cdwissenbach


GPS XML Contents to XHTML Transformation Demo

davewissenbach+yahoo.com on Sat Feb 16 07:41:43 2002 (link)

I have written a stylesheet to allow a web browser to display the 
title, author, description, author-email, and area URL information 
and map contents (waypoint, track, and route names and descriptions) 
in the web browser.

For this to work with Internet Explorer, the file suffix on the 
server must be .xml, and a processing instruction is inserted into 
the preamble of the gps xml file. The demonstration file is

http://www.cableone.net/cdwissenbach/BogusBasin.xml

The stylesheet is

http://www.cableone.net/cdwissenbach/GPXContents.xsl

I think that I might want to publish trails on the web as .xml 
files, rather than as .gpx files. (The transformed document contains 
instructions to save the file locally as a .gpx file.) But I don't 
know if it is (yet) possible to get the web browser to associate the 
document type of gpx with a program.

The stylesheet can also be used with a stylesheet processor such as 
xalan from

http://www.apache.org

to transform the .gpx file on the server side to an html document.


Re: [gpsxml] What are we waiting for?

n8004016+ccs.iitb.ernet.in on Tue Feb 19 01:47:17 2002 (link), replying to msg



Hi,

	Please let me know about the database schema that you are talking
about. I wanted to know details about this project


> Hi,
> 
> I would like to know what you think we need in order to step from 0.6 to 1.0?
> 
> As I have no problems with the current 0.6 schema I wouldn't mind going to
> 1.0 soon...
> 
> Kjeld


With best regards,
S.Q.Salman 

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
_/ Syed Qutub Salman, B-tech Fourth year    Residential address     _/
_/ Dept. of Civil Engineering               D-6/100; DAE colony;    _/
_/ Indian Institute of Technology,Bombay    ECIL post; Hyderabad    _/
_/ Powai, Mumbai-400076                     500062; Andhra Pradesh  _/
_/ Hostel-3. Room #319                      India.                  _/
_/ Phone: +91-040-7120072                   Phone:+91-040-7120072   _/
_/        +91-022-5720095                                           _/
_/ Email: N8004016+ccs.iitb.ac.in                                   _/
_/      : http://sqsalman.tripod.com                                _/
_/                                                                  _/
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/




Re: [gpsxml] What are we waiting for?

egroups+topografix.com on Tue Feb 19 13:16:48 2002 (link), replying to msg

Hello,

Tuesday, February 19, 2002, 4:31:30 AM, Kjeld wrote:

KJ> I would like to know what you think we need in order to step from 0.6 to 1.0?

KJ> As I have no problems with the current 0.6 schema I wouldn't mind going to
KJ> 1.0 soon...

I made some progress on a GPX manual last week:
http://www.topografix.com/gpx_manual.asp

Please let me know what else you'd like to see in there.  I think it
needs some larger examples and a reference to some of the "GPX guiding
philosophy" we talked about early on.

I still have concerns about the <seq> element that's in 0.6  I asked
some questions, but never got a reply back.  I'd like to see <seq>
dropped in 1.0, but other than that, I'm ready to move to a final
definition for GPX 1.0.

Dave W. pointed out some GPX implementation errors in my latest beta
software, and I'll be correcting those this week.

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com



Re: What are we waiting for?

jlinsche+hotmail.com on Tue Feb 19 20:28:46 2002 (link), replying to msg

Hi all, I'm new to this discussion, but have been lurking for a while.

Dan wrote
>I'd like to see <seq>
>dropped in 1.0, but other than that, I'm ready to move to a final
>definition for GPX 1.0.

If the GPX specification states that GPX files will be created in the 
proper order in the case of routes and tracks, then the <seq> tag is 
redundant, and such information can easily be added in post 
processing. The only issue would be if any GPS units require this 
information. My only experience is with Magellan, but I gather from 
previous postings that this is not the case.

I also read in an earlier posting about adding support for real-time 
data collection. This might be something to consider. Although a well-
adopted standard does exist, NMEA strings, it makes sense to add a 
provision for encoding it into the GPX format. Like tracks, NMEA 
represents an automatic collection of positional information over 
time. By encoding this information into GPX we can leverage GPX 
handlers to transfer the data. I'm bringing this up very late in the 
game, so perhaps waiting for 2.0 would be appropriate. My real fear 
is that it will be implemented as an extension, or worse, several 
different extensions that will have to be dealt with. 

Of course this may be a non-issue as the <trkpt> has all of the 
information that a NMEA stream provides. If <trkpt> is intended for 
both NMEA data and the standard track feature, then like I said, this 
is a non-issue. The only thing I would suggest would be either an 
attribute stating that the source of the data is NMEA, or adding a 
<nmeapt> tag that could be used in place of <trkpt> when appropriate. 
The real question however is whether such a distinction is necessary 
at all. 

As a side-note I am finishing up a C++ implementation of a GPX 
parser. It's based on libxml http://xmlsoft.org/, and compiles under 
Cygwin http://sources.redhat.com/cygwin/ at the moment. It works 
great, but needs quite a bit of clean up in order to make it 
presentable. I basically wrapped up libxml into a class called 
GPX_Parser, which has just a few public interfaces for parsing a file 
and grabbing structures that contain waypoint data. I'll post this 
when it's ready. If anyone feels a real need to play with it in its 
very alpha state I'd be happy to pass it along. Just let me know. I'm 
pretty satisfied that the API won't change, but the guts need a lot 
of work.

James Linscheid




Intro

erich+lodgenet.com on Wed Feb 20 10:00:49 2002 (link)


Howdy,

I've been following this group for a while, and finally found time to 
actually do something with Gpx.

I generally download gps data to my handspring, but want to be able to 
use a desktop program with the data too.  I've done some throwaway java 
apps, and a palm app for gps data.  But now I'm mainly using GPilotS and 
ExpertGPS.

My idea of how palm devices and gpx fit together is that palm/gps apps 
should have a conduit to do the Gpx translation.  They shouldn't have to 
do any gpx processing natively.

I've got a rough start on a gpx sync conduit.  I can save 
routes/tracks/waypoints from GPilotS (originally downloaded from a 
GPS12) in gpx format on my pc.  Then I can read the gpx docs in ExpertGPS.

The unimplemented features now are:
  * Only a few waypoint/track/route types of GPilotS are implemented
  * Only export works, sync and import don't
  * only GPilotS is implemented, but other apps should be 
straightforward to add.

I'm still sorting out what to do with this thing, as far as release, 
open source, licensing, etc...  So if it's something that you might be 
interested in, let me know.


Thanks,
Eric


GPX 1.0

egroups+topografix.com on Thu Feb 21 07:59:37 2002 (link), replying to msg

Hello,

I've posted the 1.0 schema and supporting documentation at http://www.topografix.com/gpx.asp
Direct link to the schema: http://www.topografix.com/GPX/1/0/gpx.xsd

Changes from 0.6:
dropped <seq>.
changed capitalization of elements in <bounds>.

This is the official 1.0 schema.  Please take a close look, and point
out any corrections as soon as possible.  There's still the chance to
make corrections or small changes, but after next week, we'll be
locking down the definition for GPX 1.0.

I'll post again when 1.0-enabled versions of my software are
available, probably late today or tomorrow.

We should start a collection of sample files for testing against each
other's output.  We can store them on the Yahoo Groups site (below), or each
author can maintain their own data files on the web and I'll collect
the links on a webpage.  The Yahoo Groups site requires a login, so
I'd prefer to use the web for storage.
http://groups.yahoo.com/group/gpsxml/files/Sample%20XML%20Files/

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com


Re: [gpsxml] GPX 1.0

egroups+topografix.com on Thu Feb 21 14:00:01 2002 (link), replying to msg

Hello,

I've updated my software to conform to the GPX 1.0 spec:
http://www.easygps.com/beta.asp
http://www.topografix.com/beta.asp
http://www.expertgps.com/beta.asp

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com


Re: GPX 1.0

davewissenbach+yahoo.com on Thu Feb 21 22:25:18 2002 (link), replying to msg

--- In gpsxml+y..., Dan Foster <egroups+t...> wrote:
> Hello,
> 
> I've posted the 1.0 schema and supporting documentation at 
http://www.topografix.com/gpx.asp
> Direct link to the schema: 
http://www.topografix.com/GPX/1/0/gpx.xsd
> 
I have updated the Southwestern Idaho Trails Website to the new 
standard, and published Wissenbach Map 1.7 See my website

http://www.cableone.net/cdwissenbach

for sample maps, windows application, source code, and links to our 
programs.

> 
> I'll post again when 1.0-enabled versions of my software are
> available, probably late today or tomorrow.
> 

I've downloaded the new ExpertGPS and EasyGPS Beta versions and they 
display my trails as expected.




Re: GPX 1.0

davewissenbach+yahoo.com on Sun Feb 24 13:22:13 2002 (link), replying to msg

--- In gpsxml+y..., Kjeld Jensen <gps+c...> wrote:
> Hi
> 
> - sorry for the delayed response...
> 
> Looks good to me except that I noticed that some of the date 
fields are
> represented as strings. Wouldn't it be better if all time-date 
related
> elements follows the "gpx date-time format"?
> 

Good catch. I think that this should be xsd:dateTime, which is the 
same thing as our gpx date-time format but slightly less restrictive 
in that time zone offsets are allowed.

I was using string instead of dateTime in some earlier sample dtd's 
because Xerces didn't support this before version 1.6.

I also noticed one shortcoming with track names. For waypoint, I can 
use cmt for a more descriptive long name, but with trk this option 
is not available. Right now I'm storing a long track name, as 
opposed to a short display name, in a private wissenbach:longname 
element in the track data.

> Kjeld
> 
> 
> ______________________
> Kjeld Jensen
> N 55� 22' E 10� 24'
> Email: kjeld+C...
> http://www.CetusGPS.dk


Re: [gpsxml] Re: GPX 1.0

egroups+topografix.com on Mon Feb 25 10:48:28 2002 (link), replying to msg

Hello,

Sunday, February 24, 2002, 4:22:09 PM, Dave and Kjeld wrote:

>> Looks good to me except that I noticed that some of the date
d> fields are
>> represented as strings. Wouldn't it be better if all time-date 
d> related
>> elements follows the "gpx date-time format"?
>> 

d> I also noticed one shortcoming with track names. For waypoint, I can 
d> use cmt for a more descriptive long name, but with trk this option 
d> is not available.

I've updated the schema and manual to reflect these changes to GPX
1.0.

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com


Re: [gpsxml] GPX V1.0

egroups+topografix.com on Wed Feb 27 08:01:05 2002 (link), replying to msg

Hello,

Wednesday, February 27, 2002, 7:17:30 AM, Kjeld wrote:

KJ> I have validated my track and waypoint data against the modified gpx.xsd
KJ> 1.0 and I have succesfully imported track and waypoint data from Cetus GPS
KJ> into the latest Topografix beta.

KJ> I vote for a lock of GPX 1.0 without further changes asap...

I'm also in favor of locking GPX 1.0 now.

If you've got final comments on GPX 1.0, speak up now!

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com


Re: GPX V1.0

davewissenbach+yahoo.com on Wed Feb 27 14:15:55 2002 (link), replying to msg

--- In gpsxml+y..., Dan Foster <egroups+t...> wrote:
> Hello,
> 
> Wednesday, February 27, 2002, 7:17:30 AM, Kjeld wrote:
> 
> KJ> I have validated my track and waypoint data against the 
modified gpx.xsd
> KJ> 1.0 and I have succesfully imported track and waypoint data 
from Cetus GPS
> KJ> into the latest Topografix beta.
> 
> KJ> I vote for a lock of GPX 1.0 without further changes asap...
> 
> I'm also in favor of locking GPX 1.0 now.
> 
> If you've got final comments on GPX 1.0, speak up now!
> 

The current version is pretty good, and meets the goals of this 
project! So I think that we can release the schema at any time.

We might want to consider using the built-in type xsd:anyURI instead 
of string for the url elements, but I haven't tested this change to 
see if it works OK.

I'm out sick today, so I've updated my web site to use a style 
transformation on every link. I even borrowed Dan Foster's idea and 
inserted a link to a sample photograph Tamarack.jpg in the 
Ponderosa.gpx sample file--the stylesheet looks for a waypoint type 
of "photograph" and replaces this with the tag <image> for the 
browser display!

See

http://www.cableone.net/cdwissenbach

Southwestern Idaho Trail Maps

You can link to this page for gps samples.

Use

http://www.cableone.net/cdwissenbach/map.html

if an existence proof of other supporting applications is needed to 
get the ball rolling. If not, leave the link off -- the link is 
available on the Southwestern Idaho Trail maps page already.

> -- 
> Dan Foster
> TopoGrafix - GPS Software, Waypoints, and Maps
> http://www.topografix.com - mailto:egroups+t...


Possible issue with 1.0?

jlinsche+hotmail.com on Wed Feb 27 23:57:22 2002 (link)

Hi all,

I'm not sure if this is a problem or not, but I thought I'd report it 
as the release of 1.0 is imminent. 

I've created a file with the ExpertGPS GPS Beta (V1.1b1). It contains 
URLS from topozone for some of the waypoints. 

When I load the GPX file into my parser it bombs, so I thought I'd 
give it a .xml extension and load it into IE6. It also had an error:

***** IE6 error follows *****

The XML page cannot be displayed 
Cannot view XML input using XSL style sheet. Please correct the error 
and then click the Refresh button, or try again later. 


----------------------------------------------------------------------
----------

A semi colon character was expected. Error processing 
resource 'file:///D:/devel/gis/gpx2shape/cpp/0.0/bluebooksites.gpx.xml
'. Line 35, Position 45 
 

 <url>http://www.topozone.com/map.asp?
z=11&n=5007844&e=332282&s=25&size=l</url>
--------------------------------------------^

**** End error dump ****

My thinking is that perhaps the URL field needs to be cdata? My 
parser is based on libxml if that helps. It doesn't concern me that 
my parser blew up as I'm still working on it and it's bound to be 
buggy, but the fact that IE barfed on it has me concerned.

I've uploaded the file to the files area under sample GPX files for 
analysis.

James


Re: [gpsxml] Possible issue with 1.0?

egroups+topografix.com on Thu Feb 28 13:32:38 2002 (link), replying to msg

Hello,

Thursday, February 28, 2002, 2:57:20 AM, jlinscheid2000 wrote:

j> I'm not sure if this is a problem or not, but I thought I'd report it 
j> as the release of 1.0 is imminent. 

j> I've created a file with the ExpertGPS GPS Beta (V1.1b1). It contains 
j> URLS from topozone for some of the waypoints. 

j> When I load the GPX file into my parser it bombs...

This is a problem in ExpertGPS, not GPX.  I've corrected ExpertGPS to
wrap the <url> data in CDATA tags.

Any data field that a user can enter should probably be wrapped with
CDATA.  Even waypoint name and comment are vulnerable - the new
Magellan Meridian series allows "-.'/!+#<" as a valid waypoint name!

In other news, I updated the GPX 1.0 schema to use xsd:anyURI for
<url>, as requested earlier.

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com


Re: Possible issue with 1.0?

jlinsche+hotmail.com on Thu Feb 28 22:07:50 2002 (link), replying to msg

 
> This is a problem in ExpertGPS, not GPX. 

Glad to hear that it's not a fundamental issue.

I hope I didn't alarm anyone. I just wanted to be sure.

James 


GPX 1.0 Is Officially Complete!

egroups+topografix.com on Fri Mar 01 10:40:25 2002 (link), replying to msg

Hello,

 The GPX 1.0 schema is now official!  Congratulations, everyone!  It
 took a while, but our discussions and debates made for a better
 solution in the end.

 Now let's get some GPX-enabled applications and websites out there!

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com


validating gpx files

blalor+yahoo.f6bdbf+ithacabands.org on Fri Mar 01 11:52:50 2002 (link)

I guess this is more of a general XML question, but are there any tools 
that, given a GPX file and the gpx.xsd file, will validate the GPX file?

--
Brian Lalor
blalor+ithacabands.org


Re: [gpsxml] validating gpx files

egroups+topografix.com on Fri Mar 01 12:02:17 2002 (link), replying to msg

Hello Brian,

Friday, March 01, 2002, 2:52:45 PM, you wrote:

BL> I guess this is more of a general XML question, but are there any tools 
BL> that, given a GPX file and the gpx.xsd file, will validate the GPX file?

This is described at http://www.topografix.com/gpx.asp

Use the Xerces SAXCount program to validate your GPX file against the
schema.
http://www.topografix.com/gpx_validation.asp

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com


Working with Stylesheets (Explorer 5.5 Incompatible)

davewissenbach+yahoo.com on Fri Mar 01 21:41:50 2002 (link)

I took a look at my website from the office, where I use Internet 
Explorer 5.5 instead of Internet Explorer 6.0. The xslt stylesheet 
transformations do not work correctly with Internet Explorer 5.0 and 
5.5 because those browsers were developed before the release of xslt 
and xpath as W3C Recommendations.

The trail contents are complete gobbledegook in Internet Explorer 
5.5. So stylesheet transformations of gpx documents to display 
contents may not be such a good idea after all, or at least not 
universally applicable! If you are going to publish trails to a wide 
audience using a stylesheet such as 

http://www.cableone.net/cdwissenbach/GPXContents.xsl

you should be mindful of this incompatibility. I looked at one other 
stylesheet transformation of GPX both at work (ID 5.5) and later at 
home (IE 6.0) and noticed a huge difference in appearance and had 
assumed that the stylesheet had been reposted. What I now realize is 
that what had changed was the browser.


Introduction

gps_maps+yahoo.com on Sat Mar 02 02:49:20 2002 (link)

Hello,
I'm Doug Adomatis.  I guess you'd call me a more of a publisher than 
a developer.  GPX has caught my interest because its proliferation 
will have an impact on what I do.
More about me can be found at my web.
Doug Adomatis
www.travelbygps.com



Waypoint Naming Convention

gps_maps+yahoo.com on Sat Mar 02 02:51:15 2002 (link)

There's a current thread at sci.geo.sat-nav that I thought someone 
from this group would reply to.  I want to know more about how this 
issue is handeled in the GPS format.
, Doug


Re: Waypoint Naming Convention

gps_maps+yahoo.com on Sun Mar 03 04:35:10 2002 (link), replying to msg


Oops,  I ment to write "how is (waypoint naming) handled in GPX / XML 
format.  More specifically, what are the guidelines for waypoint 
names (number of characters) and what is the waypoint symbol set used 
in the GPX/XML format?  Using these guidlines, how will these 
waypoint names and symbols look after being converted to a form that 
can eventually be intrupreted by specific brand/models of GPS 
receivers?
Clearly, I'm a newbie at understanding these development issues, but 
please humor me with a reply.
Doug





--- In gpsxml+y..., "gps_maps" <gps_maps+y...> wrote:
> There's a current thread at sci.geo.sat-nav that I thought someone 
> from this group would reply to.  I want to know more about how this 
> issue is handeled in the GPS format.
> , Doug


Re: [gpsxml] Re: Waypoint Naming Convention

egroups+topografix.com on Sun Mar 03 15:29:33 2002 (link), replying to msg

Hello,

Sunday, March 03, 2002, 7:35:06 AM, Doug wrote:

g> Oops,  I ment to write "how is (waypoint naming) handled in GPX / XML 
g> format.  More specifically, what are the guidelines for waypoint 
g> names (number of characters) and what is the waypoint symbol set used 
g> in the GPX/XML format?  Using these guidlines, how will these 
g> waypoint names and symbols look after being converted to a form that 
g> can eventually be intrupreted by specific brand/models of GPS 
g> receivers?
g> Clearly, I'm a newbie at understanding these development issues, but 
g> please humor me with a reply.
g> Doug

GPX is a data exchange format, so there are no limitations placed on the
waypoint names or symbols.  It's up to the application that transfers
the GPX data to the GPS to impose any restrictions.

If we made GPX device-dependant, we'd be forced to adopt the least
common denominator out of all the GPS units.  My Brunton GPS is
restricted to 6 character names, and no waypoint symbols!

Symbols are specified by name in GPX.  <sym>Parking Area</sym>, for
example.

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com


Re: Waypoint Naming Convention

davewissenbach+yahoo.com on Sun Mar 03 16:16:56 2002 (link), replying to msg

--- In gpsxml+y..., Dan Foster <egroups+t...> wrote:
> Hello,
> 
> GPX is a data exchange format, so there are no limitations placed 
on the
> waypoint names or symbols.  It's up to the application that 
transfers
> the GPX data to the GPS to impose any restrictions.
> 
> If we made GPX device-dependant, we'd be forced to adopt the least
> common denominator out of all the GPS units.  My Brunton GPS is
> restricted to 6 character names, and no waypoint symbols!
> 
> Symbols are specified by name in GPX.  <sym>Parking Area</sym>, for
> example.
> 

I'm letting a little bit of device-dependence creep into my sample 
trails. What I've been doing is to use the name field as a short 
name that will fit on my eTrex Summit display. 6 characters for a 
waypoint, or 13 characters for a trail. Then I'm using the cmt field 
as a longer version of the name. And, I think that I'll also repeat 
the trail name as the first sentence of the description. However, I 
have the luxury of supporting only the eTrex in my application. The 
application itself doesn't enforce this restriction, except by using 
extremely short display windows in the trail and waypoint name 
dialog boxes, and by calling the <cmt> field the long name.

<name>NYC</name>
<cmt>New York City</cmt>
<desc>New York City. First settled by the Dutch, this city as become 
the capital of the world.</desc>

But the format doesn't enforce this particular usage, because, as 
Dan points out, we shouldn't go to the least common denominator in 
naming trails and waypoints. I think that we might eventually be 
able to converge on a common usage, though.

As far as waypoint names, I was never able to find any Garmin 
documentation for the topografix names. Instead, I just matched the 
topografix output and documented this on my program website. The 
main reason that I repeat the long name as the first sentence of the 
description for trails is so that I can see the long trail name in 
ExpertGPS, in an effort to get the most utility for the greatest 
amount of people.

I think that ultimately, the publishers of trail websites and users 
of the GPX application will get to set the usage pattern. This might 
be a better topic for the map_authors group. (That's probably the 
first place to announce this format.)



Java API for using XML Schema?

ithork+yahoo.com on Sun Mar 03 23:07:05 2002 (link)

Hi,

I was looking at delveloping a Java program that supports GPX 
format.  I'm still learning about XML in general, but from what I've 
read, JAXB looked like a good API for this.  Until, though, I noticed 
that you guys were not using a DTD for this (JAXB v1.0 only supports 
DTD right now).  Can anyone suggest an alternative Java API, or has 
anyone written a DTD for GPX?

Thanks!
Thor


Re: [gpsxml] Java API for using XML Schema?

chris+wilder-smith.org on Mon Mar 04 05:38:58 2002 (link)

Thor,

Current versions of Xerces (http://xml.apache.org) support XML schema 
validation.

Chris

ithork wrote:

>Hi,
>
>I was looking at delveloping a Java program that supports GPX 
>format.  I'm still learning about XML in general, but from what I've 
>read, JAXB looked like a good API for this.  Until, though, I noticed 
>that you guys were not using a DTD for this (JAXB v1.0 only supports 
>DTD right now).  Can anyone suggest an alternative Java API, or has 
>anyone written a DTD for GPX?
>
>Thanks!
>Thor
>
>
>
>To unsubscribe from this group, send an email to:
>gpsxml-unsubscribe+yahoogroups.com
>
> 
>
>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 
>
>
>




Re: Waypoint Naming Convention

gps_maps+yahoo.com on Tue Mar 05 18:54:11 2002 (link), replying to msg

Thanks Dan, Dave.  I think I beginning to get a handel on the this.  
Let me see if I have it straight.  If I publish trail maps in gpx 
format, my readers will need an appilication that can translate gpx 
into a format that can be uploaded to a GPSR or imported into a 
mapping program.  Right?  Kinda like I'm using EasyGPS now - thanks 
to TopoGrafix.  I can see where it is a good idea to have a common 
format that all readers can use.  On one hand, that would make my 
life easier - not having to publish in multiple formats to reach a 
larger audience.  On the other hand(s), there are other issues that 
come to mind.  Two of my first questions would be: Where will my 
patrons find these applications?  Will they have to pay for them?
Clearly, I've gone beyond the subject of this thread.  Feel free to 
reply with a new subject, say "GPX for Publishers"
, Doug

--- In gpsxml+y..., "davewissenbach" <davewissenbach+y...> wrote:
> --- In gpsxml+y..., Dan Foster <egroups+t...> wrote:
> > Hello,
> > 
> > GPX is a data exchange format, so there are no limitations placed 
> on the
> > waypoint names or symbols.  It's up to the application that 
> transfers
> > the GPX data to the GPS to impose any restrictions.
> > 
> > If we made GPX device-dependant, we'd be forced to adopt the least
> > common denominator out of all the GPS units.  My Brunton GPS is
> > restricted to 6 character names, and no waypoint symbols!
> > 
> > Symbols are specified by name in GPX.  <sym>Parking Area</sym>, 
for
> > example.
> > 
> 
> I'm letting a little bit of device-dependence creep into my sample 
> trails. What I've been doing is to use the name field as a short 
> name that will fit on my eTrex Summit display. 6 characters for a 
> waypoint, or 13 characters for a trail. Then I'm using the cmt 
field 
> as a longer version of the name. And, I think that I'll also repeat 
> the trail name as the first sentence of the description. However, I 
> have the luxury of supporting only the eTrex in my application. The 
> application itself doesn't enforce this restriction, except by 
using 
> extremely short display windows in the trail and waypoint name 
> dialog boxes, and by calling the <cmt> field the long name.
> 
> <name>NYC</name>
> <cmt>New York City</cmt>
> <desc>New York City. First settled by the Dutch, this city as 
become 
> the capital of the world.</desc>
> 
> But the format doesn't enforce this particular usage, because, as 
> Dan points out, we shouldn't go to the least common denominator in 
> naming trails and waypoints. I think that we might eventually be 
> able to converge on a common usage, though.
> 
> As far as waypoint names, I was never able to find any Garmin 
> documentation for the topografix names. Instead, I just matched the 
> topografix output and documented this on my program website. The 
> main reason that I repeat the long name as the first sentence of 
the 
> description for trails is so that I can see the long trail name in 
> ExpertGPS, in an effort to get the most utility for the greatest 
> amount of people.
> 
> I think that ultimately, the publishers of trail websites and users 
> of the GPX application will get to set the usage pattern. This 
might 
> be a better topic for the map_authors group. (That's probably the 
> first place to announce this format.)


GPX considerations for publishers

egroups+topografix.com on Wed Mar 06 06:48:31 2002 (link), replying to msg

Hello,

Tuesday, March 05, 2002, 7:11:17 PM, Doug wrote:

g> If I publish trail maps in gpx
g> format, my readers will need an appilication that can translate gpx 
g> into a format that can be uploaded to a GPSR or imported into a 
g> mapping program.  Right?  Kinda like I'm using EasyGPS now - thanks 
g> to TopoGrafix.  I can see where it is a good idea to have a common 
g> format that all readers can use.  On one hand, that would make my 
g> life easier - not having to publish in multiple formats to reach a 
g> larger audience.  On the other hand(s), there are other issues that 
g> come to mind.  Two of my first questions would be: Where will my 
g> patrons find these applications?  Will they have to pay for them?

[Ann] Mobile GPS Demonstration Platform project description posted....

andrzej+chaeron.com on Wed Mar 06 08:36:26 2002 (link)

This might have some interest to the members of this list, so I have posted it 
here:

The purpose of the Mobile GPS Demonstration Platform (MGDP) project is to 
demonstrate a proof of concept for the integration of a number of emerging 
technologies including: Embedded/Realtime Java, Mobile, position-based 
applications, GPS (Global Position System) technologies, Wireless/Mobile 
connectivity, Web Services (XML, SOAP, WSDL, JAX-RPC, etc.), and server-
side J2EE (including EJB and DBMS persistence). The MGDP has been 
constructed using commonly available, inexpensive hardware and software 
(including open source software) to illustrate that applications of this nature are 
very feasible using existing tools and technologies. It is hoped that the MGDP 
project inspires others to push the threshold of what can be done with position-
based computing and the Java platform.  

This project will be demonstrated at JavaOne 2002 in San Francisco
(March 25-29, 2002). Drop by the Systronix booth in the JavaOne Vendor
Pavillion and see the MGDP in action!

A detailed white paper describing the MGDP project, architecture and
technologies is available (in .pdf format) at:

http://www.chaeron.com

Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com


Re: [gpsxml] GPX considerations for publishers

gps_maps+yahoo.com on Wed Mar 06 12:40:13 2002 (link), replying to msg

Dan,
Thank you for the very detailed information.  You've
given me a lot to think about here. I had a look the
examples, viewed the source, and saw the 'hidden' GPS
data.  I now understand that the stylesheet defines
what data in the gpx file is displayed and how it is
to be displayed.
Now it seems that I need to study up on what I can do
with stylesheets.
, Doug


--- Dan Foster <egroups+topografix.com> wrote:
> Hello,
> 
> Tuesday, March 05, 2002, 7:11:17 PM, Doug wrote:
> 
> g> If I publish trail maps in gpx
> g> format, my readers will need an appilication that
> can translate gpx 
> g> into a format that can be uploaded to a GPSR or
> imported into a 
> g> mapping program.  Right?  Kinda like I'm using
> EasyGPS now - thanks 
> g> to TopoGrafix.  I can see where it is a good idea
> to have a common 
> g> format that all readers can use.  On one hand,
> that would make my 
> g> life easier - not having to publish in multiple
> formats to reach a 
> g> larger audience.  On the other hand(s), there are
> other issues that 
> g> come to mind.  Two of my first questions would
> be: Where will my 
> g> patrons find these applications?  Will they have
> to pay for them?
> 
> From http://www.topografix.com/gpx.asp :
> 
> What are the benefits of GPX?
> Here are some of the benefits that GPX provides:
> GPX allows you to exchange data with a growing list
> of programs for Windows, MacOS, Linux, Palm, and
> PocketPC. 
> GPX can be transformed into other file formats using
> a simple webpage or converter program. 
> GPX is based on the XML standard, so many of the new
> programs you use (Microsoft Excel, for example) can
> read GPX files. 
> GPX makes it easy for anyone on the web to develop
> new features which will instantly work with your
> favorite programs. 
> 
> What programs already support GPX?
> http://www.topografix.com/gpx_resources.asp
> 
> Publishing GPS data in GPX gives you flexibility in
> reaching a wider
> audience of users.  Let's consider three types of
> users:
> 
> 1. Uses a GPX-enabled program already.
>    GPX files can be opened directly in the user's
> favorite program.
>    You could keep a list of GPX-enabled programs on
> your website's
>    resources page, or even create your own XSL
> stylesheet that
>    mentions them.  (see #3)
>    
> 2. Uses a non-GPX-enabled program.
>    Quite possibly, someone has written (or will soon
> write) an XSL
>    stylesheet to transform GPX files into that
> program's format.  For
>    example, Kevin Read wrote an XML to OziExplorer
> converter.  Once GPX
>    is introduced to the public, expect the XML-savvy
> users to start
>    writing converters. 
> http://www.kevinread.com/HTMLTemplates/locform.html
>    Once GPX starts to gain acceptance, expect more
> GPS program authors
>    to support it.
>    
> 3. Doesn't use any GPS software.
>    Remember, a GPX file on the web doesn't have to
> look like XML.  If
>    you've provided a link to your custom XSLT
> stylesheet in your GPX
>    files, you can make the GPX file look as pretty
> as you like.
>    Dave's trails are good examples of how you could
> create something
>    that reads like a trail guide, but contains all
> the info your GPS
>    needs, too!
>    Here are two examples:
>    Dave's Idaho trail page: 
> http://www.cableone.net/cdwissenbach/
>    Dan's sample:
>
http://www.topografix.com/gpx/samples/topografix/gpx_sample_mbta.gpx
> 
> 
> You should realize that GPX 1.0 is still only a week
> old, and that it
> will take a bit of time before GPX-enabled apps show
> up.   Try
> creating a GPX file with one of the apps on the GPX
> Resources page,
> and see how it looks in some of the other
> applications.  You might
> find it worthwhile to look at the sample files
> above, and begin
> learning about using XSLT to create your own "house
> format" stylesheet
> for GPX pages you publish.
> 
> -- 
> Dan Foster
> TopoGrafix - GPS Software, Waypoints, and Maps
> http://www.topografix.com -
> mailto:egroups+topografix.com
> 
> 
> ------------------------ Yahoo! Groups Sponsor
> 
> To unsubscribe from this group, send an email to:
> gpsxml-unsubscribe+yahoogroups.com
> 
>  
> 
> Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/ 
> 
> 


__________________________________________________
Do You Yahoo!?
Try FREE Yahoo! Mail - the world's greatest free email!
http://mail.yahoo.com/

GPX "Publish to Web" feature in TopoGrafix software

egroups+topografix.com on Tue Mar 12 19:07:53 2002 (link), replying to msg

Hello,

I've updated the beta versions of all my software to add improved GPX
1.0 support.  I added several private elements (route color, leg name,
leg description, and leg url) to the GPX files produced by my programs
so that my users could save their data as GPX without losing any info.
I added a File Info dialog similar to Dave's, which also allows the
advanced user to specify an XSLT stylesheet for the GPX file.  I added
a "Publish to Web" feature which allows you to upload your GPX files
to your favorite FTP server.  An example of the output can be found at:
http://home.attbi.com/~topografix/mystic_basin_trail.gpx

For more info, see http://home.attbi.com/~topografix/

The new software is at:
http://www.easygps.com/beta.asp
http://www.topografix.com/beta.asp
http://www.expertgps.com/beta.asp

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com


Wissenbach Map announced on map_authors

davewissenbach+yahoo.com on Fri Mar 29 03:30:49 2002 (link)

I have posted an announcement of Version 2.0 of Wissenbach Map on 
the map_authors group

http://groups.yahoo.com/group/map_authors

in the hope that people will begin to use the format.

I am also now distributing a local-version CD of the Wissenbach Map 
program in the Boise area to try to get a few other trails websites 
out there, and I've added my web site to the search list on

http://www.travelbygps.com

I hope to see other announcements of programs with support for our 
new format out there soon! (In fact, I'm counting on it, as I won't 
be supporting my own program with any particular diligence!)

Dave


XML Editor(?)

gps_maps+yahoo.com on Sat Mar 30 02:41:43 2002 (link)

It would be a cruel world without cordless screwdrivers, ATM 
machines, and wysiwyg HTML editors.  What do you use to edit your 
XML?  Please dont' tell me "notebook"!
, Doug


Re: XML Editor(?)

davewissenbach+yahoo.com on Sat Mar 30 05:42:56 2002 (link), replying to msg

--- In gpsxml+y..., "gps_maps" <gps_maps+y...> wrote:
> It would be a cruel world without cordless screwdrivers, ATM 
> machines, and wysiwyg HTML editors.  What do you use to edit your 
> XML?  Please dont' tell me "notebook"!
> , Doug

I rarely, if ever, edit .gpx files directly. But when I do, I use 
wordpad to edit raw text. (I also ride a bicycle to work, every day, 
rain or shine, cold or hot.)

You might visit

http://www.xslt.com

for a listing of stylesheet editors to transform xml documents. (I 
even saw a stylesheet debugger there, visual XSTL). I tend to be 
adverse to expensive new tools, although I do own a cordless 
screwdriver!


Re: Editing XML...

andrzej+chaeron.com on Sun Mar 31 09:15:18 2002 (link)

Doub inquires:

> It would be a cruel world without cordless screwdrivers, ATM 
> machines, and wysiwyg HTML editors.  What do you use to edit your 
> XML?  Please dont' tell me "notebook"!

Well....I have been known to use notebook for quick on-the-fly changes to 
small XML-encoded config files.  Usually use JPadPro or sometimes XMLSpy 
otherwise.

Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com


gps europe

js_sms+yahoo.com on Thu Apr 04 11:48:08 2002 (link)

I am starting a group about GPS (Global Positioning System) in Europe.

Everybody is invited to join

 http://groups.yahoo.com/group/gps-europe/

to join, just send ANY email to:

gps-europe-subscribe+yahoogroups.com





GPX 1.0 questions: time format, etc.

robertlipe+yahoo.com on Thu Apr 04 19:21:51 2002 (link)

Hello.

I've started an implementation of a program using GPX 1.0.  I intend to
make it freely available.  Though I'm not a an XML jock, I have a few 
questions and I hope you can help me capture the intent of GPX.

1) <time> is specified as "conforming to ISO 8601" but that allows a 
   plethora of potential encodings.  Is a conforming GPX reader expected
   to handle any of them?  Could I get a clarification on the precise 
   allowable members of this field?   Bonus points for providing suitable 
   strftime (as in ISO/IEC 9899:1999) specifiers to make it completely 
   unambiguous.

2) By my reading, the example file is illegal.

	http://groups.yahoo.com/group/gpsxml/files/Sample%20XML%20Files/Kevin%20Read%20Untitled.gpx

  This file, among other deviations, contains "lat" and "lon" instead
  of "latitude" and "longitude".   Are abbreviations for the tag names
  really allowed?

3) Does the <url> tag include protocol?   ("http://www.mountwashington.org")

4) Are there guidelines for <sym>?  Tables for Magellan and Garmin would
   be helpful.

5) There is a reference a the elements in <gpx> that links to "Private
   elements" but there is no such tag on the page.   Is additional
   information on this available?


Additionally, this isn't strictly an GPX question, but I suspect this
group has experience on this subject.  Is there a table of "real
world" field sizes for the various makers of GPSRs available?  For
example, I've learned that Magellan supports 8 character waypoints
and 30 character descriptions in Magellan protocol but the NMEA
limits are 6 and 20.  (I've also learned that at least one well known
commercial program crashes when it gets waypoints from my 330 that have
descriptions longer than 20 bytes, so I suspect this is not exactly a
route well travelled.)  Similarly, are there published "best practices"
for adapting "portable" data for the various receivers?  "Truncate this
field from the right, preserving any trailing numeric data", etc.

Thanx for any help you can offer.

RJL

Re: [gpsxml] GPX 1.0 questions: time format, etc.

egroups+topografix.com on Fri Apr 05 06:07:16 2002 (link), replying to msg

Hello,

Thursday, April 04, 2002, 10:21:48 PM, Robert wrote:

RL> I've started an implementation of a program using GPX 1.0.  I intend to
RL> make it freely available.  Though I'm not a an XML jock, I have a few 
RL> questions and I hope you can help me capture the intent of GPX.

Keep us posted on your progress, Robert, and let us know if you run
into other areas of GPX that aren't sufficiently clear.

In general, GPX was designed with these goals in mind:
 - Easy to parse (only ONE way to represent things)
 - Easy for humans to read
 
RL> 1) <time> is specified as "conforming to ISO 8601" but that allows a 
RL>    plethora of potential encodings.  Is a conforming GPX reader expected
RL>    to handle any of them?  Could I get a clarification on the precise 
RL>    allowable members of this field?   Bonus points for providing suitable 
RL>    strftime (as in ISO/IEC 9899:1999) specifiers to make it completely 
RL>    unambiguous.

Re: GPX 1.0 questions: time format, etc.

robertlipe+yahoo.com on Fri Apr 05 11:29:01 2002 (link), replying to msg

Hello, Dan.  

Thanx for the reply.


> Keep us posted on your progress, Robert, and let us know if you run

I'm largely successfuly parsing the inputs.  I haven't started on the
output side yet.   It was interesting that I started laying out my
data structures before learning about GPX and had to make very few
changes to accomodate it.   I'll probably use it as my primary storage
format.

> In general, GPX was designed with these goals in mind:
>  - Easy to parse (only ONE way to represent things)
>  - Easy for humans to read

I'm appreciate both goals.

To go to your first point, could you distinguish why some of the
example fields are encoded as CDATA while others have the tag data
directly in the bodies?

The falls creek example contains:
 <sym>Dot</sym>
 <type><![CDATA[Intersection]]></type>
yet the spec doesn't distinguish those two tags in any way that I see
that allows the different content styles.   Perhaps this is one of
those things that's obvious to XML jocks in which case, please just
point me politly to an authoritative paper.

>  GPX 1.0 is more strict, and only allows two representations: ("Easy
 to Parse")

Do I need to file some kind of formal erratum to get the official
spec clarified, or are message like this enough?   Is there any kind
of revision scheme in place since we've just made an incompatible
change to "1.0" or is slipstreaming it accepted practice here?   (I
don't mind - I'm just trying to understand the guidelines.)

> 1. <time>2002-02-10T21:01:29.250Z</time>   (fractional seconds)
> 
> 2. <time>2002-02-10T21:01:29Z</time>       (no fractional seconds)

This, for example, should be spelled out in the spec, becuase I could
(and did!) fill that with an ISO 8601-compliant string that was
against the intent.   Spell it out very plainly.  Are leading zeros
required or optional?  Is 12-hour format with AM/PM ever acceptable,
etc.  (Don't answer the questions; fix the spec. :-) 

Similary, clarifying the meaning of the "T" and "Z" in your example
would be helpful.   To this moment, I don't know what they are.



> lat and lon are the correct tag names.  "latitude" and "longitude"
> aren't allowed.  The guiding rule was "choose a tag name that's long

OK, good.

> I've corrected the manual to remove references to "latitude" and
> "longitude".  Please excuse my earlier error.

I've been involved in specifications more complex than this one.  I
understand. :-)


> RL> 4) Are there guidelines for <sym>?  Tables for Magellan and 


> becomes a guessing game.  Even Garmin has trouble keeping the names
> straight - they've switched names on several GPS models, and their
> MapSource software doesn't always use the same names.

That's indeed the rub.   I was looking for tables from industry
leaders to help guide and normalize any output I may generate - after
all, avoiding yet MORE divergence in this area would be a Good Thing.

Magellan makes things even ickier by using different icon identifier
to token mappings in different models and even different f/w versions.

> EasyGPS includes the names for many brands of GPS.  You're welcome
to
> use those for reference.  As mentioned above, nobody does a perfect
> job with the names, but in places where two programs share the same
> name for a symbol, GPX will do the right thing.

I can't spot such a list at http://www.easygps.com/manual.asp.
Can you please provide a more precise reference?


> RL> 5) There is a reference a the elements in <gpx> that links to
"Private
> RL>    elements" but there is no such tag on the page.   Is
additional
> RL>    information on this available?
> 
> You can put any tags you want at the end of any element in GPX.  You
> need to provide your own schema for these tags.  You can look at the
> topografix or wissenbach private data for examples:

Interesting.   This would be good text to put in the dangling internal
href link to:
http://www.topografix.com/gpx_manual.asp#gpx_private
	
> RL> route well travelled.)  Similarly, are there published "best
practices"
> RL> for adapting "portable" data for the various receivers? 
"Truncate this

> It's more complicated than just data length, since each GPS model
> has it's own list of acceptable characters.  

Oh, there's a form of joy I wasn't even expecting.   Thanx for the
tip.

> Converting "+MyCar" (Magellan
> Meridian) to "MYCAR " (Garmin 38) is a difficult task.  My own
method
> is:
> 1. Remove all illegal characters.
> 2. Truncate to maximum length.

So you don't try to get clever with making "+mycarisa78pinto" from
"+mycarisa71mustang" into seperate names, just letting them collide
after you apply the heuristics above?

If it's a problem you haven't seen fit to solve, then I'll feel a lot
better about not worrying about it. :-)


> GPX doesn't impose any restrictions on data length or contents, so
"My
> very 1st waypoint with ASCII JunK!$#+$$$" is a valid waypoint name.
> It's up to your program to impose any restrictions before sending to
> a GPS.

I agree that "cleansing" the data at the edges is most appropriate.  I
was just looking for guidance on the mechanics of that cleansing since
I figured this crowd had dealt with those issues.

> Hope this helps!

Indeed it does.   Thanx very much!
robertlipe+usa.net


Re: GPX 1.0 questions: time format, etc.

davewissenbach+yahoo.com on Fri Apr 05 17:54:11 2002 (link), replying to msg

--- In gpsxml+y..., Robert Lipe <robertlipe+y...> wrote:
> Hello.
> 
> I've started an implementation of a program using GPX 1.0.  I 
intend to
> make it freely available. > 
> 2) By my reading, the example file is illegal.

...

> 
> 	http://groups.yahoo.com/group/gpsxml/files/Sample%20XML%
20Files/Kevin%20Read%20Untitled.gpx
> 
>
The required version attribute tells the story here.

<gpx version="0.2" ...

The released version is 1.0. That sample probably may not have been 
validated against the version 0.2 schema. There is a different 
schema for each version of the format. The schemaLocation should 
select a schema to match the version.

Protect your application against schema changes by ignoring unknown 
elements. Protect other applications from yours by validating test 
files from your application against the schema.

Regarding symbols.

Tough question. I've put the ones I use for the Garmin eTrex on my 
web page

http://www.cableone.net/cdwissenbach/map.html

> 
> RJL


Re: GPX 1.0 questions: time format, etc.

robertlipe+yahoo.com on Sat Apr 06 09:04:37 2002 (link), replying to msg

--- In gpsxml+y..., "davewissenbach" <davewissenbach+y...> wrote:
> --- In gpsxml+y..., Robert Lipe <robertlipe+y...> wrote:

> > 2) By my reading, the example file is illegal.
> 
> ...
> 
> > 	http://groups.yahoo.com/group/gpsxml/files/Sample%20XML%
> 20Files/Kevin%20Read%20Untitled.gpx
> > 
> >
> The required version attribute tells the story here.
> 
> <gpx version="0.2" ...
> 
> The released version is 1.0. That sample probably may not have been 

Aaaah.   I'd missed that detail.   Perhaps the samples in the 'files'
section of the yahoo group should be updated or at least more clearly
marked as being for a prototype version.

> validated against the version 0.2 schema. There is a different 
> schema for each version of the format. The schemaLocation should 
> select a schema to match the version.

Forgive my XML virginity here, but I don't know what a 'schema' is.
Just reading it, it appears somewhat like what we dinosaurs would call
a 'grammar'.  In 50 words are less, can anyone offer an explanation of
what a schema is and why we'd care? (References to books or URLs or
whatever are fine; I'm not expecting a free education here. :-)


> Tough question. I've put the ones I use for the Garmin eTrex on my 
> web page
> 
> http://www.cableone.net/cdwissenbach/map.html

Thanx for the reference.   There is a substantial overlap betweeen
this table and the five (grrrrr.) magellan tables.   There are some
gratituous differences, but since this would  ultimately fall into a
case insensitive table match anyway, I think I can handle this pretty
easily with just some slightly redundant table entries.   Besides, at
the end of the day if an icon gets an inexact translation, it's not a
traumatic event.  

This disucssion will help me honor the adage of:

"Be liberal in what you accept and conservative in what you
generate..."

Thanx!
RJL


Re: Java API for using XML Schema?

Helen+CastellarPelster.com on Mon Apr 08 01:46:06 2002 (link), replying to msg

Thor,

I have recently started using JAXB for another (unrelated) project.  
I've been very impressed so far.  There are a few little glitches, 
but no show-stoppers.  I'd like to see the GPX schema have a 
companion DTD for now...  there seem to still be a bunch of tools 
that only support DTDs.

I'll take a closer look at the schema when I get a chance - maybe it 
would be an easy conversion to a DTD.

-Helen


--- In gpsxml+y..., "ithork" <ithork+y...> wrote:
> Hi,
> 
> I was looking at delveloping a Java program that supports GPX 
> format.  I'm still learning about XML in general, but from what 
I've 
> read, JAXB looked like a good API for this.  Until, though, I 
noticed 
> that you guys were not using a DTD for this (JAXB v1.0 only 
supports 
> DTD right now).  Can anyone suggest an alternative Java API, or has 
> anyone written a DTD for GPX?
> 
> Thanks!
> Thor


Re: GPX 1.0 questions: time format, etc.

davewissenbach+yahoo.com on Tue Apr 09 22:17:40 2002 (link), replying to msg

--- In gpsxml+y..., "robertlipe" <robertlipe+y...> wrote:
> > 
> > The released version is 1.0. That sample probably may not have 
been 
> 
> Aaaah.   I'd missed that detail.   Perhaps the samples in 
the 'files'
> section of the yahoo group should be updated or at least more 
clearly
> marked as being for a prototype version.
> 

I've posted newer samples for GPX1.0 in the Files section.

> Forgive my XML virginity here, but I don't know what a 'schema' is.
> Just reading it, it appears somewhat like what we dinosaurs would 
call
> a 'grammar'.  In 50 words are less, can anyone offer an 
explanation of
> what a schema is and why we'd care? (References to books or URLs or
> whatever are fine; I'm not expecting a free education here. :-)
> 

An XML Schema is an XML document which defines the grammar for
an XML application such as GPS eXchange.

See the standard with supporting documentation at

http://www.w3.org/XML/Schema

I've bought two XML books so far:

XML In a Nutshell, O'REILLY, ISBN: 0-596-00058-8

and

Professional XML Schemas, WROX, ISBN: 1-861005-47-4

> 
> Thanx!
> RJL


Including app specific data in <gpx>

threadhead+mac.com on Sat Apr 13 11:35:11 2002 (link)

I am finish my app for doing some GPSR management and I 
would like to use the GPX format for saving all files. But I would 
like to include some application specific info (like window 
positions, preferences, etc.) in the <gpx>.

I couldn't file a spcification for private data in the GPX dev man. 
Where should it go? Or, is there no allowance for private data?

Karl



Re: Including app specific data in <gpx>

davewissenbach+yahoo.com on Sat Apr 13 15:08:03 2002 (link), replying to msg

--- In gpsxml+y..., "ThreadHead1" <threadhead+m...> wrote:
> I am finish my app for doing some GPSR management and I 
> would like to use the GPX format for saving all files. But I would 
> like to include some application specific info (like window 
> positions, preferences, etc.) in the <gpx>.
> 
> I couldn't file a spcification for private data in the GPX dev 
man. 
> Where should it go? Or, is there no allowance for private data?
> 
> Karl

There is a provision for private data. But shouldn't window 
positions and preferences go in the registry? (If this is a windows 
program).

Look at the Schema, url below:

http://www.topografix.com/GPX/1/0/gpx.xsd

Private data must be qualified in your namespace and can be
inserted into the document anywhere you see

<xsd:any namespace="##other" minOccurs="0" maxOccurs="unbounded" /> 

If you think that the rest of us might also eventually use this 
information then we should talk about creating a new version of the 
schema which allows this.

To validate that your application's output (and you should)conforms 
to the schema, you'll need your own auxiliary schema. You can see 
examples of how this is done in my samples at

http://www.cableone.net/cdwissenbach

<gpx
  xmlns="http://www.topografix.com/GPX/1/0"
  version="1.0" creator="Wissenbach Map 1.7"
  xmlns:wissenbach="http://www.cableone.net/cdwissenbach"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://www.topografix.com/GPX/1/0 
http://www.topografix.com/GPX/1/0/gpx.xsd 
http://www.cableone.net/cdwissenbach 
http://www.cableone.net/cdwissenbach/wissenbach.xsd">


The private schema is

http://www.cableone.net/cdwissenbach/

where I insert a <wissenbach:layer> tag to assign trails, routes and 
waypoints to a permanent layer or to a working layer. ExpertGPS uses 
the same technique to assign a color to tracks and routes. Notice 
the additional namespace declaration and the additional pair of URLs 
in the schemaLocation attribute to match the additional namespace to 
the schema for the private data.

You should be able to validate a sample document without complaint 
from the Zerces, or other schema-aware, validating parser.




Using GPX in USAPhotoMaps

lupitacox+yahoo.com on Mon Apr 22 18:49:28 2002 (link)

Thanks to TopoGrafix for starting this GPS data standard!
I was going to change the data file format in USAPhotoMaps to include 
more data, and the GPX standard looks like a great idea.

Doug Cox



Re: [gpsxml] Using GPX in USAPhotoMaps

egroups+topografix.com on Tue Apr 23 10:12:54 2002 (link), replying to msg

Hello,

Monday, April 22, 2002, 9:49:27 PM, Doug wrote:

l> Thanks to TopoGrafix for starting this GPS data standard!
l> I was going to change the data file format in USAPhotoMaps to include 
l> more data, and the GPX standard looks like a great idea.

  It's great to have you on board, Doug!  Let us know how your
  progress goes, and tell us if there's anything unclear about the
  standard or the documentation.

--
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com


More GPX publishing examples

egroups+topografix.com on Tue Apr 23 10:34:05 2002 (link), replying to msg

Hello,

  I've added some more examples of using GPX for publishing trail
  descriptions.

  This mountain biking site uses Active Server Pages to transform the
  GPX data on the server side, and deliver HTML to the web browser.
  It uses XSL to present several views of the GPX data.
  http://www.topografix.com/team/trails.asp

  One page filters the GPX data to just the waypoints, and then uses
  an HTML form to send the data to Kevin Read's GPX to Ozi Explorer
  converter.  Hopefully others will create some web-based converters
  for other data formats.


  My GPX trails page shows what you can do without using fancy
  scripting on the server side.  I used ExpertGPS to upload GPX data
  directly to my free website.
  http://home.attbi.com/~topografix/

  
-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com


Re: More GPX publishing examples

davewissenbach+yahoo.com on Tue Apr 23 19:41:16 2002 (link), replying to msg

--- In gpsxml+y..., Dan Foster <egroups+t...> wrote:
> Hello,
> 
>   I've added some more examples of using GPX for publishing trail
>   descriptions.
> 
...
> 
> 
>   My GPX trails page shows what you can do without using fancy
>   scripting on the server side.  I used ExpertGPS to upload GPX 
data
>   directly to my free website.
>   http://home.attbi.com/~topografix/
> 

I really like bicycling, so I appreciate the team Topografix bicycle 
trails pages. I never go anywhere without my GPS.

The really neat thing about the simple website is the usage of the 
map index page to index to the other trails pages! I'm going to copy 
this concept to create an index page for my own website.

The kayak trip is really neat. I know avid fishermen who are using 
their GPS receivers to mark fishing holes, and to gauge their 
progress on the river to watch out for the big rapids, and to make 
sure that they don't float too fast, wasting the day, or too slow, 
endangering themselves caught out after dark.

I may ask a couple of friends from work for text format output from 
their cereal box GPS programs to try to develop a few more 
stylesheets, time permitting.

You should cross-post the two sample trails URLs to the map_authors 
yahoo group as well!




Re: [gpsxml] More GPX publishing examples

gps_maps+yahoo.com on Wed Apr 24 05:11:04 2002 (link), replying to msg

All the examples I've seen lack richness.  I'm talking
about layout. Dan and Dave's examples read vertically,
from top to bottom using font and indention to set
apart content. What are the possibilities?  Can you
specifiy a background; include a picture, right margin
justified; use buttons, ... ?
I like the idea of using a standard file format, but
I'm not convinced that I should be using GPX showcase
file descriptions.  Currently, my plans are to link to
a GPX file from the description page as I have done at
www.travelbygps.com/guides/borrego/borrego.htm
Is this a good approach or am I still not "getting
it"?
, Doug




--- Dan Foster <egroups+topografix.com> wrote:
> Hello,
> 
>   I've added some more examples of using GPX for
> publishing trail
>   descriptions.
> 
>   This mountain biking site uses Active Server Pages
> to transform the
>   GPX data on the server side, and deliver HTML to
> the web browser.
>   It uses XSL to present several views of the GPX
> data.
>   http://www.topografix.com/team/trails.asp
> 
>   One page filters the GPX data to just the
> waypoints, and then uses
>   an HTML form to send the data to Kevin Read's GPX
> to Ozi Explorer
>   converter.  Hopefully others will create some
> web-based converters
>   for other data formats.
> 
> 
>   My GPX trails page shows what you can do without
> using fancy
>   scripting on the server side.  I used ExpertGPS to
> upload GPX data
>   directly to my free website.
>   http://home.attbi.com/~topografix/
> 
>   
> -- 
> Dan Foster
> TopoGrafix - GPS Software, Waypoints, and Maps
> http://www.topografix.com -
> mailto:egroups+topografix.com
> 
> 
> ------------------------ Yahoo! Groups Sponsor
> 
> To unsubscribe from this group, send an email to:
> gpsxml-unsubscribe+yahoogroups.com
> 
>  
> 
> Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/ 
> 
> 



__________________________________________________
Do You Yahoo!?
Yahoo! Games - play chess, backgammon, pool and more
http://games.yahoo.com/

Re: Using GPX in USAPhotoMaps

lupitacox+yahoo.com on Wed Apr 24 07:10:27 2002 (link), replying to msg

--- In gpsxml+y..., Dan Foster <egroups+t...> wrote:
>   It's great to have you on board, Doug!  Let us know how your
>   progress goes, and tell us if there's anything unclear about the
>   standard or the documentation.
> 
> --
> Dan Foster
> TopoGrafix - GPS Software, Waypoints, and Maps
> http://www.topografix.com - mailto:egroups+t...

The GPX standard covers all the waypoint data Magellan GPS
can send to a PC, but newer Garmins can send and receive
more data. I have an old Garmin Map12 (that only sends and
receives the basic data that a Magellan sends and receives),
so I don't really know if newer Garmins lose waypoint data
if you download it to a PC and then upload only the basic
waypoint data back. But if Garmins do lose data when it's
truncated in a GPX waypoint file and then sent back, then I
think the standard should be expanded. I realize this is a
judgment call, since even if some data was lost, it doesn't
look too necessary. Here's the Garmin waypoint data
structure for the newest Garmins:

    typedef 
struct                      /*                                 size */
        {
        byte            dtyp;           /* data packet type (0x01 for 
D109)1    */
        byte            wpt_class;      /* 
class                           1    */
        byte            dspl_color;     /* display & color (see 
below)     1    */
        byte            attr;           /* attributes (0x70 for 
D109)      1    */
        Symbol_Type     smbl;           /* waypoint 
symbol                 2    */
        byte            subclass[18];   /* 
subclass                        18   */
        Semicircle_Type posn;           /* 32 bit 
semicircle               8    */
        float           alt;            /* altitude in 
meters              4    */
        float           dpth;           /* depth in 
meters                 4    */
        float           dist;           /* proximity distance in 
meters    4    */
        char            state[2];       /* 
state                           2    */
        char            cc[2];          /* country 
code                    2    */
        longword        ete;            /* outbound link ete in 
seconds    4    */
    /*  char            ident[];           variable length 
string          1-51 */
    /*  char            comment[];         waypoint user 
comment           1-51 */
    /*  char            facility[];        facility 
name                   1-31 */
    /*  char            city[];            city 
name                       1-25 */
    /*  char            addr[];            address 
number                  1-51 */
    /*  char            cross_road[];      intersecting road 
label         1-51 */
        } D109_Wpt_Type;

All fields are defined the same as D108 except as noted below.

dtyp - Data packet type, must be 0x01 for D109.

dsp_color - The 'dspl_color' member contains three fields; bits 0-4 
specify
the color, bits 5-6 specify the waypoint display attribute and bit 7 
is unused
and must be 0. Color values are as specified for D108 except that the 
default
value is 0x1f. Display attribute values are as specified for D108.

attr - Attribute. Must be 0x70 for D109.

ete - Estimated time en route in seconds to next waypoint. Default 
value is
0xffffffff.




Wordwrap after 58 characters

lupitacox+yahoo.com on Wed Apr 24 07:25:18 2002 (link)

This group-posting software does an automatic wordwrap at
the end of the 58th character on a line, so everyone
writing a message here should write it in Notepad (or
whatever), and do a hard carriage return (press Enter)
before a word crosses that 58th character on a line (like
I'm doing).

Doug Cox



Re[2]: [gpsxml] More GPX publishing examples

egroups+topografix.com on Wed Apr 24 07:31:28 2002 (link), replying to msg

Hello,

Wednesday, April 24, 2002, 8:11:03 AM, Doug wrote:

DA> All the examples I've seen lack richness.  I'm talking
DA> about layout. Dan and Dave's examples read vertically,
DA> from top to bottom using font and indention to set
DA> apart content. What are the possibilities?  Can you
DA> specifiy a background; include a picture, right margin
DA> justified; use buttons, ... ?
DA> I like the idea of using a standard file format, but
DA> I'm not convinced that I should be using GPX showcase
DA> file descriptions.  Currently, my plans are to link to
DA> a GPX file from the description page as I have done at
DA> www.travelbygps.com/guides/borrego/borrego.htm
DA> Is this a good approach or am I still not "getting
DA> it"?

 The possibilities are endless...  Assuming you can figure out the
 XSL statements to use!

 Here's a general strategy for converting your HTML layout to GPX/XSL:

 Your website has a look.  On each page, the text changes, but
 certain things (background picture, fonts, margin sizes) remain the
 same.  Let's call the changing text "content", and the common style a
 "template".  The content for each page will live in a GPX file, and
 the common template will be an XSL file.  The XSL will display your
 HTML page, and insert pieces of GPX data as content.  (Think of the
 Mail Merge command in Microsoft Word...)

 The first thing to do is to strip away all the content and create a
 template with placeholders for the content.  For example, on the page
 you offered, "Anza-Borrego State Park" becomes [file-name], and
 "Most folks envision the desert as a wasteland..." becomes
 [file-description].  Do this for all the changing content on your
 page.

 Now look at the list of placeholders, and try to match them up with
 GPX tags:
 [file-name] = <gpx:name>
 [file-description] = <gpx:desc>
 [file-photo] = !!! doesn't exist in GPX !!!
 ...

 Notice that there's no way to specify a photo for the GPX file.
 If you can't include the picture information in the GPX file, you won't
 be able to use it as content on your page.  (This is different from
 including the same picture on every page - that's part of your
 template!)  You have three choices:
 1. Remove [file-photo] from your template.
 2. Create your own private GPX tag for [file-photo], and edit your
 GPX files by hand.
 3. Suggest to this group that we include a [file-photo] tag in the
 next version of GPX.

 Let's assume you chose option #1 for all placeholders that didn't
 match up with GPX tags.  You now have a list of GPX tags to insert in
 your XSL template.  Don't replace any yet.  XSL can be really
 difficult to debug when you make a mistake, so let's add the tags one
 at a time.

 First, start with an XSL document that only displays your stripped
 down template.  Here's mine:

saved as test.xsl:
<?xml version="1.0"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
  xmlns:gpx="http://www.topografix.com/GPX/1/0">
<xsl:template match="gpx:gpx">

<html>
<head>
<title>[file-title]</title>
</head>
<body>
<h2>[file-title]</h2>
<p>
[file-description]
</p>
</body>
</html>

</xsl:template>
</xsl:stylesheet>

Now let's replace the [file-title] placeholder with the <gpx:name>
tag:

saved as test.xsl:
<?xml version="1.0"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
  xmlns:gpx="http://www.topografix.com/GPX/1/0">
<xsl:template match="gpx:gpx">

<html>
<head>
<title><xsl:apply-templates select="gpx:name"/></title>
</head>
<body>
<h2><xsl:apply-templates select="gpx:name"/></h2>
<p>
[file-description]
</p>
</body>
</html>

</xsl:template>

<xsl:template match="gpx:name">
<xsl:value-of select="."/>
</xsl:template>

</xsl:stylesheet>

As you can see, I replaced all [file-title] placeholders with:
<xsl:apply-templates select="gpx:name"/>

and I added a new template:
<xsl:template match="gpx:name">
<xsl:value-of select="."/>
</xsl:template>

Keep doing that with all your placeholders, and you'll end up with
your finished XSL transform document to use with all your GPX files.

Here's the stripped-down sample GPX data I was using:
saved as borrego3.xml:
<?xml version="1.0" encoding="ISO-8859-1" standalone="yes"?>
<?xml-stylesheet type="text/xsl" href="test.xsl"?>
<gpx
 version="1.0"
 creator="ExpertGPS 1.1.1 - http://www.topografix.com"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xmlns="http://www.topografix.com/GPX/1/0"
 xmlns:topografix="http://www.topografix.com/GPX/Private/TopoGrafix/0/1"
 xsi:schemaLocation="http://www.topografix.com/GPX/1/0 http://www.topografix.com/GPX/1/0/gpx.xsd http://www.topografix.com/GPX/Private/TopoGrafix/0/1 http://www.topografix.com/GPX/Private/TopoGrafix/0/1/topografix.xsd">
<name><![CDATA[Anza-Borrego State Park]]></name>
<desc><![CDATA[Most folks envision the desert as a wasteland completely void of hospitable scenery and lacking in varied topography, but the quintessential picture of the Borrego Desert is a California Palm Oasis with the costal mountain range as backdrop. These palm oases are the object of a popular activity, called "oasis bagging." You drive for miles on jeep trails up arroyos and washes, get out and hike up canyons, then walk around to find the perfect location to photograph these desert rarities. Download this GPS Map to help you locate many of the Palm Oases and other points fo interest in the Borrego Dessert.
The Anza-Borrego State Park is located two hours east of San Diego. RVs pulling off-road vehicles are a common site along the routes between the desert and the population centers of southern California. Accommodations for RV camping are as plentiful and varied as the 4-wheel drive trails on which to ride. Likewise, other lodging facilities include budget motels, bed-and-breakfasts, and even a five-star hotel.
]]></desc>
</gpx>

This is just a basic example to get you started with XSL.  I didn't
attempt to describe what any of those XSL statements meant, because at
first, you won't care, and later, you'll use other people's examples
or Google or a book to figure things out.

XSL is tough stuff.  I'm still struggling to learn it, and I suspect
others are as well.  I'd be happy to host some sample XSL files on my
website if others want to contribute some tutorial snippets.  If
you have specific XSL questions, post them here, and someone may have
already figured out the answer.

Q. how do I turn <url> into a hyperlink?
A.
<xsl:template match="gpx:url">
<p>Related website:
 <xsl:text disable-output-escaping="yes"><a href="</xsl:text>
 <xsl:value-of select="."/>
 <xsl:text disable-output-escaping="yes">" target="_blank"></xsl:text>
 <xsl:value-of select="../gpx:urlname"/>
 <xsl:text disable-output-escaping="yes"></a> </xsl:text>
</p>
</xsl:template>

Good luck!

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com


Re: [gpsxml] Re: Using GPX in USAPhotoMaps

egroups+topografix.com on Wed Apr 24 08:02:08 2002 (link), replying to msg

Hello,

Wednesday, April 24, 2002, 10:08:44 AM, Doug wrote:

l> The GPX standard covers all the waypoint data Magellan GPS
l> can send to a PC, but newer Garmins can send and receive
l> more data. I have an old Garmin Map12 (that only sends and
l> receives the basic data that a Magellan sends and receives),
l> so I don't really know if newer Garmins lose waypoint data
l> if you download it to a PC and then upload only the basic
l> waypoint data back. But if Garmins do lose data when it's
l> truncated in a GPX waypoint file and then sent back, then I
l> think the standard should be expanded. I realize this is a
l> judgment call, since even if some data was lost, it doesn't
l> look too necessary.

Most of those data fields are used for specifying routes that contain
waypoints from aviation databases built into the GPS.  (Jeppesen data,
for example)  I've never seen a file format that included those data
elements.

I supply a custom version of EasyGPS to an aviation flight-planning
service.  We don't include any of the Garmin aviation fields in our
file exchange.

There are certainly some elements of the Garmin private data that
could be included in GPX.  <depth>120</depth> makes sense for
exchanging data between fish-finders.  <subclass>???</subclass>
doesn't make much sense outside of the Garmin world, though.
That's why you have the ability to define private data tags in GPX.


To answer your question about whether Garmins lose data, they don't.
What happens is that if you send the GPX-stripped version of an aviation
routepoint back to the GPS, it will create a user waypoint rather than
using the matching airport in the Jeppesen database.  So you end up
with one extra waypoint in memory.  Not a big issue for most people,
and pilots expect this when using 3rd party software.

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com


Re: Using GPX in USAPhotoMaps

lupitacox+yahoo.com on Wed Apr 24 09:55:53 2002 (link), replying to msg

--- In gpsxml+y..., Dan Foster <egroups+t...> wrote:
> Hello,
> 
> Most of those data fields are used for specifying routes that 
contain
> waypoints from aviation databases built into the GPS.  (Jeppesen 
data,
> for example)  I've never seen a file format that included those data
> elements.
> 
> I supply a custom version of EasyGPS to an aviation flight-planning
> service.  We don't include any of the Garmin aviation fields in our
> file exchange.
> 
> There are certainly some elements of the Garmin private data that
> could be included in GPX.  <depth>120</depth> makes sense for
> exchanging data between fish-finders.  <subclass>???</subclass>
> doesn't make much sense outside of the Garmin world, though.
> That's why you have the ability to define private data tags in GPX.
> 
> 
> To answer your question about whether Garmins lose data, they don't.
> What happens is that if you send the GPX-stripped version of an 
aviation
> routepoint back to the GPS, it will create a user waypoint rather 
than
> using the matching airport in the Jeppesen database.  So you end up
> with one extra waypoint in memory.  Not a big issue for most people,
> and pilots expect this when using 3rd party software.
> 
> -- 
> Dan Foster
> TopoGrafix - GPS Software, Waypoints, and Maps
> http://www.topografix.com - mailto:egroups+t...

Thanks a lot for the quick reply! That all sounds good to me!

Doug Cox


Re: Re[2]: [gpsxml] More GPX publishing examples

gps_maps+yahoo.com on Thu Apr 25 04:47:21 2002 (link), replying to msg

Wow.  Thanks for the detailed reply, Dan. This will
take some indigesting.
, Doug



  --- Dan Foster <egroups+topografix.com> wrote:
> Hello,
> 
> Wednesday, April 24, 2002, 8:11:03 AM, Doug wrote:
> 
> DA> All the examples I've seen lack richness.  I'm
> talking
> DA> about layout. Dan and Dave's examples read
> vertically,
> DA> from top to bottom using font and indention to
> set
> DA> apart content. What are the possibilities?  Can
> you
> DA> specifiy a background; include a picture, right
> margin
> DA> justified; use buttons, ... ?
> DA> I like the idea of using a standard file format,
> but
> DA> I'm not convinced that I should be using GPX
> showcase
> DA> file descriptions.  Currently, my plans are to
> link to
> DA> a GPX file from the description page as I have
> done at
> DA> www.travelbygps.com/guides/borrego/borrego.htm
> DA> Is this a good approach or am I still not
> "getting
> DA> it"?
> 
>  The possibilities are endless...  Assuming you can
> figure out the
>  XSL statements to use!
> 
>  Here's a general strategy for converting your HTML
> layout to GPX/XSL:
> 
>  Your website has a look.  On each page, the text
> changes, but
>  certain things (background picture, fonts, margin
> sizes) remain the
>  same.  Let's call the changing text "content", and
> the common style a
>  "template".  The content for each page will live in
> a GPX file, and
>  the common template will be an XSL file.  The XSL
> will display your
>  HTML page, and insert pieces of GPX data as
> content.  (Think of the
>  Mail Merge command in Microsoft Word...)
> 
>  The first thing to do is to strip away all the
> content and create a
>  template with placeholders for the content.  For
> example, on the page
>  you offered, "Anza-Borrego State Park" becomes
> [file-name], and
>  "Most folks envision the desert as a wasteland..."
> becomes
>  [file-description].  Do this for all the changing
> content on your
>  page.
> 
>  Now look at the list of placeholders, and try to
> match them up with
>  GPX tags:
>  [file-name] = <gpx:name>
>  [file-description] = <gpx:desc>
>  [file-photo] = !!! doesn't exist in GPX !!!
>  ...
> 
>  Notice that there's no way to specify a photo for
> the GPX file.
>  If you can't include the picture information in the
> GPX file, you won't
>  be able to use it as content on your page.  (This
> is different from
>  including the same picture on every page - that's
> part of your
>  template!)  You have three choices:
>  1. Remove [file-photo] from your template.
>  2. Create your own private GPX tag for
> [file-photo], and edit your
>  GPX files by hand.
>  3. Suggest to this group that we include a
> [file-photo] tag in the
>  next version of GPX.
> 
>  Let's assume you chose option #1 for all
> placeholders that didn't
>  match up with GPX tags.  You now have a list of GPX
> tags to insert in
>  your XSL template.  Don't replace any yet.  XSL can
> be really
>  difficult to debug when you make a mistake, so
> let's add the tags one
>  at a time.
> 
>  First, start with an XSL document that only
> displays your stripped
>  down template.  Here's mine:
> 
> saved as test.xsl:
> <?xml version="1.0"?>
> <xsl:stylesheet version="1.0"
> xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
>   xmlns:gpx="http://www.topografix.com/GPX/1/0">
> <xsl:template match="gpx:gpx">
> 
> <html>
> <head>
> <title>[file-title]</title>
> </head>
> <body>
> <h2>[file-title]</h2>
> <p>
> [file-description]
> </p>
> </body>
> </html>
> 
> </xsl:template>
> </xsl:stylesheet>
> 
> Now let's replace the [file-title] placeholder with
> the <gpx:name>
> tag:
> 
> saved as test.xsl:
> <?xml version="1.0"?>
> <xsl:stylesheet version="1.0"
> xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
>   xmlns:gpx="http://www.topografix.com/GPX/1/0">
> <xsl:template match="gpx:gpx">
> 
> <html>
> <head>
> <title><xsl:apply-templates
> select="gpx:name"/></title>
> </head>
> <body>
> <h2><xsl:apply-templates select="gpx:name"/></h2>
> <p>
> [file-description]
> </p>
> </body>
> </html>
> 
> </xsl:template>
> 
> <xsl:template match="gpx:name">
> <xsl:value-of select="."/>
> </xsl:template>
> 
> </xsl:stylesheet>
> 
> As you can see, I replaced all [file-title]
> placeholders with:
> <xsl:apply-templates select="gpx:name"/>
> 
> and I added a new template:
> <xsl:template match="gpx:name">
> <xsl:value-of select="."/>
> </xsl:template>
> 
> Keep doing that with all your placeholders, and
> you'll end up with
> your finished XSL transform document to use with all
> your GPX files.
> 
> Here's the stripped-down sample GPX data I was
> using:
> saved as borrego3.xml:
> <?xml version="1.0" encoding="ISO-8859-1"
> standalone="yes"?>
> <?xml-stylesheet type="text/xsl" href="test.xsl"?>
> <gpx
>  version="1.0"
>  creator="ExpertGPS 1.1.1 -
> http://www.topografix.com"
> 
>
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>  xmlns="http://www.topografix.com/GPX/1/0"
> 
>
xmlns:topografix="http://www.topografix.com/GPX/Private/TopoGrafix/0/1"
> 
>
xsi:schemaLocation="http://www.topografix.com/GPX/1/0
> http://www.topografix.com/GPX/1/0/gpx.xsd
> http://www.topografix.com/GPX/Private/TopoGrafix/0/1
>
http://www.topografix.com/GPX/Private/TopoGrafix/0/1/topografix.xsd">
> <name><![CDATA[Anza-Borrego State Park]]></name>
> <desc><![CDATA[Most folks envision the desert as a
> wasteland completely void of hospitable scenery and
> lacking in varied topography, but the quintessential
> picture of the Borrego Desert is a California Palm
> Oasis with the costal mountain range as backdrop.
> These palm oases are the object of a popular
> activity, called "oasis bagging." You drive for
> miles on jeep trails up arroyos and washes, get out
> and hike up canyons, then walk around to find the
> perfect location to photograph these desert
> rarities. Download this GPS Map to help you locate
> many of the Palm Oases and other points fo interest
> in 
=== message truncated ===


__________________________________________________
Do You Yahoo!?
Yahoo! Games - play chess, backgammon, pool and more
http://games.yahoo.com/

Re: XML Editor(?) - XMLSpy comments

Helen+CastellarPelster.com on Thu Apr 25 06:55:51 2002 (link), replying to msg

--- In gpsxml+y..., "davewissenbach" <davewissenbach+y...> wrote:
> --- In gpsxml+y..., "gps_maps" <gps_maps+y...> wrote:
> > It would be a cruel world without cordless screwdrivers, ATM 
> > machines, and wysiwyg HTML editors.  What do you use to edit your 
> > XML?  Please dont' tell me "notebook"!
> > , Doug
> 
> I rarely, if ever, edit .gpx files directly. But when I do, I use 
> wordpad to edit raw text. (I also ride a bicycle to work, every 
day, 
> rain or shine, cold or hot.)
> 
> You might visit
> 
> http://www.xslt.com
> 
> for a listing of stylesheet editors to transform xml documents. (I 
> even saw a stylesheet debugger there, visual XSTL). I tend to be 
> adverse to expensive new tools, although I do own a cordless 
> screwdriver!

Since I *love* expensve new tools, I do have XMLSpy (www.xmlspy.com), 
and use it a good deal.  However, I do walk to work, which gives you 
the idea that I use notepad or vi at least half the time for XML 
editing.

Here are my thoughts on XMLSpy: 

1.) It has very nice tools that can help you understand new schemas, 
such as a schema documentation generator and a handy feature 
called "Generate Sample XML".

2.) You get all the convenience of clicking on a button to check for 
well-formedness (is it legal XML?) and for validation (does it adhere 
to the schema?)

3.) It has many, many other features that you may never need to use.  
For example, it has a whole setup whereby you can define a "form" for 
editing a particular type of XML (say GPSXML...) and then an end-user 
can edit that XML via your form and the XMLSpy "Document Editor." 

4.) The XMLSpy Suite (includes everything, including the form and 
document editing described above) runs $400.  The XMLSpy IDE only 
runs $200 - this is the license that I bought.  That being said, 
unless you are designing schemas or working with new schemas often, I 
think that XMLSpy is overkill for just editing xml files.

Whew... posting this had made me think that I should consider finding 
a tool "lighter" than XMLSpy, but "heftier" than notepad.  OK, I have 
a team member working on editing some XML files today, I will have 
her try Xeena (http://www.alphaworks.ibm.com/tech/xeena) and report 
back!

Cheers,
Helen


GPX ate my CD!

egroups+topografix.com on Thu May 09 08:51:38 2002 (link), replying to msg

Hello GPX-ers,

Since there hasn't been much GPX discussion lately, I thought I'd pass
this on.  Any suggestions for her?   On a more serious note, any
suggestions for GPX 1.1?  Any progress on new GPX apps?

I received this GPX query in this morning's email.  For those of you
outside the US, GPX is a brand of cheap electronics sold at Kmart and
other stores.  It's also an XML data format, but apparently she missed
that part of the webpage...

Hello  I just recently purchased a GPX cd player, that played wonderful music
from radio to the cds the sound was beautiful.  I have only used it 6 times 
(I only have one cd so far) sinced I purchased it and lately the radio is 
playing but not the cd player it said it can't detect it, that there is no cd 
in there.  The purpose for buying the brand GPX was so that i could listen to 
music.  This has made me very upset, that your cd does not own up to the 
quality that you supposedli offered.  Please contact my ragarding this at 
name_removed_to_protect_the_ignorant+aol.com

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com


Re: [gpsxml] GPX ate my CD!

robertlipe+usa.net on Thu May 09 09:32:09 2002 (link), replying to msg

Dan Foster wrote:

>    Any suggestions for her?   

None that would be appropriate to share. :-)

>    any suggestions for GPX 1.1?

I've generally found GPX 1.0 to be expressive enough.  I don't know if
it's 1.1 material, but I've found it a bit clumsy that there are no
guidelines for <sym>.  Something as simple as "park" may be spelled
differently in the icon maps of various receivers and it's hard to do
a fuzzy match to get the mappings sane to go to a variety of targets.
"Red Buoy" may be expressible to one target but have to be truncated to
"Buoy" on another.

I've mentioned it before, but I think that nailing down the verbiage
on <time> would be helpful, too.  The 'T' and 'Z' in the example are
unspecified.

Additionally, I don't find the description of <number> to be adequate.

It's also not obvious (nor do I see it explained) why the file format
differentiates tracks and routes nor why trkpt, rtept, and waypt look to
overlap 100%.

Perhaps a few paragraphs of prose would help developers like me choose
the "right" tags for various data.  If it's not in the spec, that's
fine; just point us to it.

>    Any progress on new GPX apps?

I have two POSIX-ish programs in the oven that'll read or write GPX.
Both validate OK and are just waiting me to complete the "working" part
of the code.

A) I have a waypoint (and later, route) converting program.  It slurps
   up waypoints from one or more input files (magellan mapsend, gpsman, 
   gpsutil, magellan serial protocol, gpx, geocaching .loc, etc.) and 
   write them to one of the above.   (Sidebar to Dan, are the file 
   formats for Easy/Expert published?   Is this is a road I should go 
   down at all?)  I used libexpat to parse the XML.  Works under Linux, 
   OpenServer, and OpenUNIX.

B) I have another program in the works that I can't talk as much about
   (it's not mine; I'm just enhancing someone else's) that I've made
   emit GPX as a way of hooking it up to (A) above so I can get waypoints
   into my magellan. 
   
Developer quality source copies of (A) are available for the asking but
I'm not ready to unleash end-users onto it.

Happy travels.

RJL

GPX drag/drop and cut/copy/paste

egroups+topografix.com on Thu May 09 10:56:32 2002 (link), replying to msg

Hello,

 I recently added cut/copy/paste support to EasyGPS and ExpertGPS, and
 decided to implement it with GPX.  You can now copy waypoints,
 routes, or tracks out of EasyGPS and paste valid GPX data into any
 text editor, or into a form on a webpage (like Kevin's GPX->Ozi
 converter).  You can also paste GPX data directly into EasyGPS to add
 the GPS data to the file.  Drag and drop between apps works as well.

 For Windows programmers who might be interested: I'm writing the data
 to the clipboard as CF_TEXT and using delayed rendering.
 
 Beta versions are available at:
 http://www.easygps.com/beta.asp
 http://www.expertgps.com/beta.asp

 The beta builds have one major bug - they won't open the XML files
 created by geocaching.com.  Corrected builds will be posted by
 Saturday at the above URLs.
 
 I'll be travelling during the next two months and won't be
 contributing much to the discussion until late June.  Enjoy your
 break from me!
 
-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com


XML Waypoints for USAPhotoMaps

lupitacox+yahoo.com on Tue May 21 06:59:10 2002 (link)

They're almost done...

Doug Cox



Preview of 3D Viewer For GPX Files

davewissenbach+yahoo.com on Fri May 31 06:04:17 2002 (link)

I've got a Alpha version of terrain visualization added to 
Wissenbach Map. The program reads 7 1/2 minute, 30 Meter DEM files 
into memory and then renders triangles using OpenGL. Tracks, but not 
waypoints yet, are displayed over the terrain. This program is based 
on a viewer which I wrote for a graduate-level OpenGL programming 
class which I took by satellite link from F.S. Hill at the 
University of Massachusetts several years ago. I'll publish the 
source code after I make the program a bit more robust and add the 
GPL headers.

See

http://www.cableone.net/cdwissenbach/map.html

for a screen shot and setup program.


MapPoint & .gpx

donreith+rogers.com on Mon Jun 03 12:50:53 2002 (link)


Hi,
 
I'm new to this list. I'm a happy ExpertGPS user but want to be able to
exchange .gpx data with Microsoft MapPoint. I haven't found anything to
do this yet in my web travels so I've put this project onto my
programming to-do list. Before I start on this thing, which will
probably be a add-in for MapPoint, I thought I would check to see if
anyone is aware of an existing or soon-to-be existing solution for gpx
<-> MapPoint data exchange. I've checked out some of the MapPoint
communities ( <http://www.mp2kmag.com> www.mp2kmag.com,
<http://www.directionsmag.com> www.directionsmag.com) but gps, let alone
gpx, doesn't have a lot of visibility with MapPoint users. I guess there
is a lot of people using it to figure out where to build the next Taco
Bell or McDonalds..
 
Another item on my list is to add online browsing of the .gpx files that
I have posted on my website, building on the cool samples Dan has on his
site. Its been a good way to get up to speed on XSL, another item that's
been on my to-do list for a long time...
 
Don Reith
http://homepage.mac.com/donreith
 

------=_NextPart_000_002F_01C20B16.6FB341C0

RE: [gpsxml] MapPoint & .gpx

jeremy+groundspeak.com on Mon Jun 03 18:24:37 2002 (link), replying to msg


I've played with the com objects in MapPoint to generate maps on the
Geocaching.com site. The com objects are horribly enabled, most likely
due to M$ desire to cripple the application so people will use their new
.NET solution. Probably the best bet would be to have a conversion tool
from GPX to MapPoint files.
 
Jeremy
 
-----Original Message-----
From: Don Reith [mailto:donreith+rogers.com] 
Sent: Monday, June 03, 2002 12:50 PM
To: gpsxml+yahoogroups.com
Subject: [gpsxml] MapPoint & .gpx
 
Hi,
 
I'm new to this list. I'm a happy ExpertGPS user but want to be able to
exchange .gpx data with Microsoft MapPoint. I haven't found anything to
do this yet in my web travels so I've put this project onto my
programming to-do list. Before I start on this thing, which will
probably be a add-in for MapPoint, I thought I would check to see if
anyone is aware of an existing or soon-to-be existing solution for gpx
<-> MapPoint data exchange. I've checked out some of the MapPoint
communities ( <http://www.mp2kmag.com> www.mp2kmag.com,
<http://www.directionsmag.com> www.directionsmag.com) but gps, let alone
gpx, doesn't have a lot of visibility with MapPoint users. I guess there
is a lot of people using it to figure out where to build the next Taco
Bell or McDonalds..
 
Another item on my list is to add online browsing of the .gpx files that
I have posted on my website, building on the cool samples Dan has on his
site. Its been a good way to get up to speed on XSL, another item that's
been on my to-do list for a long time...
 
Don Reith
http://homepage.mac.com/donreith
 

To unsubscribe from this group, send an email to:
gpsxml-unsubscribe+yahoogroups.com



Your use of Yahoo! Groups is subject to the Yahoo!
<http://docs.yahoo.com/info/terms/>  Terms of Service. 

------=_NextPart_000_020B_01C20B2B.E8A54640

Re: [gpsxml] MapPoint & .gpx

robertlipe+usa.net on Mon Jun 03 18:52:23 2002 (link), replying to msg

Jeremy Irish wrote:

>    Probably the best bet would be to have a conversion tool from GPX
>    to MapPoint files.

I have a program in progress that reads and writes waypoints and routes
in arbitrary formats.  GPX is one of the formats.  I don't use (or
honestly, care much about) MapPoint but if anyone could provide me with
the file format documentation, a few sample files to work with, and so
on I'd take a stab at adding that back-end and sharing the code or work
with someone on adding such a back-end.

If the file format is at all sensible, it's probably under a hundred
lines of "real" code to slot it in. 

RJL

Re: [gpsxml] MapPoint & .gpx

blalor+yahoo.f6bdbf+ithacabands.org on Mon Jun 03 18:57:13 2002 (link), replying to msg

On Mon, 3 Jun 2002, Robert Lipe wrote:

> I have a program in progress that reads and writes waypoints and routes
> in arbitrary formats.� GPX is one of the formats.� I don't use (or

Will you be able to handle the MapSource formats?

--
      Brian Lalor                 |    http://introducingthelalors.org/
  blalor+ithacabands.org (email)  |  blalor+jabber.ithacabands.org (jabber)
                       N33�27.369' W111�56.304' (Earth)



RE: [gpsxml] MapPoint & .gpx

jeremy+groundspeak.com on Mon Jun 03 19:05:51 2002 (link), replying to msg

You can actually import all kinds of formats into MapPoint. Unless you
specifically want to generate maps (or have some automated tool),
there's no real point in working on something. Comma delimited works
fine.

Geobuddy.com is one such tool that does it already with the old .LOC
format we came up with. I know he's planning to upgrade it to support
GPX.

Jeremy

-----Original Message-----
From: Robert Lipe [mailto:robertlipe+usa.net] 
Sent: Monday, June 03, 2002 6:52 PM
To: gpsxml+yahoogroups.com
Subject: Re: [gpsxml] MapPoint & .gpx

Jeremy Irish wrote:

>    Probably the best bet would be to have a conversion tool from GPX
>    to MapPoint files.

I have a program in progress that reads and writes waypoints and routes
in arbitrary formats.  GPX is one of the formats.  I don't use (or
honestly, care much about) MapPoint but if anyone could provide me with
the file format documentation, a few sample files to work with, and so
on I'd take a stab at adding that back-end and sharing the code or work
with someone on adding such a back-end.

If the file format is at all sensible, it's probably under a hundred
lines of "real" code to slot it in. 

RJL


To unsubscribe from this group, send an email to:
gpsxml-unsubscribe+yahoogroups.com

 

Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/ 



Re: [gpsxml] MapPoint & .gpx

robertlipe+usa.net on Mon Jun 03 19:09:33 2002 (link), replying to msg

Brian Lalor wrote:
> 
>    On Mon, 3 Jun 2002, Robert Lipe wrote:
>    > I have a program in progress that reads and writes waypoints and
>    routes
>    > in arbitrary formats.  GPX is one of the formats.  I don't use (or
>    Will you be able to handle the MapSource formats?

Just a few hours ago, someone handed me a MapSource file.  I couldn't
find any documentation on the file format used and there were
some ambiguities in the sample file I got but it looked pretty
straightforward.  So I sketched in the code and am awaiting feedback
from the requester to see of MapSource will slurp up the results.  It
doesn't read the file yet, but it writes them.  84 lines of C.

I have a copy of mapsource on the way, but if you know of authoritative
documentation on the format that would greatly help that cause.


RJL

Re: [gpsxml] MapPoint & .gpx

robertlipe+usa.net on Mon Jun 03 19:15:10 2002 (link), replying to msg

Jeremy Irish wrote:

>    You can actually import all kinds of formats into MapPoint. Unless
>    you specifically want to generate maps (or have some automated
>    tool), there's no real point in working on something. Comma

Automatibilty is a specific goal of my program.  It reads and writes
files as directed via command line. No UI.

>    Geobuddy.com is one such tool that does it already with the old .LOC

It's not automatable, not cross-platform, and the author wouldn't make
source available.  But it surely does solve some problems for some
people.

Since I now recognize your name, I'll mention that my program reads and
writes the strain of waypointing XML used on your site, too. :-)

RJL

Re: MapPoint & .gpx

donreith+rogers.com on Wed Jun 05 15:51:56 2002 (link), replying to msg

I don't agree with the "horribly enabled" comment. Not that I'm a 
Microsoft cheerleader but MapPoint's object model, which has been 
updated for MapPoint 2002 by the way, is reasonably robust for what 
and doesn't get in the way for what I want to accomplish. The 
objects it exposes make sense if you are familiar with MapPoint, and 
it is relatively easy to use. I don't see any crippling there. The 
MapPoint web service, their .NET version of MapPoint, is also kinda 
interesting as well, something that I'm going to check out after 
this project. From a modern web architecture standpoint it makes 
sense; financially though it may be a different story.

Besides, if you have a choice between using an exposed and supported 
API that can get the job done, versus hacking into a private file 
format, a format that is likely to change in subsequent releases of 
the software, the pragmatic side of me thinks this is a no-brainer. 
Also, by pluging into the MapPoint UI you avoid having to go through 
a separate utility everytime you want to exchange data...

Don


--- In gpsxml+y..., "Jeremy Irish" <jeremy+g...> wrote:
> I've played with the com objects in MapPoint to generate maps on 
the
> Geocaching.com site. The com objects are horribly enabled, most 
likely
> due to M$ desire to cripple the application so people will use 
their new
> .NET solution. Probably the best bet would be to have a conversion 
tool
> from GPX to MapPoint files.
>  
> Jeremy



RE: [gpsxml] Re: MapPoint & .gpx

jeremy+groundspeak.com on Wed Jun 05 16:39:23 2002 (link), replying to msg

I'm curious. How much have you worked with the API? I'm currently using
2002. Try to:

1. Save a map to a filename (e.g. c:\mymap.jpg)
2. Look up an address, output lat/lon coordinates.
3. Look up and save 150 maps

If you have worked with the API, give me an idea what you've done with
your application and MapPoint. From my experience it has been horribly
crippled. It's probably pretty easy to prove me wrong.

Jeremy

-----Original Message-----
From: donreith [mailto:donreith+rogers.com] 
 
I don't agree with the "horribly enabled" comment. Not that I'm a 
Microsoft cheerleader but MapPoint's object model, which has been 
updated for MapPoint 2002 by the way, is reasonably robust for what 
and doesn't get in the way for what I want to accomplish. The 
objects it exposes make sense if you are familiar with MapPoint, and 
it is relatively easy to use. I don't see any crippling there.



Re: MapPoint & .gpx

donreith+rogers.com on Thu Jun 06 15:20:57 2002 (link), replying to msg

Well, as we've been doing different things we may both be right of 
our assessment of MapPoint's api. So far it has done what I've 
needed but we can't say the same for you :-). 

The outputting of lat/long is a headache. Apparantly MS cannot 
provide that functionality because of a licensing issue with the map 
data they use, or so I understand. Sounds a bit strange to me. 
However, there is a workaround that is documented here: 
http://www.mp2kmag.com/articles.asp?ArticleID=13

I haven't had to save maps to a file so I haven't looked into that. 
The absence of that functionality doesn't totally surprise me, as 
once you can do that you can more or less (mostly less, since its 
not a real server) use MapPoint to generate maps over the web, 
something MS would probably not be too happy about. The .NET version 
probably deals with this but I haven't looked into the 
cost/licensing of that version. I'm not optimistic about how 
accessible it will be for casual application use such as this.

For what I want to do in this project the api provides what is 
needed: 
 - convert waypoints into pushpins (no problem).
 - create a route in MapPoint out of the track/route data in the gpx 
problem (no problem), or perhaps just draw the route using the 
drawing tools in MP (haven't decided). One thing I am unsure of is 
how MP will react to a route with hundreds of waypoints. 

Don


--- In gpsxml+y..., "Jeremy Irish" <jeremy+g...> wrote:
> I'm curious. How much have you worked with the API? I'm currently 
using
> 2002. Try to:
> 
> 1. Save a map to a filename (e.g. c:\mymap.jpg)
> 2. Look up an address, output lat/lon coordinates.
> 3. Look up and save 150 maps
> 
> If you have worked with the API, give me an idea what you've done 
with
> your application and MapPoint. From my experience it has been 
horribly
> crippled. It's probably pretty easy to prove me wrong.
> 
> Jeremy


Re: Sequence numbers

donreith+rogers.com on Tue Jun 11 13:10:36 2002 (link), replying to msg

--- In gpsxml+y..., Dan Foster <egroups+t...> wrote:
> Hello Kevin,
> 
> Wednesday, February 06, 2002, 4:57:42 AM, you wrote:
> 
> KR> Strongly disagree
> 
> KR> I use XPATH extensively to manage waypoints.  Most of my XNL 
comes from
> KR> a native XML DB so I'm dealing with XML only not a prog 
specific class
> KR> that is loaded via XML.
> 
> KR> Sequencing is used to sort and re-order waypoints as well as 
routes and
> KR> tracks trather than manipulating the timestamp and modifying 
the base
> KR> data.
> 
> KR> For example:
> 
> KR> <.....  Sort-by='trk[seq] desc'>
> 
> KR> If I want to re-order a planned route all I need do is change 
the
> KR> sequence and viola.  Leaving the orginal track info intact so 
point to
> KR> point time caculations can still be made based on the orginal 
sequence.
> 
> KR> Seq - I'll be using it regardless, remember those of us using 
XSLT and
> KR> XML:DBs please
> 
> KR> Kevin
> 
> Does that mean you'll be producing XML files with out-of-order
> sequences?
> 
> Do you have any reply to my earlier statement that I can't 
correctly
> parse an out-of-order sequence?  (I assume this is the case for
> other apps as well.)
> 
> Since <seq> is optional, what do you do about all the files we're
> producing without <seq>?
> 
> <seq> isn't defined for waypoints.  I can see the usefulness of
> sorting a list of waypoints by various criteria (elevation,
> timestamp).  Other than reversing a route, why would you want to
> sort a route/track?
> 
> Can you make a small example GPX and XSLT file to demonstrate how
> you'd use <seq>?
> 
> -- 
> Dan Foster

Yeah, this is an ancient thread, but I didn't see a response, so 
here goes. 

I'm having a somewhat related problem right now: using XSLT I want 
to display the starting & ending waypoint of a route/track on the 
generated web page, something that is not too unreasonable. Having a 
sequence # would let me find these track elements easily using a 
filter or xsl:key. I'm currently thumbing through my xml references 
for an alternate solution to this, so speak up if you have any ideas.

Don




Re: MapPoint & .gpx

donreith+rogers.com on Tue Jun 11 13:21:56 2002 (link), replying to msg

--- In gpsxml+y..., Robert Lipe <robertlipe+u...> wrote:
> Brian Lalor wrote:
> > 
> >    On Mon, 3 Jun 2002, Robert Lipe wrote:
> >    > I have a program in progress that reads and writes 
waypoints and
> >    routes
> >    > in arbitrary formats.  GPX is one of the formats.  I don't 
use (or
> >    Will you be able to handle the MapSource formats?
> 
> Just a few hours ago, someone handed me a MapSource file.  I 
couldn't
> find any documentation on the file format used and there were
> some ambiguities in the sample file I got but it looked pretty
> straightforward.  So I sketched in the code and am awaiting 
feedback
> from the requester to see of MapSource will slurp up the results.  
It
> doesn't read the file yet, but it writes them.  84 lines of C.
> 
> I have a copy of mapsource on the way, but if you know of 
authoritative
> documentation on the format that would greatly help that cause.
> 
> 
> RJL

I would be interested to see how it deals with routes, as I believe 
that MapPoint only saves the starting & end point of the route. The 
actual route legs are calculated when the MapPoint file is opened.

Of course, the actual legs are also available using the API...

Don


Re: Sequence numbers

donreith+rogers.com on Tue Jun 11 16:10:24 2002 (link), replying to msg

> Yeah, this is an ancient thread, but I didn't see a response, so 
> here goes. 
> 
> I'm having a somewhat related problem right now: using XSLT I want 
> to display the starting & ending waypoint of a route/track on the 
> generated web page, something that is not too unreasonable. Having 
a 
> sequence # would let me find these track elements easily using a 
> filter or xsl:key. I'm currently thumbing through my xml 
references 
> for an alternate solution to this, so speak up if you have any 
ideas.
> 
> Don

Ignore my post. A little digging through my XSL reference unearthed 
a way to index into a element list.

Don



.xsl demonstrating extracting track waypoints

donreith+rogers.com on Tue Jun 11 19:09:08 2002 (link)


Attached to this message is a small .xsl file that demonstrates how to
access the first and last waypoint for each track in the .gpx file. It
also shows conditional output, sorting, and use of variables (more on
that below) in case you haven't played with those features.
 
It turns out the it was pretty simple to do reference specific trkpt
nodes, although I'm still having to do something that doesn't seem quite
right. 
 
Referencing the first trackpoint is easy:
 
     <xsl:apply-templates select="gpx:trkpt[1]"\>

Getting the last trackpoint should also be easy:

     <xsl:apply-templates select="gpx:trkpt[count(gpx:trkpt)]"/>

but I couldn't get this to work. However, if I do the count and put it
into a variable, then reference the variable, I get the desired result:

     <xsl:variable name="numtrkpt" select="count(gpx:trkpt)"/>

     <xsl:apply-templates select="gpx:trkpt[$numtrkpt]"/>
 
Perhaps the MSXML parser doesn't like a function inside the [ ]?

Don

 


------=_NextPart_001_005F_01C21194.99F075A0

Re: [gpsxml] .xsl demonstrating extracting track waypoints

blalor+yahoo.f6bdbf+ithacabands.org on Tue Jun 11 20:37:20 2002 (link), replying to msg

On Tue, 11 Jun 2002, Don Reith wrote:

> Referencing the first trackpoint is easy:
>  
>      <xsl:apply-templates select="gpx:trkpt[1]"\>
> 
> Getting the last trackpoint should also be easy:
> 
>      <xsl:apply-templates select="gpx:trkpt[count(gpx:trkpt)]"/>
> 
> but I couldn't get this to work. However, if I do the count and put it

Hrm. I've never worked with XSL before, so forgive my naivety.  Wouldn't 
the *first* element in a list be index zero, not one?  By that same 
rational, count(gpx:trkpt) would be one *past* the last element in the 
list.

--
      Brian Lalor                 |    http://introducingthelalors.org/
  blalor+ithacabands.org (email)  |  blalor+jabber.ithacabands.org (jabber)
                       N33�27.369' W111�56.304' (Earth)



Re: .xsl demonstrating extracting track waypoints

donreith+rogers.com on Wed Jun 12 04:23:08 2002 (link), replying to msg

> Hrm. I've never worked with XSL before, so forgive my naivety.  
Wouldn't 
> the *first* element in a list be index zero, not one?  By that 
same 
> rational, count(gpx:trkpt) would be one *past* the last element in 
the 
> list.
> 
> --
>       Brian Lalor                 |    
http://introducingthelalors.org/
>   blalor+i... (email)  |  blalor+j... (jabber)
>                        N33�27.369' W111�56.304' (Earth)

That's what I would have expected as well, but XSL ain't C. In XSL 
functions that operate on node sets, the first node in a list has 
position *1*.

Don


Re: [gpsxml] Re: MapPoint & .gpx

robertlipe+usa.net on Wed Jun 12 09:47:21 2002 (link), replying to msg

donreith wrote:

>    --- In gpsxml+y..., Robert Lipe <robertlipe+u...> wrote:
>
>    > Brian Lalor wrote:
>    >
>    > >    On Mon, 3 Jun 2002, Robert Lipe wrote:
>    > >
>    > >    > I have a program in progress that reads and writes
>    > >    > waypoints and routes in arbitrary formats.  GPX is one of
>    > >    > the formats.  I don't use (or
>    > >
>    > >    Will you be able to handle the MapSource formats?
>    >
>    > Just a few hours ago, someone handed me a MapSource file.  I
>    > couldn't find any documentation on the file format used and
>    > there were some ambiguities in the sample file I got but it
>    > looked pretty straightforward.  So I sketched in the code and am
>    > awaiting feedback from the requester to see of MapSource will
>    > slurp up the results.  It doesn't read the file yet, but it
>    > writes them.  84 lines of C.
>    >
>    > I have a copy of mapsource on the way, but if you know of
>    > authoritative documentation on the format that would greatly help
>    > that cause.
>
>    I would be interested to see how it deals with routes, as I
>    believe that MapPoint only saves the starting & end point of the
>    route. The actual route legs are calculated when the MapPoint file
>    is opened.  Of course, the actual legs are also available using

I think we have too many programs called mapSOMETHING. :-) Brian asked
about Garmin MapSource format, which I've not accomplished (sorta) via
providing PCX.  (I'm still looking for documentation on the "reaL'
mapsend .mps format.)

Your question seems to be about MapPoint which I know nothing about.

RJL

[ANN] pyGPX - python GPX library

blalor+yahoo.f6bdbf+ithacabands.org on Thu Jun 13 10:45:36 2002 (link)

I've whacked together a quick and dirty package[1] for reading and writing
GPX[2] files in python.  It is not feature complete and will allow you to
create GPX documents that will not validate.  The interface is clunky at
best, but I believe I've got the basic data structures down.  I encourage
you to take a look at it and add to it as you see fit!  Download it and 
take a look!

[1] http://ithacabands.org/~blalor/GPX/
[2] http://www.topografix.com/gpx.asp

Thanks,
B

--
      Brian Lalor                 |    http://introducingthelalors.org/
  blalor+ithacabands.org (email)  |  blalor+jabber.ithacabands.org (jabber)
                       N33�27.369' W111�56.304' (Earth)




Open Source C++ XML interface??

lemire1+attbi.com on Mon Jun 24 19:17:07 2002 (link)

Does anyone know if there exists an open source C++ class available that
would take an XML file (ideally using a standard like GPX) and upload it to
a Garmin unit?

I wrote a C++ application that parses HTML output from a mapping web site
like Maps On Us.  You build a route on the web site and save the source code
which has lattitude and longitude embedded for each waypoint in the route.
My app takes the HTML and constructs a csv file, passing it to Ron
Henderson's G7toW app which uploads it to a Garmin unit.

I'm trying to come up with a more elegant solution, including dynamic web
transactions, and at the same time I'd like to take advantage of XML
standards in whatever form they are available. XML would seem to make sense,
especially if source code is already available to do the translation between
XML and the various proprietary interface formats used by GPS units.  Code
developers could write any number of applications like mine for various
purposes that generate the same XML code, using these open source XML->GPS
interface classes.

The only things available I can find are EasyGps and ExpertGps which could
read in the XML files but this would mean using a two-step process.  I'd
prefer a more seamless approach by including the XML->GPS interface class
directly in my program.

There is also the Chaeron Java-based classes (ChaeronGPS) which would be
exactly what I want (http://www.chaeron.com/gps.html#JavaLibrary), but I'm
looking for something in C or C++ and think I'd prefer to use GPX instead of
GPSml which is what ChaeronGPS uses.

Does anyone have any suggesting?

Thanks very much!!

Mark Lemire (lemire1+attbi.com)


Re: [gpsxml] Open Source C++ XML interface??

davewissenbach+yahoo.com on Wed Jun 26 11:28:39 2002 (link), replying to msg

There isn't something packaged exactly the way that
you would like it. But as a starting point you might
look at the source code for my Mapping program which
does what you want, more or less. You'll just need to
discard the viewing code and keep the document
serialization code and GPS download. This works for
Garmin eTrex, and probably Garmin eMap, but you'll
need to modify this further if you're going to use
older Garmin units.

http://www.cableone.net/cdwissenbach/map.html

describes the program.

The source code for this MFC-based application is
zipped together as

http://www.cableone.net/cdwissenbach/MapSource.zip

--- lemire1 <lemire1+attbi.com> wrote:
> Does anyone know if there exists an open source C++
> class available that
> would take an XML file (ideally using a standard
> like GPX) and upload it to
> a Garmin unit?
> 
> I wrote a C++ application that parses HTML output
> from a mapping web site
> like Maps On Us.  You build a route on the web site
> and save the source code
> which has lattitude and longitude embedded for each
> waypoint in the route.
> My app takes the HTML and constructs a csv file,
> passing it to Ron
> Henderson's G7toW app which uploads it to a Garmin
> unit.
> 
> I'm trying to come up with a more elegant solution,
> including dynamic web
> transactions, and at the same time I'd like to take
> advantage of XML
> standards in whatever form they are available. XML
> would seem to make sense,
> especially if source code is already available to do
> the translation between
> XML and the various proprietary interface formats
> used by GPS units.  Code
> developers could write any number of applications
> like mine for various
> purposes that generate the same XML code, using
> these open source XML->GPS
> interface classes.
> 
> The only things available I can find are EasyGps and
> ExpertGps which could
> read in the XML files but this would mean using a
> two-step process.  I'd
> prefer a more seamless approach by including the
> XML->GPS interface class
> directly in my program.
> 
> There is also the Chaeron Java-based classes
> (ChaeronGPS) which would be
> exactly what I want
> (http://www.chaeron.com/gps.html#JavaLibrary), but
> I'm
> looking for something in C or C++ and think I'd
> prefer to use GPX instead of
> GPSml which is what ChaeronGPS uses.
> 
> Does anyone have any suggesting?
> 
> Thanks very much!!
> 
> Mark Lemire (lemire1+attbi.com)
> 
> 


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

Most famous site about GPS

amandapaixaom+yahoo.com.br on Sun Jun 30 10:44:45 2002 (link)


http://www.geocities.com/nineamf/index.html

---------------------------------
Yahoo! Encontros - O lugar certo para encontrar a sua alma g?a.
--0-25811992-1025459084=:14276

Site about GPS from Brasil

amandapaixaom+yahoo.com.br on Sun Jul 21 09:28:38 2002 (link)


http://www.geocities.com/zemaplata/index.html 

---------------------------------
Yahoo! Encontros - O lugar certo para encontrar a sua alma g?a.
--0-1342488013-1027268917=:20500

ANN: a GPX reader/writer.

robertlipe+usa.net on Mon Jul 29 21:46:44 2002 (link)


I'll give this group a little head start on a program I'm releasing in
the hopes that a group of programmers will be kinder to their own. :-)

GPS Babel is a free (in both senses) utlity to read and write waypoints
in a variety of forms.  GPX input and output works well.  Other backends
include Magellan serial protocol, Geocaching.com *.loc, GPSMan, Garmin
PCX5 for Mapsource, Magellan Mapsend, gpsutil, Census Bureau Tiger, and
CSV for S&A 9.

It works on POSIXy operating systems and is ISO C.  I've run it on
OpenUNIX 8, Solaris 8, UnixWare 7, OpenServer 5, Linux, and Cygwin.
(Non-Intel processors choke on Magellan's Mapsend files becuase of
silliness involving FP formats.) Ports to OSes that start with an "M"
are welcome as long as they don't gunk up the code too much.  Other
contributions or comments are similarly welcome.  The output validates
OK, and I've successfully interchanged data with EasyGPS, demos of
ExpertGPS.

The code seems solid enough and I've used it to process a few thousand
waypoints of differing kinds.  Things like doc, web pages, and such are
sort of shaky.  That's the only reason for the downgraded "sub 1.0"
version number.

It has a temporary home at:

	http://robertlipe.0catch.com/gpsbabel/index.html

I'll move it somewhere else within a few days.

RJL

Re: ANN: a GPX reader/writer.

davewissenbach+yahoo.com on Tue Jul 30 05:57:03 2002 (link), replying to msg

This is great. I downloaded this and noticed that you've published 
under the GPL. Maybe this fall I'll attempt to use this on Windows--
unless someone else does first. I don't have much spare time right 
now, or rather, I'm busy hiking and bicycling and don't spend too 
much time indoors.

One format that would be very useful is for National Geographic 
Topo. This program is being aggressively marketed and I think that 
we'll see output from this program everywhere.


--- In gpsxml+y..., Robert Lipe <robertlipe+u...> wrote:
> 
> I'll give this group a little head start on a program I'm 
releasing in
> the hopes that a group of programmers will be kinder to their 
own. :-)
> 
> GPS Babel is a free (in both senses) utlity to read and write 
waypoints
> in a variety of forms.  GPX input and output works well.  Other 
backends
> include Magellan serial protocol, Geocaching.com *.loc, GPSMan, 
Garmin
> PCX5 for Mapsource, Magellan Mapsend, gpsutil, Census Bureau 
Tiger, and
> CSV for S&A 9.
> 
> It works on POSIXy operating systems and is ISO C.  I've run it on
> OpenUNIX 8, Solaris 8, UnixWare 7, OpenServer 5, Linux, and Cygwin.
> (Non-Intel processors choke on Magellan's Mapsend files becuase of
> silliness involving FP formats.) Ports to OSes that start with 
an "M"
> are welcome as long as they don't gunk up the code too much.  Other
> contributions or comments are similarly welcome.  The output 
validates
> OK, and I've successfully interchanged data with EasyGPS, demos of
> ExpertGPS.
> 
> The code seems solid enough and I've used it to process a few 
thousand
> waypoints of differing kinds.  Things like doc, web pages, and 
such are
> sort of shaky.  That's the only reason for the downgraded "sub 1.0"
> version number.
> 
> It has a temporary home at:
> 
> 	http://robertlipe.0catch.com/gpsbabel/index.html
> 
> I'll move it somewhere else within a few days.
> 
> RJL


Re: [gpsxml] Re: ANN: a GPX reader/writer.

robertlipe+usa.net on Tue Jul 30 07:42:19 2002 (link), replying to msg

davewissenbach wrote:

>    This is great. 

Thank you.

>    I downloaded this and noticed that you've published under the GPL.

Since the problem i was trying to solve would have been less of a
problem if the various programs were Free Software, it would have been
wrong for me to solve the problem with anything else.

I thought it would be of special interest to this groups since it
includes an example of using expat to process GPX and it makes a
reasonable "stepping stone" since I think most of us are using GPX AND
something else.

>    Maybe this fall I'll attempt to use this on Windows--
>    unless someone else does first. 

I verified it builds and passes the testsuite under Cygwin but don't
know if that really is an an "acceptable" approach for someone that
actually likes to use Windows.

>    One format that would be very useful is for National Geographic
>    Topo. This program is being aggressively marketed and I think that
>    we'll see output from this program everywhere.

Is the file format documented?  If it's a sensible format at all, a
backend can probably be slotted in in about an hour.

RJL

Re: [gpsxml] Re: ANN: a GPX reader/writer.

polt+snaptek.com on Tue Jul 30 10:53:54 2002 (link)

i have all ready reversed engineered the TOPO format and garmins 
MAPSOURCE file formats.  i use those programs the most myself and wanted 
to be able to use them for my geocaching site.

TOPO actually uses bilinear interpolation which was quite a pain... but 
i got a little help from one of the engineers in the right direction.

if you want to take a look at what my code outputs get and idea take a 
look at my site http://www.azgeocaching.com

if ya would like i could help contribute the code to the project...
it is in php right now...

jason poulter



davewissenbach wrote:
> This is great. I downloaded this and noticed that you've published
> under the GPL. Maybe this fall I'll attempt to use this on Windows--
> unless someone else does first. I don't have much spare time right
> now, or rather, I'm busy hiking and bicycling and don't spend too
> much time indoors.
> 
> One format that would be very useful is for National Geographic
> Topo. This program is being aggressively marketed and I think that
> we'll see output from this program everywhere.
> 
> 
> --- In gpsxml+y..., Robert Lipe <robertlipe+u...> wrote:
>  >
>  > I'll give this group a little head start on a program I'm
> releasing in
>  > the hopes that a group of programmers will be kinder to their
> own. :-)
>  >
>  > GPS Babel is a free (in both senses) utlity to read and write
> waypoints
>  > in a variety of forms.  GPX input and output works well.  Other
> backends
>  > include Magellan serial protocol, Geocaching.com *.loc, GPSMan,
> Garmin
>  > PCX5 for Mapsource, Magellan Mapsend, gpsutil, Census Bureau
> Tiger, and
>  > CSV for S&A 9.
>  >
>  > It works on POSIXy operating systems and is ISO C.  I've run it on
>  > OpenUNIX 8, Solaris 8, UnixWare 7, OpenServer 5, Linux, and Cygwin.
>  > (Non-Intel processors choke on Magellan's Mapsend files becuase of
>  > silliness involving FP formats.) Ports to OSes that start with
> an "M"
>  > are welcome as long as they don't gunk up the code too much.  Other
>  > contributions or comments are similarly welcome.  The output
> validates
>  > OK, and I've successfully interchanged data with EasyGPS, demos of
>  > ExpertGPS.
>  >
>  > The code seems solid enough and I've used it to process a few
> thousand
>  > waypoints of differing kinds.  Things like doc, web pages, and
> such are
>  > sort of shaky.  That's the only reason for the downgraded "sub 1.0"
>  > version number.
>  >
>  > It has a temporary home at:
>  >
>  >       http://robertlipe.0catch.com/gpsbabel/index.html
>  >
>  > I'll move it somewhere else within a few days.
>  >
>  > RJL
> 
> 
> *Yahoo! Groups Sponsor*
> Click here to visit our exclusive feature of ACUVUE2 Colours at 
> LensExpress.com!
> Click here to find your contact lenses!
> 
> <http://rd.yahoo.com/M=225674.2075965.3644786.1829184/D=egroupweb/S=1706030390:HM/A=1153156/R=0/*http://www.lensexpress.com/tracker/trackclick.aspx?Page=ACUVUE%202%20Colors&AffUrl=273&AffCode=14> 
> 
> 
> 
> To unsubscribe from this group, send an email to:
> gpsxml-unsubscribe+yahoogroups.com
> 
> 
> 
> Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service 
> <http://docs.yahoo.com/info/terms/>.


Re: [gpsxml] Re: ANN: a GPX reader/writer.

joel+coastaloutdoors.com on Tue Jul 30 11:17:44 2002 (link)


Jason:

I could really use that code in php.  I'm trying to put together a page where folks can input their waypoints and download their waypoints now.  That input/output should be converted to EasyGPS so they can use Dan's program to upload/download to their GPS.  That would sure save a lot of time.

Thanks in advance,

Joel E. Williams, Jr.
www.coastaloutdoors.com

  ----- Original Message ----- 
  From: Jason Poulter 
  To: gpsxml+yahoogroups.com 
  Sent: Tuesday, July 30, 2002 1:53 PM
  Subject: Re: [gpsxml] Re: ANN: a GPX reader/writer.


  i have all ready reversed engineered the TOPO format and garmins 
  MAPSOURCE file formats.  i use those programs the most myself and wanted 
  to be able to use them for my geocaching site.

  TOPO actually uses bilinear interpolation which was quite a pain... but 
  i got a little help from one of the engineers in the right direction.

  if you want to take a look at what my code outputs get and idea take a 
  look at my site http://www.azgeocaching.com

  if ya would like i could help contribute the code to the project...
  it is in php right now...

  jason poulter



  davewissenbach wrote:
  > This is great. I downloaded this and noticed that you've published
  > under the GPL. Maybe this fall I'll attempt to use this on Windows--
  > unless someone else does first. I don't have much spare time right
  > now, or rather, I'm busy hiking and bicycling and don't spend too
  > much time indoors.
  > 
  > One format that would be very useful is for National Geographic
  > Topo. This program is being aggressively marketed and I think that
  > we'll see output from this program everywhere.
  > 
  > 
  > --- In gpsxml+y..., Robert Lipe <robertlipe+u...> wrote:
  >  >
  >  > I'll give this group a little head start on a program I'm
  > releasing in
  >  > the hopes that a group of programmers will be kinder to their
  > own. :-)
  >  >
  >  > GPS Babel is a free (in both senses) utlity to read and write
  > waypoints
  >  > in a variety of forms.  GPX input and output works well.  Other
  > backends
  >  > include Magellan serial protocol, Geocaching.com *.loc, GPSMan,
  > Garmin
  >  > PCX5 for Mapsource, Magellan Mapsend, gpsutil, Census Bureau
  > Tiger, and
  >  > CSV for S&A 9.
  >  >
  >  > It works on POSIXy operating systems and is ISO C.  I've run it on
  >  > OpenUNIX 8, Solaris 8, UnixWare 7, OpenServer 5, Linux, and Cygwin.
  >  > (Non-Intel processors choke on Magellan's Mapsend files becuase of
  >  > silliness involving FP formats.) Ports to OSes that start with
  > an "M"
  >  > are welcome as long as they don't gunk up the code too much.  Other
  >  > contributions or comments are similarly welcome.  The output
  > validates
  >  > OK, and I've successfully interchanged data with EasyGPS, demos of
  >  > ExpertGPS.
  >  >
  >  > The code seems solid enough and I've used it to process a few
  > thousand
  >  > waypoints of differing kinds.  Things like doc, web pages, and
  > such are
  >  > sort of shaky.  That's the only reason for the downgraded "sub 1.0"
  >  > version number.
  >  >
  >  > It has a temporary home at:
  >  >
  >  >       http://robertlipe.0catch.com/gpsbabel/index.html
  >  >
  >  > I'll move it somewhere else within a few days.
  >  >
  >  > RJL
  > 
  > 
  > *Yahoo! Groups Sponsor*
  > Click here to visit our exclusive feature of ACUVUE2 Colours at 
  > LensExpress.com!
  > Click here to find your contact lenses!
  > 
  > <http://rd.yahoo.com/M=225674.2075965.3644786.1829184/D=egroupweb/S=1706030390:HM/A=1153156/R=0/*http://www.lensexpress.com/tracker/trackclick.aspx?Page=ACUVUE%202%20Colors&AffUrl=273&AffCode=14> 
  > 
  > 
  > 
  > To unsubscribe from this group, send an email to:
  > gpsxml-unsubscribe+yahoogroups.com
  > 
  > 
  > 
  > Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service 
  > <http://docs.yahoo.com/info/terms/>.


        Yahoo! Groups Sponsor 
              ADVERTISEMENT
             
       

  To unsubscribe from this group, send an email to:
  gpsxml-unsubscribe+yahoogroups.com



  Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. 


------?extPart_000_0070_01C237D4.1181AA20

Re: [gpsxml] Re: ANN: a GPX reader/writer.

robertlipe+usa.net on Tue Jul 30 11:37:44 2002 (link), replying to msg

Jason Poulter wrote:

>    i have all ready reversed engineered the TOPO format and garmins
>    MAPSOURCE file formats.  i use those programs the most myself and

If you can provide doc or sample code (I can read most languages, but
might need help with some details) I'd be very interested in Mapsource
format.

>    look at my site [1]http://www.azgeocaching.com

Seeet.

>    if ya would like i could help contribute the code to the project...
>    it is in php right now...

Bring it on!

I'll have this on Sourceforge in the next couple of days.  

RJL

GPS Utility now imports/exports GPX files

murphy+enterprise.net on Wed Jul 31 00:27:29 2002 (link), replying to msg

This is just to let you folks know that there is now a Beta Test
version of "GPS Utility" (4.10.e) which imports/exports GPX files at:
http://www.gpsutility.co.uk/files/gpsu410e.zip

You need to download this, unzip and manually install in the existing
GPSU program installation directory - probably "C:/Program Files/GPS
Utility"  (so you will need to download and install the standard
version first (4.04.3)).

I have not yet implemented every field type, so there will be some
transfer limitations.  I have tested it against EasyGPS and Wissenbach
Map and this seems to work OK, but there could be the odd bug lying
around.  However it should allow the interchange of some GPS data
between GPX applications and the other file formats supported by GPSU.

Please let me know by direct email of any problems/shortcomings etc.
as I don't check the newsgroup that often. 

Cheers,

Alan Murphy  (author GPSU) 

http://www.gpsu.co.uk/
at approx N50�53.8' W001�23.2' 

Topo! file format

egroups+topografix.com on Wed Jul 31 07:12:24 2002 (link), replying to msg

Hello,

Tuesday, July 30, 2002, 8:03:01 PM, Troy wrote:

TH> I agree that TOPO! is an important format to support. I find topo files everywhere and rarely see anything else. The biggest challenge here is .tpo files as they're a proprietary binary format. 

TH> .tpg files aren't that tough, but if any of you have figured out how to convert routes from a .tpo file to .gpx, I'd love to hear about it.

TH> Troy

Let them know you want an XML file format for import/export:
http://maps.nationalgeographic.com/ngmaps/contact.cfm?topocontact=yes

I just wrote them a nice email asking them to support some form of XML
for file interchange.  If enough of their users write to them, they'll
take notice.  Take 5 minutes and send them a note.

I've looked at the .tpo file format, and it's ugly.  I suspect it
changes from release to release, but don't have any proof of that.
.tpg is the way to go, but apparently they've dropped support for .tpg
in their new Topo!Sync program.

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com


Documenting file formats

egroups+topografix.com on Wed Jul 31 07:29:30 2002 (link), replying to msg

Hello,

Tuesday, July 30, 2002, 1:53:28 PM, Jason wrote:
JP> i have all ready reversed engineered the TOPO format and garmins
JP> MAPSOURCE file formats.  i use those programs the most myself and wanted 
JP> to be able to use them for my geocaching site.

and then on Tuesday, July 30, 2002, 2:37:41 PM, Robert wrote:
RL> If you can provide doc or sample code (I can read most languages, but
RL> might need help with some details) I'd be very interested in Mapsource
RL> format.

Since there seem to be a number of us working on import/export of
various file formats, and since we are working on many different
platforms (Palm, Linux, Windows, Mac...) and in many different languages
(PHP, ASP, C...) I'd like to join Robert in asking for a sharing of
knowledge.  Source code is good, but documentation of the file format
is probably more useful since we've all got different programming
requirements and backgrounds.  I'd like to propose that we write up
some quick descriptions of the file formats we know and put them up on
the web "for the benefit of humanity".  I can contribute Topo! .tpg
and MapTech .mxf, and maybe some others.

I'll offer to host some of the files on my website, but due to DMCA
nonsense, I'd suggest that file formats with even the most basic of
"encryption" be kept on servers outside the US.  Any volunteers from
saner nations?

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com


Re: [gpsxml] Documenting file formats

polt+snaptek.com on Wed Jul 31 12:31:28 2002 (link)

ya that sounds like a good idea... i will write up the file description 
for TOPO and MAPSOURCE....

Dan I did notice that your TOPO algorithm is a little bit off... you 
loose a couple of digits of precision in your conversion... with a 
little help from one of the engineers and National Geographic I was able 
to get my algorithm, to what i've tested, actually match theirs... 
havent heard any complaints from my users about it being bad either.

so we might want to go with mine, or merge the two or something?

Dan where should we send them? to your email?


jason poulter

Dan Foster wrote:
> Hello,
> 
> Tuesday, July 30, 2002, 1:53:28 PM, Jason wrote:
> JP> i have all ready reversed engineered the TOPO format and garmins
> JP> MAPSOURCE file formats.  i use those programs the most myself and 
> wanted
> JP> to be able to use them for my geocaching site.
> 
> and then on Tuesday, July 30, 2002, 2:37:41 PM, Robert wrote:
> RL> If you can provide doc or sample code (I can read most languages, but
> RL> might need help with some details) I'd be very interested in Mapsource
> RL> format.
> 
> Since there seem to be a number of us working on import/export of
> various file formats, and since we are working on many different
> platforms (Palm, Linux, Windows, Mac...) and in many different languages
> (PHP, ASP, C...) I'd like to join Robert in asking for a sharing of
> knowledge.  Source code is good, but documentation of the file format
> is probably more useful since we've all got different programming
> requirements and backgrounds.  I'd like to propose that we write up
> some quick descriptions of the file formats we know and put them up on
> the web "for the benefit of humanity".  I can contribute Topo! .tpg
> and MapTech .mxf, and maybe some others.
> 
> I'll offer to host some of the files on my website, but due to DMCA
> nonsense, I'd suggest that file formats with even the most basic of
> "encryption" be kept on servers outside the US.  Any volunteers from
> saner nations?
> 
> -- 
> Dan Foster
> TopoGrafix - GPS Software, Waypoints, and Maps
> http://www.topografix.com - mailto:egroups+topografix.com
> 
> 
> *Yahoo! Groups Sponsor*
> ADVERTISEMENT
> <http://rd.yahoo.com/M=231049.2206939.3660593.1971030/D=egroupweb/S=1706030390:HM/A=1175203/R=0/*http://www.gotomypc.com/u/tr/yh/grp/300_06/g22lp?Target=mm/g22lp.tmpl>
> 
> 
> To unsubscribe from this group, send an email to:
> gpsxml-unsubscribe+yahoogroups.com
> 
> 
> 
> Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service 
> <http://docs.yahoo.com/info/terms/>.


Re[2]: [gpsxml] Documenting file formats

egroups+topografix.com on Wed Jul 31 14:23:48 2002 (link), replying to msg

Hello Jason,

Wednesday, July 31, 2002, 3:31:24 PM, you wrote:

JP> ya that sounds like a good idea... i will write up the file description 
JP> for TOPO and MAPSOURCE....

JP> Dan I did notice that your TOPO algorithm is a little bit off... you 
JP> loose a couple of digits of precision in your conversion... with a 
JP> little help from one of the engineers and National Geographic I was able 
JP> to get my algorithm, to what i've tested, actually match theirs... 
JP> havent heard any complaints from my users about it being bad either.

JP> so we might want to go with mine, or merge the two or something?

I'll be interested to see how yours works.  It's been a few years
since I wrote mine, so perhaps it needs an update.

JP> Dan where should we send them? to your email?

You can send them to this email address: egroups+topografix.com

Robert already sent me links to several formats - I'm quoting his
email below.  I'll throw together a webpage to hold all this sometime
next week.

Re: ANN: a GPX reader/writer.

robertlipe+usa.net on Tue Aug 06 21:56:36 2002 (link), replying to msg

Robert Lipe wrote:

> GPS Babel is a free (in both senses) utlity to read and write waypoints
> in a variety of forms.  GPX input and output works well.  Other backends
> include Magellan serial protocol, Geocaching.com *.loc, GPSMan, Garmin
> PCX5 for Mapsource, Magellan Mapsend, gpsutil, Census Bureau Tiger, and
> CSV for S&A 9.

[ blah blah blah ] 

> It has a temporary home at:

It now has a permanent home.  (Well, as permanent as anything gets on
the web.)  It will disappear from the temporary location in coming days.

Dan, please add GPSBabel at

	http://gpsbabel.sourceforge.net/

to the list of programs that read and write GPX.


Enjoy.
RJL

New Garmin Rino GPS yahoo group!

misbach+yahoo.com on Fri Aug 09 22:45:43 2002 (link)

GPS Users,
 
I just created a new Yahoo group for the new Garmin Rino.  If you 
have not heard or read about this new GPS device you are missing 
out.  The Garmin Rino is the first GPS device to have a GMRS/FRS 
radio integrated into it. It also is the first GPS device to support 
the Peer-to-Peer Positioning, this patented technology makes it 
possible to transmit your location to a friend or family member. 

What really separates the Rino from the rest of the FRS herd is the 
ability to "beam" your exact location to another Rino user within a 
two-mile range using the FRS spectrum. 

Even if you don't have a Garmin Rino I think you will find this group 
useful and informative.
 
To go to the website or subscribe to the new yahoo group use the 
information below.
 
Website: http://groups.yahoo.com/group/garmin-rino 
To Subscribe:  garmin-rino-subscribe+yahoogroups.com 

Thanks!
 
Matt
 
P.S. I've already got lots of links, files, pictures, calendar items, 
and polls at the new Yahoo group website.  It's going to be a great 
group for all GPS users.


Looking for guidance on how to incorporate extensions to GPX

fouts+fogey.com on Sat Aug 10 14:00:33 2002 (link)

Background:

www.geocaching.com maintains a data base of geocaches. An entry in the data
base is sort of a waypoint, but with a lot of additional information. This
additional information includes such things as a description of the geocache
and logs people enter to describe their attempts to find the cache.

Members of www.geocaching.com can search the database using a feature called
"pocket query". In response to the query, the web site will email a reply
containing those entries that match the search criteria. The web site makes
information available in .loc files so that people can download it into GPS
receivers, and it also makes the additional information available as an
Ebook for people to download to PDAs. They are currently developing an
extension to GPX format to make this additional information available in an
XML format.

You can see an example of a preliminary version of the GPX/geocache
extension at http://www.geocaching.com/media/example.gpx

This extension is being discussed in the geocaching forum, and in the
discussion, two questions have come up that, in my opinion, are general to
the idea of extending GPX, so I thought I'd raise them in this forum.

The Questions:

1) If you examine the example file, you will see that all of the
geocaching.com extension are in a separate 'groundspeak' namespace. This
leads to what I hope will be the easy question: Should this be a recommended
practice for adding extensions to GPX?

I think this is a good thing because it reduces the likelihood of extension
name collision and makes it easier to track extensions back to their source
and to use multiple extension sets in the same GPX file.

I'm curious what other people think.

2) In response to some requests for additions to the extension, Jeremy Irish
is proposing adding some redundant information like lat/long to the
extension. I believe the reasoning has to do with how the xsd for the
extension will be built. (My apologies to Jeremy if I misunderstand.) His
comment in the forum was

     Yes. I'll have an xsd available for it, I suspect. Which means I'll
probably have to add
     redundant information like lat/lon so if the namespace is used alone,
the Groundspeak
     format can be decoded and used.

from the point of view of a software purist, such redundant information is a
Bad Thing (r) but I don't know enough about XML to understand whether the
reasoning should apply here.

Anyway, the question here is: if a datum is an element of the base GPX
specification, should that element be duplicated in an extension?

My own opinion is that no, it shouldn't, because it's an opportunity for
having two watches and never knowing what time it is.

Marty



Re: [gpsxml] Looking for guidance on how to incorporate extensions to GPX

egroups+topografix.com on Mon Aug 12 04:59:59 2002 (link), replying to msg

Hello,

Saturday, August 10, 2002, 5:05:54 PM, Marty wrote:

M> Background:

M> www.geocaching.com maintains a data base of geocaches.
M> They are currently developing an
M> extension to GPX format to make this additional information available in an
M> XML format.

M> You can see an example of a preliminary version of the GPX/geocache
M> extension at http://www.geocaching.com/media/example.gpx

M> This extension is being discussed in the geocaching forum, and in the
M> discussion, two questions have come up that, in my opinion, are general to
M> the idea of extending GPX, so I thought I'd raise them in this forum.

M> The Questions:

M> 1) If you examine the example file, you will see that all of the
M> geocaching.com extension are in a separate 'groundspeak' namespace. This
M> leads to what I hope will be the easy question: Should this be a recommended
M> practice for adding extensions to GPX?

Yes.  This is the required practice for adding private extensions to
GPX.  I'm using topografix:foo for my private extensions, and Dave
Wissenbach is using wissenbach:foo for his private extensions.  As you
noted, this prevents namespace collisions.

If you've got a set of extensions that might be useful in other GPS
applications, it's best to propose them here in the forum.  If there's
enough interest in getting them into GPX, they could become part of
the public GPX format in a future version, or at least you may get a
group of people interested in supporting that set of private
extensions in their programs.

An example of something that might be useful in the public standard or
as a common private extension would be map calibration points.

M> 2) In response to some requests for additions to the extension, Jeremy Irish
M> is proposing adding some redundant information like lat/long to the
M> extension. I believe the reasoning has to do with how the xsd for the
M> extension will be built. (My apologies to Jeremy if I misunderstand.) His
M> comment in the forum was

M>      Yes. I'll have an xsd available for it, I suspect. Which means I'll
M> probably have to add
M>      redundant information like lat/lon so if the namespace is used alone,
M> the Groundspeak
M>      format can be decoded and used.

M> from the point of view of a software purist, such redundant information is a
M> Bad Thing (r) but I don't know enough about XML to understand whether the
M> reasoning should apply here.

M> Anyway, the question here is: if a datum is an element of the base GPX
M> specification, should that element be duplicated in an extension?

M> My own opinion is that no, it shouldn't, because it's an opportunity for
M> having two watches and never knowing what time it is.

Again, you're correct.  If it's in the public GPX standard, it doesn't
need to (and shouldn't be) be duplicated elsewhere.

The sample GPX file on the geocaching site isn't valid GPX yet.
Jeremy needs to create a schema for his private groundspeak
extensions, and reference it in the GPX file.  Until it validates as a
proper GPX file, it's not valid GPX.  See
http://www.topografix.com/gpx_validation.asp

I know there are a number of geocachers on this list and using
GPX-enabled software, and we're all looking forward to having the
Geocaching Pocket Queries available in GPX format!
-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com


EasyGPS xml to G7toWIN csv parser

steve+sprintmail.com on Mon Aug 12 15:58:34 2002 (link)


If anyone is interested, I have written a perl parser to convert EasyGPS xml files to G7toWIN csv files.

I run the perl program under Activer Perl which can be downloaded from http://www.activeperl.com

The perl program has been uploaded to the files section of this group on yahoogroups at http://groups.yahoo.com/group/gpsxml/files/

If this is not the kind of stuff for this group, let me know and I'll remove it.

Steve Brown

------?extPart_000_03E7_01C24229.D7951800

Describing datum

engineering+thewalker.com on Sun Sep 15 09:18:41 2002 (link)

I would be grateful to anyone who can help me with these points:

1.  Is there a gpx convention for describing longitude and lattitude position formats, for instance hddd mm ss s, hddd mm mm, British Grid, UTM, etc.  Without this field, how does a gpx file describe the type of
position format of this data?

2.  What is the difference between <ele> and <geoid>?

3.  I don't understand <bounds> - what does a bounding rectangle do?

Answers on a postage stamp, please!

Regards,

Steve Galloway


Re: [gpsxml] Describing datum

egroups+topografix.com on Mon Sep 16 10:14:53 2002 (link), replying to msg

Hello,

Sunday, September 15, 2002, 12:18:35 PM, Steve wrote:

s> I would be grateful to anyone who can help me with these points:

s> 1.  Is there a gpx convention for describing longitude and
s> latitude position formats, for instance hddd mm ss s, hddd mm mm,
s> British Grid, UTM, etc.  Without this field, how does a gpx file
s> describe the type of position format of this data?

GPX is a data transfer format, not a display format.  GPX always uses
WGS84 datum, decimal degrees.  This ensures that every GPX program
knows how to interpret the lat/lon values they receive from the GPX
file.

GPX-enabled programs can display the GPX data they receive in any
format they wish.  For example, if a GPS Utility user in the UK opened
a GPX file I saved with EasyGPS, it would display in British Grid
coordinates (assuming that was the display format set in GPS Utility)
even though EasyGPS and GPX know nothing about British Grid.

By the way, this is the way your GPS receiver works - all data is
stored in WGS84 datum internally, and it gets converted to your
favorite datum and grid format for display purposes.

s> 2.  What is the difference between <ele> and <geoid>?

<ele> Elevation - I didn't define this very precisely in the
documentation.  It means what you think it means - the height, in
meters above mean sea level, of an object.

<geoidheight> Height, in meters, of WGS-84 earth ellipsoid above mean
sea level at the point. (This value is useful if you're processing the
NMEA GGA message)

Why do we have both?  Kjeld (CetusGPS) wanted to be able to express
all of the data in the standard NMEA messages in GPX.  Geoid Height
was needed for that purpose.  For 99% of the applications out there,
<ele> is all you need.  If you care about geoid height, your GPS will
be happy to tell you the current value, and GPX has a place for you to
store it.

s> 3.  I don't understand <bounds> - what does a bounding rectangle do?

<bounds> is an optional tag which specifies the geographic area
covered by the data in the file.  Imagine that someone wrote a search
engine for GPX files, and you were using it to find all GPX data in
the UK.  If the <bounds> tag was present, the search engine could
quickly determine if the GPX file overlapped any part of the UK.  If
the <bounds> tag wasn't there, the search engine would have to test
each waypoint, route point, and track point in the GPX file to see if
any of them were located inside the UK.

We added a number of metadata tags (<bounds>, <keywords>, etc) to the
main <GPX> element to describe the GPX file to search engines,
websites, and other programs.

Of course, all of the tags discussed above are optional in GPX, so you
can ignore them if your application doesn't need them.

I hope this helps answer some of your questions about GPX!
-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com


SVG anyone? anyone SVG?

lesj+mistycreek.com on Wed Sep 18 02:55:37 2002 (link)

Hi,

Just for the benefit of us lurkers,
Anybody working towards SVG display of the GPX data?
How about XLST conversion from GPX to SVG? (or conversion w/o xlst ?)

Where I'm coming from:
Ok when I got my program downloading data from my Garmin
I went looking for a storage format I wouldn't have to invent.
I was hoping for something XML related - I found this group and GPX.
I read though all the messages in the archives, thought about it and
figured I've got nothing to lose and much to gain.
So now my program reads and writes GPX files. And supports drag and drop
of waypoints/routes/tracks from one GPX file to another.
(it's a hack - I'm parsing the XML in VB myself and I'm sure it'll break 
eventually :)

One of the things on my 'shopping list' was displaying the GPS/GPX data in
a graphical format. (on a web page - not a window's picture box)
I go looking at the few sites with GPX samples and I find they show mostly 
text/HTML
representations of the data. Some may have GPX information overlaid on JPG's 
...
but that's not quite what I'm looking for.
I don't want to dust off my Flash/SWF writing code so, I take a look at SVG 
instead.
(it's already XML and I didn't want to add another 20 classes to my project 
anyway :)
I've zero experience with XSLT but I'm not shy of VB :) so now my GPX files can
be exported as SVG. (well actually they're 'your' GPX files :)
Kinda simple and clumsy SVG right now but it's early days.

Before I go off charging further down this avenue I figured I should touch base
and find out what the concensus on that avenue is.
My avenue leads to GPX integrated with other content into web pages.
GPX data displayed as SVG in one frame with media content displayed in other 
frames.
Click on a waypoint and up comes a picture or pano or web page.
I'm toying with ideas for GPX display in a psuedo/virtual GPS ... (think Flash 
thingy's)
with pannable maps and searchable content. At least that's the plan/dream ...

Anybody have any suggestions or comments on all that?

Think that's enough for my first post ...

- Les Johnson

PS: Thanks Dan, Kjeld, et al for all the work you've put into making GPX a real 
thing.



Re: [gpsxml] SVG anyone? anyone SVG?

egroups+topografix.com on Wed Sep 18 05:21:26 2002 (link), replying to msg

Hello,

Wednesday, September 18, 2002, 5:59:12 AM, Les wrote:

L> Just for the benefit of us lurkers,
L> Anybody working towards SVG display of the GPX data?
L> How about XLST conversion from GPX to SVG? (or conversion w/o xlst ?)

L> Where I'm coming from:
L> Ok when I got my program downloading data from my Garmin
L> I went looking for a storage format I wouldn't have to invent.
L> I was hoping for something XML related - I found this group and GPX.
L> I read though all the messages in the archives, thought about it and
L> figured I've got nothing to lose and much to gain.
L> So now my program reads and writes GPX files. And supports drag and drop
L> of waypoints/routes/tracks from one GPX file to another.
L> (it's a hack - I'm parsing the XML in VB myself and I'm sure it'll break 
L> eventually :)

L> One of the things on my 'shopping list' was displaying the GPS/GPX data in
L> a graphical format. (on a web page - not a window's picture box)
L> I go looking at the few sites with GPX samples and I find they show mostly 
L> text/HTML
L> representations of the data. Some may have GPX information overlaid on JPG's 
L> ...
L> but that's not quite what I'm looking for.
L> I don't want to dust off my Flash/SWF writing code so, I take a look at SVG 
L> instead.
L> (it's already XML and I didn't want to add another 20 classes to my project 
L> anyway :)
L> I've zero experience with XSLT but I'm not shy of VB :) so now my GPX files can
L> be exported as SVG. (well actually they're 'your' GPX files :)
L> Kinda simple and clumsy SVG right now but it's early days.

L> Before I go off charging further down this avenue I figured I should touch base
L> and find out what the concensus on that avenue is.
L> My avenue leads to GPX integrated with other content into web pages.
L> GPX data displayed as SVG in one frame with media content displayed in other 
L> frames.
L> Click on a waypoint and up comes a picture or pano or web page.
L> I'm toying with ideas for GPX display in a psuedo/virtual GPS ... (think Flash 
L> thingy's)
L> with pannable maps and searchable content. At least that's the plan/dream ...

L> Anybody have any suggestions or comments on all that?

L> Think that's enough for my first post ...

L> - Les Johnson

L> PS: Thanks Dan, Kjeld, et al for all the work you've put into making GPX a real 
L> thing.

Yes, I'm starting to look at SVG as well.

For anyone who doesn't know about Scalable Vector Graphics, it's an
XML language for controlling the display and positioning of text and
graphics.  It's like Flash, only XML-based.  Adobe makes a free SVG
plugin for your web browser, and it's likely that future browsers will
have SVG support built-in.

Some SVG links:
http://www.adobe.com/svg/viewer/install/main.html
http://www.adobe.com/svg/basics/intro.html

GPS tracking with SVG:
http://www.svgopen.org/papers/2002/bennett__gps_tracking_with_svg/

The Bennett demo is worth checking out.  It simulates tracking a car
through Minnesota, and lets you zoom in on maps to get a more detailed
view of any part of the state.

Here's what I've been doing with SVG:
Eventually, I'd like to be able to transform any GPX file into an SVG
map using XSLT.  Since I'm still getting up to speed on SVG and XSLT,
I decided to start by hacking up ExpertGPS to export SVG files
directly.  Once I get that working to my liking, I'll try to create an
XSL transform that converts my GPX output to match my SVG output.

A few general questions:
Does anyone know of a tool, preferably a freeware Win32 app, that will
take a generic XML file, transform it with a generic XSL file, and
output the transformed XML?  This seems like a basic development tool,
but I haven't been able to find one.

My initial attempt to create an XSL file that would transform XML to
SVG failed because Internet Explorer wouldn't recognise the result as
an SVG stream and wouldn't pass it to the Adobe plugin.  Anyone know a
way to do this, preferably without any server-side processing?

I'll try to put up some sample SVG maps in the next week or so.  The
Export SVG functionality will be in the next beta release of
ExpertGPS.

Anyone else using SVG, or interested in working together on a GPX->SVG
converter?

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com


Re: Describing datum

engineering+thewalker.com on Wed Sep 18 06:00:25 2002 (link), replying to msg

Thanks for your help, appreciated.. SJG

--- In gpsxml+y..., Dan Foster <egroups+t...> wrote:
> Hello,
> 
> Sunday, September 15, 2002, 12:18:35 PM, Steve wrote:
> 
> s> I would be grateful to anyone who can help me with these points:
> 
> s> 1.  Is there a gpx convention for describing longitude and
> s> latitude position formats, for instance hddd mm ss s, hddd mm mm,
> s> British Grid, UTM, etc.  Without this field, how does a gpx file
> s> describe the type of position format of this data?
> 
> GPX is a data transfer format, not a display format.  GPX always uses
> WGS84 datum, decimal degrees.  This ensures that every GPX program
> knows how to interpret the lat/lon values they receive from the GPX
> file.
> 
> GPX-enabled programs can display the GPX data they receive in any
> format they wish.  For example, if a GPS Utility user in the UK opened
> a GPX file I saved with EasyGPS, it would display in British Grid
> coordinates (assuming that was the display format set in GPS Utility)
> even though EasyGPS and GPX know nothing about British Grid.
> 
> By the way, this is the way your GPS receiver works - all data is
> stored in WGS84 datum internally, and it gets converted to your
> favorite datum and grid format for display purposes.
> 
> s> 2.  What is the difference between <ele> and <geoid>?
> 
> <ele> Elevation - I didn't define this very precisely in the
> documentation.  It means what you think it means - the height, in
> meters above mean sea level, of an object.
> 
> <geoidheight> Height, in meters, of WGS-84 earth ellipsoid above mean
> sea level at the point. (This value is useful if you're processing the
> NMEA GGA message)
> 
> Why do we have both?  Kjeld (CetusGPS) wanted to be able to express
> all of the data in the standard NMEA messages in GPX.  Geoid Height
> was needed for that purpose.  For 99% of the applications out there,
> <ele> is all you need.  If you care about geoid height, your GPS will
> be happy to tell you the current value, and GPX has a place for you to
> store it.
> 
> s> 3.  I don't understand <bounds> - what does a bounding rectangle do?
> 
> <bounds> is an optional tag which specifies the geographic area
> covered by the data in the file.  Imagine that someone wrote a search
> engine for GPX files, and you were using it to find all GPX data in
> the UK.  If the <bounds> tag was present, the search engine could
> quickly determine if the GPX file overlapped any part of the UK.  If
> the <bounds> tag wasn't there, the search engine would have to test
> each waypoint, route point, and track point in the GPX file to see if
> any of them were located inside the UK.
> 
> We added a number of metadata tags (<bounds>, <keywords>, etc) to the
> main <GPX> element to describe the GPX file to search engines,
> websites, and other programs.
> 
> Of course, all of the tags discussed above are optional in GPX, so you
> can ignore them if your application doesn't need them.
> 
> I hope this helps answer some of your questions about GPX!
> -- 
> Dan Foster
> TopoGrafix - GPS Software, Waypoints, and Maps
> http://www.topografix.com - mailto:egroups+t...


Re: SVG anyone? anyone SVG?

donreith+rogers.com on Thu Sep 19 04:51:50 2002 (link), replying to msg

> A few general questions:
> Does anyone know of a tool, preferably a freeware Win32 app, that 
will
> take a generic XML file, transform it with a generic XSL file, and
> output the transformed XML?  This seems like a basic development 
tool,
> but I haven't been able to find one.

Yup. On MSDN you'll find msxsl.exe, a command line tool that will do 
this. The syntax is

msxsl generic.xml generic.xsl -o transformed.xml

Go to http://msdn.microsoft.com/downloads/default.asp?
URL=/code/sample.asp?url=/msdn-files/027/001/485/msdncompositedoc.xml

or, in case Yahoo munged the URL, just search msdn on "msxsl.exe" - 
one result is returned.

Binary and source is available for download.

Don


Re: SVG anyone? anyone SVG?

davewissenbach+yahoo.com on Fri Sep 20 16:30:31 2002 (link), replying to msg

--- In gpsxml+y..., Dan Foster <egroups+t...> wrote:
> Hello,
> 
> Anyone else using SVG, or interested in working together on a GPX-
>SVG
> converter?
> 
I'm interested in using SVG, but with a slightly different twist. 
I'd like to use the SVG coordinate transform as a way of 
Georeferencing basemaps. SVG requires that both PNG and JPEG image 
types be supported. What I'd do is publish a GPX file with a 
reference to the SVG basemap, which in turn would reference either 
PNG or JPEG image data. The SVG and associated JPEG/PNG data would 
be output by the program at the time that the GPX file was written.

This SVG basemap data would serve as a sort of universal screen dump 
of the GPX file. I think that the basemap could also include the 
vector representation of the GPX trails in SVG format, or the trail 
could be output without the SVG.

I don't have the time to develop this idea in the next few months 
because of both employment and continuing education.

But I'm very interested in SVG as a method of representing image 
data (of all kinds.)

Dave


> -- 
> Dan Foster
> TopoGrafix - GPS Software, Waypoints, and Maps
> http://www.topografix.com - mailto:egroups+t...


Decimal point as comma in coords?

robertlipe+usa.net on Sun Sep 22 19:39:17 2002 (link)

Hi, Crew.

I've not (yet) asked the user whence said file came, but it's an
interesting question.   What localization is legal in a GPX file?
Is "1.00001" treated identically to "1,00001"?

I'm handing the data to sscanf which claims to be able to handle this.
But before I get into bits and bytes with the user, I'd like help
determing what exactly is legal in this regard in well-formed GPX.

Assume that "gpx" in his question below means my implementation of 
the GPX reader in gpsbabel via expat and not the actual file format.

Thanx,
RJL





> To: "Robert Lipe" <robertlipe+usa.net>
> 
>    A  friend in the Netherlands tested a pre-release of gpsbabel with
>    holux support, but the program didn't work for him.
>    
>    After I looked at his files I found  the problem.
>    
>    The gpx file he created used "," as a decimal point.
>    
>    In most European countries ","  (comma) is the decimal point and gpx
>    cant work with it.
>    
>    Is there a way ( like an option or better two options, one for input
>    and one for output ) to implement this into gpsbabel?


----

Gpsbabel now supports Garmin and Windows.   See http://gpsbabel.sourceforge.net

Re: [gpsxml] Decimal point as comma in coords?

egroups+topografix.com on Tue Sep 24 07:10:11 2002 (link), replying to msg

Hello,

Sunday, September 22, 2002, 10:39:13 PM, Robert wrote:

R> Hi, Crew.

R> I've not (yet) asked the user whence said file came, but it's an
R> interesting question.   What localization is legal in a GPX file?
R> Is "1.00001" treated identically to "1,00001"?

R> I'm handing the data to sscanf which claims to be able to handle this.
R> But before I get into bits and bytes with the user, I'd like help
R> determing what exactly is legal in this regard in well-formed GPX.

A quick check with SAXCount.exe shows that lat="1,0001" contains
invalid characters for the latitudeType defined in GPX.xsd

If you have a question about whether some GPX data is valid, your
first step should be to check the validator.  That's what it's for.
http://www.topografix.com/gpx_validation.asp

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com


Map calibration (georeferencing images) in GPX

egroups+topografix.com on Tue Sep 24 07:24:13 2002 (link), replying to msg

Hello,

Several of us are working on programs that can use a bitmap image as a
basemap.  I'd like to start a discussion about exchanging map
calibration information using GPX.  I've included a sample XML snippet
below, which shows the "gpxmap" structure that I've been using as a
prototype.  The <mappt> structures hold the georeferencing information
- they associate a lat/lon coordinate pair with a specific pixel
location on the map.

<gpxmap:map url="D:\MyMaps\SampleMap.jpg">
 <name>Hiking Trails in the Middlesex Fells Reservation</name>
 <mappt lat="42.449383000" lon="-71.086467000" x="342.0" y="117.0"/>
 <mappt lat="42.443667000" lon="-71.072100000" x="877.0" y="403.0"/>
 <mappt lat="42.437933000" lon="-71.082850000" x="479.0" y="692.0"/>
</gpxmap:map>

Is anyone else interested in creating a public definition for map
calibration information?

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com


Re: Map calibration (georeferencing images) in GPX

haywoodkb+yahoo.com on Tue Sep 24 17:04:21 2002 (link), replying to msg

--- In gpsxml+y..., Dan Foster <egroups+t...> wrote:
>  I'd like to start a discussion about exchanging map
> calibration information using GPX.  

How about using the "world file" specs instead of creating another 
format or "standard"?
 Aerial photographs and scanned topo-maps in JPG and TIFF format are 
georeferenced using six numbers that describe the pixel size, the 
latitude/longitude of the southwest corner, and the rotation of the 
image (usually zero). The units used are UTM meters, so it should be 
easy to plot GPS data over the image. The graphics would be in a 
format compatible with other graphics and GIS projects. World files 
have the extentions JGW and TFW. 
 Terraserver delivers images and "world files" in this format. 

Kevin Haywood





Re: Map calibration (georeferencing images) in GPX

davewissenbach+yahoo.com on Tue Sep 24 19:53:24 2002 (link), replying to msg

--- In gpsxml+y..., Dan Foster <egroups+t...> wrote:
> Hello,
> 
> Several of us are working on programs that can use a bitmap image 
as a
> basemap.  I'd like to start a discussion about exchanging map
> calibration information using GPX.  I've included a sample XML 
snippet
> below, which shows the "gpxmap" structure that I've been using as a
> prototype.  The <mappt> structures hold the georeferencing 
information
> - they associate a lat/lon coordinate pair with a specific pixel
> location on the map.
> 
> <gpxmap:map url="D:\MyMaps\SampleMap.jpg">
>  <name>Hiking Trails in the Middlesex Fells Reservation</name>
>  <mappt lat="42.449383000" lon="-71.086467000" x="342.0" 
y="117.0"/>
>  <mappt lat="42.443667000" lon="-71.072100000" x="877.0" 
y="403.0"/>
>  <mappt lat="42.437933000" lon="-71.082850000" x="479.0" 
y="692.0"/>
> </gpxmap:map>
> 
> Is anyone else interested in creating a public definition for map
> calibration information?
> 
> -- 
> Dan Foster
> TopoGrafix - GPS Software, Waypoints, and Maps
> http://www.topografix.com - mailto:egroups+t...

I think that the concept could be extended to include other metadata 
as well. I published 50 copies of Wissenbach map, but I couldn't get 
too much of Idaho on one CD. I'd like to convert my DRG files to PNG 
files. (Pretty easy, just run tif2png), but I lose the metadata 
necessary to georeference. A format like this one would let me put 
the georeference information back. But I think that other metadata 
might be useful as well.

This is probably way more complicated than what you're thinking, but 
consider a PNG or JPEG format replacement for geotiff as a use case. 
I prefer to use PNG because the compression is lossless, but I'd use 
JPEG if I had to.


Extending the public definition of GPX

egroups+topografix.com on Fri Sep 27 08:24:59 2002 (link), replying to msg

Hello,

Tuesday, September 24, 2002, 10:17:48 AM, I wrote:

D> Is anyone else interested in creating a public definition for map
D> calibration information?

I made the classic mistake of including technical information along
with a philosophical question, so the responses I got back focused on
the technical side of things.

Here are the real questions I have.  Answers that start with "Yes" or
"No" are appreciated.

Should we extend the public definition of GPX to include related sets
of information?

Is "Map calibration information" (in some form or another) related
enough to be included in the public definition of GPX?

Is "Real-time positioning information" (in some form or another) related
enough to be included in the public definition of GPX?

Are there other sets of information that should be included in the
public definition of GPX?



Why am I asking these questions?
I believe that GPX should be extended to include vocabularies for
related sets of information.  We discussed this earlier in the GPX
forum, and one of the founding goals of GPX was that it would be
extensible.  Andrzej made a strong case for consolidating related
vocabularies with his GPSml schemas, where each "vocabulary set" had
its own schema.

I will be adding XML-based map calibration and real-time positioning
features to my ExpertGPS software.  I believe that these two features
are general enough that other software programs would benefit from a
public definition for exchanging this data.  If there's no interest in
developing a public definition, I'll define this elements as private
elements in my topografix: schema, and leave this discussion group
alone.  If there is interest within the group for creating a public
definition, or at least for collaborating on a private definition,
then I'll work with the interested parties to create a format for
interchanging this data.

I look forward to hearing your thoughts and opinions on this topic.

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com


Re[2]: [gpsxml] Extending the public definition of GPX

egroups+topografix.com on Wed Oct 09 15:07:43 2002 (link), replying to msg

Hello,

Wednesday, October 9, 2002, 3:50:45 PM, Kjeld wrote:

>>Should we extend the public definition of GPX to include related sets
>>of information?

K> In principle I like the idea of extending the GPX with related information
K> like Map calibration and definitely real time positioning information.

K> I am no expert into XML but maybe you could help me (and others) a little
K> by showing an example for each "information type".

K> One thing I like about GPX 1.0 though is that it is simple to implement if
K> you just need to for instance read a waypoint list or a track.

K> To the extent possible I believe we should try to maintain this simplicity
K> for those who only need the data sets available in 1.0 and therefore I like
K> the idea of different vocabularies (one basic that represents 1.0, one for
K> map calibration info and one for real time positioning info).

K> Bottom line is "yes" but I would like to see some examples written by those
K> of you who knows more about XML than I do :-)

If we expand GPX, we should do it in a way that preserves the
simplicity it has today.

The way to extend GPX while preserving the simplicity is to create new
namespaces to describe the new features.  GPX authors then only have
to worry about the namespaces that they care about.  We already have
the existing GPX namespace, which you include in your GPX documents
this way:

xmlns="http://www.topografix.com/GPX/1/0"

Some of us include our own private namespaces, which add additional
features which only our programs use:

xmlns:topografix="http://www.topografix.com/GPX/Private/TopoGrafix/0/1"
xmlns:wissenbach="http://www.cableone.net/cdwissenbach"

If you don't care about TopoGrafix Active Points, or Wissenbach Map
Layers, you don't need to include those namespaces in your documents,
or extend your GPX parser to interpret them correctly.  This would
also apply to any public extensions to GPX we create.  They are
entirely optional, and you can ignore them and just use the main GPX
namespace if you only care about waypoints, routes, and tracks.

There are two areas that have been mentioned as possible candidates
for their own public GPX extensions: maps, and real-time tracking.
There are probably other areas for extension as well.  Feel free to
suggest some.

Adding a public map extension would allow you to specify a map to go
along with your GPS data, and optionally provide calibration
information that allows a mapping program to position your GPS data on
the map at the correct locations.  I've already created my own private
namespace for expressing this in GPX, and have a working demo in which
a GPX file can be displayed on my website as a graphic map (using SVG)
and then downloaded and opened in ExpertGPS, where the data is
displayed over a jpeg image specified in the GPX file.

Here's a hypothetical namespace for GPX maps, and a sample:
xmlns:gpxmap="http://www.topografix.com/GPX/Map/1/0"

<!-- the waypoints in this GPX file were taken from this map -->
<gpxmap:map url="http://www.grandcanyon.com/fakeURL/trailmap.jpg">
 <gpxmap:width>640</gpxmap:width>
 <gpxmap:height>640</gpxmap:height>
 <gpxmap:height>480</gpxmap:height>
 <gpxmap:name>Trail Map of the Grand Canyon</gpxmap:name>
</gpxmap:map>

There are lots of optional things that can be included in map data.
The only required thing is the location of the map.  In addition to
the size of the map and the name of the map, you could also have:
 - map publication date
 - copyright/author info
 - calibration information for georeferencing the map
All of this would get wrapped up in the gpxmap schema.

Another area where several of us have expressed an interest in
extending GPX is in the real-time reporting of location data.  Andrzej
had a demo where he had a GPS attached to a cellphone, sending back
data about its speed and location to a web server using XML.  Others
on this list have an interest in tracking mobile users, to keep track
of delivery vans or to locate lost hikers.  Others may want to
experiment with transmitting NMEA data across the Internet in an XML
format.

I'll attempt to create an example of a real-time tracking extension to
GPX below.  While I've given it some thought, I haven't come up with a
good way to express time-sensitive information in XML yet.  And that's
my reason for wanting to create a public extension - to hear what all
you think!

Here's a hypothetical namespace for GPX tracking, and a sample:
xmlns:gpxtracking="http://www.topografix.com/GPX/Tracking/1/0"

<!-- www.bountyhunter.com - last known tracking data for fugitive Dan Foster -->
<gpxtracking:info>
 <gpxtracking:time>2002-07-25T03:27:54Z</gpxtracking:time>
 <gpxtracking:lat>42.5109</gpxtracking:lat>
 <gpxtracking:lon>42.5109</gpxtracking:lon>
 <gpxtracking:speed>75</gpxtracking:speed>
</gpxtracking:info>

Optional things that I could imagine being part of tracking object:
 - lat/lon
 - speed
 - timestamp
 - object ID (for tracking more than one object at a time)

Most of the difficulty I see for the tracking extension is figuring
out how to handle issues related to streaming data between devices.
It's not too hard to imagine how to send a position update to a web
server once per hour using GPX, but consider trying to send all the
data in a standard NMEA stream between devices every second.

Let me know if you'd like to see more examples of how using separate
namespaces can allow us to extend GPX while keeping the simplicity.
Just a reminder - the examples I gave above are just examples of what
a public definition COULD look like.  If we decide to go ahead with a
public collaboration, we'd follow the same process we used when
designing the original GPX spec.

Here's a complete sample of a GPX file containing a map reference (at
the end of the file)  I included three calibration points, as well as
specifying the name and size of the jpeg map that goes with the
waypoints in the file.

blue_hills.gpx:

<?xml version="1.0" standalone="yes"?>
<?xml-stylesheet type="text/xsl" href="details.xsl"?>
<gpx
 version="1.0"
 creator="ExpertGPS 1.1.1 - http://www.topografix.com"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xmlns="http://www.topografix.com/GPX/1/0"
 xmlns:gpxmap="http://www.topografix.com/GPX/Map/0/1"
 xsi:schemaLocation="http://www.topografix.com/GPX/1/0 http://www.topografix.com/GPX/1/0/gpx.xsd http://www.topografix.com/GPX/Map/0/1 http://www.topografix.com/GPX/Map/0/1/gpxmap.xsd">
<name><![CDATA[Blue Hills Reservation]]></name>
<desc><![CDATA[Riding in the Blue Hills is a mix of fast fire roads and technical rock gardens.  Oh, and there's a hill around every corner, too.
Watch out for horses on the fire roads, and pick up a mountain bike trail map at the Headquarters trailhead.  Trails marked in red are off-limits to bikes.  Every intersection in the Blue Hills is marked with a 4 digit number, shown on the map.
The Blue Hills are a great place to hike, as well!]]></desc>
<author><![CDATA[Dan Foster]]></author>
<email>trails+topografix.com</email>
<url><![CDATA[http://www.nemba.org/ridingzone/p_Blue_Hills_Reservation.html]]></url>
<urlname><![CDATA[Blue Hills description at NEMBA]]></urlname>
<time>2002-04-19T02:47:17Z</time>
<keywords><![CDATA[blue hills, mountain biking, milton]]></keywords>
<bounds minlat="42.204420" minlon="-71.123630" maxlat="42.228312" maxlon="-71.069634"/>
<wpt lat="42.209547" lon="-71.119025">
 <ele>86.258400</ele>
 <time>2001-06-24T20:59:47Z</time>
 <name><![CDATA[LOOKOUT]]></name>
 <desc><![CDATA[Lookout Rock]]></desc>
 <sym>Summit</sym>
 <type><![CDATA[rock]]></type>
</wpt>
<wpt lat="42.218051" lon="-71.112672">
 <ele>114.041260</ele>
 <time>2001-10-13T23:50:58Z</time>
 <name><![CDATA[1072]]></name>
 <desc><![CDATA[1072]]></desc>
 <sym>Dot</sym>
 <type><![CDATA[Dot]]></type>
</wpt>
<gpxmap:map url="blue_hills_trail_map.jpg">
 <gpxmap:name>Blue Hills Mtn Bike Trails</gpxmap:name>
 <gpxmap:width>940</gpxmap:width>
 <gpxmap:height>600</gpxmap:height>
 <gpxmap:mappt lat="42.228475501" lon="-71.120628643" x="1.0" y="1.0"/>
 <gpxmap:mappt lat="42.228338019" lon="-71.064200124" x="939.0" y="1.0"/>
 <gpxmap:mappt lat="42.201942738" lon="-71.120819073" x="1.0" y="599.0"/>
</gpxmap:map>
</gpx>

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com


Re: Extending the public definition of GPX

lupitacox+yahoo.com on Thu Oct 10 16:37:38 2002 (link), replying to msg

I don't think this example of GPS/cell phone position updating-to-the-
internet is done in XML, but it gets the job done:
http://www.findu.com/cgi-bin/find.cgi?N5CV

Doug Cox

--- In gpsxml+y..., Dan Foster <egroups+t...> wrote:
> Hello,
> 
> 
> If we expand GPX, we should do it in a way that preserves the
> simplicity it has today.
> 
> The way to extend GPX while preserving the simplicity is to create 
new
> namespaces to describe the new features.  GPX authors then only have
> to worry about the namespaces that they care about.  We already have
> the existing GPX namespace, which you include in your GPX documents
> this way:
> 
> xmlns="http://www.topografix.com/GPX/1/0"
> 
> Some of us include our own private namespaces, which add additional
> features which only our programs use:
> 
> 
xmlns:topografix="http://www.topografix.com/GPX/Private/TopoGrafix/0/1
"
> xmlns:wissenbach="http://www.cableone.net/cdwissenbach"
> 
> If you don't care about TopoGrafix Active Points, or Wissenbach Map
> Layers, you don't need to include those namespaces in your 
documents,
> or extend your GPX parser to interpret them correctly.  This would
> also apply to any public extensions to GPX we create.  They are
> entirely optional, and you can ignore them and just use the main GPX
> namespace if you only care about waypoints, routes, and tracks.
> 
> There are two areas that have been mentioned as possible candidates
> for their own public GPX extensions: maps, and real-time tracking.
> There are probably other areas for extension as well.  Feel free to
> suggest some.
> 
> Adding a public map extension would allow you to specify a map to go
> along with your GPS data, and optionally provide calibration
> information that allows a mapping program to position your GPS data 
on
> the map at the correct locations.  I've already created my own 
private
> namespace for expressing this in GPX, and have a working demo in 
which
> a GPX file can be displayed on my website as a graphic map (using 
SVG)
> and then downloaded and opened in ExpertGPS, where the data is
> displayed over a jpeg image specified in the GPX file.
> 
> Here's a hypothetical namespace for GPX maps, and a sample:
> xmlns:gpxmap="http://www.topografix.com/GPX/Map/1/0"
> 
> <!-- the waypoints in this GPX file were taken from this map -->
> <gpxmap:map url="http://www.grandcanyon.com/fakeURL/trailmap.jpg">
>  <gpxmap:width>640</gpxmap:width>
>  <gpxmap:height>640</gpxmap:height>
>  <gpxmap:height>480</gpxmap:height>
>  <gpxmap:name>Trail Map of the Grand Canyon</gpxmap:name>
> </gpxmap:map>
> 
> There are lots of optional things that can be included in map data.
> The only required thing is the location of the map.  In addition to
> the size of the map and the name of the map, you could also have:
>  - map publication date
>  - copyright/author info
>  - calibration information for georeferencing the map
> All of this would get wrapped up in the gpxmap schema.
> 
> Another area where several of us have expressed an interest in
> extending GPX is in the real-time reporting of location data.  
Andrzej
> had a demo where he had a GPS attached to a cellphone, sending back
> data about its speed and location to a web server using XML.  Others
> on this list have an interest in tracking mobile users, to keep 
track
> of delivery vans or to locate lost hikers.  Others may want to
> experiment with transmitting NMEA data across the Internet in an XML
> format.
> 
> I'll attempt to create an example of a real-time tracking extension 
to
> GPX below.  While I've given it some thought, I haven't come up 
with a
> good way to express time-sensitive information in XML yet.  And 
that's
> my reason for wanting to create a public extension - to hear what 
all
> you think!
> 
> Here's a hypothetical namespace for GPX tracking, and a sample:
> xmlns:gpxtracking="http://www.topografix.com/GPX/Tracking/1/0"
> 
> <!-- www.bountyhunter.com - last known tracking data for fugitive 
Dan Foster -->
> <gpxtracking:info>
>  <gpxtracking:time>2002-07-25T03:27:54Z</gpxtracking:time>
>  <gpxtracking:lat>42.5109</gpxtracking:lat>
>  <gpxtracking:lon>42.5109</gpxtracking:lon>
>  <gpxtracking:speed>75</gpxtracking:speed>
> </gpxtracking:info>
> 
> Optional things that I could imagine being part of tracking object:
>  - lat/lon
>  - speed
>  - timestamp
>  - object ID (for tracking more than one object at a time)
> 
> Most of the difficulty I see for the tracking extension is figuring
> out how to handle issues related to streaming data between devices.
> It's not too hard to imagine how to send a position update to a web
> server once per hour using GPX, but consider trying to send all the
> data in a standard NMEA stream between devices every second.
> 
> Let me know if you'd like to see more examples of how using separate
> namespaces can allow us to extend GPX while keeping the simplicity.
> Just a reminder - the examples I gave above are just examples of 
what
> a public definition COULD look like.  If we decide to go ahead with 
a
> public collaboration, we'd follow the same process we used when
> designing the original GPX spec.
> 
> Here's a complete sample of a GPX file containing a map reference 
(at
> the end of the file)  I included three calibration points, as well 
as
> specifying the name and size of the jpeg map that goes with the
> waypoints in the file.
> 
> blue_hills.gpx:
> 
> <?xml version="1.0" standalone="yes"?>
> <?xml-stylesheet type="text/xsl" href="details.xsl"?>
> <gpx
>  version="1.0"
>  creator="ExpertGPS 1.1.1 - http://www.topografix.com"
>  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>  xmlns="http://www.topografix.com/GPX/1/0"
>  xmlns:gpxmap="http://www.topografix.com/GPX/Map/0/1"
>  xsi:schemaLocation="http://www.topografix.com/GPX/1/0 
http://www.topografix.com/GPX/1/0/gpx.xsd 
http://www.topografix.com/GPX/Map/0/1 
http://www.topografix.com/GPX/Map/0/1/gpxmap.xsd">
> <name><![CDATA[Blue Hills Reservation]]></name>
> <desc><![CDATA[Riding in the Blue Hills is a mix of fast fire roads 
and technical rock gardens.  Oh, and there's a hill around every 
corner, too.
> Watch out for horses on the fire roads, and pick up a mountain bike 
trail map at the Headquarters trailhead.  Trails marked in red are 
off-limits to bikes.  Every intersection in the Blue Hills is marked 
with a 4 digit number, shown on the map.
> The Blue Hills are a great place to hike, as well!]]></desc>
> <author><![CDATA[Dan Foster]]></author>
> <email>trails+t...</email>
> <url><![CDATA
[http://www.nemba.org/ridingzone/p_Blue_Hills_Reservation.html]]
></url>
> <urlname><![CDATA[Blue Hills description at NEMBA]]></urlname>
> <time>2002-04-19T02:47:17Z</time>
> <keywords><![CDATA[blue hills, mountain biking, milton]]></keywords>
> <bounds minlat="42.204420" minlon="-71.123630" maxlat="42.228312" 
maxlon="-71.069634"/>
> <wpt lat="42.209547" lon="-71.119025">
>  <ele>86.258400</ele>
>  <time>2001-06-24T20:59:47Z</time>
>  <name><![CDATA[LOOKOUT]]></name>
>  <desc><![CDATA[Lookout Rock]]></desc>
>  <sym>Summit</sym>
>  <type><![CDATA[rock]]></type>
> </wpt>
> <wpt lat="42.218051" lon="-71.112672">
>  <ele>114.041260</ele>
>  <time>2001-10-13T23:50:58Z</time>
>  <name><![CDATA[1072]]></name>
>  <desc><![CDATA[1072]]></desc>
>  <sym>Dot</sym>
>  <type><![CDATA[Dot]]></type>
> </wpt>
> <gpxmap:map url="blue_hills_trail_map.jpg">
>  <gpxmap:name>Blue Hills Mtn Bike Trails</gpxmap:name>
>  <gpxmap:width>940</gpxmap:width>
>  <gpxmap:height>600</gpxmap:height>
>  <gpxmap:mappt lat="42.228475501" lon="-71.120628643" x="1.0" 
y="1.0"/>
>  <gpxmap:mappt lat="42.228338019" lon="-71.064200124" x="939.0" 
y="1.0"/>
>  <gpxmap:mappt lat="42.201942738" lon="-71.120819073" x="1.0" 
y="599.0"/>
> </gpxmap:map>
> </gpx>
> 
> -- 
> Dan Foster
> TopoGrafix - GPS Software, Waypoints, and Maps
> http://www.topografix.com - mailto:egroups+t...


invisble trkseg tags?

robertlipe+usa.net on Mon Oct 28 18:57:19 2002 (link)

I was implementing track suport in gpsbabel and came across what appears 
to be either an error in the DTD or the spec.

If I mimic the <trkseg> tags in Dan's sample files, my output will validate.
But the string "trkseg" does not appear in the GPX specification.   This 
doesn't seem right.

I can live with this being a correction to 1.0, but is it time for an erratum?

Which is considered authoritative, the spec or the validator?

RJL

Re: [gpsxml] invisble trkseg tags?, new GPX applications?

egroups+topografix.com on Tue Oct 29 07:44:06 2002 (link), replying to msg

Hello Robert,

Monday, October 28, 2002, 9:57:17 PM, you wrote:

R> I was implementing track suport in gpsbabel and came across what appears 
R> to be either an error in the DTD or the spec.

R> If I mimic the <trkseg> tags in Dan's sample files, my output will validate.
R> But the string "trkseg" does not appear in the GPX specification.   This 
R> doesn't seem right.

R> I can live with this being a correction to 1.0, but is it time for an erratum?

R> Which is considered authoritative, the spec or the validator?

The GPX schema is authoritative.  I'll update the user's guide to
include the <trkseg> element from the schema.

While I'm updating the website, I'll be updating the list of GPX
applications and web services.  If you'd like your project listed at
http://www.topografix.com/gpx_resources.asp, let me know.  (I've
already heard from Scott M.)

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com


Add <type> element to <rte> and <trk>?

egroups+topografix.com on Mon Nov 04 07:31:34 2002 (link), replying to msg

Hello,

I just updated the GPX website to include some new GPX programs and
websites, and I fixed the documentation to include <trkseg> and
correct some typos.

I've been using GPX in some larger mapping projects, and I have found
some things that I think should be included in GPX.  We added a <type>
element to <wpt>, <rtept>, and <trkpt> to allow users to classify
point data for their specific applications.  Example types:
"geocache", "intersection", "fire hydrant", "coffee shop".

I'd like to add a <type> element to <rte> and <trk> as well.  Example
types: "highway", "unpaved road", "pipeline", "tracklog from Magellan
GPS", "saved track".  Because it's a text field, users can store
anything they want there.  I'd like to be able to pass my mountain
bike trails from ExpertGPS to Wissenbach Map and TopoFusion and other
GPX programs, and still be able to sort my tracks based on the type of
trail surface.

What do you think?  Should we add <type> as an optional element to
<rte> and <trk>?

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com


Re: [gpsxml] Add <type> element to <rte> and <trk>?

hamish+travellingkiwi.com on Mon Nov 04 08:01:54 2002 (link)

Dan Foster wrote:

> Hello,
>
> I just updated the GPX website to include some new GPX programs and
> websites, and I fixed the documentation to include <trkseg> and
> correct some typos.
>
> I've been using GPX in some larger mapping projects, and I have found
> some things that I think should be included in GPX.  We added a <type>
> element to <wpt>, <rtept>, and <trkpt> to allow users to classify
> point data for their specific applications.  Example types:
> "geocache", "intersection", "fire hydrant", "coffee shop".
>
> I'd like to add a <type> element to <rte> and <trk> as well.  Example
> types: "highway", "unpaved road", "pipeline", "tracklog from Magellan
> GPS", "saved track".  Because it's a text field, users can store
> anything they want there.  I'd like to be able to pass my mountain
> bike trails from ExpertGPS to Wissenbach Map and TopoFusion and other
> GPX programs, and still be able to sort my tracks based on the type of
> trail surface.
>
> What do you think?  Should we add <type> as an optional element to
> <rte> and <trk>?


Yes. Has my vote 100%.

PS> Any chance of moving this group to sourceforge instead of the yahoo 
spambot? It's really getting on my tits.


---

I don't suffer from Insanity... 	| Linux User #16396
	I enjoy every minute of it...	|
					|
http://www.travellingkiwi.com/		|





Sourceforge vs. Yahoo Groups

egroups+topografix.com on Mon Nov 04 08:32:53 2002 (link), replying to msg

Hello,

Monday, November 4, 2002, 11:01:50 AM, Hamish wrote:

PS>> Any chance of moving this group to sourceforge instead of the yahoo 
H> spambot? It's really getting on my tits.

For anyone who might not know, Sourceforge is a website for Open
Source software development and collaboration.
http://www.sourceforge.net

I'd be more than happy to leave Yahoo Groups, if that's what the group
wants to do.  We originally picked Yahoo because we thought it would
be good to have a file repository and archives.  The file dump has
gotten a bit of use, but not much.  Sourceforge has files and
archives, and puts everything out in the open so people can browse
through our group before deciding to join the mailing list.  Moving to
Sourceforge would probably increase the number of open source projects
using GPX, which would be good for all of us.

I don't have any experience with Sourceforge mailing lists - anyone
care to comment?

Are there other standards groups using Sourceforge?  Most of the open
source projects on the site are applications.  We're a little
different - we'd be using Sourceforge for discussions of an open
interchange standard, with no actual source code on their site.

What do you all think?
-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com


Re: [gpsxml] Add <type> element to <rte> and <trk>?

robertlipe+usa.net on Mon Nov 04 08:47:53 2002 (link), replying to msg

Dan Foster wrote:

> some things that I think should be included in GPX.  We added a <type>
> element to <wpt>, <rtept>, and <trkpt> to allow users to classify
> point data for their specific applications.  Example types:
> "geocache", "intersection", "fire hydrant", "coffee shop".

The problem with this is the same as the problem with our waypoint
icon id's: since they're free-form text they're difficult to use
programmatically.

But if it solves some problems for some people, go for it...

RJL

Re: [gpsxml] Sourceforge vs. Yahoo Groups

robertlipe+usa.net on Mon Nov 04 08:58:22 2002 (link), replying to msg

> gotten a bit of use, but not much.  Sourceforge has files and
> archives, and puts everything out in the open so people can browse
> through our group before deciding to join the mailing list.  

Yes, it lowers the entry barrier for casual shoppers.

> Moving to Sourceforge would probably increase the number of open
> source projects using GPX, which would be good for all of us.

It's let GPX show up in a place more programmers are more likely to look.

> I don't have any experience with Sourceforge mailing lists - anyone
> care to comment?

I have experience with both.

Sourceforge uses the excellent 'mailman' mailing list manager that allows
you to turn knobs on archiving, searching, spam filtering, and so on.
Yahoo makes it really painful to read messages from the archives by
hijacking your pages  while sf merely adds a tag to th bottom of the
message.

> Are there other standards groups using Sourceforge?  Most of the
> open source projects on the site are applications.  We're a little

Project UDI (a standard for portable drivers that I'm involved in)
was one of the early projects on sf.  In the beginning, we used only
the mailling lists and later added code for a reference implementation.
We used the bug tracking system to track open issues in the spec and
so on.   It wasn't a terrible fit, but it was a little forced.

I think if you sold the "project" as the DTD or the spec instead of 
actual code, you'd probably be welcomed.
 
RJL


Re: Add <type> element to <rte> and <trk>?

davewissenbach+yahoo.com on Mon Nov 04 19:29:57 2002 (link), replying to msg

--- In gpsxml+y..., Dan Foster <egroups+t...> wrote:
> Hello,
> 
> I just updated the GPX website to include some new GPX programs and
> websites, and I fixed the documentation to include <trkseg> and
> correct some typos.
> 
> I've been using GPX in some larger mapping projects, and I have 
found
> some things that I think should be included in GPX.  We added a 
<type>
> element to <wpt>, <rtept>, and <trkpt> to allow users to classify
> point data for their specific applications.  Example types:
> "geocache", "intersection", "fire hydrant", "coffee shop".
> 
> I'd like to add a <type> element to <rte> and <trk> as well.  
Example
> types: "highway", "unpaved road", "pipeline", "tracklog from 
Magellan
> GPS", "saved track".  Because it's a text field, users can store
> anything they want there.  I'd like to be able to pass my mountain
> bike trails from ExpertGPS to Wissenbach Map and TopoFusion and 
other
> GPX programs, and still be able to sort my tracks based on the 
type of
> trail surface.
> 
> What do you think?  Should we add <type> as an optional element to
> <rte> and <trk>?
> 
> -- 

I'm going to recycle my post number 90 below! Yes, we should add 
<type> as an optional element, but I think that this should be an 
enumeration, so that a program such as your gpx to svg converter can 
interpret the data in a uniform manner. (I'd expect that the range 
of values for this type is constantly changing, though.) While we're 
at this, please consider the <mode> tag, as well. This tag would 
provide further differentiation, such as pedestrian only, etc. 
Perhaps there should be one <mode> tag for each allowed mode. While 
we're adding tags, what about adding another top level tag called 
<region>? I know that from time to time Farmer Brown comes onto the 
GPS newsgroups and asks for a way to measure his fields.

Recycled post follows. Substitude type for <way>.

I recently purchased a trail map for an area of interest, the trails 
of the Boise Front, so that I can use the proper trail names when 
coding in XML format. A couple of features of this map that we are 
missing in current format are the ability to describe the type of 
road or trail, such as Roads, Streets, Gravel Roads, Primitive 
Roads, Dual-track trails, ATV trails, single-track trails, and also 
the ability to describe the modes of travel allowed (or possible). 
Such as 4-WD, Motorized, Non-Motorized, pedestrian only, horse and 
pedestrian only (Mountain Bike excluded), etc.

I think that this is something like a link, where in a route between 
waypoints we might want all of these properties. I think that for a 
trail we would also want all of these properties.

With this added data, I could post a trail or route without 
misleading a person into the type of travel possible.

We could use tags such as <way>, one only, for air, road, street, 
trail, etc, and <mode>, multiple allowed, for modes of travel.

What do you all think?

> Dan Foster
> TopoGrafix - GPS Software, Waypoints, and Maps
> http://www.topografix.com - mailto:egroups+t...


enumerated types

egroups+topografix.com on Tue Nov 05 07:29:12 2002 (link), replying to msg

Hello,

Monday, November 4, 2002, 10:29:51 PM, Dave W. wrote:


d> Yes, we should add
d> <type> as an optional element, but I think that this should be an 
d> enumeration, so that a program such as your gpx to svg converter can 
d> interpret the data in a uniform manner. (I'd expect that the range 
d> of values for this type is constantly changing, though.)

As a general principle, I don't like enumerated types in GPX.
Enumerated types make you choose from a list, and that means that
everyone who uses GPX is restricted to the choices we offer.
Restrictions are bad.

We didn't use an enumerated type for <sym>, even though it's possible
to track down every GPS ever created and make an exhaustive list of
all possible symbol names.  That would cause us to have to update the
spec whenever a new GPS is created with different symbols.

The free text in <sym> doesn't mean your application can't use an
enumerated type.  I use a drop list of symbol types in my programs,
and so I'll only emit <sym> data from that list.  If you send me
<sym>Watermelon</sym>, I'll just ignore it and use the default symbol
for your GPS, since I have no idea how to tell your GPS to draw a
watermelon.

<type> would be even more complicated to enumerate.  We could start
with the official list of USGS types, but that ignores entire
industries which might want to use <type> for their specialized data.
Why should we restrict the powerful monorail lobby from creating GPX
files that contain <type>Monorail</type>?

Another reason to avoid enumerated types is to keep the schema
understandable and maintainable.  A list of several dozen <type>
enumerations will double the size of the current schema.  What happens
when the list grows to a few hundred?

There are other ways to achieve compatibility between applications.
One, already mentioned, would be for the applications that need to
have compatibility to restrict user choices by using a droplist.

The other way is through documentation - if my map drawing program
only handles three types (trail, lake, road), I should make that part
of the documentation.  Users will quickly learn that if they want to
create a document that works with my map drawing program, they'll
need to restrict themselves to those three types.

I'm all for making "canonical lists" available for all to use.  I'm
currently verifying all the symbol names used in all the GPS receivers
my programs support, and I'll make this data publicly available when
it's done (draft at http://www.topografix.com/gps.xml).  I see that
Dave keeps a similar list on his website.

Any other thoughts on enumerated types?
-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com


RE: [gpsxml] enumerated types

fouts+fogey.com on Tue Nov 05 15:16:22 2002 (link), replying to msg

Over the years, when situations like this have come up, where there amounts
to an open ended list, we've adopted various approaches, and the one i like
best is:

1) Make the list 'open-ended' in the spec, meaning that there can always be
unspeced additions

2) Make the list 'open-ended' in implementation, usually by doing things
like having a drop down list but also a fill-in blank

3) Set up a 'standard' set of items that all implementations are expected to
deal with.

4) Set up 'reasonable' behavior for an implementation when the
implementation sees a 'non-standard' item from the list.

> -----Original Message-----
> From: Dan Foster [mailto:egroups+topografix.com]
> Sent: Tuesday, November 05, 2002 7:07 AM
> To: davewissenbach
> Subject: [gpsxml] enumerated types
>
>
> Hello,
>
> Monday, November 4, 2002, 10:29:51 PM, Dave W. wrote:
>
>
> d> Yes, we should add
> d> <type> as an optional element, but I think that this should be an
> d> enumeration, so that a program such as your gpx to svg
> converter can
> d> interpret the data in a uniform manner. (I'd expect that the range
> d> of values for this type is constantly changing, though.)
>
> As a general principle, I don't like enumerated types in GPX.
> Enumerated types make you choose from a list, and that means that
> everyone who uses GPX is restricted to the choices we offer.
> Restrictions are bad.
>
> We didn't use an enumerated type for <sym>, even though it's possible
> to track down every GPS ever created and make an exhaustive list of
> all possible symbol names.  That would cause us to have to update the
> spec whenever a new GPS is created with different symbols.
>
> The free text in <sym> doesn't mean your application can't use an
> enumerated type.  I use a drop list of symbol types in my programs,
> and so I'll only emit <sym> data from that list.  If you send me
> <sym>Watermelon</sym>, I'll just ignore it and use the default symbol
> for your GPS, since I have no idea how to tell your GPS to draw a
> watermelon.
>
> <type> would be even more complicated to enumerate.  We could start
> with the official list of USGS types, but that ignores entire
> industries which might want to use <type> for their specialized data.
> Why should we restrict the powerful monorail lobby from creating GPX
> files that contain <type>Monorail</type>?
>
> Another reason to avoid enumerated types is to keep the schema
> understandable and maintainable.  A list of several dozen <type>
> enumerations will double the size of the current schema.  What happens
> when the list grows to a few hundred?
>
> There are other ways to achieve compatibility between applications.
> One, already mentioned, would be for the applications that need to
> have compatibility to restrict user choices by using a droplist.
>
> The other way is through documentation - if my map drawing program
> only handles three types (trail, lake, road), I should make that part
> of the documentation.  Users will quickly learn that if they want to
> create a document that works with my map drawing program, they'll
> need to restrict themselves to those three types.
>
> I'm all for making "canonical lists" available for all to use.  I'm
> currently verifying all the symbol names used in all the GPS receivers
> my programs support, and I'll make this data publicly available when
> it's done (draft at http://www.topografix.com/gps.xml).  I see that
> Dave keeps a similar list on his website.
>
> Any other thoughts on enumerated types?
> --
> Dan Foster
> TopoGrafix - GPS Software, Waypoints, and Maps
> http://www.topografix.com - mailto:egroups+topografix.com
>
>
> ------------------------ Yahoo! Groups Sponsor
> ---------------------~-->
> Get 128 Bit SSL Encryption!
> http://us.click.yahoo.com/JjlUgA/vN2EAA/kG8FAA/2U_rlB/TM
> --------------------------------------------------------------
> -------~->
>
> To unsubscribe from this group, send an email to:
> gpsxml-unsubscribe+yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
>
>



Re: enumerated types

davewissenbach+yahoo.com on Tue Nov 05 19:56:33 2002 (link), replying to msg

--- In gpsxml+y..., Dan Foster <egroups+t...> wrote:
> Hello,
> 
> Monday, November 4, 2002, 10:29:51 PM, Dave W. wrote:
> 
> 
> d> Yes, we should add
> d> <type> as an optional element, but I think that this should be 
an 
> d> enumeration, so that a program such as your gpx to svg 
converter can 
> d> interpret the data in a uniform manner. (I'd expect that the 
range 
> d> of values for this type is constantly changing, though.)
> 
> As a general principle, I don't like enumerated types in GPX.
> Enumerated types make you choose from a list, and that means that
> everyone who uses GPX is restricted to the choices we offer.
> Restrictions are bad.
> 
> We didn't use an enumerated type for <sym>, even though it's 
possible
> to track down every GPS ever created and make an exhaustive list of
> all possible symbol names.  That would cause us to have to update 
the
> spec whenever a new GPS is created with different symbols.
> 
> The free text in <sym> doesn't mean your application can't use an
> enumerated type.  I use a drop list of symbol types in my programs,
> and so I'll only emit <sym> data from that list.  If you send me
> <sym>Watermelon</sym>, I'll just ignore it and use the default 
symbol
> for your GPS, since I have no idea how to tell your GPS to draw a
> watermelon.
> 
> <type> would be even more complicated to enumerate.  We could start
> with the official list of USGS types, but that ignores entire
> industries which might want to use <type> for their specialized 
data.
> Why should we restrict the powerful monorail lobby from creating 
GPX
> files that contain <type>Monorail</type>?
> 
> Another reason to avoid enumerated types is to keep the schema
> understandable and maintainable.  A list of several dozen <type>
> enumerations will double the size of the current schema.  What 
happens
> when the list grows to a few hundred?
> 
> There are other ways to achieve compatibility between applications.
> One, already mentioned, would be for the applications that need to
> have compatibility to restrict user choices by using a droplist.
> 
> The other way is through documentation - if my map drawing program
> only handles three types (trail, lake, road), I should make that 
part
> of the documentation.  Users will quickly learn that if they want 
to
> create a document that works with my map drawing program, they'll
> need to restrict themselves to those three types.
> 
> I'm all for making "canonical lists" available for all to use.  I'm
> currently verifying all the symbol names used in all the GPS 
receivers
> my programs support, and I'll make this data publicly available 
when
> it's done (draft at http://www.topografix.com/gps.xml).  I see that
> Dave keeps a similar list on his website.
> 

Keeping well-known lists in the documentation might do the trick. I 
advanced the idea of the enumerated type because of the confusion 
that many people had with the <sym> element. I think that also we 
might have similar confusion with the <type> element as used in 
waypoints. I've got a couple of type values that my stylesheet keys 
on, such as photograph, to instruct the stylesheet to display a 
photo in the converted html.

Perhaps there's a way in the schema to create an open-ended type. 
Those w3c guys seem to have thought of everything.

> Any other thoughts on enumerated types?
> -- 
> Dan Foster
> TopoGrafix - GPS Software, Waypoints, and Maps
> http://www.topografix.com - mailto:egroups+t...


Re: [gpsxml] enumerated types

robertlipe+usa.net on Wed Nov 06 06:46:06 2002 (link), replying to msg

Dan Foster wrote:

> As a general principle, I don't like enumerated types in GPX.
> Enumerated types make you choose from a list, and that means that
> everyone who uses GPX is restricted to the choices we offer.
> Restrictions are bad.

But guidelines are good.

GPSBabel, for example, swims in waypoint types.  It knows about dozens
of receiver combinations and tries to paper things up at the outer edges
but in the absence of guidelines on what's in GPX, most stuff just ends
up as "default"

> <type> would be even more complicated to enumerate.  We could start
> with the official list of USGS types, but that ignores entire
> industries which might want to use <type> for their specialized data.

But if we could offer suggested spellings for the most common types, it
would be a Good Thing.

If I spell it "Geocache - Virtual" and Irish spells it "Geocache" and
you call it "Virtual", we've failed in our goal of interoperability.

> I'm all for making "canonical lists" available for all to use.  I'm

That would solve it for me.  I'm not suggesting that we have cast a
formal, definitive list on clay tables but I think that a list of
suggested spellings for these sorts of things would further our goal.

RJL

<region>

egroups+topografix.com on Wed Nov 06 07:06:05 2002 (link), replying to msg

Hello,

Monday, November 4, 2002, 10:29:51 PM, Dave wrote:

d> While
d> we're adding tags, what about adding another top level tag called 
d> <region>? I know that from time to time Farmer Brown comes onto the 
d> GPS newsgroups and asks for a way to measure his fields.

Can you explain a bit more what you're proposing?  What would <region>
look like, and how would Farmer Brown use it?

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com


Change the GPX version number?

egroups+topografix.com on Wed Nov 06 08:02:43 2002 (link), replying to msg

Hello,

Assuming the proposal to add <type> to <rte> and <trk> is accepted,
it will be added to the GPX schema.  Should we increment the GPX
version number at this time, to 1.1 (or 1.00001)?  It's not
necessarily a requirement - if the 1.0 schema were to suddenly include
<type>, no existing files or programs would break.

The logical place to put the <type> element is at the end of the list
of public types, but before the private type catch-all.  If you look
at the schema now, you'll see that I've added <type> in that location,
but commented it out.  (I did a quick test to make sure that a sample
file including <type> would validate correctly.)

My personal feeling is that we should bump the increment the version
number each time we make a change.  If that's what we choose to do,
we should try to lump changes together.

To me, changing the major version number (2.x) means that we've done
something that is no longer compatible with 1.x.  To avoid only being
able to make 9 changes to GPX 1.x, we might want to change to a
longer version number (1.01 or 1.001).  Or is the version number just
a number, and 2.7 is has no difference in meaning than 1.2 and 1.7.

What do you all think?  How should we handle minor additions and
drastic changes to the GPX schema?

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com


Re: [gpsxml] Change the GPX version number?

hamish+travellingkiwi.com on Wed Nov 06 09:39:08 2002 (link)

Dan Foster wrote:

> Hello,
>
> Assuming the proposal to add <type> to <rte> and <trk> is accepted,
> it will be added to the GPX schema.  Should we increment the GPX
> version number at this time, to 1.1 (or 1.00001)?  It's not
> necessarily a requirement - if the 1.0 schema were to suddenly include
> <type>, no existing files or programs would break.
>
> The logical place to put the <type> element is at the end of the list
> of public types, but before the private type catch-all.  If you look
> at the schema now, you'll see that I've added <type> in that location,
> but commented it out.  (I did a quick test to make sure that a sample
> file including <type> would validate correctly.)
>
> My personal feeling is that we should bump the increment the version
> number each time we make a change.  If that's what we choose to do,
> we should try to lump changes together.
>
> To me, changing the major version number (2.x) means that we've done
> something that is no longer compatible with 1.x.  To avoid only being
> able to make 9 changes to GPX 1.x, we might want to change to a
> longer version number (1.01 or 1.001).  Or is the version number just
> a number, and 2.7 is has no difference in meaning than 1.2 and 1.7.
>
> What do you all think?  How should we handle minor additions and
> drastic changes to the GPX schema?


What's wrong with just major.minor, where minor increments by one for 
every change... It doesn't have to just be a decimal number where 1.2 is 
more than 1.19

Oops... Or does the xml spec indicate otherwise?

H

-- 

I don't suffer from Insanity... 	| Linux User #16396
	I enjoy every minute of it...	|
					|
http://www.travellingkiwi.com/		|





Re[2]: [gpsxml] Change the GPX version number?

egroups+topografix.com on Wed Nov 06 10:38:27 2002 (link), replying to msg

Hello,

Wednesday, November 6, 2002, 12:12:21 PM, Hamish wrote:

H> What's wrong with just major.minor, where minor increments by one for 
H> every change... It doesn't have to just be a decimal number where 1.2 is 
H> more than 1.19

H> Oops... Or does the xml spec indicate otherwise?

You're entirely correct.  I was thinking that version was a number,
and that we'd have a problem of "1.10" being the same as "1.1".  I
should have actually looked at the schema.  Version is a string.
Problem solved.

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com


Re: Re[2]: [gpsxml] Change the GPX version number?

martinp13+earthlink.net on Wed Nov 06 12:20:51 2002 (link), replying to msg



But wouldn't it be cleaner to have the first revision be 1.01, the second 1.02, and the tenth be 1.10?  That was there is NO ambiguity.  And it allows for 99 minor revisions before you are "forced" to do a major. :)
> Martin (from the geocaching side of the house)
 Dan Foster <egroups+topografix.com> wrote:Hello,

Wednesday, November 6, 2002, 12:12:21 PM, Hamish wrote:

H> What's wrong with just major.minor, where minor increments by one for 
H> every change... It doesn't have to just be a decimal number where 1.2 is 
H> more than 1.19

H> Oops... Or does the xml spec indicate otherwise?

You're entirely correct. I was thinking that version was a number,
and that we'd have a problem of "1.10" being the same as "1.1". I
should have actually looked at the schema. Version is a string.
Problem solved.

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com



To unsubscribe from this group, send an email to:
gpsxml-unsubscribe+yahoogroups.com



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 






---------------------------------
Do you Yahoo!?
HotJobs - Search new jobs daily now
--0-958601301-1036614050=:2380

Re: Re[2]: [gpsxml] Change the GPX version number?

techlist+hisys.com on Wed Nov 06 15:46:46 2002 (link)

> But wouldn't it be cleaner to have the first revision be 1.01, the 
> second 1.02, and the tenth be 1.10?  That was there is NO ambiguity.  
> And it allows for 99 minor revisions before you are "forced" to do a major. :)

That makes sense; otherwise even though XML doesn't care, some humans 
will be confused over the years about 1.11 vs 1.9 etc.  All ambiguity can be 
avoided with 1.09 vs 1.11.

And yes, I think it makes sense from human terms to reserve 2.x for major 
updates.  Otherwise, skip the pseudo decimal point and just number with 
integers from 1 upwards.

Zhahai (ps: Hi!)

+ Zhahai Stewart       zhahai+hisys.com
+ A Meme Gardener      
+ Standard Disclaimer  YMMV - Your Maya May Vary


Re: [gpsxml] Re: Add <type> element to <rte> and <trk>?

blalor+keyword+yahoo.f6bdbf+ithacabands.org on Wed Nov 06 16:27:19 2002 (link), replying to msg

On Thu, 7 Nov 2002, Kjeld Jensen wrote:

> With <mode> and <way> I believe we are about to introduce tags that 
> does not apply to all GPS users.  Again I am not saying that we 
> shouldn't do it, but we should definitely discuss if we want to go 
> this way. Glider pilots want turn point info added to their 
> waypoints, and yachting people want buoy tags and so on....

Have we discussed using namespaces at all?  I really don't know a great 
deal about XML, but it seems like namespaces can make it fairly modular.  
We (or other parties) could define modules for boating, soaring, 
spelunking, etc. and then include them when they're needed.  This would 
keep the base GPX spec from becoming polluted and allow infinite 
expandability for future uses...

--
      Brian Lalor                 |    http://introducingthelalors.org/
  blalor+ithacabands.org (email)  |  blalor+jabber.ithacabands.org (jabber)
                       N33�27.369' W111�56.304' (Earth)



RE: [gpsxml] Re: Add <type> element to <rte> and <trk>?

jeremy+groundspeak.com on Wed Nov 06 16:50:24 2002 (link), replying to msg

Why not just make it an optional attribute?

Jeremy

-----Original Message-----
From: Kjeld Jensen [mailto:gps+cetus.dk] 
Sent: Wednesday, November 06, 2002 4:24 PM
To: gpsxml+yahoogroups.com
Subject: [gpsxml] Re: Add <type> element to <rte> and <trk>?



RE: [gpsxml] Sourceforge vs. Yahoo Groups

jeremy+groundspeak.com on Wed Nov 06 17:05:47 2002 (link), replying to msg

We'd be happy to host it at Groundspeak, and bypass either option. 

We have ecartis running here (formerly Listar). Dan can continue as the
moderator.

Jeremy

-----Original Message-----
From: Kjeld Jensen [mailto:gps+cetus.dk] 
Sent: Wednesday, November 06, 2002 4:20 PM
To: gpsxml+yahoogroups.com
Subject: Re: [gpsxml] Sourceforge vs. Yahoo Groups


RE: [gpsxml] Re: Add <type> element to <rte> and <trk>?

jeremy+groundspeak.com on Wed Nov 06 17:23:09 2002 (link), replying to msg

True. I'm doing this with cache data in a groundspeak:cache namespace.

-- I take back my last statement. <rte> and <trk> should have a <type>
tag to duplicate the <wpt> tag, though I think it should be an attribute
on all three. Since it is too late to change <wpt> then creating the
<type> makes it uniform.
 
-- Isn't it straightforward how decimal places work? After Version 1.09
is version 1.10. Next release should be 1.01 or 1.00001 - I don't care
either way :)

-- This hasn't been discussed, but I'd like to add this: There is a
<src> tag but should separate manufacturer and software version from the
model. Like: <src mfr="Garmin" ver="1.2">eTrex Legend</src>

Jeremy

-----Original Message-----
From: Brian Lalor [mailto:blalor+keyword+yahoo.f6bdbf+ithacabands.org] 
Sent: Wednesday, November 06, 2002 4:27 PM
To: gpsxml+yahoogroups.com
Subject: Re: [gpsxml] Re: Add <type> element to <rte> and <trk>?


On Thu, 7 Nov 2002, Kjeld Jensen wrote:

> With <mode> and <way> I believe we are about to introduce tags that 
> does not apply to all GPS users.  Again I am not saying that we 
> shouldn't do it, but we should definitely discuss if we want to go 
> this way. Glider pilots want turn point info added to their waypoints,

> and yachting people want buoy tags and so on....

Have we discussed using namespaces at all?  I really don't know a great 
deal about XML, but it seems like namespaces can make it fairly modular.

We (or other parties) could define modules for boating, soaring, 
spelunking, etc. and then include them when they're needed.  This would 
keep the base GPX spec from becoming polluted and allow infinite 
expandability for future uses...

--
      Brian Lalor                 |    http://introducingthelalors.org/
  blalor+ithacabands.org (email)  |  blalor+jabber.ithacabands.org
(jabber)
                       N33�27.369' W111�56.304' (Earth)



To unsubscribe from this group, send an email to:
gpsxml-unsubscribe+yahoogroups.com

 

Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/ 



Re: <region>

davewissenbach+yahoo.com on Thu Nov 07 06:12:19 2002 (link), replying to msg

--- In gpsxml+y..., Dan Foster <egroups+t...> wrote:
> Hello,
> 
> Monday, November 4, 2002, 10:29:51 PM, Dave wrote:
> 
> d> While
> d> we're adding tags, what about adding another top level tag 
called 
> d> <region>? I know that from time to time Farmer Brown comes onto 
the 
> d> GPS newsgroups and asks for a way to measure his fields.
> 
> Can you explain a bit more what you're proposing?  What would 
<region>
> look like, and how would Farmer Brown use it?
> 
Region would be a closed path, but otherwise look just like a track. 
Farmer Brown would get on his four-wheeler and drive around the 
boundary of his field. He would name the region "The North Forty". 
He could then select the region in his gpx application and ask for 
the area in acres. If he decided that he wanted to irrigate north 
forty, he could draw tracks across the area at the desired slope, 
provided that his basemap included elevation data. Farmer Brown 
might want to use a number of such reasons when he creates his crop 
plan.

I also see another use. Farmer Brown sells Hunter Bob permission to 
hunt pheasants in the North Forty, and Hunter Joe permission to hunt 
Geese in the West Cornfield. Farmer Brown might want to give Hunter 
Bob and Hunter Joe GPX regions to keep these two apart. Boundaries 
are important to hunters in Idaho because of the "Ask First" law 
which forbids hunting on private land, posted or not.

In general, I would use the regions for defining land boundaries. 
Here in the Boise area, the land is very fragmented as to ownership. 
Being able to see a region lets you know when or if you're 
trespassing. On foot or by bicycle this isn't a problem, but in Ada 
County, Idaho, driving a motor vehicle on private land, posted or 
not, without permission is a crime.

Another use. Out to the on the snake river plain we have a 
restricted area used by the National Guard for artillery practice. A 
pilot would might to stay out of such a region.

Another one. The Boise Cascade corporation logged a square mile of 
old-growth "by accident." A conscientious logger or firewood cutter 
or mushroom picker might want a GPS receiver capable of telling them 
whether or not they are within their assigned region.

> -- 
> Dan Foster
> TopoGrafix - GPS Software, Waypoints, and Maps
> http://www.topografix.com - mailto:egroups+t...


Re: [gpsxml] Re: <region>

egroups+topografix.com on Thu Nov 07 07:42:59 2002 (link), replying to msg

Hello,

Thursday, November 7, 2002, 9:12:15 AM, Dave wrote:

d> Region would be a closed path, but otherwise look just like a track.

Wouldn't something like this be simpler?
<trk>
 <name>Back Forty</name>
 <closed>true</closed>
 ...
</trk>

I'm very much in favor of adding a way to specify that a path is
closed, but I don't like the idea of duplicating everything that's
already in <rte> and <trk> to do it.  In fact, I now believe that we
made a bad choice with <rte> and <trk> - I think we should have used
one top-level object for point data, and one top-level object for line
data.  Something like:
<path>
 <name>Back Forty</name>
 <gps>track</gps>
 <closed>true</closed>
 ...
</path>
<path>
 <name>Lake Boise</name>
 <gps>none</gps> <!-- show it on the map, but don't send to GPS! -->
 <closed>true</closed>
 ...
</path>

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com


Public Namespaces

egroups+topografix.com on Thu Nov 07 07:51:03 2002 (link), replying to msg

Hello,

Wednesday, November 6, 2002, 7:38:17 PM, Kjeld wrote:

K> Hi Brian Lalor,

>>Have we discussed using namespaces at all?  I really don't know a great
>>deal about XML, but it seems like namespaces can make it fairly modular. 

K> As far as I know this is exactly where the private tags are currently 
K> used by at least Dan and Dave.

K> But I was under the impression that they want to include the tags in 
K> the basic GPX scheme and therefore I wanted to discuss it. I may be 
K> wrong though.

K> Kjeld

I'd like to see us start using multiple public namespaces for public tags,
and I've even suggest that we remove many of the things that are
currently in the public spec and put them in their own namespaces.
Most of the things I think should be removed just happen to be things
that I lobbied to get included...  (type, url, urlname...)

The way I see it, the only thing that should be in the default GPX
namespace are things having to do with geographic position.  Latitude,
longitude, elevation, and time are really the only universal things
that this group has in common.  Even GPS tags like <com> and
<sym> aren't really universal - maybe there are weather programs that
would output forecasts for world cities in GPX, but don't care a bit
about GPS receivers.

The GPX namespace would set a base level for data interchange.
Programs that support only the GPX namespace can still exchange
geographic data without losing the basic info.

On top of that, we add public namespaces.  The only thing that makes a
public namespace different from a private namespace is that public
namespaces are agreed upon by a group (possibly this group, or perhaps
we'll break up into sub-groups).  There are several areas where public
namespaces would be appropriate.  I'll try to describe them below.

Trail description publishing:  Dave and I have been doing a lot with
this, and things like long text descriptions, <way>, <type> would fall
here.

Graphical map publishing: As I've said before, I'm interested in
working with others on this.  Things like map projection data would
fall here, as well as display issues (font, color, line size).

Real-time tracking: The NMEA stuff from <trkpt> would go here, along
with any additional info related to time-based positioning.  Kjeld's
interested in this, so am I.

Geocaching: I know Jeremy is working on a private schema for this.  I
also know there are a bunch of geocachers on this list who might be
interested in contributing to this effort if it was public.


I know Kjeld is concerned about increasing the size of GPX files and
the complexity of the format.  I think that switching to multiple
namespaces will decrease the complexity of the base format
considerably.  If Kjeld has to include the "base GPX" and "GPS stuff"
and "tracking stuff" namespaces at the head of each GPX file, the file
size will certainly go up a bit.  We should talk about those
tradeoffs.

What do you all think?
-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com


RE: [gpsxml] Re: <region>

jeremy+groundspeak.com on Thu Nov 07 09:48:56 2002 (link), replying to msg

Seems like spacial data should be separate from waypoint, route and
track sharing. Showing a closed loop bike path is one thing (which IMO
belongs as part of route data), but defining boundaries fits better
within a spacial schema. At that point you're moving into G-XML and GML
type schemas, which I don't think belongs in the "light-weight" GPX
format.

I like the idea of creating <region> tags (especially based on the ideas
put forth by Wissenbach), but it seems out of scope for the purpose of
the GPX format. I'd suggest other namespaces that define spacial
information and keep GPX from encountering scope creep.

Jeremy

-----Original Message-----
From: Dan Foster [mailto:egroups+topografix.com] 
Sent: Thursday, November 07, 2002 7:10 AM
To: davewissenbach
Subject: Re: [gpsxml] Re: <region>


Hello,

Thursday, November 7, 2002, 9:12:15 AM, Dave wrote:

d> Region would be a closed path, but otherwise look just like a track.

Wouldn't something like this be simpler?
<trk>
 <name>Back Forty</name>
 <closed>true</closed>
 ...
</trk>


RE: [gpsxml] Re: Add <type> element to <rte> and <trk>?

jeremy+groundspeak.com on Thu Nov 07 13:11:35 2002 (link), replying to msg

Wow. I can see how the GPX format could get bloated fast. Is that
written in stone? It seems to me the purpose of attributes in XML are to
give further information about a specific tag, as long as the
information has a restricted length and exists as only one instance.

So this is more appropriate for source info?

<src mfr="Garmin" model="eTrex Vista" ver="1.2" /> 

Or even...

<src mfr="Garmin" ver="1.2">eTrex Vista</src> 

seems a lot better than

<src>eTrex Vista</src>
<src_mfr>Garmin</manufacturer>
<src_ver>1.2</version>

My reasoning for additional hardware information (including software
versions) can help a user understand the validity of the unit's
capabilities that generated the info. You could also notify the user if
a new software version was available, or react to a firmware issue, etc.
And a well-documented source tag will just plain help when managing
data.

Unfortunately I can't seem to get into the archives, so please enlighten
me as to why attributes are required.

Jeremy

-----Original Message-----
From: Kjeld Jensen [mailto:gps+cetus.dk] 
Sent: Wednesday, November 06, 2002 11:26 PM
To: gpsxml+yahoogroups.com
Subject: RE: [gpsxml] Re: Add <type> element to <rte> and <trk>?


Hi Jeremy Irish,

>Why not just make it an optional attribute?

When we defined 1.0 we decided (after a long discussion) to use 
attributes only for required information and elements only for 
optional information. I prefer that we keep it this way.

Kjeld
-- 


RE: [gpsxml] Re: Add <type> element to <rte> and <trk>?

martinp13+earthlink.net on Thu Nov 07 13:20:58 2002 (link), replying to msg



I think he meant that if mfr, ver, model were required, then:
<src mfr="Garmin" ver="1.2" model="Etrex Vista" />
would be fine... but if they are optional, then:
<src>
<mfr>Garmin</mfr>
<ver>1.2</ver>
<model>Etrex Vista</model>

</src>
was appropriate.  Sorry I couldn't paginate that... Yahoo groups editor is the pits. :(
> Martin
 
 Jeremy Irish <jeremy+groundspeak.com> wrote:Wow. I can see how the GPX format could get bloated fast. Is that
written in stone? It seems to me the purpose of attributes in XML are to
give further information about a specific tag, as long as the
information has a restricted length and exists as only one instance.

So this is more appropriate for source info?



Or even...

eTrex Vista 

seems a lot better than

eTrex Vista
Garmin
1.2

My reasoning for additional hardware information (including software
versions) can help a user understand the validity of the unit's
capabilities that generated the info. You could also notify the user if
a new software version was available, or react to a firmware issue, etc.
And a well-documented source tag will just plain help when managing
data.

Unfortunately I can't seem to get into the archives, so please enlighten
me as to why attributes are required.

Jeremy

-----Original Message-----
From: Kjeld Jensen [mailto:gps+cetus.dk] 
Sent: Wednesday, November 06, 2002 11:26 PM
To: gpsxml+yahoogroups.com
Subject: RE: [gpsxml] Re: Add element to and ?


Hi Jeremy Irish,

>Why not just make it an optional attribute?

When we defined 1.0 we decided (after a long discussion) to use 
attributes only for required information and elements only for 
optional information. I prefer that we keep it this way.

Kjeld
-- 



To unsubscribe from this group, send an email to:
gpsxml-unsubscribe+yahoogroups.com



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 






---------------------------------
Do you Yahoo!?
U2 on LAUNCH - Exclusive medley & videos from Greatest Hits CD
--0-1826139515-1036704057=:91384

Re: <region>

davewissenbach+yahoo.com on Fri Nov 08 06:09:04 2002 (link), replying to msg

--- In gpsxml+y..., Dan Foster <egroups+t...> wrote:
> Hello,
> 
> Thursday, November 7, 2002, 9:12:15 AM, Dave wrote:
> 
> d> Region would be a closed path, but otherwise look just like a 
track.
> 
> Wouldn't something like this be simpler?
> <trk>
>  <name>Back Forty</name>
>  <closed>true</closed>
>  ...
> </trk>
> 
> I'm very much in favor of adding a way to specify that a path is
> closed, but I don't like the idea of duplicating everything that's
> already in <rte> and <trk> to do it.  In fact, I now believe that 
we
> made a bad choice with <rte> and <trk> - I think we should have 
used
> one top-level object for point data, and one top-level object for 
line
> data.  Something like:
> <path>
>  <name>Back Forty</name>
>  <gps>track</gps>
>  <closed>true</closed>
>  ...
> </path>
> <path>
>  <name>Lake Boise</name>
>  <gps>none</gps> <!-- show it on the map, but don't send to GPS! --
>
>  <closed>true</closed>
>  ...
> </path>
> 

One way to achieve this would be to define a type which is common to 
route, track, or region, but keep the element name different. Then 
route, track and region are all elements with type PathType, and 
waypoint and trackpoint are elements with type PointType. I'm not 
sure that we have a better or more formal way of expressing 
inheritance with XML Schema. Another way might be with substitution 
groups, where elements can be allowed to substitute for each other.

The path/point concept will certainly lead to better and simpler 
implementations. I think that internally in Wissenbach Map I made a 
poor design choice when I used a separate implementation for route 
and track, and this is probably also true for the gpx schema itself.

> -- 
> Dan Foster
> TopoGrafix - GPS Software, Waypoints, and Maps
> http://www.topografix.com - mailto:egroups+t...


Re: Public Namespaces

davewissenbach+yahoo.com on Fri Nov 08 06:32:09 2002 (link), replying to msg

--- In gpsxml+y..., Dan Foster <egroups+t...> wrote:
> Hello,
> 
> Wednesday, November 6, 2002, 7:38:17 PM, Kjeld wrote:
> 
> 
> I'd like to see us start using multiple public namespaces for 
public tags,
> and I've even suggest that we remove many of the things that are
> currently in the public spec and put them in their own namespaces.
> Most of the things I think should be removed just happen to be 
things
> that I lobbied to get included...  (type, url, urlname...)
> 
> The way I see it, the only thing that should be in the default GPX
> namespace are things having to do with geographic position.  
Latitude,
> longitude, elevation, and time are really the only universal things
> that this group has in common.  Even GPS tags like <com> and
> <sym> aren't really universal - maybe there are weather programs 
that
> would output forecasts for world cities in GPX, but don't care a 
bit
> about GPS receivers.
> 
> The GPX namespace would set a base level for data interchange.
> Programs that support only the GPX namespace can still exchange
> geographic data without losing the basic info.
> 
> On top of that, we add public namespaces.  The only thing that 
makes a
> public namespace different from a private namespace is that public
> namespaces are agreed upon by a group (possibly this group, or 
perhaps
> we'll break up into sub-groups).  There are several areas where 
public
> namespaces would be appropriate.  I'll try to describe them below.
> 
> Trail description publishing:  Dave and I have been doing a lot 
with
> this, and things like long text descriptions, <way>, <type> would 
fall
> here.
> 
> Graphical map publishing: As I've said before, I'm interested in
> working with others on this.  Things like map projection data would
> fall here, as well as display issues (font, color, line size).
> 
> Real-time tracking: The NMEA stuff from <trkpt> would go here, 
along
> with any additional info related to time-based positioning.  
Kjeld's
> interested in this, so am I.
> 
> Geocaching: I know Jeremy is working on a private schema for 
this.  I
> also know there are a bunch of geocachers on this list who might be
> interested in contributing to this effort if it was public.
> 
> 
> I know Kjeld is concerned about increasing the size of GPX files 
and
> the complexity of the format.  I think that switching to multiple
> namespaces will decrease the complexity of the base format
> considerably.  If Kjeld has to include the "base GPX" and "GPS 
stuff"
> and "tracking stuff" namespaces at the head of each GPX file, the 
file
> size will certainly go up a bit.  We should talk about those
> tradeoffs.
> 
> What do you all think?

Perhaps we should restrict GPX to the application of trip planning 
and trail logging only. In that context, trail descriptions and 
waypoint descriptions, are still appropriate. Region might not be.

To set the context of the trip, we use a vector basemap, which is 
described in some other namespace. In many cases we'll create those 
vector basemaps by transforming GPX data into the vector basemap 
format. I know that there is activity in the area of a georeferenced 
SVG extension already out there, so we might just try to figure out 
how to relate our trip maps to the basemaps. Whatever the format is, 
this should include level-of-detail, so that at various zoom levels 
information that isn't so relevant disappears off the screen.

I think that the utility of USGS topographic map data is decreasing 
rapidly. With Digital Elevation Model data, and the national 
geographic data set, we probably have better ways of describing 
elevation data that don't clutter up the computer screen so much. 
But we should probably search for a good XML basemap format before 
we make our own. But I would like have good agreement on a basemap 
format. GPX should add tags which allow the referencing of a 
particular basemap.

Eventually, cell phones, PDAs, and GPS receivers will converge into 
one device, and I'd like to see the mapping format for these devices 
be public-domain. That's where I think that we're going.
> -- 
> Dan Foster
> TopoGrafix - GPS Software, Waypoints, and Maps
> http://www.topografix.com - mailto:egroups+t...


Re: [gpsxml] Re: <region>

robertlipe+usa.net on Fri Nov 08 08:31:53 2002 (link), replying to msg

davewissenbach wrote:

> The path/point concept will certainly lead to better and simpler 
> implementations. I think that internally in Wissenbach Map I made a 
> poor design choice when I used a separate implementation for route 
> and track, and this is probably also true for the gpx schema itself.

I recall questioning why they were distinguished in the GPX spec.

While I certainly haven't pushed the bounds of GPX like you guys have, I
wound up handling tracks as "anonymous routes" (the individual waypoints
may or may not have names) inside GPSBabel.  It really didn't seem like
a contrived fit at all.  Tracks are just routes of many points that
don't have unique names.

RJL

differences between <trk> and <rte>

egroups+topografix.com on Fri Nov 08 10:42:24 2002 (link), replying to msg

Hello,

Friday, November 8, 2002, 11:31:51 AM, Robert wrote:

R> I recall questioning why [routes and tracks] were distinguished in the GPX spec.

R> While I certainly haven't pushed the bounds of GPX like you guys have, I
R> wound up handling tracks as "anonymous routes" (the individual waypoints
R> may or may not have names) inside GPSBabel.  It really didn't seem like
R> a contrived fit at all.  Tracks are just routes of many points that
R> don't have unique names.

I treat tracks the same way as routes in the internals of my programs.
 They are just routes with the "isTrack" property set.

As I recall, one reason we kept <rte> and <trk> separate was that
Kjeld had a bunch of NMEA-type data to store in <trkpt>, and it didn't
make sense to make it available in <rtept> as well.  Also, we
introduced the concept of <trkseg> to handle discontinuous tracks,
which don't have much use in <rte>.

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com


Namespace, Tag and Metadata discussion

joel+coastaloutdoors.com on Sun Nov 10 19:14:42 2002 (link)

Gentlemen:

I have followed the discussions with great interest.  I confess to not
giving the attention to the group it deserves and apologize for any 
apparent ignorance.

The application I have been working on is web based.  I already have 
a simple GPS search and list tool for approximately 15,000 marine 
waypoints on the US East and Gulf coasts.  The next step in the 
application development will be a trip planner for inshore and 
offshore fishing trips, and, to allow the users to download the 
waypoints, routes and tracks for upload to their GPS.

I have thousands of land-based coordinates in my database also, but, 
am currently only using the marine coordinates.  Future development 
of the application calls for inclusion of marine freshwater 
coordinates.  "Support" locations for all the above will be utilized 
as well.  Additionally, we will begin inclusion of recreational land 
coordinates for hunting, hiking, general boating, etc.

The discussions with respect to trails, regions, bounds, map 
calibration points have been of particular interest to me.

To kind of help me differentiate between the namespaces, if someone 
could, please take a moment to "label" the following correctly for 
me.  I will give my current field name and the purpose of the field.

coord_id:  the unique identifier in my database for the coordinate.

name: common name of the waypoint, in many cases, this may be just a 
number such as Grays 1 or Grays SW Ledge.

cmt:  commments about the waypoint.

lat:  latitude

lon:  longitude

desc:  description of the waypoint.

date:  date the waypoint was acquired.

st:  the state of the coordinate location.

type:  the descriptive type of the coordinate, such as boat ramp, 
marina, hard bottom/live bottom, ledge, wreck, etc.

coord_area:  the general area in which the coordinate is located, 
right now I'm using bounds here.


area:  "common area name" such as "Grays Reef" or "J Reef".

material:  if the waypoint is an artificial reef, the type material 
used to create the reef.

depth:  depth at the waypoint  -  I would assume this would be 
geoidheight

Thank you for your time.  With elucidation on the above, I may be 
able to contribute in the future.

Joel
http://www.coastaloutdoors.com




 




Re: [gpsxml] Re: <region>

robertlipe+usa.net on Tue Nov 12 00:11:55 2002 (link), replying to msg

Kjeld Jensen wrote:

> >a contrived fit at all.  Tracks are just routes of many points that
> >don't have unique names.
> 
> No
> 
> - at least not following my definition :-)

OK, but I'm still not sure I agree with your definition since you seem
to define them different just to make them easier to grasp and not based
on real a real distinction. ;-)

> Tracks are sets of positions along with information about the current
> state of the tracker at that position. The state may include the time,
> current speed, current course and so on.

Given position, you know current course.  Given time, you know current
speed from the last point, right?  (If you're storing "current speed" as
"instantaneous speed when this trackpoint was dropped", I'd be a little
suprised.)

> Routes are sets of positions that you in some way want to follow
> sequentially.

Tracks and routes both sets of sequentially ordered waypoints.

Tracks probably have optional <time> records.   Routes probably don't.

While the disinction you make might help the developer that wants to
code one very specific task using GPX ("Here, Junior, code me some
XML gibberish that reads section A.B.C of this spec...") gain a quick
understanding, it actually complicates the XML parsers becuase you have
to maintain extra state to know if a waypoint appears in a track or a
route.  You have to parse lat/lon as mandatory data in all three (waypt,
track, route) even though you probably want to handle all three in
very similar ways.

I guess I'm saying that routes and tracks are more alike than they are
different and the differences can be handled via the optional data
already defined.  If you treat the wpt as the fundamental unit, the
abstraction gets even stronger.  You now have on "thingy" that appears
either in isolation or in an ordered sequence.

But I'm the new kid on this block.  You GIS and XML guys can just go
nuts with this stuff. :-)

> Maybe our different point of view follows from the fact that I
> spend most time creating those sets of data and you spend most time
> converting, presenting and analyzing them. I don't know, but it
> becomes obvious that this "discussion" way of building up a general
> exchange format is very fruitful although long winded.

Oh, I'm sure perception has a lot to do with it.  I don't think we're
really arguing substantially different views. But getting the views of
GPX from a variety of folks using it in different ways was one of the
goals of this discussion originally.  It'll hopefully help shape future
directions.



Re: [gpsxml] Re: <region>

robertlipe+usa.net on Tue Nov 12 10:24:33 2002 (link), replying to msg

> from universities and companys that use Cetus GPS for quite advanced 
> tasks and I do not think we should cut off this functionality just to 
> merge routes and tracks.

OK, sold.   Keep it as an otional tag.

> So far we agree :-) - if I could just get you to call it positions 
> and not waypoints, as route and trackpoints normally does not contain 

I'm just calling them that becuase we call the tag "wpt" inside gpx.
I'm certainly not bent on the term and I do understand the distinction
you're making.

> to define a basic "position" record containing only the information 
> that are related to the position itself and the conditions under 
> which it was obtained.
> 
> Then waypoints would consist of the position record along with 
> waypoint related information (url, icon and so on). Routes, tracks, 
> regions, real-time positioning, map calibration points etc. could be 
> defined the same way.

I could go for that.  We'd then have one way of expressing a waypoint,
er, position instead of three (with more on the horizon) and would gain
the simplification I describe and desire.

RJL

Redundancy of Rte and Trk?

jeremy+groundspeak.com on Wed Nov 13 07:46:29 2002 (link), replying to msg

I changed the topic since <region> didn't really fit the discussion.

Personally, I thought XML was supposed to be both readable and parsable.
Normalization is fine and dandy for databases, but I would personally
prefer both a trk and rte data since I can quickly discern which is
which. It is well known by most users of GPS units, and most GPS
software has these options available. I vote to keep it as it is.

It seems to me that Trk data is sequential track data indicating an
exact defined path, while rte data is a list of sequential waypoints
that can be reached by x alternate paths. So, for example if you were
going from the Visitor's Center to the geyser, it would show you to take
the long path (trail 2), while a route would show you the visitor's
center as step one and geyser as step 2. True that all routes could be
tracks, but not all tracks are routes.

Jeremy



Groups of waypoints

henry_wede+yahoo.com on Sun Nov 24 19:56:45 2002 (link)

Hello - 

I new here (and new to XML), so this question may have been addressed 
early on...
 
Why are the waypoint elements on the same 'level' as the route and 
track elements?  Wouldn't it be good to allow groups of waypoints 
under a waypoint element the same way there can be different routes 
or tracks under their headings?  


Henry



Re: [gpsxml] Groups of waypoints

chris+groundspeak.com on Mon Nov 25 10:50:53 2002 (link)


Hi Henry,

I'm merely a user of GPX-- but I'm fairly sure one of the goals is 
simplicity.  If you're new to XML, you'll soon realize that for 
everything you work with you'll need to understand the organization of 
the data (or at least the parts you're interested in).  Keeping things 
simple will greatly speed your development efforts, and your ability to 
move things in and out of the chosen format.  Both routes and tracks are 
already collections of "points".  In almost all cases, having multiple 
waypoints is a given, and frequently a GPX file may only be waypoints, 
without tracks or routes-- zo in most cases the GPX file itself is a 
collection of waypoints, and the need to give it another wrapper is a 
bit redundant.  With most XML software and platforms, you should be able 
to use simple XPath to build a collection (nodelist) of waypoints: //wpt.

Chris

henry_wede wrote:

> Hello -
>
> I new here (and new to XML), so this question may have been addressed
> early on...
>
> Why are the waypoint elements on the same 'level' as the route and
> track elements?  Wouldn't it be good to allow groups of waypoints
> under a waypoint element the same way there can be different routes
> or tracks under their headings? 
>
>
> Henry
>
>
>
> *Yahoo! Groups Sponsor*
> ADVERTISEMENT
> <http://rd.yahoo.com/M=237459.2675695.4055211.2225243/D=egroupweb/S=1706030390:HM/A=1267611/R=0/*http://ad.doubleclick.net/jump/N2524.Yahoo/B1071650;sz=300x250;ord=1038196606310311?> 
>
>
>
> To unsubscribe from this group, send an email to:
> gpsxml-unsubscribe+yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service 
> <http://docs.yahoo.com/info/terms/>.




--------------080604010000070804040003

TopoFusion, Call for GPS data (GPX format)

scmorris+mailcity.com on Wed Dec 11 21:18:12 2002 (link)


Hi All,

I never announced it here, but just wanted to let everyone know that there is another GPX mapping program out there, TopoFusion.  We use GPX as our primary storage format.  We're quite happy with the concept and specs in GPX; bravo to everyone.

I also wanted to let you know that I'm working on simulating recreational trail users on GPS tracks and am getting people involved collecting data in the GPX format.  I'm really insisting on GPX because I need the time component with each data point.

Also, I will soon be extending GPX to include topology information.  TopoFusion works with networks of trails and there is currently no way to store topological information in GPX.  I will probably make them private extensions for now, but if anyone else is interested in helping (or interested in networks in general), I'd love to hear from you.

More information about all this can be found on our site, www.topofusion.com

Thanks,

       Scott Morris


Importing Waypoint Cooridinates from formatted text files

interjunk+shaw.ca on Sun Jan 05 22:24:44 2003 (link)

I don't know if this is the correct group to be posing this 
question.  If not, I apologize.

I need to find a software program or utility (freeware or otherwise)
to help with the following problem:

- We want to be able to download data from the Handheld GPS and 
export coordinates (as waypoints) to formated text file to import to 
Mine Modeling/CAD Software.  Want to export from Mine Modelling 
Software and upload to Handheld GPS, as well.  The driver for this 
solution is to minimize manual coordinate entry (time is money).

Current Situation:

- Using Garmin 12XL handheld GPS for rough mining surveying.  We 
modified the user grid to work in the mine coordinates (on both GPS 
and MapSource Software).  This transformation works well.
- Example Situation:  We have the Drillhole IDs and coordinates in a 
formated text file (Exported from Mine Modelling Software) and want 
to upload the coordinates in order to survey the position using 
handheld GPS.
- Example Situation: We survey testing locations with IDs (stored as 
waypoints) and we want to download from GPS and import to Mine 
Modelling Software (or potential to database)


I tried the following programs, and they do not work for my situation:
- GPS Utility Ver 4.04.6
- GPS TrackMaker

Thanks in advance.

Todd



Sample SVG with UTM Coordinates

davewissenbach+yahoo.com on Wed Jan 08 18:17:27 2003 (link)

I've worked out simple coordinate transformations for drawing trails 
and waypoints as Scalable Vector Graphics with UTM coordinates. The 
sample file references TerraServer aerial photo tiles on the SVG.

The SVG file is

http://myweb.cableone.net/cdwissenbach/BogusBasin.svg

This is best viewed with an html wrapper which sets the scale at 2 
meters per pixel.

http://myweb.cableone.net/cdwissenbach/EmbeddedSVG.html

The SVG file was output by a prototype version of Wissenbach Map. 
The place names shown without waypoints are drawn by making a 
special waypoint with type="Place Name". What's probably of most 
interest to the developers who read this group are the viewport and 
outermost g element transformations which flip the coordinate system 
to set up the UTM coordinate system, and the transformations to flip 
the coordinate system back, temporarily, to render text and 
waypoints.

This work was inspired by Dan Foster's SVG effort and by the thread 
in this group SVG Anyone? and by my desire to learn SVG.

I'll be embellishing the SVG output features of Wissenbach Map and 
publishing a version of the program which allows SVG drawing in the 
next few months. (As always, this depends on the workload in my real 
job, and will of course depend on the local skiing conditions--not 
so good right now.)

I intend to use the type fields to provide the hints as to what line 
types and fills to use in SVG. For example, type="Ski Run" might 
cause a wide, translucent line to be drawn. type="Ski Lift" would 
give a thin dotted line.


Re: source code (C++, Qt)

davewissenbach+yahoo.com on Sat Jan 11 19:37:43 2003 (link), replying to msg

--- In gpsxml+yahoogroups.com, Ralf Haselmeier 
<Ralf.Haselmeier+g...> wrote:
> Hi,
> 
> I want to implement waypoints and routes to my gps application 
> (qpegps.sourceforge.net).
> I'll use the gpx format: Is there any open source code which I can 
use
> as a starting point (C++, Qt resp. Qt/embedded, Qtopia) ?
> 
> Thanks for Your help.
> Ralf

See

http://myweb.cableone.net/cdwissenbach/map.html

for a link to source code to my program.

However, If I had to do this over again, I'd use the same code for 
routes and tracks, and/or program using the xml document object 
model, or DOM. (The reason that I would do this is so that my 
program could work with an existing program but not lose data for 
tags which I don't implement. For example, my program would lose the 
topografix trail color information right now, and ExpertGPS eats 
layer information.

So, with a disclaimer, you have source code. (The license is GPL)

Dave


SVG Sample

lesj+mistycreek.com on Thu Jan 16 13:28:59 2003 (link)

Belated congratulations to Dave W. for the SVG example.
I've been away for a while so this response is a bit tardy ...

I'm glad to 'see' that progress is being made out there.
Keep going Dave.

Ok, now the 'nice' stuff is out of the way ... ;)

Dave, some questions:
(I haven't peeked at the source code yet so bear with me here :)
This is mostly picking at nits ...
I have no real gripes and find no real faults, just wouldn't want to try vieing
it on a dial-up connection. So most of what follows pertains to potential 
'bloat'.

I've opened it up and am looking at the SVG code.
I see the transform="scale(1,-1)" in a lot of places.
But in other places I see scale(1,1) ...
I have to wonder if all these local transforms are 'needed' or if there's
some sort of redundancy going on here.
Then I encountered the paths in the last half of the doc.
Take 'id="PINE CRK RD"' for instance.
It has a <path> object wrapped in a <g> object.
Both have transform="scale(1,-1)" ... so, not having tinkered with variations,
I have to ask: Are they are cancelling each other out? or Is one is redundant?
If they were redundant then that's approx. 50 bytes per double instance that
don't need to be there ...
Either way is there one transform spec too many or am I showing my ignorance?

I told you I was being picky :)

The next thing is I noticed is that the drawing primitive lists (<d>) for paths 
defined for
the 'symbols' earlier in the doc are quite different from those used for the
track lines (like the PINE CRK RD one) later.
The earlier code makes use of the efficient shortcuts like:
- relative positions (drops 6 digit absolute coord values down to 2 or 3 digit 
ones)
- dropping redundant commands - successive 'L's not needed
Am I correct in guessing that the code is different?
(like maybe the earlier stuff came from a graphics program)

The last things are just out of curiosity.
All those Terrasever maps ... did you have to collect the tiling information 
manually
or is that info derivable by code or program or provided by them?
(meaning the values for T,S,X,Y and Z and the tile name)

As for symbols, are yours adhoc or is there a clip-art collection in use?

Once again, congratulations on this.
I wish I had something 'svg'ish to share as well but my code's getting bogged 
down
trying to be too many things :)
I'll definitely study your use of the Transforms and maps.
And maybe I'll peek at the code ... but if it's C it won't mean that much to 
me.

I can grok the problems of doing your own XML parser instead of a DOM compliant
3rd party standard. I'm wearing myself out with 'parallel' development streams. 
Arghh!
I do wonder if the output would be 'efficient enough' for the picky me though 
... :)

Keep it up Dave.

Lurking and hacking in the background,
Les Johnson


Re: SVG Sample

davewissenbach+yahoo.com on Thu Jan 16 19:38:56 2003 (link), replying to msg

--- In gpsxml+yahoogroups.com, Les Johnson <lesj+m...> wrote:
> Belated congratulations to Dave W. for the SVG example.
...
> Dave, some questions:
> (I haven't peeked at the source code yet so bear with me here :)
> This is mostly picking at nits ...
> I have no real gripes and find no real faults, just wouldn't want 
to try vieing
> it on a dial-up connection. So most of what follows pertains to 
potential 
> 'bloat'.
Remember that the SVG standard includes a compressed version svgz. 
So this might keep the size down.
> 
> I've opened it up and am looking at the SVG code.
> I see the transform="scale(1,-1)" in a lot of places.

The outermost group inverts the scale. Because of this, text would 
be printed upside down if not for the (1,-1) transforms.

> But in other places I see scale(1,1) ...

Usually these are waypoint symbol definitions where I plotted or 
entered coordinates by hand.

> I have to wonder if all these local transforms are 'needed' or if 
there's
> some sort of redundancy going on here.

The scale(1,1) tranformations aren't really needed in the waypoint 
symbols. I think that eventually I'll have to provide an option to 
output waypoint symbols at different scales depending on the extent 
of the map.

> Then I encountered the paths in the last half of the doc.
> Take 'id="PINE CRK RD"' for instance.
> It has a <path> object wrapped in a <g> object.
> Both have transform="scale(1,-1)" ... so, not having tinkered with 
variations,
> I have to ask: Are they are cancelling each other out? or Is one 
is redundant?

Yes, they are cancelling each other out, but no, one is not 
redundant. The path is a named path so that when I apply the same 
path to the text path, I can apply a 1,-1 scale factor to the text 
plus path. This is necessary so that the text doesn't appear upside 
down along the text path. (I'm not too pleased with the wacky nature 
of the text path, so I might not use the SVG text path feature 
without attempting to smooth the path first.)

> If they were redundant then that's approx. 50 bytes per double 
instance that
> don't need to be there ...
> Either way is there one transform spec too many or am I showing my 
ignorance?
> 
> I told you I was being picky :)
> 
As I explained above, I was being clever. But I couldn't find a 
better way to deal with the inverted coordinate system.

> The next thing is I noticed is that the drawing primitive lists 
(<d>) for paths 
> defined for
> the 'symbols' earlier in the doc are quite different from those 
used for the
> track lines (like the PINE CRK RD one) later.
> The earlier code makes use of the efficient shortcuts like:
> - relative positions (drops 6 digit absolute coord values down to 
2 or 3 digit 
> ones)
> - dropping redundant commands - successive 'L's not needed
> Am I correct in guessing that the code is different?
> (like maybe the earlier stuff came from a graphics program)
> 
Right. Everything in the <defs></defs> section is boilerplate that 
defines the drawing of the waypoint symbols. I'm using a trial 
version of Adobe Illustrator which came with the SAMS book SVG Now 
to draw the symbols. And of course Adobe is much better at SVG than 
I am.

> The last things are just out of curiosity.
> All those Terrasever maps ... did you have to collect the tiling 
information 
> manually
> or is that info derivable by code or program or provided by them?
> (meaning the values for T,S,X,Y and Z and the tile name)
> 
The tiling information is derivable by program. The Terraserver web 
site contains instructions. See

http://terraserver.homeadvisor.msn.com/about.aspxn=AboutLinktoTerrase
rver

> As for symbols, are yours adhoc or is there a clip-art collection 
in use?
> 
No clip art. Once you other developers start publishing SVG I'll 
steal yours. Feel free to use mine. I've added to the collection but 
haven't had time to publish.

> Once again, congratulations on this.
> I wish I had something 'svg'ish to share as well but my code's 
getting bogged 
> down
> trying to be too many things :)
> I'll definitely study your use of the Transforms and maps.
> And maybe I'll peek at the code ... but if it's C it won't mean 
that much to 
> me.
> 
This is C++.
> I can grok the problems of doing your own XML parser instead of a 
DOM compliant
> 3rd party standard. I'm wearing myself out with 'parallel' 
development streams. 
> Arghh!
> I do wonder if the output would be 'efficient enough' for the 
picky me though 
> ... :)
> 
> Keep it up Dave.
> 
> Lurking and hacking in the background,
> Les Johnson

Thanks for your interest. This was a learning exercise for me that 
seemed to yield some pretty good results. 

Dave


Re: SVG Sample (and CSS rules for type)

davewissenbach+yahoo.com on Sat Jan 18 12:44:23 2003 (link), replying to msg

--- In gpsxml+yahoogroups.com, "davewissenbach 
<davewissenbach+y...>" <davewissenbach+y...> wrote:
> 
> The scale(1,1) tranformations aren't really needed in the waypoint 
> symbols. I think that eventually I'll have to provide an option to 
> output waypoint symbols at different scales depending on the 
extent 
> of the map.
> 
Correction. In waypoint symbols which are symmetric about the X axis,
I used scale(1,-1). But because of the inverted coordinate system,
the second scale factor in a waypoint symbol should be negative.

> I'm using a trial 
> version of Adobe Illustrator which came with the SAMS book SVG Now 
> to draw the symbols. And of course Adobe is much better at SVG 
than 
> I am.

Correction: The book is called "Teach Yourself SVG in 24 Hours"
The companion web site is
http://www.svgnow.com

I've made some more changes to Wissenbach map to support SVG.

The wissenbach:type and wissenbach:style elements are now part of a 
track. (The type element isn't officially part of the standard yet, 
so I'm keeping this private for now. The type element is used to 
form a CSS class selector and corresponding attritubes a boilerplate 
style element at the beginning of the SVG document. (Actually, the 
program loads this from a file, so that a use can customize and add 
their own.) Then, if the type element is present, the path uses that 
type in a class attribute.

The style element is used to get refinement on individual tracks. In 
the BogusBasin.gpx sample, the stroke: brown defined by the Dirt-
Road CSS rule is overriden by the style="color: green". A deep 
default CSS rule for paths is present in the root document's style 
element to prevent the tracks from being filled and to define the 
stroke color and width when no other tracks are present.

Dave


GML - Geography Markup Language

davewissenbach+yahoo.com on Sun Jan 19 08:46:08 2003 (link)

Geography Markup Language may be an alternative to the GPX format 
for complex maps. See

http://www.opengis.net/gml/02-069/GML2-12.html

I'm considering substituting GML for GPX in the trailmap layer of a 
new program similar to Wissenbach Map (but expressed in JAVA) and 
using GPX in the planning and logging layer. Then GPX would be used 
primarily for the originally stated purpose of data exchange.

Using the Geographic Markup Language namespace might take the 
evolutionary pressure off of the GPX schema.

Should we supporters of GPX format encourage the use of GML in the 
open-ended extension slots of GPX? Or would a better policy be 
returning to the original goal of GPX as an exchange policy and 
using a separate GML document for trailmap/basemap data?

What do you all think?


Validation error

clindh+homenet.se on Wed Jan 29 04:42:59 2003 (link)

I'm loading a GPX from geocaching.com but my XMLSpy complains:

   Your schema uses attributeFormDefault="qualified" - 
   you must specify a prefix for your schema 
   namespace "http://www.topografix.com/GPX/1.0

a) I would like to understand the error message; what is wrong
b) I assume they did something wrong when producing that gpx-file.  
Can we help to get it right?  It adds elements from their own schema:

---------------
<?xml version="1.0" encoding="utf-8"?>
<gpx xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="1.0" 
creator="Groundspeak Pocket Query" 
xsi:schemaLocation="http://www.topografix.com/GPX/1/0 
http://www.topografix.com/GPX/1/0/gpx.xsd 
http://www.groundspeak.com/cache/1/0 
http://www.groundspeak.com/cache/1/0/cache.xsd" 
xmlns="http://www.topografix.com/GPX/1/0">

<author>Groundspeak</author>
...
<wpt lat="57.69665" lon="11.979283">
	<time>2001-04-03T00:00:00.0000000-07:00</time>
...
	<groundspeak:cache id="1538" available="True"
xmlns:groundspeak="http://www.groundspeak.com/cache/1/0">
		<groundspeak:name>Americana 
Cache</groundspeak:name>
...


GPX to OziExplorer

clindh+homenet.se on Wed Jan 29 04:48:12 2003 (link)

I plan on writing an XSL, creating "Map Features" for OziExplorer. I 
have written one for .loc -> ozi waypoint files already.

But before I get busy, has anyone done this already...?



Re: Validation error

davewissenbach+yahoo.com on Wed Jan 29 19:20:58 2003 (link), replying to msg

--- In gpsxml+yahoogroups.com, "clindh2 <clindh+h...>" <clindh+h...> 
wrote:
> I'm loading a GPX from geocaching.com but my XMLSpy complains:
> 
>    Your schema uses attributeFormDefault="qualified" - 
>    you must specify a prefix for your schema 
>    namespace "http://www.topografix.com/GPX/1.0
> 
> a) I would like to understand the error message; what is wrong
> b) I assume they did something wrong when producing that gpx-
file.  
> Can we help to get it right?  It adds elements from their own 
schema:
> 

<gpx
  xmlns="http://www.topografix.com/GPX/1/0"
  version="1.0" creator="Wissenbach Map 2.0.3"
  xmlns:wissenbach="http://www.cableone.net/cdwissenbach"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://www.topografix.com/GPX/1/0 
http://www.topografix.com/GPX/1/0/gpx.xsd
                       http://www.cableone.net/cdwissenbach 
http://www.cableone.net/cdwissenbach/wissenbach.xsd">

The above is a output from Wissenbach Map. You'll find many such 
files at 
http://myweb.cableone.net/cdwissenbach/

I think that what they did wrong is leave out

xmlns="http://www.topografix.com/GPX/1/0"

Because this is xmlns instead of xmlns:gpx, the validator knows that 
unqualified attributes are in the GPX namespace. The section on 
schema location doesn't help the validator determine which attribute 
qualifier goes with which namespace.

They also left out xmlns:groundspeak= in the gpx element. So 
although groundspeak documents may validate on their own, they 
probably won't.

But really, your guess is as good as mine

Dave
> ---------------
> <?xml version="1.0" encoding="utf-8"?>
> <gpx xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
version="1.0" 
> creator="Groundspeak Pocket Query" 
> xsi:schemaLocation="http://www.topografix.com/GPX/1/0 
> http://www.topografix.com/GPX/1/0/gpx.xsd 
> http://www.groundspeak.com/cache/1/0 
> http://www.groundspeak.com/cache/1/0/cache.xsd" 
> xmlns="http://www.topografix.com/GPX/1/0">
> 
> <author>Groundspeak</author>
> ...
> <wpt lat="57.69665" lon="11.979283">
> 	<time>2001-04-03T00:00:00.0000000-07:00</time>
> ...
> 	<groundspeak:cache id="1538" available="True"
> xmlns:groundspeak="http://www.groundspeak.com/cache/1/0">
> 		<groundspeak:name>Americana 
> Cache</groundspeak:name>
> ...


Re: [gpsxml] GPX to OziExplorer

clindh+homenet.se on Thu Jan 30 08:32:35 2003 (link)


Interesting, tell me more ;-)

I completed my XSL for waypoints yesterday; my main use is to import geocaches so I can see them on detailed maps.
  ----- Original Message ----- 
  From: Chris Schulz 
  To: gpsxml+yahoogroups.com 
  Sent: Wednesday, January 29, 2003 21:51
  Subject: Re: [gpsxml] GPX to OziExplorer


  no,  but i have a gpx<->ozi<->gpx parser too!!

  perhaps we could swap and steal each others ideas?

  c.




  At 12:48 29/01/2003 +0000, you wrote:
  >I plan on writing an XSL, creating "Map Features" for OziExplorer. I
  >have written one for .loc -> ozi waypoint files already.
  >
  >But before I get busy, has anyone done this already...?
  >
  >
  >
  >Yahoo! Groups Sponsor
  >ADVERTISEMENT
  ><http://rd.yahoo.com/M=233351.2876045.4223503.2848452/D=egroupweb/S=1706030390:HM/A=1341247/R=0/*https://www.gotomypc.com/tr/yh/grp/300_mapG/g22lp?Target=mm/g22lp.tmpl>e0ae559.jpg 
  >
  >e0ae5fa.jpg
  >
  >To unsubscribe from this group, send an email to:
  >gpsxml-unsubscribe+yahoogroups.com
  >
  >
  >
  >Your use of Yahoo! Groups is subject to the 
  ><http://docs.yahoo.com/info/terms/>Yahoo! Terms of Service.

        Yahoo! Groups Sponsor 
              ADVERTISEMENT
             
       
       

  To unsubscribe from this group, send an email to:
  gpsxml-unsubscribe+yahoogroups.com



  Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. 


------?extPart_000_05AC_01C2C885.8E5A8DE0

Re: [gpsxml] GPX to OziExplorer

robertlipe+usa.net on Thu Jan 30 09:16:40 2003 (link), replying to msg

> I plan on writing an XSL, creating "Map Features" for OziExplorer. I 
> have written one for .loc -> ozi waypoint files already.

It's not XSL, but GPSBabel (http://gpsbabel.sourceforge.net) reads and
writes all three of those formats plus about two dozen others.

RJL

Re: [gpsxml] Validation error

robertlipe+usa.net on Thu Jan 30 09:18:58 2003 (link), replying to msg

> I'm loading a GPX from geocaching.com but my XMLSpy complains:

That's depressingly easy to do.   I frequently get complaints from
users of geocaching.com's GPX files that gpsbabel is choking on them.
Every time I've analyzed it, it's been illegal characters in logs, but
your case looks different.

RJL

Re: [gpsxml] GPX to OziExplorer

robertlipe+usa.net on Thu Jan 30 14:48:19 2003 (link), replying to msg

> yes... but not very well... symbols and other attributes are not 
> transformed, basically lat, lon and name only.

They're transformed for some file types and not for others.   Contributions
to the icon mapping tables are welcome.

Since I don't use Ozi, I wasn't motivated to do it.   

RJL

Re: GPX to OziExplorer

clindh+homenet.se on Mon Feb 03 02:25:32 2003 (link), replying to msg

--- In gpsxml+yahoogroups.com, "clindh2 <clindh+h...>" <clindh+h...> 
wrote:
> I plan on writing an XSL, creating "Map Features" for OziExplorer. 

OK, if anyone is interested I know have
- XSL for transforming GPX to Ozi .wpt-format
- XSL for transforming GPX + groundspeak:cache to HTML
- Perl-script for splitting the output from the HTML-XSL into 
individual files

I created these to have a local store for information about geocaches 
in my area. The .wpt-file is created so each waypoint points to an 
attached file; the HTML-file created by the HTML-converter. Thus it's 
easy to look up information about caches even when not online.



Validated file doesn't open

gpx+andrew-stock.com on Mon Mar 03 01:50:16 2003 (link)

Hi,

I have written a program for my pocket pc to plot my position and 
save the route I've taken as a <rte> in gpx format.  The output 
files from the program validate fine as explained on the topografix 
website, but when I try to open them in EasyGPS (or GPS Utility) it 
appears that there's no data there.

Below is a cut down extract which also validates and doesn't load.  
I would really appreciate it if anyone could suggest something that 
I've missed as I'm fairly new to this.

Regards

Andrew

<?xml version="1.0" encoding="ISO-8859-1" standalone="yes"?>
<gpx
version = "1.0"
creator = "CE Moving Map"
xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance"
xmlns = "http://www.topografix.com/GPX/1/0"
xmlns:topografix 
= "http://www.topografix.com/GPX/Private/TopoGrafix/0/2"
xsi:schemaLocation="http://www.topografix.com/GPX/1/0 
http://www.topografix.com/GPX/1/0/gpx.xsd 
http://www.topografix.com/GPX/Private/TopoGrafix/0/2 
http://www.topografix.com/GPX/Private/TopoGrafix/0/2/topografix.xsd">
<rte>
<name>Test Route</name>
<rtept lat="52.1971216666667" lon="0.124701666666667">
<name>Point 1</name>
</rtept>
<rtept lat="52.197135" lon="0.124698333333333">
<name>Point 2</name>
</rtept>
<rtept lat="52.1971483333333" lon="0.124701666666667">
<name>Point 3</name>
</rtept>
<rtept lat="52.1971566666667" lon="0.124695">
<name>Point 4</name>
</rtept>
<rtept lat="52.19716" lon="0.124683333333333">
<name>Point 5</name>
</rtept>
</rte>
</gpx>


Re: [gpsxml] Validated file doesn't open

egroups+topografix.com on Mon Mar 03 11:48:10 2003 (link), replying to msg

Hello,

Monday, March 3, 2003, 4:43:35 AM, Andrew wrote:

a> Hi,

a> I have written a program for my pocket pc to plot my position and 
a> save the route I've taken as a <rte> in gpx format.  The output 
a> files from the program validate fine as explained on the topografix 
a> website, but when I try to open them in EasyGPS (or GPS Utility) it 
a> appears that there's no data there.

a> Below is a cut down extract which also validates and doesn't load.  
a> I would really appreciate it if anyone could suggest something that 
a> I've missed as I'm fairly new to this.

a> Regards

a> Andrew

a> <?xml version="1.0" encoding="ISO-8859-1" standalone="yes"?>
a> <gpx
a> version = "1.0"
a> creator = "CE Moving Map"
a> xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance"
a> xmlns = "http://www.topografix.com/GPX/1/0"
a> xmlns:topografix 
a> = "http://www.topografix.com/GPX/Private/TopoGrafix/0/2"
a> xsi:schemaLocation="http://www.topografix.com/GPX/1/0 
a> http://www.topografix.com/GPX/1/0/gpx.xsd 
a> http://www.topografix.com/GPX/Private/TopoGrafix/0/2 
a> http://www.topografix.com/GPX/Private/TopoGrafix/0/2/topografix.xsd">

Your GPX file passes the validator test, so it's a legal file.
EasyGPS is broken.  I traced the problem to the spacing around the
equal sign in lines like version = "1.0" - most XML files are spaced
this way: version="1.0".

I fixed the problem in EasyGPS and the rest of my programs.

By the way, you shouldn't include the TopoGrafix private namespace
in your files unless you're actually using something from them.  (And
I should probably fix EasyGPS to only include them where needed.)

Keep us posted on your PocketPC application!

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com


Re: Validated file doesn't open

murphy+enterprise.net on Tue Mar 04 05:20:04 2003 (link), replying to msg

Andrew,

Which version of GPS Utility are you using?  I used the current
standard version of GPSU (4.04.7) to open your extracted file OK.

If you have a file that does not open in GPSU 4.04.7, then please send
it me so I can examine the problem.

Alan Murphy  (author GPSU)

On 4 Mar 2003 09:32:52 -0000, you wrote:
>   Date: Mon, 03 Mar 2003 09:43:35 -0000
>   From: "andrew_c_stock <gpx+andrew-stock.com>" <gpx+andrew-stock.com>
>Subject: Validated file doesn't open
>
>Hi,
>
>I have written a program for my pocket pc to plot my position and 
>save the route I've taken as a <rte> in gpx format.  The output 
>files from the program validate fine as explained on the topografix 
>website, but when I try to open them in EasyGPS (or GPS Utility) it 
>appears that there's no data there.
>
>Below is a cut down extract which also validates and doesn't load.  
>I would really appreciate it if anyone could suggest something that 
>I've missed as I'm fairly new to this.
>
>Regards
>
>Andrew

Re: [gpsxml] Re: Validated file doesn't open

acs39+cam.ac.uk on Tue Mar 04 06:43:25 2003 (link)


Hi,

First of all thanks for the support on this!  I have attached a file
(Route.gpx) which I have tried opening in GPS Utility 4.04.7.  I am not sure
whether this is just me using the program incorrectly!  I load the file and
then go to View -> Routes and I get the name "Test Route" appear as one of
the routes, but under it it just says POINT and has only one.
I wondered whether this was a limitation of the free version not having so I
tried with another file with only 5 data points and I can't get this to
appear.  It's quite possible that I'm mis-using your program!
Regards

Andrew

  ----- Original Message ----- 
  From: Alan Murphy 
  To: gpsxml+yahoogroups.com 
  Sent: Tuesday, March 04, 2003 1:20 PM
  Subject: [gpsxml] Re: Validated file doesn't open


  Andrew,

  Which version of GPS Utility are you using?  I used the current
  standard version of GPSU (4.04.7) to open your extracted file OK.

  If you have a file that does not open in GPSU 4.04.7, then please send
  it me so I can examine the problem.

  Alan Murphy  (author GPSU)

  On 4 Mar 2003 09:32:52 -0000, you wrote:
  >   Date: Mon, 03 Mar 2003 09:43:35 -0000
  >   From: "andrew_c_stock <gpx+andrew-stock.com>" <gpx+andrew-stock.com>
  >Subject: Validated file doesn't open
  >
  >Hi,
  >
  >I have written a program for my pocket pc to plot my position and 
  >save the route I've taken as a <rte> in gpx format.  The output 
  >files from the program validate fine as explained on the topografix 
  >website, but when I try to open them in EasyGPS (or GPS Utility) it 
  >appears that there's no data there.
  >
  >Below is a cut down extract which also validates and doesn't load.  
  >I would really appreciate it if anyone could suggest something that 
  >I've missed as I'm fairly new to this.
  >
  >Regards
  >
  >Andrew

        Yahoo! Groups Sponsor 
              ADVERTISEMENT
             
       
       

  To unsubscribe from this group, send an email to:
  gpsxml-unsubscribe+yahoogroups.com



  Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. 

------?extPart_001_012D_01C2E25C.6AEEAAD0

Re: Validated file doesn't open

murphy+enterprise.net on Wed Mar 05 11:10:03 2003 (link), replying to msg

Thanks for your files. 

The problem is that default length for Waypoint ID name in GPSU is set
to 6 characters and GPSU is not changing this default setting on
reading a GPX file. Thus your waypoints with names 'POINT 1' etc. are
all being truncated to 'POINT ' (6 chars).

This is a bug, which I have now fixed. The fix will be in the next
version which will be released in a day or so. (4.04.8).

The workarounds are 
1) Select Options|Field Properties in GPSU and manually set the ID
length to, say, 10 characters. GPSU version 4.04.7 will then read your
Route2.gpx file. 

2). Write your file with IDs no longer than 6 characters.

Your 'Route.gpx' file exceeds the capacity limitations of the freeware
version and so this file cannot be fully read in. (It contains 346
waypoints).

Many thanks for the bug report.

Alan Murphy (author GPSU)

On 5 Mar 2003 09:38:45 -0000, you wrote:

>Message: 2
>   Date: Tue, 4 Mar 2003 14:43:27 -0000
>   From: "Andrew Stock" <acs39+cam.ac.uk>
>Subject: Re: Re: Validated file doesn't open
>
>Hi,
>
>First of all thanks for the support on this!  I have attached a file
>(Route.gpx) which I have tried opening in GPS Utility 4.04.7.  I am not sure
>whether this is just me using the program incorrectly!  I load the file and
>then go to View -> Routes and I get the name "Test Route" appear as one of
>the routes, but under it it just says POINT and has only one.
>I wondered whether this was a limitation of the free version not having so I
>tried with another file with only 5 data points and I can't get this to
>appear.  It's quite possible that I'm mis-using your program!
>Regards
>
>Andrew
>



Prelaunch Intro of GPXchange.com

fred96161+usamedia.tv on Wed Mar 05 16:02:44 2003 (link)

GPXchange.com is in development. It will serve as a central database 
for authors to make their GPX data available on a free or commercial 
basis. The rapid evolution of our other sites, Offroute.com and 
Topostore.com will provide a high profile mechanism for encouraging 
the adoption and use of this valuable file format. Visit 
www.topostore.com/index.asp?ref=ng for an example of where GPX files 
will soon be visible.

The founders of Offroute, Inc. have a combined history in the 
Outdoor Industry of approximately 40 years. Both built successful 
multi-million dollar companies in the past and intend to leverage 
their knowledge and relationships within the outdoor industry to 
promote the widespread adoption of GPX.

Please visit www.GPXchange.com for more pre-launch information. We 
are anxious to hear suggestions, comments and criticisms regarding 
our plans and a link is provided for that purpose.

Coming from the perspective of active outdoor enthusiasts, it is our 
intent to provide a mechanism to disseminate GPX data as it provides 
access to information that will otherwise remain unavailable on 
published maps or in guidebooks. 

Our thanks to all of those who have worked hard to create and 
maintain the current GPX schema.

Fred Williams
Co-founder, Offroute, Inc.


GPX pages still lack richness(?)

gps_maps+yahoo.com on Sun Mar 09 02:42:04 2003 (link)

The announcement of GPXchange motivates me catch-up on GPX 
development.  Back in April 2002, I commented here (message 256) on 
how the examples I'd seen "lack richness."  At the time, no one had 
published any GPX pages that included elements I felt essential to 
describing the embedded GPS data - like pictures and tables.  Now, 
I've gone back to look at the examples linked from 
http://www.topografix.com/gpx_sample_files.asp and it seems that 
little has changed in regard to the look of the pages. The examples 
still read vertically, from top to bottom using font and indention to 
set apart content. Are there other examples I should look at?
- Doug Adomatis
  www.travelbygps.com
  Moderator, Map Authors Group
    http://groups.yahoo.com/group/map_authors/



Driving Directions and Expertgps

mroseto+qcicleveland.com on Mon Mar 10 11:21:18 2003 (link)

Is there any way to upload driving directions from an internet source 
into expertgps? I used to be able to with mapblast but modifications 
to the website has eliminated this possiblity. Thanks for the help in 
advance.

Mike




Re: [gpsxml] Driving Directions and Expertgps

murphy+enterprise.net on Tue Mar 11 02:06:07 2003 (link), replying to msg

You could try MapsOnUs (www.mapsonus.com) and GPS Utility
(www.gpsu.co.uk).  GPSU will read html files produced by MapsOnUs and
export the data as a GPX interchange file which you can import to
ExpertGPS. See the Help topic on 'MapsOnUs'

European users can use Greenflag  (www.greenflag.com) instead of
MapsOnUs. 

The freeware version of GPSU is capacity limited, but more or less
fully functional. See the Help topic on 'Freeware' for details. 

HTH
Alan Murphy (author GPSU)


On 11 Mar 2003 08:25:17 -0000, you wrote:
>   Date: Mon, 10 Mar 2003 19:21:11 -0000
>   From: "mroseto729" <mroseto+qcicleveland.com>
>Subject: Driving Directions and Expertgps
>
>Is there any way to upload driving directions from an internet source 
>into expertgps? I used to be able to with mapblast but modifications 
>to the website has eliminated this possiblity. Thanks for the help in 
>advance.
>


NNEA to GML

pablogh_2000+yahoo.com on Mon Mar 24 08:19:44 2003 (link)

Hi all, 
 
I have to develop a GPS tracking application for industry vehicles. 
 
What I want to do is: 
 
1. read NMEA data from the GPS devices, 
2. read other data specific to vehicles, 
3. send it to a sever, where they will put together in a GML file, 
4. send this GML file to the GeoServer free application to save the 
data in a 
PostGIS database, 
5. read the updated data with MapServer. 
 
My problem comes in point 3. 
Do you know how to solve this matter? 
 
Thanks in advance, and sorry for any inconviniences. 
 
Regards, 
 
Pablo Ghiglino 
 


The Commercialization of Exchanging GPS Data

gps_maps+travelbygps.com on Fri Mar 28 03:45:43 2003 (link)

Here is an article I've written in response to the introduction of 
GPXchange.com.  Your comments are welcome.
----------

Finding your way is getting a little easier, but it may cost you a 
little more. Offroute, Inc.'s GPXchange(tm) promises widespread 
adoption of a common GPS data format by hosting a large central 
database and charging for its use.  While commercializing the 
customarily free practice of exchanging GPS data may be distasteful 
to some, the proposed business model is appealing to freelance 
authors who create quality trail guide content.

Traditionally, if you wanted to find the geographic coordinates for 
points of interest in poorly documented places, you would post your 
query to Internet newsgroups.  And if you were lucky, some kind soul 
would reply, pointing you to a collection of GPS data somewhere on 
the web.

GPS data collections found online are mostly lists of coordinates 
(waypoints) in various forms.  If you were just looking for a single 
point - say a dive site on the Great Barrier Reef - it would be 
simple enough to write down the latitude and longitude, but if you 
needed an entire route (a series of waypoints) or an even a more 
detailed track, you would hope to find a data file.  However, there 
is no standard format for these GPS data files, which makes it 
difficult to share them unless each person uses software capable of 
reading the other's files.
 
In September 2001, a forum of developers started creating a common 
format for exchanging GPS data, called GPX. The GPX format is based 
on Extensible Markup Language (XML), which is ideally suited for the 
interchange of data between applications and Internet services.  
Within a few months, development was completed on the basic GPX 
schema, which effectively stores and presents GPS waypoints, routes 
and tracks.  The GPX format caught the eye of Offroute, which has 
adopted it as the basis for a large, commercialized central database -
 GPXchange.

The pre-launch information at www.gpxchange.com describes a plan 
whereby consumers and contributing authors will be charged fees to 
download GPX files and pay for use of the database facilities.  
Authors will be able to charge consumers for downloading their files, 
which will help them recover subscriptions fees, but - and here's the 
rub - consumers will have to pay a transaction fee even if the author 
designates his files as free.

In the introduction of GPXchange.com to the GPX developer's forum, 
three questions were posed to those who object to its commercial 
aspects.  Although I do not necessarily object, I would like to offer 
my feedback along with some examples of how I address related issues.

1. Will GPX ever truly realize its potential if a high-quality, 
central database is not in place that provides easy access to the 
wealth of data it can provide? 

I think that realization of GPX's potential depends more on how many 
applications adopt the format, rather than how many databases (or how 
few) host GPX files.  That said, I do believe that GPXchange will 
indeed help the GPX format flourish in areas where Offroute and its 
partners have an interest.

The basic GPX format can be extended to include more than just GPS 
data. The pre-launch information indicates that Offroute is 
developing applications for authors to create and manage GPX files - 
files that can include guidebook-like images and text.   In that 
respect, it would seem appropriate for traditional authors/ travel 
writers to use the GPX format for communicating guidebook 
information.  I'll say more about printed materials in a moment.

Return now to the idea of exchanging data between GPS navigation and 
mapping software applications.  In the absence of a standard, at 
Travel by GPS (www.travelbygps.com) I often publish more than one 
format for the same data.  Typically, I will provide a free data file 
in GPX or another format that can be read by free software.  In many 
cases I also provide data in the format most suited for the 
adventure.  For example, most of my self-drive sightseeing maps are 
in Delorme's (.dmt) Map Transfer format for use with Street Atlas(r) 
car-navigation software.  This format allows me to use drawing layers 
and driving directions to more effectively communicate GPS-guided 
tour information.  Publishing multiple formats is a hassle, but until 
a standard is adopted, I find it necessary.

2. Will the information housed within this centralized database grow 
dramatically in size and quality without a means to compensate 
authors for their efforts and expertise?

While offering compensation may increase the number of contributions, 
the quality of the database as a whole may diminish unless measures 
are taken to discourage authors from cranking out junk and passing it 
off as first-rate.  

Quality of content is important to me at Travel by GPS. First and 
foremost, I am the editor-in-chief, and I enjoy building 
relationships with every contributor. In addition to my personal 
assurances, there are quality indicators on each GPS Map description 
page.  Each GPS Map has a data classification rating so that patrons 
will know what to expect in regard to accuracy of the data provided. 

Hans Wain, Offroute co-founder, explained the quality measures that 
are to be employed at GPXchange.  Wain explains that every publicly 
posted GPX file at GPXchange will include user reviews as they become 
available, and authors will be reviewed and rated separately from the 
individual files.

While compensating authors for quality content is good, protecting 
their works from unauthorized distribution is even more important.    
The basic GPX format does not include any copyright protection 
elements.  So, the distributors of protected material must shoulder 
more of the burden.  The founders of GPXchange have shown their 
intent to keep intellectual property safe, but in reality there is 
little you can do to prevent someone from acquiring information 
legitimately and redistributing it.

At Travel by GPS, stealing GPS data is not an issue because I seek 
permission from every contributor to freely provide their information 
without restriction.

3. And finally, regardless of depth and quality of the database, 
won't more potential users of this information benefit if it is 
actively promoted by a network of both physical and online entities 
that facilitate its use through printed representations as well as 
downloads alone?

Build-it and they will come.  The number of people who own a GPS is 
increasing, and to a lesser degree, the number of people who have the 
ability and desire to download GPS data is also increasing.  Offering 
GPX data overlays with custom maps and documents will indeed help 
expand the market to include those who have yet to be bitten by the 
GPS bug.

GPXchange will not be the first online endeavor to offer printable 
mini-guides for outdoor recreation.  Trails.com offers trail guides 
for activities like hiking, biking, and paddling called eTrails (not 
to be confused with eTRAIL CD-ROM of UK walking routes by Garmin 
Europe Ltd/Emap Active Ltd).  Each eTrail includes detailed trail 
descriptions, directions to the trailhead, and custom map images.  
The eTrail format can be opened by Adobe Acrobat eBook Reader and 
printed out on your home computer.  eTrail downloads do not include 
GPS data, and they are not authored by individual contributors.  
eTrail content comes from published guidebooks, like those from 
Falcon Publishing.

Early on, I realized the value of overlaying the GPS data on 
printable maps and mini-guides.  In 1999 and 2000, I published 
printable GPS Guides as companions to my "17-Mile Drive", "Historic 
Charleston", "Chattahoochee River", and "Mobile Bay GPS Maps".  These 
guides included map images, detailed waypoint and route descriptions, 
driving directions, trail length/difficulty tables, and a scenic 
photo in paper form, which could be stuffed in a back pocket or glove 
box.  I decided to stop producing the printable guides because they 
took too much time to write and maintain without compensation.

Providing a means of compensation is where I believe GPXchange offers 
a great opportunity for freelance authors.  Moreover, GPXchange will 
provide authors with greater exposure to wider audience - an audience 
willing to pay for quality trail guides. 

In regard to the GPXchange business model, Wain explains that 
the "barriers will be extremely low" for authors and that transaction 
fees for consumers will be on the order of cents, not dollars.  Wain 
goes on to explain that the profitability of GPXchange will depend 
more on other commercial aspects and depend less on author 
subscription and consumer transactions fees.  

As for Travel by GPS, I plan to continue providing free GPS maps 
waypoints and tracks for adventure travel.  As for Doug Adomatis, 
freelance author, having another outlet for publishing trail guides 
is appealing.

I hope this helps!
Doug Adomatis
Owner, Travel by GPS (www.travelbygps.com)


Perl tools?

ptomblin+xcski.com on Sun Mar 30 17:58:16 2003 (link)

Allow me to introduce myself.  I have a web site, http://navaid.com/,
where I allow end users to generate aviation databases for two Palm OS
programs used for flight planning, CoPilot (http://navaid.com/CoPilot/)
and GPSPilot (http://navaid.com/GPSPilot/).  One of the common requests I
have is for files that people can load into their GPSes - but I never
could figure out what sort of format would be best for each type of GPS.
It looks like GPX is exactly what I need.

Is anybody out there making GPX files using Perl?  Do you have any special
tools to do so, or just rolling your own?


-- 
Paul Tomblin <ptomblin+xcski.com>, not speaking for anybody
"I think there is a world market for maybe five computers."
--Thomas Watson, chairman of IBM, 1943.

Re: [[gpsxml] Perl tools?]

robertlipe+usa.net on Sun Mar 30 18:50:16 2003 (link)

Paul Tomblin <ptomblin+xcski.com> wrote:

> One of the common requests I
> have is for files that people can load into their GPSes - but I never
> could figure out what sort of format would be best for each type of GPS.
> It looks like GPX is exactly what I need.

Parsing GPX files with XML::Twig isn't too terrible at all.   It delivers a
callback with members that can be iterated through pretty easily.

If I understand the goal of your site correctly, yes, GPX sounds like just the
ticket for you.  It allows you to deliver the data and then let the end-user
pick whatever tool he wants to use for plunking them onto a map or stuffing
them into a receiver or so on.

There's a growing number of GPX-capable programs at:
http://www.topografix.com/gpx_resources.asp


Extra information

ptomblin+xcski.com on Mon Mar 31 17:25:45 2003 (link)

How much room does your average GPS have for extra text?  My CoPilot and
GPSPilot databases give all sorts of extra information for the waypoint,
like runway designations and lengths and communications frequencies, and
I'm wondering how much room I've got for extra information.  My 
Garmin 195 isn't handy right now, but I seem to recall it only had about a
hundred characters or of storage for user defined waypoints, so not enough
for that sort of thing.

Is there any point putting all this extra info in the xml file?  If so,
what field should I use?

Also, can I put newlines in a text field?  Do I put real newlines, or
"\n"?


-- 
Paul Tomblin <ptomblin+xcski.com>, not speaking for anybody
Quando omni flunkus moritati (when all else fails play dead)

Re: [gpsxml] Extra information

egroups+topografix.com on Tue Apr 01 10:10:07 2003 (link), replying to msg

Hello Paul,

Monday, March 31, 2003, 8:24:12 PM, you wrote:

P> How much room does your average GPS have for extra text?  My CoPilot and
P> GPSPilot databases give all sorts of extra information for the waypoint,
P> like runway designations and lengths and communications frequencies, and
P> I'm wondering how much room I've got for extra information.  My 
P> Garmin 195 isn't handy right now, but I seem to recall it only had about a
P> hundred characters or of storage for user defined waypoints, so not enough
P> for that sort of thing.

P> Is there any point putting all this extra info in the xml file?  If so,
P> what field should I use?

P> Also, can I put newlines in a text field?  Do I put real newlines, or
P> "\n"?

I'd suggest putting as much private information as possible in the GPX files
you create.  If it's in there, someone will find a way to use it.  A
good example is the way that geocaching.com is using GPX.  They're
putting lots of private data in their GPX files, all defined within
their private "groundspeak" schema.  None of that data makes it to GPS
receivers by default, but there's a whole group of add-on programs
that have sprung up to convert and display that extra data.

A similar thing should be done for aviation data.  You might want to
get together with the guys at http://www.aeroplanner.com, who already
use XML for distributing data, and have expressed an interest in GPX.
If you can come to an agreement on a standardized private namespace
for aviation extensions to GPX, then you'll probably find that users
will start creating applications to use the extra data in your GPX
files.

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com


Re: [gpsxml] Extra information

ptomblin+xcski.com on Tue Apr 01 10:39:20 2003 (link), replying to msg

Quoting Dan Foster (egroups+topografix.com):
> 
> P> Is there any point putting all this extra info in the xml file?  If so,
> P> what field should I use?

> A similar thing should be done for aviation data.  You might want to
> get together with the guys at http://www.aeroplanner.com, who already
> use XML for distributing data, and have expressed an interest in GPX.
> If you can come to an agreement on a standardized private namespace
> for aviation extensions to GPX, then you'll probably find that users
> will start creating applications to use the extra data in your GPX
> files.

Thanks to Brian Scearce, I now have a copy of gpsbabel.  I think, since I
already know the format of CoPilot and GPSPilot (and I think FlyByNav,
which I reverse engineered a while ago before told me that they'd "make
life difficult" if I were to make a waypoint generator for them), I may
make my generator for GPX do the basics, and then write translator code
for gpsbabel for those format.

BTW: This is what I have so far for my wpt records.  Does it look right to
you?

<wpt lat="37.6592777777778" lon="-122.122416666667">
<name>KHWD</name>
<elev>50</elev>
<cmt><![CDATA[HAYWARD EXECUTIVE,HAYWARD,CA,US]]></cmt>
<type><![CDATA[AIRPORT]]></type>
<src><![CDATA[FAA]]></src>
</wpt>

Actually, since "type" and "src" can only have letters, slashes and
dashes, I'm probably going to eliminate the CDATA escape for those.

-- 
Paul Tomblin <ptomblin+xcski.com>, not speaking for anybody
Company slogan:  The Mandatory Beatings Will Continue Until Morale
Improves.

Re: [gpsxml] Extra information

robertlipe+usa.net on Tue Apr 01 10:55:56 2003 (link), replying to msg

Paul Tomblin wrote:

> Thanks to Brian Scearce, I now have a copy of gpsbabel.  I think, since I

While I appreciate Brian's hand, GPSBabel shouldn't be hard to get.
It's free and it's open. http://gpsbabel.sourceforge.net

> already know the format of CoPilot and GPSPilot (and I think FlyByNav,
> which I reverse engineered a while ago before told me that they'd "make
> life difficult" if I were to make a waypoint generator for them), I may
> make my generator for GPX do the basics, and then write translator code
> for gpsbabel for those format.

If the code comes with a promise that someone is going to "make life
difficult", please feel free to NOT contribute that code to GPSBabel.  :-)

But you certainly have the right idea: write the data once as GPX
and then let converters like GPSBabel sling them to GPSes and other
applications that have not yet seen the light of GPX.

> BTW: This is what I have so far for my wpt records.  Does it look right to
> you?

The authoritative question is, "how does it look to a validating
parser?"  Grab a copy of SAXCount (it, too, is free and open) and point
it at your output.

RJL

Re: [gpsxml] Extra information

ptomblin+xcski.com on Tue Apr 01 12:34:27 2003 (link), replying to msg

Quoting Robert Lipe (robertlipe+usa.net):
> Paul Tomblin wrote:
> 
> > Thanks to Brian Scearce, I now have a copy of gpsbabel.  I think, since I
> 
> While I appreciate Brian's hand, GPSBabel shouldn't be hard to get.
> It's free and it's open. http://gpsbabel.sourceforge.net

What I mean is that Brian told me about it.  I'd never heard of it before.

> > BTW: This is what I have so far for my wpt records.  Does it look right to
> > you?
> 
> The authoritative question is, "how does it look to a validating
> parser?"  Grab a copy of SAXCount (it, too, is free and open) and point
> it at your output.

SAXCount counted the elements.  That tells me that it's valid XML, it
doesn't tell me if it looks like I've got the wrong idea about what should
be going in the <cmt> field or I've got the sign of my longitudes
backwards or something.

BTW: Does EasyGPS work under Wine?  I can't seem to get it to work.

-- 
Paul Tomblin <ptomblin+xcski.com>, not speaking for anybody
Experience is that marvelous thing that enables you recognize a
mistake when you make it again.  -- F. P. Jones

Re: [Re: [gpsxml] Extra information]

robertlipe+usa.net on Tue Apr 01 12:44:35 2003 (link)


> SAXCount counted the elements.  That tells me that it's valid XML,

That's good.

> it
> doesn't tell me if it looks like I've got the wrong idea about what should
> be going in the <cmt> field or I've got the sign of my longitudes
> backwards or something.

You'll want to do sanity checks by laying them on a mapping program to catch
that case.   By quick inspection, your stuff looked believable to me. 

> BTW: Does EasyGPS work under Wine?  I can't seem to get it to work.

I was never able to make it work, but I'm not much of a Wine-o.   Needing
something that read geocaching.locs and wrote to magellans that ran under UNIX
was the  original motivation for what became GPSBabel. :-)

RJL


Nearly ready

ptomblin+xcski.com on Tue Apr 01 17:56:05 2003 (link)

I've got a preliminary cut of my "GPX Aviation Waypoint Generator" up at
http://navaid.com/GPX/
Go there and choose the area of the world and the types of waypoints you
want, and it will generate it and you can download it.

Obviously I need to do a proper logo for it, but other than that it seems
like it's working.

-- 
Paul Tomblin <ptomblin+xcski.com>, not speaking for anybody
UNIX was half a billion (500000000) seconds old on
Tue Nov  5 00:53:20 1985 GMT (measuring since the time(2) epoch).
		-- Andy Tannenbaum

Re: [gpsxml] Nearly ready

ptomblin+xcski.com on Wed Apr 02 06:05:07 2003 (link), replying to msg

Quoting Robert Lipe (robertlipe+usa.net):
> 
> You might want to set the mime type on the actual file being output so
> that the browser can know what to do with the data ("save as..." or
> "open with...") instead of just splashing it to the user for text.

Unfortunately it's whatever apache on the hosting company sets by default
for gpx file.  I don't know how to override that in .htaccess.


-- 
Paul Tomblin <ptomblin+xcski.com>, not speaking for anybody
"Usenet is like a herd of performing elephants with diarrhea -- massive,
difficult to redirect, awe-inspiring, entertaining, and a source of mind-
boggling amounts of excrement when you least expect it."  - spaf (1992)

Re: [gpsxml] Nearly ready

ptomblin+xcski.com on Wed Apr 02 15:10:14 2003 (link), replying to msg

Quoting Robert Lipe (robertlipe+usa.net):
> You might want to set the mime type on the actual file being output so
> that the browser can know what to do with the data ("save as..." or
> "open with...") instead of just splashing it to the user for text.

I figured out how to do that in the .htaccess file.  Now it's
application/octet-stream, so it gets saved.

I've also got a logo and fixed the donation page links, so I think it's
ready for prime time.

-- 
Paul Tomblin <ptomblin+xcski.com>, not speaking for anybody
"We all agree that your theory is crazy, but is it crazy enough?"
     - Niels Bohr (1885-1962)

Re: [gpsxml] Nearly ready

ptomblin+xcski.com on Wed Apr 02 15:25:46 2003 (link), replying to msg

Quoting Robert Lipe (robertlipe+usa.net):
> > I figured out how to do that in the .htaccess file.  Now it's
> > application/octet-stream, so it gets saved.
> 
> You really want it to be something that triggers a specific application
> to be launched that knows how to handle it.   Look at the geocaching
> stuff for an example of how this can work.

Is there a common mime type for GPX files?

-- 
Paul Tomblin <ptomblin+xcski.com>, not speaking for anybody
"Leave the beaten track occasionally, and dive into the woods. You will be
certain to find something that you have never seen before."
  -- Alexander Graham Bell

RE: [gpsxml] Nearly ready

chris+groundspeak.com on Wed Apr 02 15:35:04 2003 (link), replying to msg


If you just want to send a GPX file down from a web server, you should
serve it as text/xml. 
 
So, not being familiar with htaccess that well, I would guess something
like:
 
AddType text/xml .gpx
 
Chris
 
 
-----Original Message-----
From: Paul Tomblin [mailto:ptomblin+xcski.com] 
Sent: Wednesday, April 02, 2003 3:24 PM
To: gpsxml+yahoogroups.com
Subject: Re: [gpsxml] Nearly ready
 
Quoting Robert Lipe (robertlipe+usa.net):
> > I figured out how to do that in the .htaccess file.  Now it's
> > application/octet-stream, so it gets saved.
> 
> You really want it to be something that triggers a specific
application
> to be launched that knows how to handle it.   Look at the geocaching
> stuff for an example of how this can work.

Is there a common mime type for GPX files?

-- 
Paul Tomblin <ptomblin+xcski.com>, not speaking for anybody
"Leave the beaten track occasionally, and dive into the woods. You will
be
certain to find something that you have never seen before."
  -- Alexander Graham Bell




Yahoo! Groups Sponsor


ADVERTISEMENT
 
<http://rd.yahoo.com/M=245454.3115308.4434529.1728375/D=egroupweb/S=1706
030390:HM/A=1457554/R=0/*http:/ipunda.com/clk/beibunmaisuiyuiwabei> 

 
<http://us.adserver.yahoo.com/l?M=245454.3115308.4434529.1728375/D=egrou
pmail/S=:HM/A=1457554/rand=970646635> 

To unsubscribe from this group, send an email to:
gpsxml-unsubscribe+yahoogroups.com



Your use of Yahoo! Groups is subject to the Yahoo!
<http://docs.yahoo.com/info/terms/>  Terms of Service. 

------=_NextPart_000_0001_01C2F92D.73D30910

Re: [gpsxml] Nearly ready

ptomblin+xcski.com on Wed Apr 02 16:33:28 2003 (link), replying to msg

Quoting Chris Jones (chris+groundspeak.com):
> If you just want to send a GPX file down from a web server, you should
> serve it as text/xml. 

No, when I do that, my browser displays as text without the xml tags.  I
think it's trying to interpret it as XML.

-- 
Paul Tomblin <ptomblin+xcski.com>, not speaking for anybody
"I have traveled the length and breadth of this country and talked with the
best people, and I can assure you that data processing is a fad that won't
last out the year." --Editor of business books for Prentice Hall, 1957.

RE: [gpsxml] Nearly ready

chris+groundspeak.com on Wed Apr 02 17:08:39 2003 (link), replying to msg


GPX is XML.  So text/xml is a valid mime-type.  You can't tell the
browser what application to use for a file from the web server-- you can
only tell the browser what type of file it is-that's what a mime-type
is.  By giving a mime-type, you are helping the browser to "guess" what
to do with it.  Your browser apparently doesn't know what an XML file
is, so it treats it like HTML and strips out the markup, leaving the
words.  My browser on the other hand knows about the xml mime type, and
treats the GPX file as XML and shows it to me parsed in color (IE 6).
So you have two choices: If you turn the mime-type off completely, the
user should be prompted to choose an application if they haven't already
associated one.  If you associate a mime-type on the server, the browser
will guess.  If you choose the latter, the correct mime type is XML.
 
I would recommend not providing a mime-type if you just want people to
download the file.  This will make most browsers prompt the user to
either save the file to disk, or to choose and application to open it
with.  They can usually make that associate permanent, and never be
bothered again.  
 
Chris  
 
-----Original Message-----
From: Paul Tomblin [mailto:ptomblin+xcski.com] 
Sent: Wednesday, April 02, 2003 4:31 PM
To: gpsxml+yahoogroups.com
Subject: Re: [gpsxml] Nearly ready
 
Quoting Chris Jones (chris+groundspeak.com):
> If you just want to send a GPX file down from a web server, you should
> serve it as text/xml. 

No, when I do that, my browser displays as text without the xml tags.  I
think it's trying to interpret it as XML.

-- 
Paul Tomblin <ptomblin+xcski.com>, not speaking for anybody
"I have traveled the length and breadth of this country and talked with
the
best people, and I can assure you that data processing is a fad that
won't
last out the year." --Editor of business books for Prentice Hall, 1957.




Yahoo! Groups Sponsor


ADVERTISEMENT
 
<http://rd.yahoo.com/M=246920.2960106.4328965.1728375/D=egroupweb/S=1706
030390:HM/A=1513704/R=0/*http:/www.gotomypc.com/u/tr/yh/cpm/grp/300_02F/
g22lp?Target=mm/g22lp.tmpl> 

 
<http://us.adserver.yahoo.com/l?M=246920.2960106.4328965.1728375/D=egrou
pmail/S=:HM/A=1513704/rand=192692354> 

To unsubscribe from this group, send an email to:
gpsxml-unsubscribe+yahoogroups.com



Your use of Yahoo! Groups is subject to the Yahoo!
<http://docs.yahoo.com/info/terms/>  Terms of Service. 

------=_NextPart_000_0001_01C2F93A.85F3EC10

RE: [gpsxml] Nearly ready

chris+groundspeak.com on Thu Apr 03 10:47:15 2003 (link)


Right - that's why I said you have two choices.  You can associate it
with the only correct mime type that exists today (XML), or make the
user choose an application.  There is no mime type (yet) for GPX.  Short
of creating an entirely new mime-type (which matters not until browser
makers adopt it) it's the only answer for serving the file raw from a
web server.  And even if you add a mime type for .gpx, and browser
makers adopt it, the user will still have to choose which application
handles GPX files, so you're back to the beginning.  I would just serve
it raw.
 
-----Original Message-----
From: Robert Lipe [mailto:robertlipe+usa.net] 
Sent: Wednesday, April 02, 2003 7:29 PM
To: gpsxml+yahoogroups.com
Subject: Re: [gpsxml] Nearly ready
 
Chris Jones wrote:

>    I would recommend not providing a mime-type if you just want people
to
>    download  the  file.   This will make most browsers prompt the user
to
>    either  save the file to disk, or to choose and application to open
it
>    with.   They  can  usually make that associate permanent, and never
be
>    bothered again.

But if you just let it default to application/binary (or whatever the
original suggestion was) there's no way for the browser to associate
the data with an actual program becuase it doesn't know *what* the data
is; that's the whole point of the mime type.

RJL




Yahoo! Groups Sponsor


ADVERTISEMENT
 
<http://rd.yahoo.com/M=245454.3115308.4434529.1728375/D=egroupweb/S=1706
030390:HM/A=1457554/R=0/*http:/ipunda.com/clk/beibunmaisuiyuiwabei> 

 
<http://us.adserver.yahoo.com/l?M=245454.3115308.4434529.1728375/D=egrou
pmail/S=:HM/A=1457554/rand=963479195> 

To unsubscribe from this group, send an email to:
gpsxml-unsubscribe+yahoogroups.com



Your use of Yahoo! Groups is subject to the Yahoo!
<http://docs.yahoo.com/info/terms/>  Terms of Service. 

------=_NextPart_000_0005_01C2F9CE.62DDAFB0

Re: [gpsxml] Nearly ready

ptomblin+xcski.com on Thu Apr 03 10:55:00 2003 (link), replying to msg

Quoting Chris Jones (chris+groundspeak.com):
> Right - that's why I said you have two choices.  You can associate it
> with the only correct mime type that exists today (XML), or make the

The problem with that is that every browser I've ever seen "handles"
text/xml by displaying it.  That's not what should happen when you
download a GPX file - it should either save it, or launch a helper
application.

> user choose an application.  There is no mime type (yet) for GPX.  Short
> of creating an entirely new mime-type (which matters not until browser
> makers adopt it) it's the only answer for serving the file raw from a

Browser makers don't have to adopt it.  I don't know about IE because I
don't use it, but a *good* browser (Mozilla, Safari, Konqueror, Chimera,
Opera) lets the user set up their own handler for a particular mime-type.
So if I were to make it application/gpx, then people could choose whatever
GPX program they have to launch it, or save it.


-- 
Paul Tomblin <ptomblin+xcski.com>, not speaking for anybody
Quality Control, n.:
	The process of testing one out of every 1,000 units coming off
a production line to make sure that at least one out of 100 works.

RE: [gpsxml] Nearly ready

chris+groundspeak.com on Thu Apr 03 11:07:41 2003 (link)


Sorry, I misunderstood.  I thought you didn't want users to have to do
anything.  It was my original suggestion to let the user choose an
application.  Yes, they can do this by registering a mime-type in their
browser (like application/gpx), or when they try to download a .gpx file
for the first time, their browser will prompt them to save it to disk or
choose an application.  So its an exactly equivalent amount of work for
the users: they have to associate GPX with an application on their
machine, so these solutions are equivalent.
 
-----Original Message-----
From: Paul Tomblin [mailto:ptomblin+xcski.com] 
Sent: Thursday, April 03, 2003 10:53 AM
To: gpsxml+yahoogroups.com
Subject: Re: [gpsxml] Nearly ready
 
Quoting Chris Jones (chris+groundspeak.com):
> Right - that's why I said you have two choices.  You can associate it
> with the only correct mime type that exists today (XML), or make the

The problem with that is that every browser I've ever seen "handles"
text/xml by displaying it.  That's not what should happen when you
download a GPX file - it should either save it, or launch a helper
application.

> user choose an application.  There is no mime type (yet) for GPX.
Short
> of creating an entirely new mime-type (which matters not until browser
> makers adopt it) it's the only answer for serving the file raw from a

Browser makers don't have to adopt it.  I don't know about IE because I
don't use it, but a *good* browser (Mozilla, Safari, Konqueror, Chimera,
Opera) lets the user set up their own handler for a particular
mime-type.
So if I were to make it application/gpx, then people could choose
whatever
GPX program they have to launch it, or save it.


-- 
Paul Tomblin <ptomblin+xcski.com>, not speaking for anybody
Quality Control, n.:
      The process of testing one out of every 1,000 units coming off
a production line to make sure that at least one out of 100 works.




Yahoo! Groups Sponsor


ADVERTISEMENT
 
<http://rd.yahoo.com/M=245454.3115308.4434529.1728375/D=egroupweb/S=1706
030390:HM/A=1457554/R=0/*http:/ipunda.com/clk/beibunmaisuiyuiwabei> 

 
<http://us.adserver.yahoo.com/l?M=245454.3115308.4434529.1728375/D=egrou
pmail/S=:HM/A=1457554/rand=535809482> 

To unsubscribe from this group, send an email to:
gpsxml-unsubscribe+yahoogroups.com



Your use of Yahoo! Groups is subject to the Yahoo!
<http://docs.yahoo.com/info/terms/>  Terms of Service. 

------=_NextPart_000_0011_01C2F9D1.3CCF12C0

Hello

xinren_2002+yahoo.com on Thu Apr 10 09:10:30 2003 (link)



Hi

     I'd like to be a member of this list. Thank you in advance.



---------------------------------
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
--0-650081665-1049991027=:54174

New file uploaded to gpsxml

gpsxml+yahoogroups.com on Fri Apr 11 15:56:25 2003 (link)


Hello,

This email message is a notification to let you know that
a file has been uploaded to the Files area of the gpsxml 
group.

  File        : / Live Webcam Feeds - Click Here. 
  Uploaded by : whitestorish <whitestorish+yahoo.com> 
  Description : Real home Webcam Feeds! Real and Live! 

You can access this file at the URL

http://groups.yahoo.com/group/gpsxml/files/%20Live%20Webcam%20Feeds%20-%20Click%20Here. 

To learn more about file sharing for your group, please visit

http://help.yahoo.com/help/us/groups/files

Regards,

whitestorish <whitestorish+yahoo.com>
 





New file uploaded to gpsxml

gpsxml+yahoogroups.com on Fri Apr 11 15:56:30 2003 (link)


Hello,

This email message is a notification to let you know that
a file has been uploaded to the Files area of the gpsxml 
group.

  File        : / Free Pics in Your Email - Click here 
  Uploaded by : whitestorish <whitestorish+yahoo.com> 
  Description :  All the pic you need 

You can access this file at the URL

http://groups.yahoo.com/group/gpsxml/files/%20Free%20Pics%20in%20Your%20Email%20-%20Click%20here 

To learn more about file sharing for your group, please visit

http://help.yahoo.com/help/us/groups/files

Regards,

whitestorish <whitestorish+yahoo.com>
 





New file uploaded to gpsxml

gpsxml+yahoogroups.com on Fri Apr 11 15:56:45 2003 (link)


Hello,

This email message is a notification to let you know that
a file has been uploaded to the Files area of the gpsxml 
group.

  File        : / Net Dating Service - Click here. 
  Uploaded by : whitestorish <whitestorish+yahoo.com> 
  Description :  Thousands of profiles to browse through for free 

You can access this file at the URL

http://groups.yahoo.com/group/gpsxml/files/%20Net%20Dating%20Service%20-%20Click%20here. 

To learn more about file sharing for your group, please visit

http://help.yahoo.com/help/us/groups/files

Regards,

whitestorish <whitestorish+yahoo.com>
 





Generatin of GPX from ColdFusion

mvryukalo+yahoo.com on Sat Apr 19 02:07:36 2003 (link)

Hi All,

Does anyone dynamicaly generate the GPX file from ColdFusion 
application?
I'm looking for some examples and any links or code are appreciated.

Thanks.

Maksim.


(Mostly) working GPX download available at TrailRegistry.com

bogamo+yahoo.com on Tue Jun 10 08:07:47 2003 (link)

Currently I'm just puting out text in xml format,  I'm sure there are
problems with escaping names of features that have symbols in them,
but for the most part it works.  If anyone knows of a better way to
output XML in java, please let me know. (Performance is somewhat of an
issue).

The website is at http://www.trailregistry.com

You'll need to create a user, then there will be  a "Download GPS
data" link at the top of every trail page.

The system will convert the trail data that it has in the database to
a GPX track, and all any waypoints that lay within ~0.5 miles of the
trail.


Also, I noticed that geocaching is using the mime type
application/xml-loc, so I used that too.  I'm not sure if that's the
right one though.

Please tell me what you think, and anything I can do better.


Thanks in advance,

     -Geoff


Re: [gpsxml] (Mostly) working GPX download available at TrailRegistry.com

egroups+topografix.com on Sun Jun 22 20:39:15 2003 (link), replying to msg

Hello,

Tuesday, June 10, 2003, 11:07:32 AM, Geoff wrote:

b> Also, I noticed that geocaching is using the mime type
b> application/xml-loc, so I used that too.  I'm not sure if that's the
b> right one though.

application/xml-gpx is a better choice.  Geocaching also distributes
files in a different XML format with the .loc extension, and they use
xml-loc for that.  Perhaps they didn't change their settings when they
started using GPX.

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com


Re: [gpsxml] (Mostly) working GPX download available at TrailRegistry.com

bogamo+yahoo.com on Mon Jun 23 05:05:43 2003 (link), replying to msg

Thanks.  I'll make the change the next time I push up a new version of the
site.

     -Geoff

--- Dan Foster <egroups+topografix.com> wrote:
> Hello,
> 
> Tuesday, June 10, 2003, 11:07:32 AM, Geoff wrote:
> 
> b> Also, I noticed that geocaching is using the mime type
> b> application/xml-loc, so I used that too.  I'm not sure if that's the
> b> right one though.
> 
> application/xml-gpx is a better choice.  Geocaching also distributes
> files in a different XML format with the .loc extension, and they use
> xml-loc for that.  Perhaps they didn't change their settings when they
> started using GPX.
> 
> -- 
> Dan Foster
> TopoGrafix - GPS Software, Waypoints, and Maps
> http://www.topografix.com - mailto:egroups+topografix.com
> 
> 
> 
> To unsubscribe from this group, send an email to:
> gpsxml-unsubscribe+yahoogroups.com
> 
>  
> 
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 
> 
> 


__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

Extensions for route/track color, line width or map calibration

egroups+topografix.com on Tue Jul 08 13:20:55 2003 (link), replying to msg

Hi,

I'm interested in talking with any other developers who would be
interested in using GPX to express line width, style, and color for
routes and tracks, or to exchange map calibration data.  This could be
done through a new version of the GPX public spec, or through private
namespace extensions.  I'm currently using a private topografix:color
tag for route color.

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com


Re: [gpsxml] Extensions for route/track color, line width or map calibration

kodiak+phonet.com on Tue Jul 08 13:36:22 2003 (link)


Dan,
    Sorry about not posting something along this line earlier.  I certainly am interested discussing this... as well as the map calibration data.  

Charles Jones
Digital Trails
www.digitaltrails.com

  ----- Original Message ----- 
  From: Dan Foster 
  To: gpsxml+yahoogroups.com 
  Sent: Tuesday, July 08, 2003 3:21 PM
  Subject: [gpsxml] Extensions for route/track color, line width or map calibration


  Hi,

  I'm interested in talking with any other developers who would be
  interested in using GPX to express line width, style, and color for
  routes and tracks, or to exchange map calibration data.  This could be
  done through a new version of the GPX public spec, or through private
  namespace extensions.  I'm currently using a private topografix:color
  tag for route color.

  -- 
  Dan Foster
  TopoGrafix - GPS Software, Waypoints, and Maps
  http://www.topografix.com - mailto:egroups+topografix.com


        Yahoo! Groups Sponsor 
              ADVERTISEMENT
             
       
       

  To unsubscribe from this group, send an email to:
  gpsxml-unsubscribe+yahoogroups.com



  Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. 

------?extPart_000_0009_01C3456E.CB403E10

RE: [gpsxml] Extensions for route/track color, line width or map calibration

sandro_franchi+american-outland.com on Tue Jul 08 19:09:58 2003 (link), replying to msg


We too.

-----Original Message-----
From: Charles Jones [mailto:kodiak+phonet.com] 
Sent: Martes, 08 de Julio de 2003 06:34 p.m.
To: gpsxml+yahoogroups.com
Subject: Re: [gpsxml] Extensions for route/track color, line width or map
calibration


Dan,
    Sorry about not posting something along this line earlier.  I certainly
am interested discussing this... as well as the map calibration data.  
 
Charles Jones
Digital Trails
www.digitaltrails.com
 

----- Original Message ----- 
From: Dan  <mailto:egroups+topografix.com> Foster 
To: gpsxml+yahoogroups.com 
Sent: Tuesday, July 08, 2003 3:21 PM
Subject: [gpsxml] Extensions for route/track color, line width or map
calibration


Hi,

I'm interested in talking with any other developers who would be
interested in using GPX to express line width, style, and color for
routes and tracks, or to exchange map calibration data.  This could be
done through a new version of the GPX public spec, or through private
namespace extensions.  I'm currently using a private topografix:color
tag for route color.

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com



To unsubscribe from this group, send an email to:
gpsxml-unsubscribe+yahoogroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
<http://docs.yahoo.com/info/terms/> . 



Yahoo! Groups Sponsor	

ADVERTISEMENT
 
<http://rd.yahoo.com/M=244522.3512152.4794593.1261774/D=egroupweb/S=17060303
90:HM/A=1595056/R=0/SIG=124bf4lrb/*http://ashnin.com/clk/muryutaitakenattogy
o?YH=3512152&yhad=1595056> Click Here!	
 
<http://us.adserver.yahoo.com/l?M=244522.3512152.4794593.1261774/D=egroupmai
l/S=:HM/A=1595056/rand=551937858> 	

To unsubscribe from this group, send an email to:
gpsxml-unsubscribe+yahoogroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
<http://docs.yahoo.com/info/terms/> . 



------?extPart_000_0066_01C345A6.0C384D90

RE: [gpsxml] Extensions for route/track color, line width or map calibration

gpsexpl+tiscali.no on Wed Jul 09 05:59:46 2003 (link)

This sounds interesting!

I would at the moment be most interested in exchanging map calibration data.
In that case the information should at least contain:
-File name of map
-Pixels to positions (or world point to pos in case of calibrating a WMF)
-Datum
-Size of map (x and y)
-Projection
-Path to last known location on disk.
 
Could in addition contain much more:
-Name of each calibration point
-Links to Routes, Tracks or Waypoints that always should be added to map
- Suggestions? :-)
 
Steinar


RE: [gpsxml] Extensions for route/track color, line width or map calibration

sandro_franchi+american-outland.com on Wed Jul 09 07:39:31 2003 (link), replying to msg

Projection parameters is an issue, due that every projection may have
different projection parameters. They can be called "Param1" ... "ParamX",
shouldn't be mandatory (some projections has no parameters) and the program
reading shall understand each parameter meaning, but a common set of
parameters for known or supported projection methods would be more usable,
for example:

Projection ID (from a list of supported projection names, can be a number or
a short string, i.e. UTM, TM, GK, etc.)
Central Meridian (-180 to 180)
Parallel One (-90 to 90)
Parallel Two (-90 to 90)
Zone Number (not only for UTM, many TM projections use that parameter)
Zone Letter (A..Z, a..z)
Hemisphere (N/S)
Scale Factor (0..1)
Etc.

I do prefer this approach so every program using this will have to store and
read from the same formal parameters, don't leaving "Param1..ParamX" to the
imagination of each one.

-----Original Message-----
From: gpsexpl+tiscali.no [mailto:gpsexpl+tiscali.no] 
Sent: Mi�rcoles, 09 de Julio de 2003 10:00 a.m.
To: gpsxml+yahoogroups.com
Subject: RE: [gpsxml] Extensions for route/track color, line width or map
calibration


This sounds interesting!

I would at the moment be most interested in exchanging map calibration data.
In that case the information should at least contain: -File name of map
-Pixels to positions (or world point to pos in case of calibrating a WMF)
-Datum -Size of map (x and y) -Projection -Path to last known location on
disk.
 
Could in addition contain much more:
-Name of each calibration point
-Links to Routes, Tracks or Waypoints that always should be added to map
- Suggestions? :-)
 
Steinar



To unsubscribe from this group, send an email to:
gpsxml-unsubscribe+yahoogroups.com

 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 





Re: Extensions for route/track color, line width or map calibration

davewissenbach+yahoo.com on Sun Jul 13 13:53:43 2003 (link), replying to msg

--- In gpsxml+yahoogroups.com, Dan Foster <egroups+t...> wrote:
> Hi,
> 
> I'm interested in talking with any other developers who would be
> interested in using GPX to express line width, style, and color for
> routes and tracks, or to exchange map calibration data.  This 
could be
> done through a new version of the GPX public spec, or through 
private
> namespace extensions.  I'm currently using a private 
topografix:color
> tag for route color.
> 

I think that a public specification for line width, color, etc. 
might be a good thing. My program does not allow the direct 
specification of line color or style, but the SVG output function 
will pass a wissenbach:style element through to SVG. The contents of 
the style element becomes the value of a CSS style attribute for the 
track. As an alternative, an optional CSS style attribute could be 
added to tracks and routes as is currently done with HTML4.0, 
XHTML1.0/1.1, and SVG1.0. Or perhaps we just add optional CSS style 
to everything, so that waypoint names can also be styled.

Dave


> -- 
> Dan Foster
> TopoGrafix - GPS Software, Waypoints, and Maps
> http://www.topografix.com - mailto:egroups+t...


[gpsxml] Re: Extensions for route/track color, line width, fonts

egroups+topografix.com on Wed Jul 16 08:36:54 2003 (link), replying to msg

Hello,

Sunday, July 13, 2003, 4:53:38 PM, Dave wrote:

d> I think that a public specification for line width, color, etc.
d> might be a good thing. My program does not allow the direct 
d> specification of line color or style, but the SVG output function 
d> will pass a wissenbach:style element through to SVG. The contents of 
d> the style element becomes the value of a CSS style attribute for the 
d> track. As an alternative, an optional CSS style attribute could be 
d> added to tracks and routes as is currently done with HTML4.0, 
d> XHTML1.0/1.1, and SVG1.0. Or perhaps we just add optional CSS style 
d> to everything, so that waypoint names can also be styled.

I like the idea of staying as close to CSS or SVG as possible.  However, I
think that allowing the full range of CSS style attributes in a single
<style> tag would make it difficult to parse when reading the file
back into any of our programs.  For example, CSS allows font size to
be specified as any of the following: 12pt, larger, 150%, 1.5em.  To
keep things simple, we're probably better off just using point sizes
only.

I suggest defining a subset of style elements that mapping programs
would be likely to use, and using tags and data values that match SVG
as much as possible.  For example:
<wpt lat="42.451731173" lon="-71.548814064">
 <desc>Styled Waypoint</desc>
  <gpx_style:font-family>Arial</gpx_style:font-family>
  <gpx_style:font-weight>bold</gpx_style:font-weight>
  <gpx_style:font-size>24</gpx_style:font-size>
  <gpx_style:color>ffffff</gpx_style:color>
</wpt>
<rte>
 <desc>Styled Route</desc>
  <gpx_style:stroke-width>3</gpx_style:stroke-width>
  <gpx_style:stroke>ffffff</gpx_style:stroke>
</rte>

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com


Re[2]: [gpsxml] Extensions for map calibration

egroups+topografix.com on Wed Jul 16 08:46:10 2003 (link), replying to msg

Hello,

Wednesday, July 9, 2003, 10:39:31 AM, Sandro wrote:

S> Projection parameters is an issue, due that every projection may have
S> different projection parameters. They can be called "Param1" ... "ParamX",
S> shouldn't be mandatory (some projections has no parameters) and the program
S> reading shall understand each parameter meaning, but a common set of
S> parameters for known or supported projection methods would be more usable,
S> for example:

S> Projection ID (from a list of supported projection names, can be a number or
S> a short string, i.e. UTM, TM, GK, etc.)
S> Central Meridian (-180 to 180)
S> Parallel One (-90 to 90)
S> Parallel Two (-90 to 90)
S> Zone Number (not only for UTM, many TM projections use that parameter)
S> Zone Letter (A..Z, a..z)
S> Hemisphere (N/S)
S> Scale Factor (0..1)
S> Etc.

S> I do prefer this approach so every program using this will have to store and
S> read from the same formal parameters, don't leaving "Param1..ParamX" to the
S> imagination of each one.

I like this approach.  I've already done some experiments with using
GPX to store map calibration data (everything except the projection
parameters).  Here are two examples.  The first isn't calibrated, the
second has three calibration points.

<topografix:map url="D:\sample.jpg">
 <topografix:name>sample.jpg</topografix:name>
 <topografix:width>1031</topografix:width>
 <topografix:height>901</topografix:height>
</topografix:map>

<topografix:map url="D:\TopoGrafix Data\MA\Stow\Stow Street Map 256.png">
 <topografix:name>Stow Street Map</topografix:name>
 <topografix:width>1523</topografix:width>
 <topografix:height>1830</topografix:height>
 <topografix:mappt lat="42.461548000" lon="-71.538146000" x="288.0" y="119.0"/>
 <topografix:mappt lat="42.394430000" lon="-71.480885000" x="1301.0" y="1707.0"/>
 <topografix:mappt lat="42.394152000" lon="-71.541412000" x="245.0" y="1725.0"/>
</topografix:map>

The schema for these private extensions is available at
http://www.topografix.com/GPX/Private/TopoGrafix/0/2/topografix.xsd

Perhaps we should work on a sample schema for several common
projections.  The projections of most interest to me are UTM,
Transverse Mercator, and Lambert Conformal Conic.

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com


RE: Re[2]: [gpsxml] Extensions for map calibration

sandro_franchi+american-outland.com on Wed Jul 16 09:49:36 2003 (link), replying to msg


Great, let start working with those projections, are pretty common in this
side of the world too. I'll think about it a moment and will send you
something.

-----Original Message-----
From: Dan Foster [mailto:egroups+topografix.com] 
Sent: Mi�rcoles, 16 de Julio de 2003 12:40 p.m.
To: gpsxml+yahoogroups.com
Subject: Re[2]: [gpsxml] Extensions for map calibration


Hello,

Wednesday, July 9, 2003, 10:39:31 AM, Sandro wrote:

S> Projection parameters is an issue, due that every projection may have
S> different projection parameters. They can be called "Param1" ...
"ParamX",
S> shouldn't be mandatory (some projections has no parameters) and the
program
S> reading shall understand each parameter meaning, but a common set of
S> parameters for known or supported projection methods would be more
usable,
S> for example:

S> Projection ID (from a list of supported projection names, can be a number
or
S> a short string, i.e. UTM, TM, GK, etc.)
S> Central Meridian (-180 to 180)
S> Parallel One (-90 to 90)
S> Parallel Two (-90 to 90)
S> Zone Number (not only for UTM, many TM projections use that parameter)
S> Zone Letter (A..Z, a..z)
S> Hemisphere (N/S)
S> Scale Factor (0..1)
S> Etc.

S> I do prefer this approach so every program using this will have to store
and
S> read from the same formal parameters, don't leaving "Param1..ParamX" to
the
S> imagination of each one.

I like this approach.  I've already done some experiments with using
GPX to store map calibration data (everything except the projection
parameters).  Here are two examples.  The first isn't calibrated, the
second has three calibration points.

<topografix:map url="D:\sample.jpg">
<topografix:name>sample.jpg</topografix:name>
<topografix:width>1031</topografix:width>
<topografix:height>901</topografix:height>
</topografix:map>

<topografix:map url="D:\TopoGrafix Data\MA\Stow\Stow Street Map 256.png">
<topografix:name>Stow Street Map</topografix:name>
<topografix:width>1523</topografix:width>
<topografix:height>1830</topografix:height>
<topografix:mappt lat="42.461548000" lon="-71.538146000" x="288.0"
y="119.0"/>
<topografix:mappt lat="42.394430000" lon="-71.480885000" x="1301.0"
y="1707.0"/>
<topografix:mappt lat="42.394152000" lon="-71.541412000" x="245.0"
y="1725.0"/>
</topografix:map>

The schema for these private extensions is available at
http://www.topografix.com/GPX/Private/TopoGrafix/0/2/topografix.xsd

Perhaps we should work on a sample schema for several common
projections.  The projections of most interest to me are UTM,
Transverse Mercator, and Lambert Conformal Conic.

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com



Yahoo! Groups Sponsor	

ADVERTISEMENT
 
<http://rd.yahoo.com/M=194081.3551198.4824677.1261774/D=egroupweb/S=17060303
90:HM/A=1663535/R=0/SIG=11ps6rfef/*http://www.ediets.com/start.cfm?code=3050
4&media=atkins> click here	
 
<http://us.adserver.yahoo.com/l?M=194081.3551198.4824677.1261774/D=egroupmai
l/S=:HM/A=1663535/rand=170543025> 	

To unsubscribe from this group, send an email to:
gpsxml-unsubscribe+yahoogroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
<http://docs.yahoo.com/info/terms/> . 



------?extPart_000_0001_01C34BA1.199B1E80

MrGIS.com: AVL, GIS, GPS and GeoCaching discussion forums

groups+mrgis.com on Wed Jul 16 20:03:31 2003 (link)

Wanted to let you all know about a new website, MrGIS.com No mass 
emails, no sales pitches, no fees. This site is for the use of 
anyone....recreational GPS users, GeoCachers, Professional GIS 
personnel, First Responders and Homeland Defense personnel and 
planners. The uses of this site are, but by no means limited to, 
questions, support, information, research, and whatever else it can 
be used for EXCEPT selling and/or advertising by sales personnel. The 
Message Board is the main feature of the site. Use it to post 
whatever information you are looking for or sharing, find GeoCache's, 
information on GIS Software, AVL or GPS equipment, success stories, 
anything you can think of to share.

http://www.mrgis.com

Best regards,
Dave



RE: Re[2]: [gpsxml] Extensions for map calibration

jeremy+groundspeak.com on Thu Jul 17 09:13:14 2003 (link), replying to msg


I vote an emphatic no regarding the additions of extensions for map
calibration. GPX should be restricted to waypoint, track, and route
sharing with the addition of display specifics. Maps should be in its
own XML spec and separate from GPX.
 
Track display options, however, have its place in GPX.
 
Just the tracks, m'aam.
 
JMO
 
Jeremy
 
 

------=_NextPart_000_007D_01C34C43.A2ECBED0

RE: Re[2]: [gpsxml] Extensions for map calibration

sandro_franchi+american-outland.com on Thu Jul 17 09:53:01 2003 (link), replying to msg


And what's your emphatic reason for that? If a program has not mapping
functionality wont use them, there is no overhead for it nor for its users. 
 
A standard must conform to all the needs of a "problem", if the GPX model
ignores mapping issues, the same incompatibilty we suffer day to day with
"data" will continue happening with "maps".
 
Why a map produced by the software brabd "XXX" shouldn't be opened with the
mapping solution "YYYY"?

-----Original Message-----
From: Jeremy Irish [mailto:jeremy+groundspeak.com] 
Sent: Jueves, 17 de Julio de 2003 01:13 p.m.
To: gpsxml+yahoogroups.com
Subject: RE: Re[2]: [gpsxml] Extensions for map calibration


I vote an emphatic no regarding the additions of extensions for map
calibration. GPX should be restricted to waypoint, track, and route sharing
with the addition of display specifics. Maps should be in its own XML spec
and separate from GPX.
 
Track display options, however, have its place in GPX.
 
Just the tracks, m'aam.
 
JMO
 
Jeremy
 
 

Yahoo! Groups Sponsor	

ADVERTISEMENT
 
<http://rd.yahoo.com/M=194081.3551198.4824677.1261774/D=egroupweb/S=17060303
90:HM/A=1663535/R=0/SIG=11ps6rfef/*http://www.ediets.com/start.cfm?code=3050
4&media=atkins> click here	
 
<http://us.adserver.yahoo.com/l?M=194081.3551198.4824677.1261774/D=egroupmai
l/S=:HM/A=1663535/rand=510305458> 	

To unsubscribe from this group, send an email to:
gpsxml-unsubscribe+yahoogroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
<http://docs.yahoo.com/info/terms/> . 



------?extPart_000_0022_01C34C6A.BFBACA80

RE: Re[2]: [gpsxml] Extensions for map calibration

sandro_franchi+american-outland.com on Thu Jul 17 10:00:25 2003 (link), replying to msg


Where says "brabd", read "named" :)

-----Original Message-----
From: Sandro Franchi + American Outland
[mailto:sandro_franchi+american-outland.com] 
Sent: Jueves, 17 de Julio de 2003 01:53 p.m.
To: gpsxml+yahoogroups.com
Subject: RE: Re[2]: [gpsxml] Extensions for map calibration


And what's your emphatic reason for that? If a program has not mapping
functionality wont use them, there is no overhead for it nor for its users. 
 
A standard must conform to all the needs of a "problem", if the GPX model
ignores mapping issues, the same incompatibilty we suffer day to day with
"data" will continue happening with "maps".
 
Why a map produced by the software brabd "XXX" shouldn't be opened with the
mapping solution "YYYY"?

-----Original Message-----
From: Jeremy Irish [mailto:jeremy+groundspeak.com] 
Sent: Jueves, 17 de Julio de 2003 01:13 p.m.
To: gpsxml+yahoogroups.com
Subject: RE: Re[2]: [gpsxml] Extensions for map calibration


I vote an emphatic no regarding the additions of extensions for map
calibration. GPX should be restricted to waypoint, track, and route sharing
with the addition of display specifics. Maps should be in its own XML spec
and separate from GPX.
 
Track display options, however, have its place in GPX.
 
Just the tracks, m'aam.
 
JMO
 
Jeremy
 
 


To unsubscribe from this group, send an email to:
gpsxml-unsubscribe+yahoogroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
<http://docs.yahoo.com/info/terms/> . 



Yahoo! Groups Sponsor	

ADVERTISEMENT
 
<http://rd.yahoo.com/M=194081.3551198.4824677.1261774/D=egroupweb/S=17060303
90:HM/A=1663535/R=0/SIG=11ps6rfef/*http://www.ediets.com/start.cfm?code=3050
4&media=atkins> click here	
 
<http://us.adserver.yahoo.com/l?M=194081.3551198.4824677.1261774/D=egroupmai
l/S=:HM/A=1663535/rand=378402618> 	

To unsubscribe from this group, send an email to:
gpsxml-unsubscribe+yahoogroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
<http://docs.yahoo.com/info/terms/> . 



------?extPart_000_0029_01C34C6B.C8A8E770

Re: Re[2]: [gpsxml] Extensions for map calibration

kodiak+phonet.com on Thu Jul 17 10:06:29 2003 (link)


MessageI'm a firm believer in keeping things simple.  However you suggest the addition of display specfics.. but what are maps if not a specific subclass... ie a display type?  It makes sense to me that if an application uses GPX information for the display/map that that information be included as a standard part of the GPX specification.  Least we all forget, just because the information is in the spec, doesn't mean everyone HAS to include it.

Chuck
  ----- Original Message ----- 
  From: Jeremy Irish 
  To: gpsxml+yahoogroups.com 
  Sent: Thursday, July 17, 2003 11:13 AM
  Subject: RE: Re[2]: [gpsxml] Extensions for map calibration


  I vote an emphatic no regarding the additions of extensions for map calibration. GPX should be restricted to waypoint, track, and route sharing with the addition of display specifics. Maps should be in its own XML spec and separate from GPX.

  Track display options, however, have its place in GPX.

  Just the tracks, m'aam.

  JMO

  Jeremy



        Yahoo! Groups Sponsor 
              ADVERTISEMENT
             
       
       

  To unsubscribe from this group, send an email to:
  gpsxml-unsubscribe+yahoogroups.com



  Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. 

------?extPart_000_000E_01C34C63.F369DB20

RE: Re[2]: [gpsxml] Extensions for map calibration

jeremy+groundspeak.com on Thu Jul 17 10:53:20 2003 (link), replying to msg


---------
Sandro Franchi + American Outland [sandro_franchi+american-outland.com]:
 
A standard must conform to all the needs of a "problem", if the GPX
model ignores mapping issues, the same incompatibilty we suffer day to
day with "data" will continue happening with "maps".
------------

GPX should ignore mapping issues. One problem at a time, Sandro!
 
What I suggest is that additional display parameters for tracks, routes
and waypoints are perfectly acceptable in GPX, which it's intent
(correct me if I'm wrong) is an open standard to exchange data between
GPS receivers. As GPS receivers get more sophisticated I wouldn't be
surprised if you will be able to suggest display parameters for data. We
already have this for the GPS symbol freetext.
 
If you want maps, use GML, which was specifically designed for mapping,
both vector and raster. For GPX, existing data like routes, tracks and
waypoints can and should have additional parameters, like track width,
color, border color, show points, or display. But layered maps of any
kind have no place in GPX.
 
Chuck, I agree that some information in the spec can be ignored, but I
won't put a pig in a chicken coop, even if there is space for the pig. I
don't object to shoving information in the GPX file about mapping, but
it should be a separate namespace, much like TopoGrafix does it now.
 
Jeremy

-----Original Message-----
From: Charles Jones [mailto:kodiak+phonet.com] 
Sent: Thursday, July 17, 2003 11:04 AM
To: gpsxml+yahoogroups.com
Subject: Re: Re[2]: [gpsxml] Extensions for map calibration


I'm a firm believer in keeping things simple.  However you suggest the
addition of display specfics.. but what are maps if not a specific
subclass... ie a display type?  It makes sense to me that if an
application uses GPX information for the display/map that that
information be included as a standard part of the GPX specification.
Least we all forget, just because the information is in the spec,
doesn't mean everyone HAS to include it.
 


------=_NextPart_000_0008_01C34C51.9E5A8420

RE: Re[2]: [gpsxml] Extensions for map calibration

sandro_franchi+american-outland.com on Thu Jul 17 11:34:52 2003 (link), replying to msg


GPS receivers can do nothing with GPX data without a program, so GPX is a
standard intended for those programs, not for the receiver itself, or not
only to it at least, that's the reason I would include mapping as a "must
have". 
 
I've no problem with a different namespace, but why don't make just one,
complete, including this? There is no overhead for users nor programs if the
current namespace does include mapping parameters, they will be used only
for those interested in it. 
 
As an example, MapSource will ignore map information because it only uses
its own maps, but OZIExplorer and Fugawi can show a map created in any of
both. MapSource will only read the "data" portion of the file, and others
programs all of it, or can be a user option.

-----Original Message-----
From: Jeremy Irish [mailto:jeremy+groundspeak.com] 
Sent: Jueves, 17 de Julio de 2003 02:53 p.m.
To: gpsxml+yahoogroups.com
Subject: RE: Re[2]: [gpsxml] Extensions for map calibration


---------
Sandro Franchi + American Outland [sandro_franchi+american-outland.com]:
 
A standard must conform to all the needs of a "problem", if the GPX model
ignores mapping issues, the same incompatibilty we suffer day to day with
"data" will continue happening with "maps".
------------


GPX should ignore mapping issues. One problem at a time, Sandro!
 
What I suggest is that additional display parameters for tracks, routes and
waypoints are perfectly acceptable in GPX, which it's intent (correct me if
I'm wrong) is an open standard to exchange data between GPS receivers. As
GPS receivers get more sophisticated I wouldn't be surprised if you will be
able to suggest display parameters for data. We already have this for the
GPS symbol freetext.
 
If you want maps, use GML, which was specifically designed for mapping, both
vector and raster. For GPX, existing data like routes, tracks and waypoints
can and should have additional parameters, like track width, color, border
color, show points, or display. But layered maps of any kind have no place
in GPX.
 
Chuck, I agree that some information in the spec can be ignored, but I won't
put a pig in a chicken coop, even if there is space for the pig. I don't
object to shoving information in the GPX file about mapping, but it should
be a separate namespace, much like TopoGrafix does it now.
 
Jeremy

-----Original Message-----
From: Charles Jones [mailto:kodiak+phonet.com] 
Sent: Thursday, July 17, 2003 11:04 AM
To: gpsxml+yahoogroups.com
Subject: Re: Re[2]: [gpsxml] Extensions for map calibration


I'm a firm believer in keeping things simple.  However you suggest the
addition of display specfics.. but what are maps if not a specific
subclass... ie a display type?  It makes sense to me that if an application
uses GPX information for the display/map that that information be included
as a standard part of the GPX specification.  Least we all forget, just
because the information is in the spec, doesn't mean everyone HAS to include
it.
 


Yahoo! Groups Sponsor	

ADVERTISEMENT
 
<http://rd.yahoo.com/M=194081.3551198.4824677.1261774/D=egroupweb/S=17060303
90:HM/A=1663535/R=0/SIG=11ps6rfef/*http://www.ediets.com/start.cfm?code=3050
4&media=atkins> click here	
 
<http://us.adserver.yahoo.com/l?M=194081.3551198.4824677.1261774/D=egroupmai
l/S=:HM/A=1663535/rand=576646511> 	

To unsubscribe from this group, send an email to:
gpsxml-unsubscribe+yahoogroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
<http://docs.yahoo.com/info/terms/> . 



------?extPart_000_003D_01C34C78.F973ACC0

RE: Re[2]: [gpsxml] Extensions for map calibration

jeremy+groundspeak.com on Thu Jul 17 12:08:18 2003 (link), replying to msg


 
Unless you can come up with a better reason than "why not?", I don't see
a reason why it should be part of the spec. Maps are extremely
complicated which is why there are already dedicated specifications
outside GPX. Last thing I want to see is GPX bloat from unnecessary
additions. Create your own GML lite and point to that namespace if you
want to include it in a GPX file.
 
Mapping may be a "must have" for you, but it isn't a "must have" for
GPX. 
 
Jeremy

-----Original Message-----
From: Sandro Franchi + American Outland
[mailto:sandro_franchi+american-outland.com] 
Sent: Thursday, July 17, 2003 11:35 AM
To: gpsxml+yahoogroups.com
Subject: RE: Re[2]: [gpsxml] Extensions for map calibration


GPS receivers can do nothing with GPX data without a program, so GPX is
a standard intended for those programs, not for the receiver itself, or
not only to it at least, that's the reason I would include mapping as a
"must have". 
 
I've no problem with a different namespace, but why don't make just one,
complete, including this? There is no overhead for users nor programs if
the current namespace does include mapping parameters, they will be used
only for those interested in it. 
 
As an example, MapSource will ignore map information because it only
uses its own maps, but OZIExplorer and Fugawi can show a map created in
any of both. MapSource will only read the "data" portion of the file,
and others programs all of it, or can be a user option.




------=_NextPart_000_0004_01C34C5C.16530E70

RE: Re[2]: [gpsxml] Extensions for map calibration

sandro_franchi+american-outland.com on Thu Jul 17 18:35:56 2003 (link), replying to msg


"Why not" is not my opinion, is your conception of my opinion, I did explain
"why yes" and my reasons, you don't have to agree with me, obviously.
 
Regards.

-----Original Message-----
From: Jeremy Irish [mailto:jeremy+groundspeak.com] 
Sent: Jueves, 17 de Julio de 2003 04:08 p.m.
To: gpsxml+yahoogroups.com
Subject: RE: Re[2]: [gpsxml] Extensions for map calibration


 
Unless you can come up with a better reason than "why not?", I don't see a
reason why it should be part of the spec. Maps are extremely complicated
which is why there are already dedicated specifications outside GPX. Last
thing I want to see is GPX bloat from unnecessary additions. Create your own
GML lite and point to that namespace if you want to include it in a GPX
file.
 
Mapping may be a "must have" for you, but it isn't a "must have" for GPX. 
 
Jeremy

-----Original Message-----
From: Sandro Franchi + American Outland
[mailto:sandro_franchi+american-outland.com] 
Sent: Thursday, July 17, 2003 11:35 AM
To: gpsxml+yahoogroups.com
Subject: RE: Re[2]: [gpsxml] Extensions for map calibration


GPS receivers can do nothing with GPX data without a program, so GPX is a
standard intended for those programs, not for the receiver itself, or not
only to it at least, that's the reason I would include mapping as a "must
have". 
 
I've no problem with a different namespace, but why don't make just one,
complete, including this? There is no overhead for users nor programs if the
current namespace does include mapping parameters, they will be used only
for those interested in it. 
 
As an example, MapSource will ignore map information because it only uses
its own maps, but OZIExplorer and Fugawi can show a map created in any of
both. MapSource will only read the "data" portion of the file, and others
programs all of it, or can be a user option.




Yahoo! Groups Sponsor	

ADVERTISEMENT
 
<http://rd.yahoo.com/M=194081.3551198.4824677.1261774/D=egroupweb/S=17060303
90:HM/A=1663535/R=0/SIG=11ps6rfef/*http://www.ediets.com/start.cfm?code=3050
4&media=atkins> click here	
 
<http://us.adserver.yahoo.com/l?M=194081.3551198.4824677.1261774/D=egroupmai
l/S=:HM/A=1663535/rand=440652866> 	

To unsubscribe from this group, send an email to:
gpsxml-unsubscribe+yahoogroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
<http://docs.yahoo.com/info/terms/> . 



------?extPart_000_001A_01C34CB3.C71F4C80

Re: Extensions for route/track color, line width, fonts

davewissenbach+yahoo.com on Fri Jul 18 15:30:58 2003 (link), replying to msg

--- In gpsxml+yahoogroups.com, Dan Foster <egroups+t...> wrote:
> Hello,
> 
> I like the idea of staying as close to CSS or SVG as possible.  
However, I
> think that allowing the full range of CSS style attributes in a 
single
> <style> tag would make it difficult to parse when reading the file
> back into any of our programs.  For example, CSS allows font size 
to
> be specified as any of the following: 12pt, larger, 150%, 1.5em.  
To
> keep things simple, we're probably better off just using point 
sizes
> only.
> 
> I suggest defining a subset of style elements that mapping programs
> would be likely to use, and using tags and data values that match 
SVG
> as much as possible.  For example:
> <wpt lat="42.451731173" lon="-71.548814064">
>  <desc>Styled Waypoint</desc>
>   <gpx_style:font-family>Arial</gpx_style:font-family>
>   <gpx_style:font-weight>bold</gpx_style:font-weight>
>   <gpx_style:font-size>24</gpx_style:font-size>
>   <gpx_style:color>ffffff</gpx_style:color>
> </wpt>
> <rte>
>  <desc>Styled Route</desc>
>   <gpx_style:stroke-width>3</gpx_style:stroke-width>
>   <gpx_style:stroke>ffffff</gpx_style:stroke>
> </rte>
> 

That looks like a good way to keep the parsing easy. (Use CSS 
symantics with XML syntax). I could go with that.

As far as the scanned map stuff, I'm with the people who suggest
another namespace. But perhaps the GPX format could include a
basemap tag, to confine the included map data to a well-defined
section of the document. My interest here is fairly casual--I'm
more interested in vector maps at the moment.

Dave




Newbie

traipse+terra.com.br on Wed Jul 23 10:31:46 2003 (link)

Hi there -

I'm developing a GPS fw and was thinking of exporting waypoints to 
HTML format (table) when a friend of mine told me about GPSXML. After 
visiting the website and reading some messages, I have a couple of 
questions:

1. Is there any documentation about GPSXML in doc or pdf format?

2. Since I'm not used to handheld GPSRs, I know nothing about symbols 
("<sym>")... where can I find the "exact names" of most 
popular/compatible symbols?

3. Any simple idea on how to link a file (e.g.: a picture, movie, 
midi [2nd URL?]) to a waypoint?  For instance, I have a waypoint that 
refers to a small village that has its own website 
("<url>", "<urlname>") and I would like to add a link to a picture 
that I took...

Thank you all in advance for any clue.

Traipse
http://www.traipse.com.br



Re: [gpsxml] Newbie

egroups+topografix.com on Wed Jul 23 11:05:22 2003 (link), replying to msg

Hello,

Wednesday, July 23, 2003, 1:31:42 PM, Traipse wrote:

t> Hi there -

t> I'm developing a GPS fw and was thinking of exporting waypoints to 
t> HTML format (table) when a friend of mine told me about GPSXML. After 
t> visiting the website and reading some messages, I have a couple of 
t> questions:

t> 1. Is there any documentation about GPSXML in doc or pdf format?

The only documentation is in HTML, at http://www.topografix.com/gpx_manual.asp

t> 2. Since I'm not used to handheld GPSRs, I know nothing about symbols 
t> ("<sym>")... where can I find the "exact names" of most 
t> popular/compatible symbols?

Feel free to use the lists of waypoint symbols in EasyGPS.
http://www.easygps.com/download.asp

Select the GPS receiver in File/Preferences/My GPS Receivers, and then
create a new waypoint.  The names of all the GPS symbols available are
listed in the Symbol combo box.

I believe Dave Wissenbach has a list of Garmin symbols on his website.

t> 3. Any simple idea on how to link a file (e.g.: a picture, movie, 
t> midi [2nd URL?]) to a waypoint?  For instance, I have a waypoint that 
t> refers to a small village that has its own website 
t> ("<url>", "<urlname>") and I would like to add a link to a picture 
t> that I took...

<wpt lat="40.167210000" lon="-105.101960000">
 <name>PHOTO</name>
 <url>http://www.server.com/myphoto.jpg</url>
 <urlname>Link to my photo</urlname>
</wpt>

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com


Dan -- Re: Newbie

traipse+terra.com.br on Wed Jul 23 15:13:05 2003 (link), replying to msg

Hi Dan -

Thx a bunch for your reply.  I'm gonna download EasyGPS and copy your 
symbol names. ;-)  BTW, which ones are the most popular?  I mean, 
which handheld GPSR has the most popular/compatible symbol names?

As for my 3rd question... 

t> 3. Any simple idea on how to link a file (e.g.: a picture, movie, 
t> midi [2nd URL?]) to a waypoint?  For instance, I have a waypoint 
that 
t> refers to a small village that has its own website 
t> ("<url>", "<urlname>") and I would like to add a link to a picture 
t> that I took...

Let me try to put it in XML words using your example, adding two 
lines (<xxx> & <yyy>) at the end:

<wpt lat="-25.4475" lon="-54.5833">
 <name>Itaipu</name>
 <url>http://www.itaipu.gov.br/english/main2.htm</url>
 <urlname>Official site of the largest power plant in the 
world</urlname>
 <xxx>My picture of Itaipu lake</xxx>
 <yyy>http://www.myserver.com.br/mypicture.jpg</yyy>
</wpt>

In other words, I wonder if there is a simple way that allows 
something like that (<xxx> & <yyy>).

Once again, thx for your answer.

Traipse
http://www.traipse.com.br



Dan -- Re: Newbie

davewissenbach+yahoo.com on Wed Jul 23 17:51:49 2003 (link), replying to msg

--- In gpsxml+yahoogroups.com, "traipse_sp" <traipse+t...> wrote:
> Hi Dan -
> 
> Thx a bunch for your reply.  I'm gonna download EasyGPS and copy 
your 
> symbol names. ;-)  BTW, which ones are the most popular?  I mean, 
> which handheld GPSR has the most popular/compatible symbol names?
> 
> As for my 3rd question... 
> 
> t> 3. Any simple idea on how to link a file (e.g.: a picture, 
movie, 
> t> midi [2nd URL?]) to a waypoint?  For instance, I have a 
waypoint 
> that 
> t> refers to a small village that has its own website 
> t> ("<url>", "<urlname>") and I would like to add a link to a 
picture 
> t> that I took...
> 
> Let me try to put it in XML words using your example, adding two 
> lines (<xxx> & <yyy>) at the end:
> 
> <wpt lat="-25.4475" lon="-54.5833">
>  <name>Itaipu</name>
>  <url>http://www.itaipu.gov.br/english/main2.htm</url>
>  <urlname>Official site of the largest power plant in the 
> world</urlname>
>  <xxx>My picture of Itaipu lake</xxx>
>  <yyy>http://www.myserver.com.br/mypicture.jpg</yyy>
> </wpt>
> 

Right now, in order to use your own xxx and yyy, you must create 
your own namespace and schema. There's a slot for elements in
another namespace in waypoints, routes,
and tracks and the root document that allows you to insert your own
new elements <yournamespace:xxx> and <yournamespace:yyy>.

But I have also been annoyed by the problem you illustrate above,
that we have allowed only one url and one urlname per waypoint.

You can find examples of creating and using another namespace in the 
topografix sample data and in my Southwestern Idaho Trail Maps 
websites, all linked from the Topografix gpx documentation site.


> In other words, I wonder if there is a simple way that allows 
> something like that (<xxx> & <yyy>).
> 
> Once again, thx for your answer.
> 
> Traipse
> http://www.traipse.com.br


Re: [gpsxml] Dan -- Re: Newbie

mholger+optera.net on Thu Jul 24 05:20:56 2003 (link), replying to msg

Ok, I'm no XML guru nor am I a GPS guru, but wouldn't it be feasible to 
handle URLs the same way waypoints are handled?  That is to say, <url 
href="http://www.someurl.com/somedoc.html">url name</url>, which could 
be used from 0 to 'N' times per <wpt>?  Then referencing up to 'N' URLs 
per WPT becomes as trivial as accessing multiple WPTs per GPX file. :)

I realise that this is in complete disagreement with the current GPX 
specs...but, if there were to ever be any future revisions.... ;)

Cheers!
-Matt.

davewissenbach wrote:
> --- In gpsxml+yahoogroups.com, "traipse_sp" <traipse+t...> wrote:
>>As for my 3rd question... 
>>
>>t> 3. Any simple idea on how to link a file (e.g.: a picture, 
> 
> movie, 
> 
>>t> midi [2nd URL?]) to a waypoint?  For instance, I have a 
> 
> waypoint 
> 
>>that 
>>t> refers to a small village that has its own website 
>>t> ("<url>", "<urlname>") and I would like to add a link to a 
> 
> picture 
> 
>>t> that I took...
>>
>>Let me try to put it in XML words using your example, adding two 
>>lines (<xxx> & <yyy>) at the end:
>>
>><wpt lat="-25.4475" lon="-54.5833">
>> <name>Itaipu</name>
>> <url>http://www.itaipu.gov.br/english/main2.htm</url>
>> <urlname>Official site of the largest power plant in the 
>>world</urlname>
>> <xxx>My picture of Itaipu lake</xxx>
>> <yyy>http://www.myserver.com.br/mypicture.jpg</yyy>
>></wpt>
>>
> 
> Right now, in order to use your own xxx and yyy, you must create 
> your own namespace and schema. There's a slot for elements in
> another namespace in waypoints, routes,
> and tracks and the root document that allows you to insert your own
> new elements <yournamespace:xxx> and <yournamespace:yyy>.
> 
> But I have also been annoyed by the problem you illustrate above,
> that we have allowed only one url and one urlname per waypoint.
> 
> You can find examples of creating and using another namespace in the 
> topografix sample data and in my Southwestern Idaho Trail Maps 
> websites, all linked from the Topografix gpx documentation site.
> 

-- 
        Matt Holger -//- mholger+optera.net
UNIX Systems Admin -//- http://www.Optera.NET/


Dan -- Re: Newbie

traipse+terra.com.br on Thu Jul 24 10:21:59 2003 (link), replying to msg

Thx Dan.

>>> You can find examples of creating and using another namespace in 
the topografix sample data and in my Southwestern Idaho Trail Maps 
websites, all linked from the Topografix gpx documentation site. <<<

OK. I'm gonna study your examples and try to do something.

Traipse
http://www.traipse.com.br


Matt -- multiple URLs per WPT

traipse+terra.com.br on Thu Jul 24 10:29:38 2003 (link), replying to msg

Matt -

>>> Then referencing up to 'N' URLs per WPT becomes as trivial as 
accessing multiple WPTs per GPX file. <<<

It sure is a great idea for the coming releases.

Traipse
http://www.traipse.com.br



Multiple URLs in GPX

egroups+topografix.com on Thu Jul 24 11:19:33 2003 (link), replying to msg

Hello Matt,

Thursday, July 24, 2003, 8:20:46 AM, you wrote:

m> Ok, I'm no XML guru nor am I a GPS guru, but wouldn't it be feasible to 
m> handle URLs the same way waypoints are handled?  That is to say, <url 
m> href="http://www.someurl.com/somedoc.html">url name</url>, which could 
m> be used from 0 to 'N' times per <wpt>?  Then referencing up to 'N' URLs 
m> per WPT becomes as trivial as accessing multiple WPTs per GPX file. :)

m> I realise that this is in complete disagreement with the current GPX 
m> specs...but, if there were to ever be any future revisions.... ;)

I wouldn't have any problem with making this change to the spec.
Logically, a wpt (or rte or rtept) can have 0..N URLs associated with
it, unlike the other GPX attributes (lat, lon, sym, desc).

--
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com


Public namespace extensions

egroups+topografix.com on Thu Jul 24 11:19:34 2003 (link), replying to msg

Hello,

I read through all the messages posted about map calibration
extensions, and it sounds like keeping map calibration data in its own
namespace is a solution that everyone would be willing to live with.
There is value in keeping the base GPX namespace simple.  The schema
is several pages long right now, and it's already difficult enough to
read for most people.  Having map calibration in a separate namespace
makes it very easy for people to ignore it if they don't plan to
support calibrated maps in their application.  For programs that do
support map calibration, it's a simple matter to include the
additional namespace.

There are already several examples of private namespace extensions to GPX.
groundspeak, topografix, and wissenbach are the ones I know of.  Each
of these is a private extension, with a single person or company
dictating the namespace extension, and free to change it at will.

We've talked in the past about creating public namespace extensions,
but until now we haven't implemented any.  Public namespace extensions
would be identical to private ones, but this group (or some subset of
the group) would define the schema definition and approve changes to
it.  Presumably, public namespace extensions would be for things that
are general enough that they would be exchanged between multiple
programs.  Perhaps to keep them distinguished from private extensions,
they should use namespaces starting with gpx_. (gpx_mapcal, gpx_url, etc)

I feel that private and public namespace extensions are the best way
to extend the functionality of GPX while keeping the base GPX
namespace simple.  We have several candidates for public namespaces
that have been brought up recently (or not so recently):
 map calibration
 multiple URLs per waypoint, route, etc
 display font size, style, color
 route width and color
 real-time tracking or NMEA data
 text annotations on maps

I'd like to see us pick one or two of these, and have an interested
subset of the group implement a public namespace extension.  If the
results are acceptable, I think this will become the preferred way for
extending GPX in the future.

What do you all think?

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com


RE: [gpsxml] Public namespace extensions

sandro_franchi+american-outland.com on Thu Jul 24 18:51:03 2003 (link), replying to msg


A separate namespace sounds perfect to me. Go ahead.
 
Thanks.

-----Original Message-----
From: Dan Foster [mailto:egroups+topografix.com] 
Sent: Jueves, 24 de Julio de 2003 03:20 p.m.
To: gpsxml+yahoogroups.com
Subject: [gpsxml] Public namespace extensions


Hello,

I read through all the messages posted about map calibration
extensions, and it sounds like keeping map calibration data in its own
namespace is a solution that everyone would be willing to live with.
There is value in keeping the base GPX namespace simple.  The schema
is several pages long right now, and it's already difficult enough to
read for most people.  Having map calibration in a separate namespace
makes it very easy for people to ignore it if they don't plan to
support calibrated maps in their application.  For programs that do
support map calibration, it's a simple matter to include the
additional namespace.

There are already several examples of private namespace extensions to GPX.
groundspeak, topografix, and wissenbach are the ones I know of.  Each
of these is a private extension, with a single person or company
dictating the namespace extension, and free to change it at will.

We've talked in the past about creating public namespace extensions,
but until now we haven't implemented any.  Public namespace extensions
would be identical to private ones, but this group (or some subset of
the group) would define the schema definition and approve changes to
it.  Presumably, public namespace extensions would be for things that
are general enough that they would be exchanged between multiple
programs.  Perhaps to keep them distinguished from private extensions,
they should use namespaces starting with gpx_. (gpx_mapcal, gpx_url, etc)

I feel that private and public namespace extensions are the best way
to extend the functionality of GPX while keeping the base GPX
namespace simple.  We have several candidates for public namespaces
that have been brought up recently (or not so recently):
map calibration
multiple URLs per waypoint, route, etc
display font size, style, color
route width and color
real-time tracking or NMEA data
text annotations on maps

I'd like to see us pick one or two of these, and have an interested
subset of the group implement a public namespace extension.  If the
results are acceptable, I think this will become the preferred way for
extending GPX in the future.

What do you all think?

-- 
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com



Yahoo! Groups Sponsor	

ADVERTISEMENT
 
<http://rd.yahoo.com/M=251812.3170658.4537139.1261774/D=egroupweb/S=17060303
90:HM/A=1652963/R=0/SIG=11tvulr8i/*http://www.netflix.com/Default?mqso=60178
275&partid=3170658> click here	
 
<http://us.adserver.yahoo.com/l?M=251812.3170658.4537139.1261774/D=egroupmai
l/S=:HM/A=1652963/rand=709705337> 	

To unsubscribe from this group, send an email to:
gpsxml-unsubscribe+yahoogroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
<http://docs.yahoo.com/info/terms/> . 



------?extPart_000_0001_01C35236.0B507640

Re: Multiple URLs in GPX

davewissenbach+yahoo.com on Sun Jul 27 14:50:16 2003 (link), replying to msg

--- In gpsxml+yahoogroups.com, Dan Foster <egroups+t...> wrote:
> Hello Matt,
> 
> Thursday, July 24, 2003, 8:20:46 AM, you wrote:
> 
> m> Ok, I'm no XML guru nor am I a GPS guru, but wouldn't it be 
feasible to 
> m> handle URLs the same way waypoints are handled?  That is to 
say, <url 
> m> href="http://www.someurl.com/somedoc.html">url name</url>, 
which could 
> m> be used from 0 to 'N' times per <wpt>?  Then referencing up 
to 'N' URLs 
> m> per WPT becomes as trivial as accessing multiple WPTs per GPX 
file. :)
> 
> m> I realise that this is in complete disagreement with the 
current GPX 
> m> specs...but, if there were to ever be any future 
revisions.... ;)
> 
> I wouldn't have any problem with making this change to the spec.
> Logically, a wpt (or rte or rtept) can have 0..N URLs associated 
with
> it, unlike the other GPX attributes (lat, lon, sym, desc).
> 
> --

This change should probably be in the base gpx namespace, in a 
future revision. But to avoid confusion with the existing version 
1.0, I suggest that the name of the new element be something like 
infourl, where multiple instances are allowed. GPX2.0 applications 
would write any number of urlinfo tags which would be ignored by 
GPX1.0 applications, as opposed to GPX2.0 applications writing the 
new url tag which causes a parsing error in a GPX1.0 document.


> Dan Foster
> TopoGrafix - GPS Software, Waypoints, and Maps
> http://www.topografix.com - mailto:egroups+t...


private elements

jeetsukumaran+pd.jaring.my on Fri Aug 01 21:20:49 2003 (link)

Hello.

My geodata has some additional information that I wish to save along 
with the standard fields offered by gpx. From what I can make out, I 
should declare a namespace to hold my private elements. 

Sounds kinky ... and I have no idea how to do it!

Could someone please help, by, for example, showing me how the 
following information might be encoded:

Waypoint:
Name:BRIDGE
Lat: 2.20321
Lon: 101.22322
Ele: 212.00
Time: 2003-08-01T13:00Z
Desc: Cross it when we come to it
Src: Garmin e-Trex

I want to add:
Keywords: Peat-swamp; conservation; project; river; survey;
RSOEasting: EEEEEEE
RSONorthing: NNNNNNN
Category: Survey


I know this much -

<wpt lat="2.20321" lon="101.22322">
  <ele>212.00</ele> 
  <time>2003-08-01T13:00Z</time> 
  <name>BRIDGE</name> 
  <desc>Cross it when we come to it</desc>
  <sym>Crossing</sym> 
<wpt>

How do I add the fields above? What file headers do I need to place 
at the top of the gpx file? What elements do I add to the <wpt> 
element?

Thanks!

-- jeet


Re: private elements

davewissenbach+yahoo.com on Sat Aug 02 12:07:28 2003 (link), replying to msg

--- In gpsxml+yahoogroups.com, "jeetsukumaran" <jeetsukumaran+p...> 
wrote:
> Hello.
> 
> My geodata has some additional information that I wish to save 
along 
> with the standard fields offered by gpx. From what I can make out, 
I 
> should declare a namespace to hold my private elements. 
> 
> Sounds kinky ... and I have no idea how to do it!
> 
> Could someone please help, by, for example, showing me how the 
> following information might be encoded:
> 
> Waypoint:
> Name:BRIDGE
> Lat: 2.20321
> Lon: 101.22322
> Ele: 212.00
> Time: 2003-08-01T13:00Z
> Desc: Cross it when we come to it
> Src: Garmin e-Trex
> 
> I want to add:
> Keywords: Peat-swamp; conservation; project; river; survey;
> RSOEasting: EEEEEEE
> RSONorthing: NNNNNNN
> Category: Survey
> 
> 
> I know this much -
> 
> <wpt lat="2.20321" lon="101.22322">
>   <ele>212.00</ele> 
>   <time>2003-08-01T13:00Z</time> 
>   <name>BRIDGE</name> 
>   <desc>Cross it when we come to it</desc>
>   <sym>Crossing</sym>
    <kinky:Keywords>Peat-swamp; conservation; project; river; 
survery;</kinky:Keywords>
    <kinky:RSOEasting>EEEEEE</kinky:RSOEasting>
    <kinky:RSONorthing>NNNNN</kinky:RSONORTHING>
    <kinky:Category>Survery</kinky:Category>
> <wpt>
> 
> How do I add the fields above? What file headers do I need to 
place 
> at the top of the gpx file?

For a header, use this

<gpx
  xmlns="http://www.topografix.com/GPX/1/0"
  version="1.0" creator="Wissenbach Map3D 2.8"
  xmlns:kinky="http://www.sukumarin.com/kinky"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://www.topografix.com/GPX/1/0 
http://www.topografix.com/GPX/1/0/gpx.xsd
                       http://www.sukumarin.com/kinky 
http://www.sukumarin.com/kinky/kinky.xsd">

Then at the schema location for the namespace listed, you provide an 
XML Schema, which looks
something like this:

<?xml version="1.0" encoding="utf-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
        targetNamespace="http://wwww.sukumarin.com/kinky"
        xmlns="http://www.sukumarin.com/kinky"
        elementFormDefault="qualified">

<annotation><documentation>
	This schema describes the extensions to the public gpx 
format used in the
      Map program by Jeet. Every element in the gpx format allows
      the insertion of element content, from another namespace. For 
example,
      Kinky adds Easting, Northing, and 
Category</documentation></annotation>

<xs:element name="RSAEasting" type="xs:string" minOccurs="0" /> 
<xs:element name="RSANorthing" type="xs:string" minOccurs="0" />
<xs:element name="Category" type="xs:string" minOccurs="0" /> 

</xs:schema> 

In your gpx document, kinky: is shorthand for your namespace
http://www.sukumarin.com/kinky.

I'd suggest that you get a book on XML Schema, such as Wrox Press's
XML Schema, which is where I learned this. (But some of this comes 
from trial and error.

What elements do I add to the <wpt> 
> element?
> 
> Thanks!
> 
> -- jeet


Re: private elements

jeetsukumaran+pd.jaring.my on Sat Aug 02 13:00:52 2003 (link), replying to msg

Thanks! This helps a lot. XML might as well be Sumerian to me, right 
now ... so you are right, I do have to read up on it.

I plan to use the MS xml parser to parse gpx files. Just out of 
curiosity, what files do I have to include with my program when I 
redistribute it? The MS documentation is a little confusing, 
referring to installer merge files and the like.

-- jeet

--- In gpsxml+yahoogroups.com, "davewissenbach" <davewissenbach+y...> 
wrote:
> --- In gpsxml+yahoogroups.com, "jeetsukumaran" <jeetsukumaran+p...> 
> wrote:
> > Hello.
> > 
> > My geodata has some additional information that I wish to save 
> along 
> > with the standard fields offered by gpx. From what I can make 
out, 
> I 
> > should declare a namespace to hold my private elements. 
> > 
> > Sounds kinky ... and I have no idea how to do it!
> > 
> > Could someone please help, by, for example, showing me how the 
> > following information might be encoded:
> > 
> > Waypoint:
> > Name:BRIDGE
> > Lat: 2.20321
> > Lon: 101.22322
> > Ele: 212.00
> > Time: 2003-08-01T13:00Z
> > Desc: Cross it when we come to it
> > Src: Garmin e-Trex
> > 
> > I want to add:
> > Keywords: Peat-swamp; conservation; project; river; survey;
> > RSOEasting: EEEEEEE
> > RSONorthing: NNNNNNN
> > Category: Survey
> > 
> > 
> > I know this much -
> > 
> > <wpt lat="2.20321" lon="101.22322">
> >   <ele>212.00</ele> 
> >   <time>2003-08-01T13:00Z</time> 
> >   <name>BRIDGE</name> 
> >   <desc>Cross it when we come to it</desc>
> >   <sym>Crossing</sym>
>     <kinky:Keywords>Peat-swamp; conservation; project; river; 
> survery;</kinky:Keywords>
>     <kinky:RSOEasting>EEEEEE</kinky:RSOEasting>
>     <kinky:RSONorthing>NNNNN</kinky:RSONORTHING>
>     <kinky:Category>Survery</kinky:Category>
> > <wpt>
> > 
> > How do I add the fields above? What file headers do I need to 
> place 
> > at the top of the gpx file?
> 
> For a header, use this
> 
> <gpx
>   xmlns="http://www.topografix.com/GPX/1/0"
>   version="1.0" creator="Wissenbach Map3D 2.8"
>   xmlns:kinky="http://www.sukumarin.com/kinky"
>   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>   xsi:schemaLocation="http://www.topografix.com/GPX/1/0 
> http://www.topografix.com/GPX/1/0/gpx.xsd
>                        http://www.sukumarin.com/kinky 
> http://www.sukumarin.com/kinky/kinky.xsd">
> 
> Then at the schema location for the namespace listed, you provide 
an 
> XML Schema, which looks
> something like this:
> 
> <?xml version="1.0" encoding="utf-8"?>
> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
>         targetNamespace="http://wwww.sukumarin.com/kinky"
>         xmlns="http://www.sukumarin.com/kinky"
>         elementFormDefault="qualified">
> 
> <annotation><documentation>
> 	This schema describes the extensions to the public gpx 
> format used in the
>       Map program by Jeet. Every element in the gpx format allows
>       the insertion of element content, from another namespace. For 
> example,
>       Kinky adds Easting, Northing, and 
> Category</documentation></annotation>
> 
> <xs:element name="RSAEasting" type="xs:string" minOccurs="0" /> 
> <xs:element name="RSANorthing" type="xs:string" minOccurs="0" />
> <xs:element name="Category" type="xs:string" minOccurs="0" /> 
> 
> </xs:schema> 
> 
> In your gpx document, kinky: is shorthand for your namespace
> http://www.sukumarin.com/kinky.
> 
> I'd suggest that you get a book on XML Schema, such as Wrox Press's
> XML Schema, which is where I learned this. (But some of this comes 
> from trial and error.
> 
> What elements do I add to the <wpt> 
> > element?
> > 
> > Thanks!
> > 
> > -- jeet


GPX-interface in GeoConv

eeronpoika+yahoo.com on Sun Aug 03 10:50:37 2003 (link)

I am new to GPX, but I implemented handling of GPX-format in my 
freeware program GeoConv, which converts between different file-
formats, datums, coordinate-formats.

Since most of you know GPX quite well, I send a short description of 
the implementation. All corrections, suggestions and other comments 
are welcome and appreciated.

I have tested the output against GPX-schema using XML-validator, but 
I still keep on testing. I continue with implementing Route-handling.

Address to software: www.iki.fi/eino.uikkanen/geoconvgb/

Wbr,
Eino Uikkanen
www.iki.fi/eino.uikkanen/gb/

Short description (cut of the manual):

GPX, Topografix GPS eXchange format

Because the datum is fixed to WGS84 in this format, the values of the 
parameters INDATUM and OUTDATUM have no effect.

GPX-format does not transfer height-coordinate (height above 
ellipsoid). Therefore GeoConv interprets in input and output, that 
height above ellipsoid equals to the sum of the values of elements 
<ele> and <geoidheight>.

If input-file contains both track-points and waypoints, but the order 
of appearance does not agree with GPX-standard, GeoConv does not 
change the order to agree with standard.

The values to parameters below are fetched from respective GeoConv-
parameters. Values below are default values set by initialization run 
GeoConv.ini. 

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://www.topografix.com/GPX/1/0"
xsi:schemaLocation="http://www.topografix.com/GPX/1/0 gpx.xsd">

GeoConv reads and writes the fields represented in the sample below: 

<gpx version="1.0" creator="GeoConv"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns="http://www.topografix.com/GPX/1/0"
   xsi:schemaLocation="http://www.topografix.com/GPX/1/0 gpx.xsd">
   <desc>From C:\GPSDATA\PCX5\SOUR\PORKNIEM.GRM</desc>
   
   <trk>
      <name>Track 01</name>
      <desc>Track 1</desc>
      <number>1</number>
      <trkseg>
         <trkpt lat="+059.975567" lon="+024.401246">
            <ele>0</ele>
            <time>1997-10-20T12:26:14Z</time>
            <geoidheight>0</geoidheight>
            <name>BRIDGE</name>
            <desc>Bridge to Varo</desc>
         </trkpt>
      </trkseg>
   </trk>
   
   <wpt lat="+060.008006" lon="+024.455481">
      <ele>0</ele>
      <time>1962-03-27T00:00:00Z</time>
      <geoidheight>0</geoidheight>
      <name>BRIDGE</name>
      <desc>Bridge to Varo</desc>
   </wpt>
   
</gpx>




Re: Describing datum

eeronpoika+yahoo.com on Sun Aug 03 13:13:22 2003 (link), replying to msg

--- In gpsxml+yahoogroups.com, Dan Foster <egroups+t...> wrote:
> s> 2.  What is the difference between <ele> and <geoid>?
> 
> <ele> Elevation - I didn't define this very precisely in the
> documentation.  It means what you think it means - the height, in
> meters above mean sea level, of an object.
> 
> <geoidheight> Height, in meters, of WGS-84 earth ellipsoid above
> mean sea level at the point. (This value is useful if you're
> processing the NMEA GGA message)

Hi,

I am responding to an old message, but since it is used as reference 
through archive, I suppose it is not too late to comment on that.

1) I want to check if your definition of <geoidheight> above is what 
you actually meant. I wonder if you wanted to say vice versa, "Height 
of geoid (mean sea level) above WGS84 ellipsoid", not height of 
ellipsoid above geoid?

2) I would be happy to see height coordinate (height of the point 
above the reference ellipsoid) in GPX-standard - now it is totally 
missing. Neither of <ele> nor <geoidheight> can replace it. The third 
coordinate value in addition to latitude and longitude is height 
above ellipsoid. The physical heights are actually properties of a 
point defined by (lat,lon,height above ellipsoid). To be accurate, 
physical heights are vector-functions of (lat,lon,height above 
ellipsoid), even though only the scalar part is normally used. Summa 
summarum: height above reference ellipsoid can�t be substituted by 
other heights.

With Kind Regards,
Eino Uikkanen
www.iki.fi/eino.uikkanen/gb/




Re: [gpsxml] Re: Describing datum

egroups+topografix.com on Mon Aug 04 08:07:19 2003 (link), replying to msg

Hello,

Sunday, August 3, 2003, 4:13:17 PM, Eino wrote:

e> --- In gpsxml+yahoogroups.com, Dan Foster <egroups+t...> wrote:
>> s> 2.  What is the difference between <ele> and <geoid>?
>> 
>> <ele> Elevation - I didn't define this very precisely in the
>> documentation.  It means what you think it means - the height, in
>> meters above mean sea level, of an object.
>> 
>> <geoidheight> Height, in meters, of WGS-84 earth ellipsoid above
>> mean sea level at the point. (This value is useful if you're
>> processing the NMEA GGA message)

e> Hi,

e> I am responding to an old message, but since it is used as reference 
e> through archive, I suppose it is not too late to comment on that.

e> 1) I want to check if your definition of <geoidheight> above is what 
e> you actually meant. I wonder if you wanted to say vice versa, "Height 
e> of geoid (mean sea level) above WGS84 ellipsoid", not height of 
e> ellipsoid above geoid?

I copied this definition word for word from the description of the
NMEA GGA sentence in my Magellan 315 user's manual.  But you are
correct, I believe the name we chose is confusing.  It probably should
be called <ellipsoidheight>, since it's the height of the ellipsoid
above the geoid (mean sea level).

e> 2) I would be happy to see height coordinate (height of the point 
e> above the reference ellipsoid) in GPX-standard - now it is totally 
e> missing. Neither of <ele> nor <geoidheight> can replace it. The third 
e> coordinate value in addition to latitude and longitude is height 
e> above ellipsoid. The physical heights are actually properties of a 
e> point defined by (lat,lon,height above ellipsoid). To be accurate, 
e> physical heights are vector-functions of (lat,lon,height above 
e> ellipsoid), even though only the scalar part is normally used. Summa 
e> summarum: height above reference ellipsoid can?be substituted by 
e> other heights.

Perhaps I'm not understanding you correctly.  It seems to me that your
new height "h" is just the difference between <ele> and <geoidheight>.

h = height above WGS84 ellipsoid
ele = height above mean sea level (geoid)
geoidheight = height of WGS84 ellipsoid above mean sea level (geoid)

so, h = ele - geoidheight
-- 

Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com


Re: Describing datu