Opened 13 years ago

Closed 13 years ago

#4260 closed defect (fixed)

OGR GMT layer: wrong extent identification

Reported by: peifer Owned by: warmerdam
Priority: normal Milestone: 1.9.0
Component: OGR_SF Version: svn-trunk
Severity: normal Keywords: GMT
Cc:

Description

The extent of my sample gmt file is: # @R-4/-3.9/37/37.1 However, ogrinfo reports:
Extent: (4.000000, 37.000000) - (-3.900000, 37.100000).

The first character is obviously swallowed when reading the gmt header. I changed line 183 in ogrgmtlayer.cpp which seems to help: 

 // char **papszTokens = CSLTokenizeStringComplex( osRegion.c_str() + 1,
    char **papszTokens = CSLTokenizeStringComplex( osRegion.c_str() + 0,

The sample GMT file is attached.

Attachments (2)

bb4326.gmt​ (515 bytes ) - added by peifer 13 years ago.
grid2.gmt​ (786 bytes ) - added by peifer 13 years ago.
Another sample GMT file

Download all attachments as: .zip

Change History (4)

by peifer, 13 years ago

Attachment: bb4326.gmt​ added

by peifer, 13 years ago

Attachment: grid2.gmt​ added

Another sample GMT file

comment:1 by peifer, 13 years ago

I attach another sample file (grid2.gmt) where the actual extent of # @R900000/1000000/900000/1000000 is reported to be Extent: (0.000000, 900000.000000) - (1000000.000000, 1000000.000000).

comment:2 by Even Rouault, 13 years ago

Milestone: → 1.9.0
Resolution: → fixed
Status: new → closed

Applied, thanks

r23112 /trunk/gdal/ogr/ogrsf_frmts/gmt/ogrgmtlayer.cpp: OGR GMT: fix GetExtent() result that swallowed the first char of the minx bound (#4260)

Note: See TracTickets for help on using tickets.