Re: [JPP-Devel] Shapefile with overlapping shells
Hi Stefan, Indeed, I have committed the change about one week ago. I think I'll do also the second change proposed by jukko before the end of the week as no one has reacted. Thanks for all the improvements you have done the few last months. Thanks also to Uwe for its new tutorial (is there any plan for an english translation ?) Michaël Stefan Steiniger a écrit : huhu? question again: Are you commiting it Larry? or Michael? As you both have done the work.. Otherwise people that check the sourceforge statistics think I do all the stuff. However, I can do it if you are too busy :) Stefan Stefan Steiniger schrieb: great! thank you Larry and Michael. @Michael: would you do the commit? stefan Larry Becker wrote: Hi Michaël, Thanks for the testing. It sounds like this code change is ready to be committed. Also, thanks to your instructions, I was able to construct island multipolygons and test reading them as shapefiles. They appear to work, even inside CW holes. If any Geotools or uDig people are watching this thread, you might want to consider some changes to your shapefile reader. Not only will it not read polygons with clockwise holes, but it defaults everything to multipolygons, even in files with single shells. regards, Larry Becker On Sat, May 3, 2008 at 3:59 PM, Michael Michaud [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi, Larry, I did some tests today with your new PolygonHandler. I had no file known for the specific problem the new class is supposed to solve, but I tried to load several files with more or less valid geometries. Most shapefiles have been read exactly the same way with the old code and with the new code. The only one with a different result was a big shapefile with many kind of valid and invalid polygons (37128 polygons) old code : 37128 objects imported, including 22 empty GeometryCollections (shapes that the parser could not read) new code : 37128 objects imported, including 20 empty GeometryCollections (shapes that the parser could not read) I cannot say much about the two polygons new new parser could read except that one is self intersecting (the other is just simple!). Indeed, the imported polygon have probably been repaired by the importer, because if I export them again into shapefile, then I can read them with the old PolygonHandler. I cannot do much more at home, I'll try to import this shapefile with arcgis to try to go a step further. Anyway, the new PolygonHandler can read a little more than the old one, and that's what it it supposed to do ;-) (I'm just curious about the 20 objects it still could not read) I did not benchmark the tests, but I did not notice slowdown. Michaël Larry Becker a écrit : Hi Michaël, I found another problem with the PolygonHandler routines I copied from geotools. It causes MultiPolygons to be created by default instead of simple Polygons. I restored the original code and inserted the modifications for clockwise holes. Now it is a much less radical change. Note that I haven't committed any changes to OpenJump yet, only SkyJUMP. regards, Larry On Sun, Apr 20, 2008 at 2:12 PM, Larry Becker [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi Michaël, I've attached OJ's updated PolygonHandler for your review. It is a fairly radical change so exhaustive testing of shapefile loading is recommended. regards, Larry On Fri, Apr 18, 2008 at 3:43 PM, Michaël Michaud [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi, Larry I'm glad if I could help, thanks again for the hard work. It seems that you found a way to keep both correctness and performance. If you think you can commit, I am very confident. I'll be able to do more tests with complex polygons (but not with CW holes). Note : you can create a MultiPolygon with an island by selecting the two polygons, then right click and run Combine Selected Features. Regards, Michaël - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2.
Re: [JPP-Devel] Shapefile with overlapping shells
Salut Michael Indeed, I have committed the change about one week ago. mhm.. I have not seen them at the svn-mail list but you are right! I can see it in the SVN History (5.May). Sorry... looks like I need to check the mail list settings? I think I'll do also the second change proposed by jukko before the end of the week as no one has reacted. Ok.. I actually commited the changes except for Uwe's PostGIS plugin. I wrote him today an email, as I needed somebody to check a build of this Plugin that I have done with Ant (Eric switched to Maven) and I don't have PostGIS installed. So if Uwe replys positively I/You can add the last patch. Thanks for all the improvements you have done the few last months. Thanks also to Uwe for its new tutorial (is there any plan for an english translation ?) very good question... The plan exists. But it is rather a question of time. I thought I would start with the PostGIS chapter first. And then later ... However, You know as me how much effort (and good will) it takes ;) thank you too Stefan Michaël Stefan Steiniger a écrit : huhu? question again: Are you commiting it Larry? or Michael? As you both have done the work.. Otherwise people that check the sourceforge statistics think I do all the stuff. However, I can do it if you are too busy :) Stefan Stefan Steiniger schrieb: great! thank you Larry and Michael. @Michael: would you do the commit? stefan Larry Becker wrote: Hi Michaël, Thanks for the testing. It sounds like this code change is ready to be committed. Also, thanks to your instructions, I was able to construct island multipolygons and test reading them as shapefiles. They appear to work, even inside CW holes. If any Geotools or uDig people are watching this thread, you might want to consider some changes to your shapefile reader. Not only will it not read polygons with clockwise holes, but it defaults everything to multipolygons, even in files with single shells. regards, Larry Becker On Sat, May 3, 2008 at 3:59 PM, Michael Michaud [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi, Larry, I did some tests today with your new PolygonHandler. I had no file known for the specific problem the new class is supposed to solve, but I tried to load several files with more or less valid geometries. Most shapefiles have been read exactly the same way with the old code and with the new code. The only one with a different result was a big shapefile with many kind of valid and invalid polygons (37128 polygons) old code : 37128 objects imported, including 22 empty GeometryCollections (shapes that the parser could not read) new code : 37128 objects imported, including 20 empty GeometryCollections (shapes that the parser could not read) I cannot say much about the two polygons new new parser could read except that one is self intersecting (the other is just simple!). Indeed, the imported polygon have probably been repaired by the importer, because if I export them again into shapefile, then I can read them with the old PolygonHandler. I cannot do much more at home, I'll try to import this shapefile with arcgis to try to go a step further. Anyway, the new PolygonHandler can read a little more than the old one, and that's what it it supposed to do ;-) (I'm just curious about the 20 objects it still could not read) I did not benchmark the tests, but I did not notice slowdown. Michaël Larry Becker a écrit : Hi Michaël, I found another problem with the PolygonHandler routines I copied from geotools. It causes MultiPolygons to be created by default instead of simple Polygons. I restored the original code and inserted the modifications for clockwise holes. Now it is a much less radical change. Note that I haven't committed any changes to OpenJump yet, only SkyJUMP. regards, Larry On Sun, Apr 20, 2008 at 2:12 PM, Larry Becker [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi Michaël, I've attached OJ's updated PolygonHandler for your review. It is a fairly radical change so exhaustive testing of shapefile loading is recommended. regards, Larry On Fri, Apr 18, 2008 at 3:43 PM, Michaël Michaud [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi, Larry I'm glad if I could help, thanks again for the hard work. It seems that you found a way to keep both correctness and performance. If you think you can
Re: [JPP-Devel] Shapefile with overlapping shells
huhu? question again: Are you commiting it Larry? or Michael? As you both have done the work.. Otherwise people that check the sourceforge statistics think I do all the stuff. However, I can do it if you are too busy :) Stefan Stefan Steiniger schrieb: great! thank you Larry and Michael. @Michael: would you do the commit? stefan Larry Becker wrote: Hi Michaël, Thanks for the testing. It sounds like this code change is ready to be committed. Also, thanks to your instructions, I was able to construct island multipolygons and test reading them as shapefiles. They appear to work, even inside CW holes. If any Geotools or uDig people are watching this thread, you might want to consider some changes to your shapefile reader. Not only will it not read polygons with clockwise holes, but it defaults everything to multipolygons, even in files with single shells. regards, Larry Becker On Sat, May 3, 2008 at 3:59 PM, Michael Michaud [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi, Larry, I did some tests today with your new PolygonHandler. I had no file known for the specific problem the new class is supposed to solve, but I tried to load several files with more or less valid geometries. Most shapefiles have been read exactly the same way with the old code and with the new code. The only one with a different result was a big shapefile with many kind of valid and invalid polygons (37128 polygons) old code : 37128 objects imported, including 22 empty GeometryCollections (shapes that the parser could not read) new code : 37128 objects imported, including 20 empty GeometryCollections (shapes that the parser could not read) I cannot say much about the two polygons new new parser could read except that one is self intersecting (the other is just simple!). Indeed, the imported polygon have probably been repaired by the importer, because if I export them again into shapefile, then I can read them with the old PolygonHandler. I cannot do much more at home, I'll try to import this shapefile with arcgis to try to go a step further. Anyway, the new PolygonHandler can read a little more than the old one, and that's what it it supposed to do ;-) (I'm just curious about the 20 objects it still could not read) I did not benchmark the tests, but I did not notice slowdown. Michaël Larry Becker a écrit : Hi Michaël, I found another problem with the PolygonHandler routines I copied from geotools. It causes MultiPolygons to be created by default instead of simple Polygons. I restored the original code and inserted the modifications for clockwise holes. Now it is a much less radical change. Note that I haven't committed any changes to OpenJump yet, only SkyJUMP. regards, Larry On Sun, Apr 20, 2008 at 2:12 PM, Larry Becker [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi Michaël, I've attached OJ's updated PolygonHandler for your review. It is a fairly radical change so exhaustive testing of shapefile loading is recommended. regards, Larry On Fri, Apr 18, 2008 at 3:43 PM, Michaël Michaud [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi, Larry I'm glad if I could help, thanks again for the hard work. It seems that you found a way to keep both correctness and performance. If you think you can commit, I am very confident. I'll be able to do more tests with complex polygons (but not with CW holes). Note : you can create a MultiPolygon with an island by selecting the two polygons, then right click and run Combine Selected Features. Regards, Michaël - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net mailto:Jump-pilot-devel@lists.sourceforge.net mailto:Jump-pilot-devel@lists.sourceforge.net
Re: [JPP-Devel] Shapefile with overlapping shells
great! thank you Larry and Michael. @Michael: would you do the commit? stefan Larry Becker wrote: Hi Michaël, Thanks for the testing. It sounds like this code change is ready to be committed. Also, thanks to your instructions, I was able to construct island multipolygons and test reading them as shapefiles. They appear to work, even inside CW holes. If any Geotools or uDig people are watching this thread, you might want to consider some changes to your shapefile reader. Not only will it not read polygons with clockwise holes, but it defaults everything to multipolygons, even in files with single shells. regards, Larry Becker On Sat, May 3, 2008 at 3:59 PM, Michael Michaud [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi, Larry, I did some tests today with your new PolygonHandler. I had no file known for the specific problem the new class is supposed to solve, but I tried to load several files with more or less valid geometries. Most shapefiles have been read exactly the same way with the old code and with the new code. The only one with a different result was a big shapefile with many kind of valid and invalid polygons (37128 polygons) old code : 37128 objects imported, including 22 empty GeometryCollections (shapes that the parser could not read) new code : 37128 objects imported, including 20 empty GeometryCollections (shapes that the parser could not read) I cannot say much about the two polygons new new parser could read except that one is self intersecting (the other is just simple!). Indeed, the imported polygon have probably been repaired by the importer, because if I export them again into shapefile, then I can read them with the old PolygonHandler. I cannot do much more at home, I'll try to import this shapefile with arcgis to try to go a step further. Anyway, the new PolygonHandler can read a little more than the old one, and that's what it it supposed to do ;-) (I'm just curious about the 20 objects it still could not read) I did not benchmark the tests, but I did not notice slowdown. Michaël Larry Becker a écrit : Hi Michaël, I found another problem with the PolygonHandler routines I copied from geotools. It causes MultiPolygons to be created by default instead of simple Polygons. I restored the original code and inserted the modifications for clockwise holes. Now it is a much less radical change. Note that I haven't committed any changes to OpenJump yet, only SkyJUMP. regards, Larry On Sun, Apr 20, 2008 at 2:12 PM, Larry Becker [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi Michaël, I've attached OJ's updated PolygonHandler for your review. It is a fairly radical change so exhaustive testing of shapefile loading is recommended. regards, Larry On Fri, Apr 18, 2008 at 3:43 PM, Michaël Michaud [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi, Larry I'm glad if I could help, thanks again for the hard work. It seems that you found a way to keep both correctness and performance. If you think you can commit, I am very confident. I'll be able to do more tests with complex polygons (but not with CW holes). Note : you can create a MultiPolygon with an island by selecting the two polygons, then right click and run Combine Selected Features. Regards, Michaël - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net mailto:Jump-pilot-devel@lists.sourceforge.net mailto:Jump-pilot-devel@lists.sourceforge.net mailto:Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- http://amusingprogrammer.blogspot.com/ --
Re: [JPP-Devel] Shapefile with overlapping shells
Hi Michaël, I found another problem with the PolygonHandler routines I copied from geotools. It causes MultiPolygons to be created by default instead of simple Polygons. I restored the original code and inserted the modifications for clockwise holes. Now it is a much less radical change. Note that I haven't committed any changes to OpenJump yet, only SkyJUMP. regards, Larry On Sun, Apr 20, 2008 at 2:12 PM, Larry Becker [EMAIL PROTECTED] wrote: Hi Michaël, I've attached OJ's updated PolygonHandler for your review. It is a fairly radical change so exhaustive testing of shapefile loading is recommended. regards, Larry On Fri, Apr 18, 2008 at 3:43 PM, Michaël Michaud [EMAIL PROTECTED] wrote: Hi, Larry I'm glad if I could help, thanks again for the hard work. It seems that you found a way to keep both correctness and performance. If you think you can commit, I am very confident. I'll be able to do more tests with complex polygons (but not with CW holes). Note : you can create a MultiPolygon with an island by selecting the two polygons, then right click and run Combine Selected Features. Regards, Michaël - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- http://amusingprogrammer.blogspot.com/ -- http://amusingprogrammer.blogspot.com/ PolygonHandler.java Description: Binary data - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] Shapefile with overlapping shells
Hi Michaël, I've attached OJ's updated PolygonHandler for your review. It is a fairly radical change so exhaustive testing of shapefile loading is recommended. regards, Larry On Fri, Apr 18, 2008 at 3:43 PM, Michaël Michaud [EMAIL PROTECTED] wrote: Hi, Larry I'm glad if I could help, thanks again for the hard work. It seems that you found a way to keep both correctness and performance. If you think you can commit, I am very confident. I'll be able to do more tests with complex polygons (but not with CW holes). Note : you can create a MultiPolygon with an island by selecting the two polygons, then right click and run Combine Selected Features. Regards, Michaël - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- http://amusingprogrammer.blogspot.com/ PolygonHandler.java Description: Binary data - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] Shapefile with overlapping shells
Hi Larry, Thanks for clarification (my english is not so good, and I often need a detailed explanation to grasp the problem) I think your approach is the good one as the problem we want to solve is much more specific than the one I tried to solve in my GeoConcept parser. Try to sum up different hypothesis which are done about the shapefile input and the way to handle them 1) Polygon may have multiple outer rings Are rings described between two consecutive outer rings supposed to represent holes in the first polygon ? shapefile specification says : The order of rings in the points array is not significant. 1a) if one suppose that holes of P1 follow P1 outer ring description, one can process polygons one after the other, 1b) if one suppose that a hole in P1 may be described after the outer ring of P2 (hum, hope this does not occur in shapefile despite the lack of specification), one have to test relations between all pairs or so 2) Holes may be described in CCW or CW (polygons with CW holes are described as dirty in the spec, but this is the problem we want to solve) Depending on hypothesis 1, one have to test inclusion of current ring in the previous polygon or inclusion of the current ring in any previous polygon I think it is necessary to test inclusion of the current ring in the ongoing polygon and not only in the previous outer ring to differentiate a hole from a island inside a hole. 3) Overlapping polygons (specification says that it is not authorized : Has no self-intersections) If one consider that the entry polygon has no self intersection, I think at least two point in polygon test have to be done to know if the CW polygon is a hole or an outer ring, because a hole can touch the outer ring but cannot have a colinear segment If a polygon with an island inside a hole is valid (I can't see any reason why it is not) test of point in polygon must be done with the whole polygon and not only with the outer ring. If one wants to manage self-intersection polygons (to repair them ?), may be a full intersection matrix has to be computed instead of the point in polygon test Hope that makes sense Michaël Larry Becker a écrit : Hi Michaël, Thanks for the advice. I may end up doing the DE-9IM matrix, but I'd like to start with a review and critique of what I'm currently doing. To reiterate: The problem that I'm trying to fix is: support for polygon shells with CW holes in PolygonHandler because ESRI allows this. Without the fix, JUMP imports these as overlapping shells which is a topology error. I attempted to limit the scope of the change by testing for (shells.size()1) (holes.size() == 0). This triggers for the case I am trying to fix, but unfortunately my shellsOverlap() method assumes that the first polygon found that contains another is the shell and that the rest are holes. This is a serious flaw that you caught. There may be multiple shells with holes (or not) in each. If I am going to eliminate this case, an additional test is needed to determine if the linear ring found by shellsOverlap() does indeed contain all of the rest. Of course, if it turns out that it does not, I'll have to deal with the case somehow; perhaps by just allowing the bad geometry to be build as it is now. I very much want to maintain the current speed of the shapefile reader. I'm not sure how much this fix will help others, but it seems to handle the data that I have found so far. Any comments? regards, Larry On Thu, Apr 17, 2008 at 4:12 PM, Michaël Michaud [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi Larry, I get a case somewhat similar with a parser I wrote for GeoConcept format. In this format, multi-polygon come as a set of linear rings with no special order and eventually some overlaps or other bad topology I wanted to catch. I decided to compute the DE-9IM matrix in a double loop Something like ListPolygon input = ... // the list of polygons issued from my linear rings ListPolygon result = ... // an empty list of polygons for (Polygon pi : input) for (Polygon pr : result) IntersectionMatrix im = pi.relate(pr) // then decide if pi is a new polygon, a hole in an existing polygon (result), an overlapping polygon... I must admit this approach may have an unecessary performance penalty for a format like shapefile (in my case, correctness was more important than performance) Michaël - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___
Re: [JPP-Devel] Shapefile with overlapping shells
I don't want to muddy this conversation, but you guys have triggered my curiousity. Michael wrote: Polygon may have multiple outer rings... This is only true in the case of a polygon with holes, correct? Michael wrote: I think it is necessary to test inclusion of the current ring in the ongoing polygon and not only in the previous outer ring to differentiate a hole from a island inside a hole. This is really the problem we are trying to solve, correct? Have we thought about contacting the GeoTools programmers about this problem? I could send an e-mail to the mailing list. I don't know how much good it would do. I think the ESRI Shapefile code we are using is a lot older than what they have now. The Sunburned Surveyor On Thu, Apr 17, 2008 at 11:57 PM, Michaël Michaud [EMAIL PROTECTED] wrote: Hi Larry, Thanks for clarification (my english is not so good, and I often need a detailed explanation to grasp the problem) I think your approach is the good one as the problem we want to solve is much more specific than the one I tried to solve in my GeoConcept parser. Try to sum up different hypothesis which are done about the shapefile input and the way to handle them 1) Polygon may have multiple outer rings Are rings described between two consecutive outer rings supposed to represent holes in the first polygon ? shapefile specification says : The order of rings in the points array is not significant. 1a) if one suppose that holes of P1 follow P1 outer ring description, one can process polygons one after the other, 1b) if one suppose that a hole in P1 may be described after the outer ring of P2 (hum, hope this does not occur in shapefile despite the lack of specification), one have to test relations between all pairs or so 2) Holes may be described in CCW or CW (polygons with CW holes are described as dirty in the spec, but this is the problem we want to solve) Depending on hypothesis 1, one have to test inclusion of current ring in the previous polygon or inclusion of the current ring in any previous polygon I think it is necessary to test inclusion of the current ring in the ongoing polygon and not only in the previous outer ring to differentiate a hole from a island inside a hole. 3) Overlapping polygons (specification says that it is not authorized : Has no self-intersections) If one consider that the entry polygon has no self intersection, I think at least two point in polygon test have to be done to know if the CW polygon is a hole or an outer ring, because a hole can touch the outer ring but cannot have a colinear segment If a polygon with an island inside a hole is valid (I can't see any reason why it is not) test of point in polygon must be done with the whole polygon and not only with the outer ring. If one wants to manage self-intersection polygons (to repair them ?), may be a full intersection matrix has to be computed instead of the point in polygon test Hope that makes sense Michaël Larry Becker a écrit : Hi Michaël, Thanks for the advice. I may end up doing the DE-9IM matrix, but I'd like to start with a review and critique of what I'm currently doing. To reiterate: The problem that I'm trying to fix is: support for polygon shells with CW holes in PolygonHandler because ESRI allows this. Without the fix, JUMP imports these as overlapping shells which is a topology error. I attempted to limit the scope of the change by testing for (shells.size()1) (holes.size() == 0). This triggers for the case I am trying to fix, but unfortunately my shellsOverlap() method assumes that the first polygon found that contains another is the shell and that the rest are holes. This is a serious flaw that you caught. There may be multiple shells with holes (or not) in each. If I am going to eliminate this case, an additional test is needed to determine if the linear ring found by shellsOverlap() does indeed contain all of the rest. Of course, if it turns out that it does not, I'll have to deal with the case somehow; perhaps by just allowing the bad geometry to be build as it is now. I very much want to maintain the current speed of the shapefile reader. I'm not sure how much this fix will help others, but it seems to handle the data that I have found so far. Any comments? regards, Larry On Thu, Apr 17, 2008 at 4:12 PM, Michaël Michaud [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi Larry, I get a case somewhat similar with a parser I wrote for GeoConcept format. In this format, multi-polygon come as a set of linear rings with no special order and eventually some overlaps or other bad topology I wanted to catch. I decided to compute the DE-9IM matrix in a double loop Something like ListPolygon input = ... // the list of polygons issued from my linear rings ListPolygon result = ... // an empty list of polygons
Re: [JPP-Devel] Shapefile with overlapping shells
Hi, Larry I'm glad if I could help, thanks again for the hard work. It seems that you found a way to keep both correctness and performance. If you think you can commit, I am very confident. I'll be able to do more tests with complex polygons (but not with CW holes). Note : you can create a MultiPolygon with an island by selecting the two polygons, then right click and run Combine Selected Features. Regards, Michaël - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] Shapefile with overlapping shells
Hei Larry, as I am reading the left over emails from last week: any news on this issue? stefan Larry Becker schrieb: It looks like the code needs more work. I'm just using it as a quick fix for now. thanks, Larry On Fri, Apr 4, 2008 at 2:22 PM, Sunburned Surveyor [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: You guys are definitely over my head, but it sounds like I should hold off on commiting Larry's file. Is this correct? If Larry is still working on a fix I can wait until he tells me it is ready to be commited. The Sunburned Surveyor On Fri, Apr 4, 2008 at 12:14 PM, Larry Becker [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Well, I have already found problems with this mod. I incorrectly assumed that the clock-ness of the shells that were added as holes would be fixed by later methods. That appears not to be true. Even though the mod makes the holes appear correct, they still test bad with the QA tool. I'll have to uncomment out the reverseRing loop. @Michaël, surely you didn't make the mistake of thinking I knew what I was doing? ;-) My check for ((shells.size()1) (holes.size()== 0)) is simply an attempt to minimize any damage my hack might do. Sorry the code had so many changes. I knew I needed to subroutine the inline code so I copied the work that was already done in geotools 2.5. regards, Larry On Fri, Apr 4, 2008 at 2:00 PM, Michaël Michaud [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Martin Davis a écrit : Michaël Michaud wrote: ... about the second point, as you know SFS a no one, you may have an answer to the following question : why polylines may be made of lines sharing their boundaries and multipolygons cannot be made of polygons sharing their edges (if that's what shells can touch at any finite number of points means) That *is* what I meant by shells can touch at any finite number of points. I can't see into the minds of the standards authors, but speaking as a developer who has implemented the standard, the restriction on how polygon shells touch makes for nicer topological assumptions, and hence simpler code. With this rule you can assume that all edges in polygon geometries are truly on the topological boundary - i.e that they divide the polygon interior from the exterior. Without this assumption, you have to basically do a dissolve to remove interior edges before doing any further processing. Polylines don't offer quite such a strong topological distinction (they don't divide the world into interior and exterior), so there aren't any unpleasant implications to just letting their linework go anywhere it wants to. There are other assumptions which SFS could have made to make processing simpler - such as enforcing an orientation for polygon rings. But I guess they wanted to open the model up as much as reasonable, so as not to make a whole bunch of geometry invalid. Although then they could have allowed inverted polygons (self-touching at a point - ArcSDE style) as well. M All that makes sense to me. Thanks for the detailed answer. Michaël - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net mailto:Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- http://amusingprogrammer.blogspot.com/ - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Jump-pilot-devel mailing list
Re: [JPP-Devel] Shapefile with overlapping shells
Hi Michaël, Thanks for the advice. I may end up doing the DE-9IM matrix, but I'd like to start with a review and critique of what I'm currently doing. To reiterate: The problem that I'm trying to fix is: support for polygon shells with CW holes in PolygonHandler because ESRI allows this. Without the fix, JUMP imports these as overlapping shells which is a topology error. I attempted to limit the scope of the change by testing for (shells.size()1) (holes.size() == 0). This triggers for the case I am trying to fix, but unfortunately my shellsOverlap() method assumes that the first polygon found that contains another is the shell and that the rest are holes. This is a serious flaw that you caught. There may be multiple shells with holes (or not) in each. If I am going to eliminate this case, an additional test is needed to determine if the linear ring found by shellsOverlap() does indeed contain all of the rest. Of course, if it turns out that it does not, I'll have to deal with the case somehow; perhaps by just allowing the bad geometry to be build as it is now. I very much want to maintain the current speed of the shapefile reader. I'm not sure how much this fix will help others, but it seems to handle the data that I have found so far. Any comments? regards, Larry On Thu, Apr 17, 2008 at 4:12 PM, Michaël Michaud [EMAIL PROTECTED] wrote: Hi Larry, I get a case somewhat similar with a parser I wrote for GeoConcept format. In this format, multi-polygon come as a set of linear rings with no special order and eventually some overlaps or other bad topology I wanted to catch. I decided to compute the DE-9IM matrix in a double loop Something like ListPolygon input = ... // the list of polygons issued from my linear rings ListPolygon result = ... // an empty list of polygons for (Polygon pi : input) for (Polygon pr : result) IntersectionMatrix im = pi.relate(pr) // then decide if pi is a new polygon, a hole in an existing polygon (result), an overlapping polygon... I must admit this approach may have an unecessary performance penalty for a format like shapefile (in my case, correctness was more important than performance) Michaël - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- http://amusingprogrammer.blogspot.com/ - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] Shapefile with overlapping shells
Larry, Will we need to make mods to OpenJUMP to benefit from your improvements? I am a little confused as to whether this is a fix you made to a tool specific to SkyJUMP, or if we need to fix OpenJUMP's Shapefile reader. The Sunburned Surveyor On Thu, Apr 3, 2008 at 2:11 PM, Larry Becker [EMAIL PROTECTED] wrote: Thanks for the quick answer, Martin. I've made a mod to PolygonHandler in SkyJUMP and committed my change. You can browse it at: http://skyjump.cvs.sourceforge.net/skyjump/skyjump/org/geotools/shapefile/PolygonHandler.java?view=markup My mod begins in read() at // quick optimization:. I used some of the geotools 2.5 code to help with the update. In essence, I do a check for ((shells.size()1) (holes.size()== 0)) before trying anything new to minimize the impact of the change. Then I call the shellsOverlap() method which returns the index of the first shell that contains another. I then make the big assumption that all the rest are holes. I think I can get away with this because the assignHolesToShells() method converts any unassigned holes back to shells. I would appreciate any comments. regards, Larry Becker On Thu, Apr 3, 2008 at 12:44 PM, Martin Davis [EMAIL PROTECTED] wrote: Ugh. Larry, I think your approach is probably what's necessary. I would suggest NOT trying to do a JTS contains() to implement the wholly inside test - it would be very slow (although the new PreparedGeometry work would make it a lot faster - but it would still be slow). You might consider just check say 3 points of the ring to see if they are wholly inside - if so, assume it is a hole. That should be a lot faster. Larry Becker wrote: I've found a shapefile that has what JTS thinks is a topology error of overlapping shells. In ESRI ArcMap it displays correctly as a shell polygon with a hole, but in JUMP, it displays as overlapping polygons. It fails the QA Basic Topology test. I have verified that the hole polygon is not CCW (counter clockwise) and this is being interpreted as a shell by the org.geotools.PolygonHandler. It looks like another case where ESRI isn't following their own specifications. Any suggestions? I don't like to fix customer's data when it works fine in their ESRI system. I'm considering modifying the PolygonHandler code to test all of the polygons in a multipolygon shape to determine if they are completely inside, and then reversing the point order to force CCW. This might make shapefiles read slightly slower. regards, Larry Becker -- http://amusingprogrammer.blogspot.com/ - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- Martin Davis Senior Technical Architect Refractions Research, Inc. (250) 383-3022 - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- http://amusingprogrammer.blogspot.com/ - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] Shapefile with overlapping shells
Hi Larry, It is not easy to understand the changes you did, but I tried to review your code and have some questions : In shellsOverlap, there is the following condition : CGAlgorithms.isPointInRing(testPt, coordList) || (pointInList(testPt, coordList))) I'm not sure about shapefile, but for SFS, I think that a hole cannot touch the exterior ring but two exterior ring can touch each other. So I should not consider pointInList(testPt, coordList) as a case of a shell inside another shell Otherwise, there are several assumptions I don't understand in the read method : if ((shells.size()1) (holes.size()== 0)) do you assume that when there is a shell inside another one, that means that every hole is decribed as a shell (holes.size()==0) ? shells.remove(realShell) holes.addAll(shells) do you assume that if one shell contains another shell, every shell except that one is a hole ? I think that there is only one shapefile type for polygon and multipolygon, so that if every ring are described as shells, some may be real shells and others may be holes I hope I did not misunderstand what the code is supposed to do. Thanks, Michaël Larry Becker a écrit : Thanks for the quick answer, Martin. I've made a mod to PolygonHandler in SkyJUMP and committed my change. You can browse it at: http://skyjump.cvs.sourceforge.net/skyjump/skyjump/org/geotools/shapefile/PolygonHandler.java?view=markup My mod begins in read() at // quick optimization:. I used some of the geotools 2.5 code to help with the update. In essence, I do a check for ((shells.size()1) (holes.size()== 0)) before trying anything new to minimize the impact of the change. Then I call the shellsOverlap() method which returns the index of the first shell that contains another. I then make the big assumption that all the rest are holes. I think I can get away with this because the assignHolesToShells() method converts any unassigned holes back to shells. I would appreciate any comments. regards, Larry Becker On Thu, Apr 3, 2008 at 12:44 PM, Martin Davis [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Ugh. Larry, I think your approach is probably what's necessary. I would suggest NOT trying to do a JTS contains() to implement the wholly inside test - it would be very slow (although the new PreparedGeometry work would make it a lot faster - but it would still be slow). You might consider just check say 3 points of the ring to see if they are wholly inside - if so, assume it is a hole. That should be a lot faster. Larry Becker wrote: I've found a shapefile that has what JTS thinks is a topology error of overlapping shells. In ESRI ArcMap it displays correctly as a shell polygon with a hole, but in JUMP, it displays as overlapping polygons. It fails the QA Basic Topology test. I have verified that the hole polygon is not CCW (counter clockwise) and this is being interpreted as a shell by the org.geotools.PolygonHandler. It looks like another case where ESRI isn't following their own specifications. Any suggestions? I don't like to fix customer's data when it works fine in their ESRI system. I'm considering modifying the PolygonHandler code to test all of the polygons in a multipolygon shape to determine if they are completely inside, and then reversing the point order to force CCW. This might make shapefiles read slightly slower. regards, Larry Becker -- http://amusingprogrammer.blogspot.com/ - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net mailto:Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- Martin Davis Senior Technical Architect Refractions Research, Inc. (250) 383-3022 - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net
Re: [JPP-Devel] Shapefile with overlapping shells
Michaël Michaud wrote: I'm not sure about shapefile, but for SFS, I think that a hole cannot touch the exterior ring but two exterior ring can touch each other. Actually in SFS a hole can touch the shell at at most one point. Two shells can touch at any finite number of points. Haven't had a chance to think about the rest of the code - this whole area is a bit of a brain-buster for a Friday! 8^) -- Martin Davis Senior Technical Architect Refractions Research, Inc. (250) 383-3022 - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] Shapefile with overlapping shells
Actually in SFS a hole can touch the shell at at most one point. Two shells can touch at any finite number of points. Hey, of course, you are right. We spent so much times to discuss this point with some co-workers that I mixed up everything. ... about the second point, as you know SFS a no one, you may have an answer to the following question : why polylines may be made of lines sharing their boundaries and multipolygons cannot be made of polygons sharing their edges (if that's what shells can touch at any finite number of points means) Of course, this is not a vital question, and it should not compromise your week-end ;-) Michaël Haven't had a chance to think about the rest of the code - this whole area is a bit of a brain-buster for a Friday! 8^) - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] Shapefile with overlapping shells
Martin Davis a écrit : Michaël Michaud wrote: ... about the second point, as you know SFS a no one, you may have an answer to the following question : why polylines may be made of lines sharing their boundaries and multipolygons cannot be made of polygons sharing their edges (if that's what shells can touch at any finite number of points means) That *is* what I meant by shells can touch at any finite number of points. I can't see into the minds of the standards authors, but speaking as a developer who has implemented the standard, the restriction on how polygon shells touch makes for nicer topological assumptions, and hence simpler code. With this rule you can assume that all edges in polygon geometries are truly on the topological boundary - i.e that they divide the polygon interior from the exterior. Without this assumption, you have to basically do a dissolve to remove interior edges before doing any further processing. Polylines don't offer quite such a strong topological distinction (they don't divide the world into interior and exterior), so there aren't any unpleasant implications to just letting their linework go anywhere it wants to. There are other assumptions which SFS could have made to make processing simpler - such as enforcing an orientation for polygon rings. But I guess they wanted to open the model up as much as reasonable, so as not to make a whole bunch of geometry invalid. Although then they could have allowed inverted polygons (self-touching at a point - ArcSDE style) as well. M All that makes sense to me. Thanks for the detailed answer. Michaël - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] Shapefile with overlapping shells
You guys are definitely over my head, but it sounds like I should hold off on commiting Larry's file. Is this correct? If Larry is still working on a fix I can wait until he tells me it is ready to be commited. The Sunburned Surveyor On Fri, Apr 4, 2008 at 12:14 PM, Larry Becker [EMAIL PROTECTED] wrote: Well, I have already found problems with this mod. I incorrectly assumed that the clock-ness of the shells that were added as holes would be fixed by later methods. That appears not to be true. Even though the mod makes the holes appear correct, they still test bad with the QA tool. I'll have to uncomment out the reverseRing loop. @Michaël, surely you didn't make the mistake of thinking I knew what I was doing? ;-) My check for ((shells.size()1) (holes.size()== 0)) is simply an attempt to minimize any damage my hack might do. Sorry the code had so many changes. I knew I needed to subroutine the inline code so I copied the work that was already done in geotools 2.5. regards, Larry On Fri, Apr 4, 2008 at 2:00 PM, Michaël Michaud [EMAIL PROTECTED] wrote: Martin Davis a écrit : Michaël Michaud wrote: ... about the second point, as you know SFS a no one, you may have an answer to the following question : why polylines may be made of lines sharing their boundaries and multipolygons cannot be made of polygons sharing their edges (if that's what shells can touch at any finite number of points means) That *is* what I meant by shells can touch at any finite number of points. I can't see into the minds of the standards authors, but speaking as a developer who has implemented the standard, the restriction on how polygon shells touch makes for nicer topological assumptions, and hence simpler code. With this rule you can assume that all edges in polygon geometries are truly on the topological boundary - i.e that they divide the polygon interior from the exterior. Without this assumption, you have to basically do a dissolve to remove interior edges before doing any further processing. Polylines don't offer quite such a strong topological distinction (they don't divide the world into interior and exterior), so there aren't any unpleasant implications to just letting their linework go anywhere it wants to. There are other assumptions which SFS could have made to make processing simpler - such as enforcing an orientation for polygon rings. But I guess they wanted to open the model up as much as reasonable, so as not to make a whole bunch of geometry invalid. Although then they could have allowed inverted polygons (self-touching at a point - ArcSDE style) as well. M All that makes sense to me. Thanks for the detailed answer. Michaël - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- http://amusingprogrammer.blogspot.com/ - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] Shapefile with overlapping shells
It looks like the code needs more work. I'm just using it as a quick fix for now. thanks, Larry On Fri, Apr 4, 2008 at 2:22 PM, Sunburned Surveyor [EMAIL PROTECTED] wrote: You guys are definitely over my head, but it sounds like I should hold off on commiting Larry's file. Is this correct? If Larry is still working on a fix I can wait until he tells me it is ready to be commited. The Sunburned Surveyor On Fri, Apr 4, 2008 at 12:14 PM, Larry Becker [EMAIL PROTECTED] wrote: Well, I have already found problems with this mod. I incorrectly assumed that the clock-ness of the shells that were added as holes would be fixed by later methods. That appears not to be true. Even though the mod makes the holes appear correct, they still test bad with the QA tool. I'll have to uncomment out the reverseRing loop. @Michaël, surely you didn't make the mistake of thinking I knew what I was doing? ;-) My check for ((shells.size()1) (holes.size()== 0)) is simply an attempt to minimize any damage my hack might do. Sorry the code had so many changes. I knew I needed to subroutine the inline code so I copied the work that was already done in geotools 2.5. regards, Larry On Fri, Apr 4, 2008 at 2:00 PM, Michaël Michaud [EMAIL PROTECTED] wrote: Martin Davis a écrit : Michaël Michaud wrote: ... about the second point, as you know SFS a no one, you may have an answer to the following question : why polylines may be made of lines sharing their boundaries and multipolygons cannot be made of polygons sharing their edges (if that's what shells can touch at any finite number of points means) That *is* what I meant by shells can touch at any finite number of points. I can't see into the minds of the standards authors, but speaking as a developer who has implemented the standard, the restriction on how polygon shells touch makes for nicer topological assumptions, and hence simpler code. With this rule you can assume that all edges in polygon geometries are truly on the topological boundary - i.e that they divide the polygon interior from the exterior. Without this assumption, you have to basically do a dissolve to remove interior edges before doing any further processing. Polylines don't offer quite such a strong topological distinction (they don't divide the world into interior and exterior), so there aren't any unpleasant implications to just letting their linework go anywhere it wants to. There are other assumptions which SFS could have made to make processing simpler - such as enforcing an orientation for polygon rings. But I guess they wanted to open the model up as much as reasonable, so as not to make a whole bunch of geometry invalid. Although then they could have allowed inverted polygons (self-touching at a point - ArcSDE style) as well. M All that makes sense to me. Thanks for the detailed answer. Michaël - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- http://amusingprogrammer.blogspot.com/ - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- http://amusingprogrammer.blogspot.com/ - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace___ Jump-pilot-devel
Re: [JPP-Devel] Shapefile with overlapping shells
i am having the exact same problem with some esri generated shapefiles from one of my sources. eric On Apr 3, 2008, at 11:24 AM, Larry Becker wrote: I've found a shapefile that has what JTS thinks is a topology error of overlapping shells. In ESRI ArcMap it displays correctly as a shell polygon with a hole, but in JUMP, it displays as overlapping polygons. It fails the QA Basic Topology test. I have verified that the hole polygon is not CCW (counter clockwise) and this is being interpreted as a shell by the org.geotools.PolygonHandler. It looks like another case where ESRI isn't following their own specifications. Any suggestions? I don't like to fix customer's data when it works fine in their ESRI system. I'm considering modifying the PolygonHandler code to test all of the polygons in a multipolygon shape to determine if they are completely inside, and then reversing the point order to force CCW. This might make shapefiles read slightly slower. regards, Larry Becker -- http://amusingprogrammer.blogspot.com/ - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] Shapefile with overlapping shells
Ugh. Larry, I think your approach is probably what's necessary. I would suggest NOT trying to do a JTS contains() to implement the wholly inside test - it would be very slow (although the new PreparedGeometry work would make it a lot faster - but it would still be slow). You might consider just check say 3 points of the ring to see if they are wholly inside - if so, assume it is a hole. That should be a lot faster. Larry Becker wrote: I've found a shapefile that has what JTS thinks is a topology error of overlapping shells. In ESRI ArcMap it displays correctly as a shell polygon with a hole, but in JUMP, it displays as overlapping polygons. It fails the QA Basic Topology test. I have verified that the hole polygon is not CCW (counter clockwise) and this is being interpreted as a shell by the org.geotools.PolygonHandler. It looks like another case where ESRI isn't following their own specifications. Any suggestions? I don't like to fix customer's data when it works fine in their ESRI system. I'm considering modifying the PolygonHandler code to test all of the polygons in a multipolygon shape to determine if they are completely inside, and then reversing the point order to force CCW. This might make shapefiles read slightly slower. regards, Larry Becker -- http://amusingprogrammer.blogspot.com/ - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- Martin Davis Senior Technical Architect Refractions Research, Inc. (250) 383-3022 - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] Shapefile with overlapping shells
Thanks for the quick answer, Martin. I've made a mod to PolygonHandler in SkyJUMP and committed my change. You can browse it at: http://skyjump.cvs.sourceforge.net/skyjump/skyjump/org/geotools/shapefile/PolygonHandler.java?view=markup My mod begins in read() at // quick optimization:. I used some of the geotools 2.5 code to help with the update. In essence, I do a check for ((shells.size()1) (holes.size()== 0)) before trying anything new to minimize the impact of the change. Then I call the shellsOverlap() method which returns the index of the first shell that contains another. I then make the big assumption that all the rest are holes. I think I can get away with this because the assignHolesToShells() method converts any unassigned holes back to shells. I would appreciate any comments. regards, Larry Becker On Thu, Apr 3, 2008 at 12:44 PM, Martin Davis [EMAIL PROTECTED] wrote: Ugh. Larry, I think your approach is probably what's necessary. I would suggest NOT trying to do a JTS contains() to implement the wholly inside test - it would be very slow (although the new PreparedGeometry work would make it a lot faster - but it would still be slow). You might consider just check say 3 points of the ring to see if they are wholly inside - if so, assume it is a hole. That should be a lot faster. Larry Becker wrote: I've found a shapefile that has what JTS thinks is a topology error of overlapping shells. In ESRI ArcMap it displays correctly as a shell polygon with a hole, but in JUMP, it displays as overlapping polygons. It fails the QA Basic Topology test. I have verified that the hole polygon is not CCW (counter clockwise) and this is being interpreted as a shell by the org.geotools.PolygonHandler. It looks like another case where ESRI isn't following their own specifications. Any suggestions? I don't like to fix customer's data when it works fine in their ESRI system. I'm considering modifying the PolygonHandler code to test all of the polygons in a multipolygon shape to determine if they are completely inside, and then reversing the point order to force CCW. This might make shapefiles read slightly slower. regards, Larry Becker -- http://amusingprogrammer.blogspot.com/ - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- Martin Davis Senior Technical Architect Refractions Research, Inc. (250) 383-3022 - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- http://amusingprogrammer.blogspot.com/ - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
