OGR GPX driver bad extensions filling from GRASS

[hamish]

Hi,

this is a followup to #2638,

​https://trac.osgeo.org/gdal/ticket/2638#comment:1

cross-filed as GRASS bug # 354

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

data intended for <extensions> is filling standard GPX fields instead.

Exporting a points feature map as GPX: (GRASS's North Carolina sample dataset)

# export GRASS points map as GPX format
GRASS64> v.out.ogr in=hospitals dsn=hsp.gpx format=GPX type=point \
   dsco="GPX_USE_EXTENSIONS=YES"


GRASS64> v.info -c hospitals
Displaying column types/names for database connection of layer 1:
INTEGER|cat
INTEGER|OBJECTID
DOUBLE PRECISION|AREA
DOUBLE PRECISION|PERIMETER
INTEGER|HLS_
INTEGER|HLS_ID
CHARACTER|NAME
CHARACTER|ADDRESS
CHARACTER|CITY
CHARACTER|ZIP
CHARACTER|COUNTY
CHARACTER|PHONE
CHARACTER|CANCER
INTEGER|POLYGONID
DOUBLE PRECISION|SCALE
DOUBLE PRECISION|ANGLE

# SQL: select * FROM hospitals ...
GRASS64> v.db.select hospitals | head -n 4
cat|OBJECTID|AREA|PERIMETER|HLS_|HLS_ID|NAME|ADDRESS|CITY|ZIP|COUNTY|PHONE|CANCER|POLYGONID|SCALE|ANGLE
1|1|0|0|1|1|Cherry Hospital|400 Stevens Mill Rd|Goldsboro|27533|Wayne|(919) 731-3200|yes|0|1|1
2|2|0|0|2|2|Wayne Memorial Hospital|2700 Wayne Memorial Dr|Goldsboro|27534|Wayne|(919) 736-1110|yes|0|1|1
3|3|0|0|3|3|Watauga Medical Center|336 Deerfield Rd|Boone|28607|Watauga|(828) 262-4100|yes|0|1|1


$ cat hsp.gpx
<?xml version="1.0"?>
<gpx version="1.1" creator="GDAL 1.5.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ogr="http://osgeo.org/gdal" xmlns="http:
//www.topografix.com/GPX/1/1" xsi:schemaLocation="http://www.topografix.com/GPX/1/1 http://www.topografix.com/GPX/1/1/gpx.xsd">
<wpt lat="182012.655400562332943" lon="697237.563861500239000">
  <ele>1</ele>
  <magvar>0</magvar>
  <geoidheight>0</geoidheight>
  <name>1</name>
  <cmt>1</cmt>
  <desc>Cherry Hospital</desc>
  <src>400 Stevens Mill Rd</src>
  <link href="Goldsboro"><text>27533</text><type>Wayne</type></link>
  <link href="(919) 731-3200"><text>yes</text><type>0</type></link>
  <sym>1</sym>
  <type>1</type>
  <extensions>
  </extensions>
</wpt>
<wpt lat="183568.906400562496856" lon="704563.187861500075087">
  <ele>2</ele>
  <magvar>0</magvar>
  <geoidheight>0</geoidheight>
  <name>2</name>
  <cmt>2</cmt>
  <desc>Wayne Memorial Hospital</desc>
  <src>2700 Wayne Memorial Dr</src>
  <link href="Goldsboro"><text>27534</text><type>Wayne</type></link>
  <link href="(919) 736-1110"><text>yes</text><type>0</type></link>
  <sym>1</sym>
  <type>1</type>
  <extensions>
  </extensions>
</wpt>
<wpt lat="274897.219400562578812" lon="371094.156861500116065">
  <ele>3</ele>
  <magvar>0</magvar>
  <geoidheight>0</geoidheight>
  <name>3</name>
  <cmt>3</cmt>
  <desc>Watauga Medical Center</desc>
  <src>336 Deerfield Rd</src>
  <link href="Boone"><text>28607</text><type>Watauga</type></link>
  <link href="(828) 262-4100"><text>yes</text><type>0</type></link>
  <sym>1</sym>
  <type>1</type>
  <extensions>
  </extensions>
</wpt>
...

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.

??, Hamish

[Even Rouault]

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.

[hamish]

yes, that would seem to be the case: "j" is used as Field directly, it assumes OGR fields use the same index as the grass column order:

​https://trac.osgeo.org/grass/browser/grass/trunk/vector/v.out.ogr/main.c#L705

thanks, Hamish