Opened 6 years ago

Closed 6 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 6 years ago.
grid2.gmt (786 bytes) - added by peifer 6 years ago.
Another sample GMT file

Download all attachments as: .zip

Change History (4)

Changed 6 years ago by peifer

Attachment: bb4326.gmt added

Changed 6 years ago by peifer

Attachment: grid2.gmt added

Another sample GMT file

comment:1 Changed 6 years ago by peifer

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 Changed 6 years ago by Even Rouault

Milestone: 1.9.0
Resolution: fixed
Status: newclosed

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.