Bug #1089

gmtselect considers no region interior of a polygon with meridional sides only

Added by Peter 21 days ago. Updated 19 days ago.

Status:In ProgressStart date:2017-05-01
Priority:NormalDue date:
Assignee:Paul% Done:


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


Tested on gmtselect(core) 5.4.0_r17525M [64-bit]

It seems that gmtselect fails to detect the interior region of a polygon defined by two meridians, attached is a polygon with sides along meridian 30 and 180. Running the commands

$~> echo "0 31" | gmtselect -: -Fmeridian_30_180.poly -fg -If
0 31
$~> echo "0 29" | gmtselect -: -Fmeridian_30_180.poly -fg -If
0 29

demonstrates that gmtselect considers either side on the 30'th meridian as the exterior of the polygon

meridian_30_180.poly (14.4 KB) Peter, 2017-05-01 23:40

meridian_-1_1.poly (13.7 KB) Peter, 2017-05-02 22:37

meridian_1_-1.poly (13.3 KB) Peter, 2017-05-02 22:41

Associated revisions

Revision 18111
Added by Paul 20 days ago

Address issue #1089


#1 Updated by Paul 20 days ago

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

Think this is fixed in r18111 but I will do some more tests later.

#2 Updated by Peter 20 days ago

Sorry, forgot to update to latest svn version before testing/reporting.

Just did so now at gmtselect(core) 5.4.0_r18111M [64-bit] with the result

$~>echo "0 31" | gmtselect -: -Fmeridian_30_180.poly -fg -If
0 31
$~> echo "0 29" | gmtselect -: -Fmeridian_30_180.poly -fg -If
$~> echo "0 29" | gmtselect -: -Fmeridian_30_180.poly -fg
0 29

So gmtselect now do consider one of the regions to be inside.

However, the region considered inside is the larger of the two rather than the smaller one. Initially I suspected it selected the region containing the 0'th meridian but this does not seem to be the case as confirmed using a polygon defined by meridian -1 and 1. Attached files contains one clockwise and one anticlockwise version of this polygon (just to test that the orientation does not matter as this was discussed in an earlier related thread)

$~> echo "0 0" | gmtselect -: -Fmeridian_1_-1.poly -fg 
$~> echo "0 0" | gmtselect -: -Fmeridian_-1_1.poly -fg
$~> echo "0 0" | gmtselect -: -Fmeridian_1_-1.poly -fg -If
0 0
$~> echo "0 0" | gmtselect -: -Fmeridian_-1_1.poly -fg -If
0 0

#3 Updated by Paul 19 days ago

I will see what can be done. However, these polygons are a bit unusual since a single -R check is way faster and more accurate for selecting data in such wedges. If these are actual polygons needed for real work then I suggest you simply use the -R option.

#4 Updated by Peter 19 days ago

Yes, the polygons are unusual and no, they are not needed for real work at present. They were specifically designed to figure out how gmtselect works under different conditions as I was asked to set up some test cases in the original thread related to this in the forum.

I have to say though that I still fail to see the answer to my original question, that is how gmt decides which region is inside and which is outside to a polygon on a spherical surface. Apparently the answer is not as simple as the polygon with smallest area, as illuminated by the polygons above.

#5 Updated by Paul 19 days ago

No, it isn't that simple. The area is not even computed. The search clearly has limitations at the present time and your tests are pointing those out. I am interested in getting it to work for cases such as very large polygons that may be more than half the sphere. It is a matter of resources.

Also available in: Atom PDF