typo in ogr/drv_gpx.html

[hamish]

Hi,

while trying to debug GRASS's 'v.out.ogr format=GPX'*, I noticed a small typo in ogr/drv_gpx.html:

 * GPX_EXTENSIONS_NS: Only used if [...]
 he namespace value used for extension tags. By default, "ogr".

[he -> The] on the second line.

[*] gpx driver problem: (suspect user error)

  GRASS> v.out.ogr in=temp_epsg4326_1234 dsn=temp_12345.xml \
    type=line format=GPX lco="GPX_USE_EXTENSIONS=YES"
[...]
ERROR 6: Field of name 'cat' is not supported in GPX schema. Use GPX_USE_EXTENSIONS creation option to allow use of the <extensions> element.

but I did ask for GPX_USE_EXTENSIONS...? (no <extensions> fields in the GPX) -debian/stable/backports.org gdal/ogr 1.5.0

Hamish

[hamish]

GRASS> v.out.ogr in=temp_epsg4326_1234 dsn=temp_12345.xml \
    type=line format=GPX lco="GPX_USE_EXTENSIONS=YES"
[...]
ERROR 6: Field of name 'cat' is not supported in GPX schema. Use GPX_USE_EXTENSIONS creation option to allow use of the <extensions> element.

not only does "cat" not become an <extentions>, it's value ends up in the <ele> elevation field in the GPX file.

does cat have to be renamed foo_cat or?

Hamish

[rouault]

Typo fixed in r15655.

And for the other issue, I understand why it doesn't work for you. The current doc was wrong. GPX_USE_EXTENSIONS is not a layer creation option, but a dataset one... (dsco=...). Fixed in r15656

[rouault]

hamish,

I can't reproduce a way that a field not handled by the GPX schema goes into the <ele> field.

Could you provide me with a simple input datafile and a ogr2ogr commandline that reproduces that (wrong) behaviour ?

[hamish]

Thanks for fixing docs, that makes more sense.

Replying to rouault:

I can't reproduce a way that a field not handled by the GPX schema goes into the <ele> field. Could you provide me with a simple input datafile and a ogr2ogr commandline that reproduces that (wrong) behaviour ?

Hmmm, it works ok using ogr2ogr:

GRASS's sample Spearfish dataset:
# export shapefile
v.out.ogr in=archsites type=point dsn=archsites.shp

# get PROJ.4 params of current location (Spearfish=UTM 13N)
IN_PROJ=`g.proj -jf`


ogr2ogr -f GPX -dsco GPX_USE_EXTENSIONS=YES \
  -a_srs "$IN_PROJ" -t_srs EPSG:4326 \
  output.gpx archsites.shp

result:

<?xml version="1.0"?>
<gpx version="1.1" creator="GDAL 1.5.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instan
ce" xmlns:ogr="http://osgeo.org/gdal" xmlns="http://www.topografix.com/GPX/1/1" xsi:schema
Location="http://www.topografix.com/GPX/1/1 http://www.topografix.com/GPX/1/1/gpx.xsd">
<wpt lat="44.381771718385657" lon="-103.826359511024279">
  <extensions>
    <ogr:cat>          1</ogr:cat>
    <ogr:str1>Signature Rock</ogr:str1>
  </extensions>
</wpt>
<wpt lat="44.456408157151380" lon="-103.844259647363543">
  <extensions>
    <ogr:cat>          2</ogr:cat>
    <ogr:str1>No Name</ogr:str1>
  </extensions>
</wpt>
<wpt lat="44.447669817618234" lon="-103.870697678751810">
  <extensions>
    <ogr:cat>          3</ogr:cat>
    <ogr:str1>Canyon Station</ogr:str1>
  </extensions>
</wpt>
...

slight issue: cat number (column type integers) get padded?

but using GRASS's 'v.out.ogr format=GPX' (via v.out.gps[babel] 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 during the v.extract step)

and output:

<?xml version="1.0"?>
<gpx version="1.1" creator="GDAL 1.5.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instan
ce" xmlns:ogr="http://osgeo.org/gdal" xmlns="http://www.topografix.com/GPX/1/1" xsi:schema
Location="http://www.topografix.com/GPX/1/1 http://www.topografix.com/GPX/1/1/gpx.xsd">
<wpt lat="44.381755779999999" lon="-103.826838609999996">
  <ele>1</ele>
  <extensions>
  </extensions>
