[GeoJSON] (no subject)

[Jukka Rahkonen]

Hi,

Most GIS formats do not support nested features like GPX does. In GPX
tracks and routes are linear features with a set of attributes and they
contain track and route points which are point features with their own set
of attributes. Something to read about nested features can be found from
this document:
http://docs.codehaus.org/display/GEOTOOLS/GML+Schema+support+requirements

Handling GPX track points as coordinates with XYZM dimensios is not a
general solution because track points can have however complicated schema.
This is a track point schema of a GPX file which is recorded with
OziExplorer

track_fid: Integer (0.0)
track_seg_id: Integer (0.0)
track_seg_point_id: Integer (0.0)
ele: Real (0.0)
time: DateTime (0.0)
magvar: Real (0.0)
geoidheight: Real (0.0)
name: String (0.0)
cmt: String (0.0)
desc: String (0.0)
src: String (0.0)
link1_href: String (0.0)
link1_text: String (0.0)
link1_type: String (0.0)
link2_href: String (0.0)
link2_text: String (0.0)
link2_type: String (0.0)
sym: String (0.0)
type: String (0.0)
fix: String (0.0)
sat: Integer (0.0)
hdop: Real (0.0)
vdop: Real (0.0)
pdop: Real (0.0)
ageofdgpsdata: Real (0.0)
dgpsid: Integer (0.0)

I do not know if nested features are allowed in GeoJSON but they are in
any case hard to handle and an easier and still usable solution would be
to make the conversion application to create two GeoJSON files, one for
the track and another for the track points. This is also how GDAL GPX
driver works. GDAL finds totally five layers from a GPX data
http://gdal.org/ogr/drv_gpx.html

-Jukka Rahkonen-

Tom MacWright wrote:

> Hey all,
>
> So recently I've been working on a site that centers around editing maps
> and treats GeoJSON as its latin[1]. As one of the features on this site, it
> uses a library to convert from other formats - KML, CSV, and GPX - to
> GeoJSON[2]. This has been pretty great, and clearly GeoJSON is a superset
> of CSV, and can handle most bits of KML. That said, though, GPX files
> present a bit of an issue.
>
> That is, GPX allows you to specify values at points - a segment is made up
> of trackpoints, which can have their own data points - elevation, time,
> heart rate, and so on. The conversion library right now simply converts
> segments into lines and throws away data-at-points.
>
> So, my question is: what's a better way? I don't want to encourage or imply
> that GeoJSON should grow, since its simplicity is incredibly valuable. But,
> in order to stem the fidelity loss in this conversion, is there a good
> pattern for storing this kind of data? What kind of data is this - what's
> the right term for values-on-lines and is it weird that GPX supports it
> while other geospatial formats don't?
>
> Thanks for any knowledge or advice here, it's much appreciated!
>
> Tom
>
> [1]: http://geojson.io/
> [2]: https://github.com/tmcw/togeojson
> [3]: http://en.wikipedia.org/wiki/GPS_eXchange_Format#Sample_GPX_document