[Geojson] GPX files to GeoJSON

[Sean Gillies]

Hi, John

On Jun 25, 2009, at 12:05 AM, John Smith wrote:

>
> I've looked into the GeoJSON specs and I'm curious as to the way GPX  
> to GeoJSON conversions are handled.
>

GeoJSON wasn't particularly designed for GPX, as you're discovering,  
but is general enough that GPS traces can be represented in a few  
different ways.


> At most the information converted only includes the latitude and  
> longitude, where as GPX files generally contain a lot more useful  
> information, at the very minimum the time stamp is required, along  
> with optional fields like elevation, HDOP or other dilution of  
> precision information.
>
> While I think it's a good idea in general to come to some sort of  
> agreement on a common format, I don't think GeoJSON spec hit the  
> mark entirely.
>
> Also I noticed an email sent to the list about a schema to parse/ 
> describe, but that's defeating the point of JSON since it is a bad  
> idea in general to outsource your parsing to someone else.
>
> Take this example I pulled from OSM at random: http://www.openstreetmap.org/trace/423839/data
>
> It contains redundant information of speed which can be calculated,  
> and hdop is more informative than the number of satellites and if  
> you have a 2d or 3d fix. That aside, the information produced comes  
> out a lot less useful when converted to GeoJSON.
>
> http://gpx2geojson.appspot.com?gpxurl=http://www.openstreetmap.org/trace/423839/data
>
> While it's nice to save bytes, I think the lack of field names does  
> more harm than good and further breaks the intent of JSON,  
> especially since compression can save all the bytes you need.
>
> Also instead of breaking existing specs, may I be so bold as to  
> propose extending the current spec to include another geometry type  
> of GPStrace, and the coordinate array would be made up of at least  
> the following fields:
>
> latitude, longitude, time
>
> option fields:
>
> elevation, hdop, pdop, vdop, satallites, fix
>
> However each field would need to be labelled, which would allow for  
> greater flexibility for people to extend this even further without  
> breaking the spec.
>
> A full example of what I mean:
>
> {
> 	"properties":
> 	{
> 		"gpxversion":1,
> 		"gpxcreator":"GPSBabel - http:\/\/www.gpsbabel.org"
> 	},
> 	"type":"FeatureCollection",
> 	"features":
> 	{
> 		"properties":
> 		{
> 			"gpxtype":"trkType",
> 			"name":"TRCK3"
> 		},
> 		"type":"Feature",
> 		"geometry":
> 		{
> 			"type":"GPStrace",
> 			"coordinates":
> 			[
> 				{"lat":0,"lon":0,"ele":0,"time":0,"hdop":0},
> 				{"lat":0,"lon":0,"ele":0,"time":0,"hdop":0},
> 				{"lat":0,"lon":0,"ele":0,"time":0,"hdop":0},
> 				{"lat":0,"lon":0,"ele":0,"time":0,"hdop":0},
> 				{"lat":0,"lon":0,"ele":0,"time":0,"hdop":0},
> 				{"lat":0,"lon":0,"ele":0,"time":0,"hdop":0},
> 				{"lat":0,"lon":0,"ele":0,"time":0,"hdop":0},
> 				{"lat":0,"lon":0,"ele":0,"time":0,"hdop":0},
> 				{"lat":0,"lon":0,"ele":0,"time":0,"hdop":0}
> 			]
> 		}
> 	}
> }
>

A GPS trace isn't a geometry in the GML sense (GeoJSON is inspired by,  
and fairly faithful to the GML geometry model, or at least a subset).  
I see two ways to do this without inventing a odd geometry type: 1)  
every trace point as a GeoJSON feeature with a point geometry (3D  
even) and time and hdop properties, or 2) a trace as a GeoJSON feature  
with a multipoint or linestring geometry (3D even) and time and hdop  
array properties having the same length as your geometry coordinates,  
perhaps even within a "gpx" object like this:

{ "type": "Feature",
   "geometry": { "type": "LineString",
                 "coordinates": [[0.0, 0.0], [1.0, 1.0]]
                 },
   "properties": { "gpx": { "hdop": [0, 0], "time": [1..., 2...] } },
   "title": "GPS trace feature"
   }

I believe it was Jeremy Cothran who proposed matching arrays to me. I  
didn't like it at first, but it's growing on me.

Sean


--
Sean Gillies
sean.gillies at gmail.com
http://sgillies.net