Bug #539

OGR/GMT aspatial data read does not correctly select column

Added by Jed about 3 years ago. Updated over 2 years ago.

Status:ClosedStart date:2014-04-15
Priority:NormalDue date:
Assignee:Paul% Done:

0%

Category:-
Target version:Candidate for next bugfix release
Affected version:5.x-svn Platform:

Description

I am attempting to use GMT5's (5.x-svn) ability to read and use aspatial data from the headers in an OGR/GMT vector file to set the fill colors of polygons. When using the OGR/GMT vector file below, gmt does not parse the -a option correctly; it appears that psxy always uses the values in the first aspatial data column regardless of the column name label I specify using the -acol=name syntax. In the case of my example below, that means that the value read by psxy is "5" - this is the first number after the "# @D" flag - regardless of the column name I specify. I have also tried specifying a column position number, as some older GMT programs did, but this did not change the incorrect behavior of the program.

Here is an extract from my plotting script:

psxy $infile -R -J -W0.5p,0 -B0 -A -fg -aG=gmtrgb -L -O -P -K >> tmp.ps

The column is also not read correctly if I use a CPT file and try to set the Z values as in this example:

psxy $infile -R -J -W0.5p,0 -B0 -A -fg -aZ=major_group -Cmajor_group_colors.cpt -L -O -P -K >> tmp.ps

And here are the first few lines of my OGR/GMT polygon file:

# @VGMT1.0 @GPOLYGON
# @R-180.000002508/185.593483405/-53.6649710199/82.1554661247             
# @Jp"+proj=longlat +datum=WGS84 +no_defs " 
# @Jw"GEOGCS[\"wgs84\",DATUM[\"WGS_1984\",SPHEROID[\"WGS_1984\",6378137,298.257223563]],PRIMEM[\"Greenwich\",0],UNIT[\"degree\",0.0174532925199433]]" 
# @Ncat|minor_group|major_group|name|grassrgb|gmtrgb|major_group_name
# @Tinteger|integer|integer|string|string|string|string
# FEATURE_DATA
>
# @D5|43|5|Egypt|110:186:103|110/186/103|"Urbanized societies / kingdoms" 
# @P
22.352701791714399 34.8933607512989 0
24.216735747524599 34.788404360311198 0
26.080774240660201 34.683447388937203 0
27.4237110379527 34.359237459559502 0
...

Thank you in advance for your help!

Jed

Associated revisions

Revision 13335
Added by Paul almost 3 years ago

Add test that will help us address issue #539

History

#1 Updated by Paul about 3 years ago

  • Status changed from New to In Progress
  • Assignee set to Paul
  • Target version set to Candidate for next bugfix release

Hi Jed, thanks for posting. I can confirm things go wrong here. Somewhat unrelated, why is there a 3rd column in the spatial section? I've heard there are those rare 3-D shape files; is this the case?
As for the problem, what happens is that when the multiple segment record is encountered (>) we try to parse it for any -G -Z settings but that is before the next record with those values (in the comment) are processed. So I understand the issue and what the solution will be; just need time to implement it.

#2 Updated by Jed about 3 years ago

Thanks for looking into this Paul.

The vector file I am plotting is a direct export from GRASS to GMT format using v.out.ogr; I believe that the OGR exporter adds that 3rd column of data after the vector lon-lat coordinates. The original GRASS vector is definitely 2D, so in my case, the 3rd column can be safely ignored.

Would a quick workaround for my problem be to simply delete all of the multiple segment flags (>)? I'm not at my computer this week so have not had a chance to test, but will try this next week.

Thanks again.

#3 Updated by Paul about 3 years ago

No, you need those > records to separate the polygons.
The technical issue is that (for non-OGR data) psxy tries to parse that record for the color changes, e.g.

-Gyellow -W5p or -Z45 etc

but in the case of OGR it should delay that until the comment line immediately following has been processed. So no simple workaround, unfortunately.

#4 Updated by Paul almost 3 years ago

No real progress yet (no time), but I have turned your example into a new GMT test (test/ogr/lookup.sh) so that we are constantly reminded this issue remains unresolved.

#5 Updated by Paul over 2 years ago

  • Status changed from In Progress to Resolved

I finally had some time to look into this and fixed a few problems in how these assignments were made. My test, based on your example above, now passes. Please give it a go and let me know if you can. Updated in r13926.

#6 Updated by Jed over 2 years ago

I can confirm that this feature works as expected now.

Thanks Paul!

#7 Updated by Paul over 2 years ago

  • Status changed from Resolved to Closed

Closing this issue as fixed.

Also available in: Atom PDF