slight issue: cat number (column type integers) get padded?
but using GRASS's 'v.out.ogr format=GPX' (via v.out.gpsbabel script) I
get:
{{{
v.out.gpsbabel -w in=archsites out=archsites.gpx where="cat < 4" --verbose
Extracting data ...
Reprojecting data ...
Exporting data ...
WARNING: No attribute table found -> using only category numbers as
attributes
Cleaning up ...
Fast exit.
}}}
(but there is an attribute table found, otherwise SQL where= query
would fail in the v.extract step)
#354: v.out.ogr: bad DB read for format=GPX
---------------------+------------------------------------------------------
Reporter: hamish | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: major | Milestone: 6.4.0
Component: Vector | Version: svn-develbranch6
Resolution: | Keywords: v.out.ogr GPX
Platform: Linux | Cpu: x86-32
---------------------+------------------------------------------------------
Comment (by hamish):
also to note diff in lat/lon in above two examples:
{{{
<wpt lat="44.381771718385657" lon="-103.826359511024279">
<wpt lat="44.381755779999999" lon="-103.826838609999996">
}}}
I don't really know why that is different. Both ogr2ogr and m.proj (cs2cs
frontend script) should be using +nadgrids conus and identical setup
method..? strange.
#354: v.out.ogr: bad DB read for format=GPX
---------------------+------------------------------------------------------
Reporter: hamish | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: major | Milestone: 6.4.0
Component: Vector | Version: svn-develbranch6
Resolution: | Keywords: v.out.ogr GPX
Platform: Linux | Cpu: x86-32
---------------------+------------------------------------------------------
Comment (by hamish):
Replying to [comment:1 hamish]:
> also to note diff in lat/lon in above two examples:
> {{{
> <wpt lat="44.381771718385657" lon="-103.826359511024279">
> <wpt lat="44.381755779999999" lon="-103.826838609999996">
> }}}
>
> I don't really know why that is different. Both ogr2ogr and
> m.proj (cs2cs frontend script) should be using +nadgrids conus
> and identical setup method..? strange.
v.out.gps[babel] -> m.proj -> cs2cs is called with "-f %.8f", which
explains the FP quant in the second set, but the top one (ogr2ogr) changes
at ~ %.4f or .5 (>1m)
the "cat" field will always be present regardless of if the map has an
attached attribute DB or not. (i.e. a key INTEGER db field will always be
present, and by default this is named "cat")
AFAICT if there is no attribute DB attached to the map the key field (eg
"cat") should be used for <name> in the GPX file.
#354: v.out.ogr: bad DB read for format=GPX
---------------------+------------------------------------------------------
Reporter: hamish | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: major | Milestone: 6.4.0
Component: Vector | Version: svn-develbranch6
Resolution: | Keywords: v.out.ogr GPX
Platform: Linux | Cpu: x86-32
---------------------+------------------------------------------------------
Comment (by hamish):
----
rouault wrote:
Hamish,
I'm pretty sure that it's a GRASS issue and not a OGR one.
Disclaimer, I've not read GRASS source code, but the only way to explain
what happens is that GRASS proceeds that way :
* first, it uses poLayer->CreateField(poField) where poField in your
example is something like ("cat", String), then ("OBJECTID", String),
etc... But for the GPX driver, when you add the first use field, namely
"cat", it's not put at index 0 of the field definition array, but at field
10 or so, after all the compulsory GPX fields for the <wpt> tag
* then, GRASS uses poFeature->SetField(0,
"the_value_of_the_cat_record_on_that_feature"), which is wrong because
index 0 is in fact the <ele> field. Instead of using index 0, it should
use poFeature->GetFieldIndex("cat") to retrieve the good index of the cat
field when it is set in the GPX layer object.
I hope I'm clear and that will make sense for the GRASS developers.
#354: v.out.ogr: bad DB read for format=GPX
---------------------+------------------------------------------------------
Reporter: hamish | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: major | Milestone: 6.4.0
Component: Vector | Version: svn-develbranch6
Resolution: | Keywords: v.out.ogr GPX
Platform: Linux | Cpu: x86-32
---------------------+------------------------------------------------------
Comment (by hamish):
patch to v.out.ogr added to ticket. It populates OGR table using correct
OGR field index, not GRASS's DB column order.
todo:
- clear data columns (need to open Table/cursor or move that
functionality into top of population loop.
- verify the removal of keyval doesn't hurt anything (e.g. case
insensitive column names)
- test, test, test (breaking shapefile output would be bad..)