Opened 14 years ago

Closed 14 years ago

#3363 closed defect (fixed)

[PATCH - Shapelib] Shapefile driver can write wrong winding order for some polygons with small area but big coordinates

Reported by: Even Rouault Owned by: warmerdam
Priority: normal Milestone: 1.7.1
Component: OGR_SF Version: unspecified
Severity: normal Keywords: shapelib
Cc:

Description

Frank, this is an issue strictly identical to #3356, but in shpopen.c. The code to detect the winding order used a variant of Green Formula which would return 0 for polygons with small area but big coordinates.

The issue can be seen when enabling the new ogr_shape_34 test I've commited in r18675.

Attached a fix that uses a more stable variant of Green Formula. Another possibility would have been to adapt the new implementation of OGRLinearRing::isClockWise() (which turns to be the old used in the read part of the shapefile driver of older GDAL), but this requires more coding.

Attachments (1)

ticket_3363.patch (1.3 KB ) - added by Even Rouault 14 years ago.

Download all attachments as: .zip

Change History (5)

by Even Rouault, 14 years ago

Attachment: ticket_3363.patch added

comment:1 by warmerdam, 14 years ago

Component: defaultOGR_SF
Milestone: 1.7.1
Status: newassigned

Patch applied in shapelib.

comment:2 by warmerdam, 14 years ago

shpopen.c pulled into trunk (r18678), and 1.7 branch (r18679). ogr_shape_34 enabled in trunk autotest (r18677).

comment:3 by Even Rouault, 14 years ago

Frank, when looking at r18678 and r18679, I see some reverts. So I guess that means that Chaitanya's changes done in r18413 for #3236 have not yet been pushed into shapelib upstream (some int* array converted to unsigned int*).

comment:4 by warmerdam, 14 years ago

Resolution: fixed
Status: assignedclosed

Even, you are quite right, I dropped the ball on upstreaming. I have done this now and repulled from upstream (r18680, r18681).

Note: See TracTickets for help on using tickets.