OGR/GMT aspatial data read does not correctly select column
|Target version:||Candidate for next bugfix release|
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!
#1 Updated by Paul over 6 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 over 6 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.
#3 Updated by Paul over 6 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.
#5 Updated by Paul almost 6 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.