#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)
Change History (14)
comment:1 by , 15 years ago
comment:2 by , 15 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:3 by , 15 years ago
follow-up: 5 comment:4 by , 15 years ago
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 by , 15 years ago
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/browser/grass/trunk/vector/v.out.ogr https://trac.osgeo.org/grass/browser/grass/trunk/scripts/v.out.gps
thanks, Hamish
follow-up: 7 comment:6 by , 15 years ago
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 by , 15 years ago
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 by , 15 years ago
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
follow-up: 10 comment:9 by , 15 years ago
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.
by , 15 years ago
Attachment: | archsites.tgz added |
---|
grass's spearfish demo dataset's archsites points map as a shapefile
comment:10 by , 15 years ago
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
follow-up: 12 comment:11 by , 15 years ago
Keywords: | gpx added |
---|---|
Milestone: | → 1.6.0 |
Resolution: | → fixed |
Status: | assigned → closed |
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 by , 15 years ago
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 by , 15 years ago
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 ;-)
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