Ticket #3363 (closed defect: fixed)

Opened 3 years ago

Last modified 3 years ago

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

Reported by: 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

ticket_3363.patch Download (1.3 KB) - added by rouault 3 years ago.

Change History

Changed 3 years ago by rouault

Changed 3 years ago by warmerdam

  • status changed from new to assigned
  • component changed from default to OGR_SF
  • milestone set to 1.7.1

Patch applied in shapelib.

Changed 3 years ago by warmerdam

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

Changed 3 years ago by rouault

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*).

Changed 3 years ago by warmerdam

  • status changed from assigned to closed
  • resolution set to fixed

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.