Hi Loren, Some work has been done in OpenJUMP on Polygon handling following your bug report (2009-05). Just wonder if you had test it and checked it solved your problem in order to close the ticket (https://sourceforge.net/tracker/?func=detail&aid=2788633&group_id=118054&atid=679906).
Thanks for help, Michaël Le 10/05/2009 12:47, Michaël Michaud a écrit : > > Hi Loren, > > In fact, the polygon that was build by OJ 1.3 was a strange beast > including an "outer hole". > Hope I fixed it. > I'm not sure that you can test the new code now as the nightly build > is broken. > If you need it and cannot build it from svn, let me know, we'll find a > way. > > Michael > > > Michaël Michaud a écrit : >> >> Hi, >> >> The last change made on the way OJ reads shapefile is from may 2008 >> http://jump-pilot.svn.sourceforge.net/viewvc/jump-pilot/core/trunk/src/org/geotools/shapefile/PolygonHandler.java?r1=859&r2=1394 >> >> >> It's a piece of code from Larry I committed in an attempt to solve a >> particular problem with abnormal shapefiles having outer-rings >> described as holes (ccw) >> It is not the case of Laren's polygon, but in the code, there is an >> approximative test to check if a polygon could be a hole. It tests if >> two first points in a ring are inside or on the boudary of another >> ring (which is the case of Laren's polygon) >> I think, but cannot prove, this is the origin of the problem. >> It will need a bit more work to test and fix the problem. I did not >> yet understood how the single polygon with a hole was created. >> >> Michaël >> >> >> Stefan Steiniger a écrit : >>> >>> note to other developers: >>> >>> I got the shape file from Loren for testing. >>> >>> stefan >>> >>> Stefan Steiniger wrote: >>>> >>>> ah ok.. that bring as closer to the problem. >>>> Now the question is, what is it in the original file. Can you find >>>> that out (with a different software than OJUMP)? or would you be >>>> willing to send the original shp file (you could delete all other >>>> objects if you don't use OJ since it would change the type when >>>> writing back to the file)? >>>> >>>> thanks for pointing out that difference (I hope somebody else has a >>>> clue what might go on) >>>> >>>> stefan >>>> >>>> Loren wrote: >>>>> yes, I think it is in the reading process. These polygons are read >>>>> from the same shapefile. JUMP version 1.2 reads it in as a >>>>> multipolygon(valid) and version 1.3 reads it in as a polygon(invalid) >>>>> >>>>> On May 7, 4:19 pm, Stefan Steiniger <sst...@geo.uzh.ch> wrote: >>>>>> Hei Loren, >>>>>> >>>>>> not sure if I understand, but could it be that the problem is >>>>>> related to >>>>>> reading the data? >>>>>> Because if it is a MultiPolygon, things are completely different (no >>>>>> holes, but touching single polygon). While for a Polygon having >>>>>> holes >>>>>> this may not be allowed. >>>>>> So, if you load the polygon is it once read as polygon and once >>>>>> read as >>>>>> multipolygon? If yes - which Jump version does what? and In what >>>>>> file >>>>>> format is the polygon/multipolygon stored? >>>>>> However, maybe I misunderstood you and you asked us to check OJ >>>>>> 1.3 for >>>>>> conformance with the OGC simple feature specification. >>>>>> >>>>>> stefan >>>>>> >>>>>> Loren wrote: >>>>>>> Here is the valid WKT from jump 1.2. (these were both read from >>>>>>> the >>>>>>> same shapefile) -> >>>>>>> MULTIPOLYGON ((( >>>>>>> -117.30644 40.68306, >>>>>>> -117.31865 40.68356, >>>>>>> -117.3094 40.68347, >>>>>>> -117.30866 40.68341, >>>>>>> -117.30729 40.68318, >>>>>>> -117.30644 40.68306 >>>>>>> )), (( >>>>>>> -117.31865 40.68356, >>>>>>> -117.31806 40.68333, >>>>>>> -117.31701 40.68317, >>>>>>> -117.31125 40.68321, >>>>>>> -117.31093 40.68318, >>>>>>> -117.30977 40.68303, >>>>>>> -117.30644 40.68306, >>>>>>> -117.30631 40.68306, >>>>>>> -117.30602 40.68302, >>>>>>> -117.30109 40.68238, >>>>>>> -117.30024 40.67772, >>>>>>> -117.29997 40.67645, >>>>>>> -117.29993 40.6758, >>>>>>> -117.29991 40.67201, >>>>>>> -117.29996 40.67056, >>>>>>> -117.29998 40.66568, >>>>>>> -117.29999 40.67355, >>>>>>> -117.30026 40.67343, >>>>>>> -117.30336 40.67203, >>>>>>> -117.30681 40.67061, >>>>>>> -117.3078 40.67009, >>>>>>> -117.3081 40.66994, >>>>>>> -117.31047 40.66912, >>>>>>> -117.31293 40.66809, >>>>>>> -117.31408 40.66864, >>>>>>> -117.31498 40.66921, >>>>>>> -117.31753 40.67044, >>>>>>> -117.31937 40.67106, >>>>>>> -117.3233 40.67273, >>>>>>> -117.32583 40.67365, >>>>>>> -117.32772 40.67463, >>>>>>> -117.32943 40.6753, >>>>>>> -117.3316 40.67642, >>>>>>> -117.33397 40.67671, >>>>>>> -117.33512 40.67715, >>>>>>> -117.33605 40.67726, >>>>>>> -117.33896 40.67717, >>>>>>> -117.34035 40.67742, >>>>>>> -117.34236 40.67728, >>>>>>> -117.34425 40.67735, >>>>>>> -117.34443 40.67856, >>>>>>> -117.34458 40.67959, >>>>>>> -117.34476 40.67987, >>>>>>> -117.34474 40.68248, >>>>>>> -117.3446 40.68269, >>>>>>> -117.34414 40.68341, >>>>>>> -117.34414 40.68355, >>>>>>> -117.34065 40.68358, >>>>>>> -117.34045 40.68357, >>>>>>> -117.33942 40.68319, >>>>>>> -117.33882 40.68324, >>>>>>> -117.33813 40.68358, >>>>>>> -117.33706 40.68359, >>>>>>> -117.33114 40.68357, >>>>>>> -117.31924 40.68357, >>>>>>> -117.31873 40.68356, >>>>>>> -117.31865 40.68356 >>>>>>> ))) >>>>>>> On May 7, 3:16 pm, Loren <loren.sla...@gmail.com> wrote: >>>>>>>> Hi, >>>>>>>> I frequently use JUMP to do QA using the validation tool and have >>>>>>>> recently noticed some features being flagged as self-intersections >>>>>>>> using the jump ver. 1.3. The same features are not being flagged >>>>>>>> using the previous 1.2F version. >>>>>>>> The issue affects polygons of the following type: a multi-polygon >>>>>>>> where two exterior rings share two points. >>>>>>>> in jump 1.2 the feature is displayed as a multi-polygon and the >>>>>>>> validation tool agrees that it is properly formed. I believe >>>>>>>> this is >>>>>>>> appropriate according to OGC specs. >>>>>>>> in jump 1.3 the feature is being shown as a polygon with an >>>>>>>> interior >>>>>>>> ring that touches at the same two points. The validation tool >>>>>>>> flags >>>>>>>> this as a self-intersect. >>>>>>>> So, version 1.2 is OK with handling the multi-polygon, where >>>>>>>> 1.3 is >>>>>>>> calling it a self-intersecting polygon. >>>>>>>> Let me know if you have any insights as to why this may be. >>>>>>>> Here's the WKT so you can see what I mean. >>>>>>>> POLYGON ((-117.31865 40.68356, -117.31806 40.68333, -117.31701 >>>>>>>> 40.68317, -117.31125 40.68321, -117.31093 40.68318, -117.30977 >>>>>>>> 40.68303, -117.30644 40.68306, -117.30631 40.68306, -117.30602 >>>>>>>> 40.68302, -117.30109 40.68238, -117.30024 40.67772, -117.29997 >>>>>>>> 40.67645, -117.29993 40.6758, -117.29991 40.67201, -117.29996 >>>>>>>> 40.67056, -117.29998 40.66568, -117.29999 40.67355, -117.30026 >>>>>>>> 40.67343, -117.30336 40.67203, -117.30681 40.67061, -117.3078 >>>>>>>> 40.67009, -117.3081 40.66994, -117.31047 40.66912, -117.31293 >>>>>>>> 40.66809, -117.31408 40.66864, -117.31498 40.66921, -117.31753 >>>>>>>> 40.67044, -117.31937 40.67106, -117.3233 40.67273, -117.32583 >>>>>>>> 40.67365, -117.32772 40.67463, -117.32943 40.6753, -117.3316 >>>>>>>> 40.67642, >>>>>>>> -117.33397 40.67671, -117.33512 40.67715, -117.33605 40.67726, >>>>>>>> -117.33896 40.67717, -117.34035 40.67742, -117.34236 40.67728, >>>>>>>> -117.34425 40.67735, -117.34443 40.67856, -117.34458 40.67959, >>>>>>>> -117.34476 40.67987, -117.34474 40.68248, -117.3446 40.68269, >>>>>>>> -117.34414 40.68341, -117.34414 40.68355, -117.34065 40.68358, >>>>>>>> -117.34045 40.68357, -117.33942 40.68319, -117.33882 40.68324, >>>>>>>> -117.33813 40.68358, -117.33706 40.68359, -117.33114 40.68357, >>>>>>>> -117.31924 40.68357, -117.31873 40.68356, -117.31865 40.68356), >>>>>>>> (-117.30644 40.68306, -117.30729 40.68318, -117.30866 40.68341, >>>>>>>> -117.3094 40.68347, -117.31865 40.68356, -117.30644 40.68306)) >>>>>>>> -Loren Slater >>>>> >>>>> >>>> >>>> >>> >>> >> >> >> > > > ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