</wpt>
<wpt lat="44.456392070000000" lon="-103.844739759999996">
  <ele>2</ele>
  <extensions>
  </extensions>
</wpt>
<wpt lat="44.447653719999998" lon="-103.871178959999995">
  <ele>3</ele>
  <extensions>
  </extensions>
</wpt>
</gpx>

(<ele> is cat number in above)

So it's a GRASS v.out.ogr bug I guess. filed as GRASS bug # 354:

 https://trac.osgeo.org/grass/ticket/354

 https://trac.osgeo.org/grass/browser/grass/trunk/vector/v.out.ogr  https://trac.osgeo.org/grass/browser/grass/trunk/scripts/v.out.gps

thanks, Hamish

[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.

Hamish

[hamish]

Replying to 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)

?? Hamish

[hamish]

GRASS> IN_PROJ=`g.proj -jf`
GRASS> echo $IN_PROJ
+proj=utm +zone=13 +a=6378206.4 +rf=294.9786982 +no_defs +nadgrids=/usr/local/src/grass/svn/grass64/dist.i686-pc-linux-gnu/etc/nad/conus +to_meter=1.0

GRASS> echo "593493 4914730" | cs2cs -f '%.8f' $IN_PROJ +to +init=epsg:4326
-103.82683861   44.38175578 0.00000000

which matches the lower (as it should, as m.proj is the cs2cs frontend)

but if I mangle the nadfile name we get the top (ogr2ogr) number:

$ echo "593493 4914730" | cs2cs -f '%.8f' +proj=utm +zone=13 +a=6378206.4 +rf=294.9786982 +no_defs +nadgrids=/usr/local/src/grass/svn/grass64/dist.i686-pc-linux-gnu/etc/nad/conusFOO +to_meter=1.0 +to +init=epsg:4326
-103.82635951   44.38177172 0.00000000

so ogr2ogr isn't applying the given +nadgrid file. (this is gdal 1.5.0)

Hamish

[rouault]

Hum, different issues. I'm getting a bit lost...

About the padding thing, would you mind attaching 'archsites.shp' to the ticket ?

About nadgrids, this is a completely different topic. My understanding while reading ogr_srs_proj4.cpp is that OSR doesn't support the nadgrid parameter when parsing PROJ4 strings. But that's not in my area of competence, so you should rather email or search the gdal-dev mailing list to get better feedback on that issue.

[hamish]

grass's spearfish demo dataset's archsites points map as a shapefile

[hamish]

Replying to rouault:

About nadgrids, this is a completely different topic. My understanding while reading ogr_srs_proj4.cpp is that OSR doesn't support the nadgrid parameter when parsing PROJ4 strings. But that's not in my area of competence, so you should rather email or search the gdal-dev mailing list to get better feedback on that issue.

Correct, first google hit for ogr2ogr+nadgrids gave the answer: append +wktext to the input SRS. Then it works.

 http://lists.osgeo.org/pipermail/gdal-dev/2007-April/012561.html

Hamish

[rouault]

Hamish,

I've commited a fix in r15680 for the issue of leading spaces in front of numeric values. This is due to the fact that the shapefile defines an explicit width for the 'cat' field and that GetFieldAsString?() uses this width to pad it with spaces.

Closing now.

And thanks for the reference to the +wktext parameter ;-)

[hamish]

Replying to rouault:

I've commited a fix in r15680 for the issue of leading spaces in front of numeric values. This is due to the fact that the shapefile defines an explicit width for the 'cat' field and that GetFieldAsString?() uses this width to pad it with spaces. Closing now.

thanks for all your help.

And thanks for the reference to the +wktext parameter ;-)

how shall I say.. it is not exactly intuitive to the layman, but easily dealt with once you know the answer.

cheers, I am sure GRASS's new v.out.gps[babel] script will be a nice addition to the toolkit once we get the v.out.ogr DB issue sorted out. Between v.out.ogr and v.out.gpsbabel the user has many many format options...!

Hamish

[rouault]

I agree it is not intuite. In r15681, I've added a note (copy&paste of the discussion you pointed out) in the documentation of OGRSpatialReference::importFromProj4(). Hopefully some people will find it ;-)