Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#2638 closed defect (fixed)

typo in ogr/drv_gpx.html

Reported by: hamish Owned by: Even Rouault
Priority: normal Milestone: 1.6.0
Component: Website Version: 1.5.0
Severity: trivial Keywords: gpx
Cc:

Description

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

Attachments (1)

archsites.tgz (1.1 KB) - added by hamish 12 years ago.
grass's spearfish demo dataset's archsites points map as a shapefile

Download all attachments as: .zip

Change History (14)

comment:1 Changed 12 years ago by 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

comment:2 Changed 12 years ago by Even Rouault

Owner: changed from Mateusz Łoskot to Even Rouault
Status: newassigned

comment:3 Changed 12 years ago by Even 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

comment:4 Changed 12 years ago by Even 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 ?

comment:5 in reply to:  4 Changed 12 years ago by 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

comment:6 Changed 12 years ago 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.

Hamish

comment:7 in reply to:  6 Changed 12 years ago by 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

comment:8 Changed 12 years ago by 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

comment:9 Changed 12 years ago by Even 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.

Changed 12 years ago by hamish

Attachment: archsites.tgz added

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

comment:10 in reply to:  9 Changed 12 years ago by 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

comment:11 Changed 12 years ago by Even Rouault

Keywords: gpx added
Milestone: 1.6.0
Resolution: fixed
Status: assignedclosed

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 ;-)

comment:12 in reply to:  11 Changed 12 years ago by 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

comment:13 Changed 12 years ago by Even 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 ;-)

Note: See TracTickets for help on using tickets.