Opened 13 years ago

Closed 13 years ago

#3802 closed defect (fixed)

ogr does NOT correctly read multilinestring & multipolygon features from GMT format files

Reported by: pcreso Owned by: warmerdam
Priority: normal Milestone: 1.7.3
Component: OGR_SF Version: 1.7.2
Severity: normal Keywords: multi GMT ogr


I'm working with some Postgis data to map with GMT and was using ogr2ogr to generate GMT format data from the Postgis data source.

This works fine, but when I tried to generate shapefiles from the GMT files written by ogr2ogr, I found that ogr2ogr was unable to correctly read data when the features were multilinestrings or multipolygons in GMT files it had written.

Essentially it does not correctly identify the constituent geometries comprising the multi-geometry feature.

A simple multiline file written by ogr2ogr is attached, as is output from ogrinfo illustrating the problem.

The feature type is identified as @GMULTILINESTRING.

In the GMT file each constituent geoemetry is separated by a line starting with ">" (so there is no explicit difference between individual features & multi features)

The attribute data is stored in the # @D record.

With a multi datasource, ogr writes each geometry to a GMT file as if they are separate features, which is fine, as only the first such feature in a multi has a # @D record, as these attributes are inherited by all members of the multi. So the the presence of a # @D record implies the first component of a new multi feature.

However, when reading the file, ogr fails to interpret this and therefore does not recognise the multi geometries.

I'm using version 1.7.2 of GDAL, which I can't enter in the version field in this form.

Attachments (2)

test_multi.gmt (807 bytes ) - added by pcreso 13 years ago.
ogrinfo.txt (1.7 KB ) - added by pcreso 13 years ago.

Download all attachments as: .zip

Change History (11)

by pcreso, 13 years ago

Attachment: test_multi.gmt added

by pcreso, 13 years ago

Attachment: ogrinfo.txt added

comment:1 by warmerdam, 13 years ago

Status: newassigned
Version: unspecified1.7.2

comment:2 by pcreso, 13 years ago

Thanks Frank,

GMT 5.0 is nearing release, & will be the first version to fully make use of the format used by OGR, hence the extra testing right now.


comment:3 by warmerdam, 13 years ago

I have added support for reading multilinestring geometries (r20982).

While adding a test for this (not yet committed) I have come to the conclusion that writing and reading of multipolygons is also likely broken. So I'm leaving this ticket open till I resolve that - but tonight is not the time to do so.

comment:4 by warmerdam, 13 years ago

I have restructured the feature reader substantially to handle multipolygons (r20987). I've also added some limited testing of the same (r20986).

I'm nervous about the multipolygon handling especially, and a bit dubious about the multilinestring. How are we supposed to know when we have finished one feature and started the next in these situations? The drv_gmt.html document does not reference the format specification we prepared - is there something I can point to?

More testing of the driver would be a good idea if you have some time.

I'm interested in backporting the changes to 1.7, but perhaps not till you and I are more comfortable with them.

comment:5 by pcreso, 13 years ago

The document will be an appendix of the forthcoming GMT v5 documentation, so will be able to be referenced when that is released.

I agree there are issues with multi-features, which are not supported explicitly by GMT. I'm not averse to disabling those altogether if it gets too hard twisting things to fit.

As I see it:

If a feature type is specified as a multiline or polygon in the file header (# @G record) then every feature start line (> record) is checked for a attribute data (# @D) record. If present, then it is the start of a new multi feature, if absent then it is a new line or polygon within the current multi, so inherits the attribute data from the last # @D record.

comment:6 by warmerdam, 13 years ago


OK, I think my approach is compatible with the approach you describe.

comment:7 by pcreso, 13 years ago

Thanks Frank,

I guess I now need to work out how to access & build your newly fixed version for testing.

Sorry to be a pain, but can you toss me a pointer as to how to do this? (I'm using something like "apt-get install gdal" these days, as I'm more interested in using it than building it, but I think an exception is called for in this case :-)



comment:8 by warmerdam, 13 years ago

Milestone: 1.7.3

Fixes backported to 1.7 tree (r21081).

comment:9 by Even Rouault, 13 years ago

Resolution: fixed
Status: assignedclosed
Note: See TracTickets for help on using tickets.