Changes between Initial Version and Version 1 of Ticket #976


Ignore:
Timestamp:
Apr 2, 2007, 8:30:30 PM (17 years ago)
Author:
warmerdam
Comment:

Mateusz,

There is quite a block of code in the the Shapefile OGR driver for analysing the rings in a shapefile polygon to determine which are inner or outer rings. I think this logic is failing in the quoted situation.

I think we have lost the external url in the bugzilla to trac conversion, but you can dig it out of the bugzilla database which should still be online.

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #976

    • Property Cc warmerdam added
    • Property Owner changed from warmerdam to Mateusz Łoskot
    • Property Milestone → 1.4.2
    • Property Priority highest → high

  • Ticket #976 – Description

    initial v1  
    1 {{{
    21Wrong conversion to shapefile.
    32
     3OGR2OGR utility converts vector data into shapefile in a wrong way. Here is a description of the problem.
    44
    5 OGR2OGR utility converts vector data into shapefile in a wrong way. Here is a
    6 description of the problem.
    7 
    8 I have a shapefile, for example with a polygon and two holes (see attached
    9 pictures, holes are numbered as hole 1 and hole 2). Ordering is CW for exterior
    10 and CCW for interiors, see the shpdump for initial file:
    11 
     5I have a shapefile, for example with a polygon and two holes (see attached pictures, holes are numbered as hole 1 and hole 2). Ordering is CW for exterior and CCW for interiors, see the shpdump for initial file:
     6{{{
    127Shapefile Type: Polygon   # of Shapes: 1
    138
    … …  
    3328     (       3.000,       3.000, 0, 0) 
    3429     (       3.000,       2.000, 0, 0) 
     30}}}
    3531
    36 
    37 Now lets convert this file from SHP to SHP (Initially I got that bug after
    38 converting from TAB to SHP, but it doesn’t matter, bug is present when
    39 converting from SHP to SHP).
     32Now lets convert this file from SHP to SHP (Initially I got that bug after converting from TAB to SHP, but it doesn’t matter, bug is present when converting from SHP to SHP).
    4033
    4134After convertation shpdump gives the next result:
    42 
     35{{{
    4336Shapefile Type: Polygon   # of Shapes: 1
    4437
    … …  
    6457     (       4.000,       2.000, 0, 0) 
    6558     (       3.000,       2.000, 0, 0) 
     59}}}
     60As you see the hole 2 becomes a usual polygon because of CW coordinate sequence ordering after conversion, but in initial file it was a hole with CCW ordering!!!
    6661
    67 As you see the hole 2 becomes a usual polygon because of CW coordinate sequence
    68 ordering after conversion, but in initial file it was a hole with CCW ordering!!!
     62So, my deduction is the bug appears during OGR2OGR conversion when in initial data two holes touch each other in one polygon or multipolygon....
    6963
    70 So, my deduction is the bug appears during OGR2OGR conversion when in initial
    71 data two holes touch each other in one polygon or multipolygon....
     64This wrong behaviour is quite critical for java shapefile library for example. It considers this wrong ring as a polygon in multipolygon, not as a hole in polygon.
    7265
    73 This wrong behaviour is quite critical for java shapefile library for example.
    74 It considers this wrong ring as a polygon in multipolygon, not as a hole in polygon.
    75 
    76 
     66{{{
    7767P.S.
    7868