[GRASS-user] d.what.vect multi-layer, SQLite datetime

Hi,

I have a 5 layer vector map created with v.in.ogr's GPX driver.

I've displayed layer=3 cat=n (a single GPS track) with d.vect in an xmon.
So far so good.

if I then run d.what.vect it only shows details for layer=5 (track points)
when what I want to know is track name (stored in layer 3).
How to query layer=3?

also I get a number of warnings like:
WARNING: SQLite driver: unable to parse decltype: datetime
WARNING: SQLite driver: unable to parse decltype: datetime
WARNING: SQLite driver: column 'time', SQLite type 3 is not supported

?
(timestamps are rather important to tell overlapping tracks apart)

thanks,
Hamish

Hamish wrote:

I have a 5 layer vector map created with v.in.ogr's GPX
driver.

....

also I get a number of warnings like:
WARNING: SQLite driver: unable to parse decltype: datetime
WARNING: SQLite driver: unable to parse decltype: datetime
WARNING: SQLite driver: column 'time', SQLite type
3 is not supported

?
(timestamps are rather important to tell overlapping tracks
apart)

some more info:

ogr2ogr gives this warning for GPX->shp:
Warning 6: Field time create as date field, though DateTime requested.
Warning 6: Field time create as date field, though DateTime requested.
Warning 6: Field time create as date field, though DateTime requested.

and time column in track_points shapefile is empty when it has a value,
and 0 when not. In GRASS with v.in.ogr track_points layer fills in
previous column (elevation) in time column when there is no timestamp,
or real timestamp when it does have it. mmph.

shp uses dbf, which will cut column names at 10 chars, but output layers
are named well (route_points, routes, track_points, tracks, waypoints)
which are lost when called grass layers 1-5.

Hamish

On Tue, Nov 18, 2008 at 8:32 AM, Hamish <hamish_b@yahoo.com> wrote:

Hamish wrote:

I have a 5 layer vector map created with v.in.ogr's GPX
driver.

....

also I get a number of warnings like:
WARNING: SQLite driver: unable to parse decltype: datetime
WARNING: SQLite driver: unable to parse decltype: datetime
WARNING: SQLite driver: column 'time', SQLite type
3 is not supported

?
(timestamps are rather important to tell overlapping tracks
apart)

some more info:

ogr2ogr gives this warning for GPX->shp:
Warning 6: Field time create as date field, though DateTime requested.
Warning 6: Field time create as date field, though DateTime requested.
Warning 6: Field time create as date field, though DateTime requested.

and time column in track_points shapefile is empty when it has a value,
and 0 when not. In GRASS with v.in.ogr track_points layer fills in
previous column (elevation) in time column when there is no timestamp,
or real timestamp when it does have it. mmph.

Could this be related:
http://trac.osgeo.org/gdal/ticket/2474
"DateTime -> Date write support in Shapefile support"

?

Markus

shp uses dbf, which will cut column names at 10 chars, but output layers
are named well (route_points, routes, track_points, tracks, waypoints)
which are lost when called grass layers 1-5.

Hamish

_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

--
Open Source Geospatial Foundation
http://www.osgeo.org/
http://www.grassbook.org/

Hamish wrote:
....

> ogr2ogr gives this warning for GPX->shp:
> Warning 6: Field time create as date field, though DateTime requested.
> Warning 6: Field time create as date field, though DateTime requested.
> Warning 6: Field time create as date field, though DateTime requested.
>
> and time column in track_points shapefile is empty when it has a value,
> and 0 when not. In GRASS with v.in.ogr track_points layer fills in
> previous column (elevation) in time column when there is no timestamp,
> or real timestamp when it does have it. mmph.

Markus:

Could this be related:
http://trac.osgeo.org/gdal/ticket/2474
"DateTime -> Date write support in Shapefile support"

?

for the ogr2ogr problem I'd say yes. Amazing timing, fixed 14 hours ago.

For the GRASS problem perhaps it helps, I'm not sure. They are two
different issues at the end, but maybe they have the same grandparent.

to expand on previous layer issues, v.in.ogr creates 5 tables for 5
layers with GPX input, but names tables as <${MAPNAME}_ogr_[1-5]> instead
of naming the tables as route, route_points, track, trk_pts, wpts as with
SHP output from ogr2ogr. So somwhere "_ogr_${n}" needs some work.
Is table name the usual way folks manage which layer is which?

Hamish