[Geojson] GPX files to GeoJSON

[Jeremy Cothran]

The two issues that most run into with both traditional GIS and GeoJSON,etc
is that neither is designed to address content associative time-series or
collections.  The most technically efficient thing of pushing everything
into one array would break the model of separating geometry from associated
content, unfortunately associated content in today's context assumes a
single time and a single thing(or set of attributes associated with a single
thing like a golf course hole or a newt at a point,etc).
So I'd also like to see those two common(but more complex) issues addressed
in a common way, hopefully enough user/application interest can gather to
spark developer interest in addressing them.

The earlier experimentation I was playing with in regards to GeoJSON was in
the ocean observing systems context, just some ideas and fodder to foment
further discussion.

http://code.google.com/p/xenia/wiki/ObsJSON#Simple_schema_version_2

The issues with Chris's suggestion I have are that 'time', etc aren't really
formally recognized content but more like all other geometry content - just
a bucket of disorganized information - this is fine in the usual GeoRSS type
context of free-form/twitter type content but not useful from a
data-processing/microformat type context.  I don't think that GeoJSON as a
geometry-focused model is going to go down to the content level of detail
that will make application developers happy - I think its more for
application developers to tie-into/associate their content with the existing
GML, GeoJSON model in a microformat type context.

Thanks
Jeremy Cothran

On Thu, Jun 25, 2009 at 10:57 AM, John Smith <delta_foxtrot at yahoo.com>wrote:

>
> --- On Thu, 25/6/09, Sean Gillies <sgillies at frii.com> wrote:
>
> > 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.
>
> If the fields had column names like JSON is designed, it wouldn't be a
> problem to extend things in any number of ways to deal with this.
>
> > 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.
>
> I think that would waste a lot of memory and/or be very inefficient to
> parse/process.
>
> I don't see the point in having 2 arrays with virtually identical data,
> when one would accomplish a thing.
>
> Also GPS traces are fairly geospatial. :) so I don't know why GPS traces
> don't fit in this particular model, all it will do is force people to do
> there own thing where GeoJSON could fit the role just fine with very little
> tweaking.
>
>
>
> _______________________________________________
> Geojson mailing list
> Geojson at lists.geojson.org
> http://lists.geojson.org/listinfo.cgi/geojson-geojson.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.geojson.org/pipermail/geojson-geojson.org/attachments/20090625/95ab8a30/attachment.htm>