I keep getting the error \"TopologyException: found non-noded intersection between LINESTRING(...) and LINESTRING(...)\". I tested my output to ensure polygon validity using the Java-based tool by amaia and found no errors. I also tested it using the C#-based contest evaluation code (using sample_submission.csv as the \"reference solution\") and again it did not encounter any errors. Likewise, shapely and rgeos also state that the polygons are valid. At this point I can only conclude that my polygons are valid, but when they are intersected with the reference solution the evaluation code is somehow producing invalid polygons. I am stuck, does anybody have any ideas how to proceed? I could just manually remove the bad polygons in the part that is graded immediately, but I have no way of knowing whether there are bad polygons in the private test set.
", "messages": [ { "id": "155843", "postDate": "01/13/2017 00:39:20", "content": "I keep getting the error \"TopologyException: found non-noded intersection between LINESTRING(...) and LINESTRING(...)\". I tested my output to ensure polygon validity using the Java-based tool by amaia and found no errors. I also tested it using the C#-based contest evaluation code (using sample_submission.csv as the \"reference solution\") and again it did not encounter any errors. Likewise, shapely and rgeos also state that the polygons are valid. At this point I can only conclude that my polygons are valid, but when they are intersected with the reference solution the evaluation code is somehow producing invalid polygons. I am stuck, does anybody have any ideas how to proceed? I could just manually remove the bad polygons in the part that is graded immediately, but I have no way of knowing whether there are bad polygons in the private test set.
", "rawMarkdown": "I keep getting the error \"TopologyException: found non-noded intersection between LINESTRING(...) and LINESTRING(...)\". I tested my output to ensure polygon validity using the [Java-based tool by amaia][1] and found no errors. I also tested it using the [C#-based contest evaluation code][2] (using sample_submission.csv as the \"reference solution\") and again it did not encounter any errors. Likewise, shapely and rgeos also state that the polygons are valid. At this point I can only conclude that my polygons are valid, but when they are intersected with the reference solution the evaluation code is somehow producing invalid polygons. I am stuck, does anybody have any ideas how to proceed? I could just manually remove the bad polygons in the part that is graded immediately, but I have no way of knowing whether there are bad polygons in the private test set.\r\n\r\n\r\n [1]: https://github.com/cxz/tpex\r\n [2]: https://gist.github.com/wendykan/2fcbbf95945faa0f2c89895694069010", "votes": null }, { "id": "155897", "postDate": "01/13/2017 06:10:16", "content": "Hi,
\nI'm having exactly the same problem. Yesterday I checked my submission with amaia tool and it was ok. When I submit the file I got this error message:
\n", "rawMarkdown": "Hi, \r\nI'm having exactly the same problem. Yesterday I checked my submission with amaia tool and it was ok. When I submit the file I got this error message:\r\n\r\n> Evaluation Exception: For image 6100_0_2, class 2, there's an\r\n> exception in geometry NetTopologySuite.Geometries.TopologyException:\r\n> found non-noded intersection between LINESTRING(0.0080353833333333333\r\n> -0.0034745333333333333, 0.008036 -0.003477) and LINESTRING(0.0080369858204119415 -0.0034829149224716504,\r\n> 0.008035597826086956 -0.003474586956521739) [ (0.008036, -0.0034769999999999983, NaN) ] at Kaggle.Metrics.Custom.JaccardDSTL.compareMultipolygon(IGeometry\r\n> predMultipoly, IGeometry truthMultipoly) at\r\n> Kaggle.Metrics.Custom.JaccardDSTL.calculateIoUVector(Dictionary`2\r\n> submission, Dictionary`2 solution).", "votes": null }, { "id": "156103", "postDate": "01/14/2017 08:37:05", "content": "Evaluation Exception: For image 6100_0_2, class 2, there's an\n exception in geometry NetTopologySuite.Geometries.TopologyException:\n found non-noded intersection between LINESTRING(0.0080353833333333333\n -0.0034745333333333333, 0.008036 -0.003477) and LINESTRING(0.0080369858204119415 -0.0034829149224716504,\n 0.008035597826086956 -0.003474586956521739) [ (0.008036, -0.0034769999999999983, NaN) ] at Kaggle.Metrics.Custom.JaccardDSTL.compareMultipolygon(IGeometry\n predMultipoly, IGeometry truthMultipoly) at\n Kaggle.Metrics.Custom.JaccardDSTL.calculateIoUVector(Dictionary
\n2\n submission, Dictionary2 solution).
Hi,\nI had same problems when I used cv2.findContours() for edge detection. Then I tried to use skimage.measure.findContours() and all errors disappeared. Moreover, most polygons obtained with cv2 were not valid and I had to use buffer(0) method to fix that. Skimage, in turn, produce valid polygons in most cases. I guess the best strategy is to use both of these methods and compare the result. Good luck!
", "rawMarkdown": "Hi,\r\nI had same problems when I used cv2.findContours() for edge detection. Then I tried to use skimage.measure.findContours() and all errors disappeared. Moreover, most polygons obtained with cv2 were not valid and I had to use buffer(0) method to fix that. Skimage, in turn, produce valid polygons in most cases. I guess the best strategy is to use both of these methods and compare the result. Good luck!", "votes": null }, { "id": "156105", "postDate": "01/14/2017 08:44:26", "content": "Hi, \nI have been able to solve the problem by reducing the precision of the submission to only 6 decimals.
", "rawMarkdown": "Hi, \r\nI have been able to solve the problem by reducing the precision of the submission to only 6 decimals.", "votes": null }, { "id": "156195", "postDate": "01/14/2017 20:17:13", "content": "Today using 6 decimals of precission I'm getting the exception in geometry again...
", "rawMarkdown": "Today using 6 decimals of precission I'm getting the exception in geometry again...", "votes": null }, { "id": "157206", "postDate": "01/19/2017 17:12:01", "content": "This error happens when jts's intersection method is used. One way to cause this error on purpose is to use TopologyPreservingSimplifier.simplify(geometry, tolerance) with a very big tolerance value. A geometry object created in this way passes isSimple() and isValid() methods, but sometimes fails on the intersection method depending on the shape of the other geometry to be intersected with.
\n\nOne thing we can do would be to ask admin to rewrite their evaluation code so that our submitted wkts will be deployed onto a raster and calculate intersection areas on this raster. This prevents errors which is caused by the shape of Kaggle's validation geometry and allows us to control our own submissions by ourselves.
", "rawMarkdown": "This error happens when jts's intersection method is used. One way to cause this error on purpose is to use TopologyPreservingSimplifier.simplify(geometry, tolerance) with a very big tolerance value. A geometry object created in this way passes isSimple() and isValid() methods, but sometimes fails on the intersection method depending on the shape of the other geometry to be intersected with. \r\n\r\nOne thing we can do would be to ask admin to rewrite their evaluation code so that our submitted wkts will be deployed onto a raster and calculate intersection areas on this raster. This prevents errors which is caused by the shape of Kaggle's validation geometry and allows us to control our own submissions by ourselves.", "votes": null }, { "id": "157240", "postDate": "01/19/2017 20:58:43", "content": "[quote=Komaki;157206]
\n\nOne thing we can do would be to ask admin to rewrite their evaluation code so that our submitted wkts will be deployed onto a raster and calculate intersection areas on this raster. This prevents errors which is caused by the shape of Kaggle's validation geometry and allows us to control our own submissions by ourselves.
\n\n[/quote]
\n\nThat's a very good suggestion, I don't see any disadvantages. And it's a lot faster too.
", "rawMarkdown": "[quote=Komaki;157206]\r\n\r\nOne thing we can do would be to ask admin to rewrite their evaluation code so that our submitted wkts will be deployed onto a raster and calculate intersection areas on this raster. This prevents errors which is caused by the shape of Kaggle's validation geometry and allows us to control our own submissions by ourselves.\r\n\r\n[/quote]\r\n\r\nThat's a very good suggestion, I don't see any disadvantages. And it's a lot faster too.", "votes": null }, { "id": "157345", "postDate": "01/20/2017 11:28:34", "content": "I agree with you both. The advantage of projecting the polygons to a raster is the speed. That way we could submit bigger files.
\nI have asked Wendy about the size of a \"perfect submission\" in the welcome post, because I think that it will get timeout error right now.
[quote=Komaki;157206]
\n\nOne thing we can do would be to ask admin to rewrite their evaluation code so that our submitted wkts will be deployed onto a raster and calculate intersection areas on this raster. This prevents errors which is caused by the shape of Kaggle's validation geometry and allows us to control our own submissions by ourselves.
\n\n[/quote]
\n\nGetting the same nasty error on submissions I totally agree with this proposal.
", "rawMarkdown": "[quote=Komaki;157206]\r\n\r\nOne thing we can do would be to ask admin to rewrite their evaluation code so that our submitted wkts will be deployed onto a raster and calculate intersection areas on this raster. This prevents errors which is caused by the shape of Kaggle's validation geometry and allows us to control our own submissions by ourselves.\r\n\r\n[/quote]\r\n\r\nGetting the same nasty error on submissions I totally agree with this proposal.", "votes": null }, { "id": "157469", "postDate": "01/21/2017 11:03:35", "content": "@aj7210\nI also keep running on errors while submitting, and I cannot find either where is the problem coming from. As you said, it gives the impression that it is when the polygons are intersected with the reference solution that the evaluation code is producing invalid polygons. Did you find any improvement?
", "rawMarkdown": "aj7210\r\nI also keep running on errors while submitting, and I cannot find either where is the problem coming from. As you said, it gives the impression that it is when the polygons are intersected with the reference solution that the evaluation code is producing invalid polygons. Did you find any improvement?", "votes": null }, { "id": "157470", "postDate": "01/21/2017 11:04:29", "content": "I agree that modifying the evaluation code would indeed be great. The minimum would be that it warns us about the errors but just ignore these polygons and still provides a result. But indeed, projecting onto rasters to compute the intersection would even be better.
", "rawMarkdown": "I agree that modifying the evaluation code would indeed be great. The minimum would be that it warns us about the errors but just ignore these polygons and still provides a result. But indeed, projecting onto rasters to compute the intersection would even be better.", "votes": null }, { "id": "159322", "postDate": "02/01/2017 20:15:55", "content": "I received the same error. I checked all my MultiPolygon using shapely, is_valid return True.
", "rawMarkdown": "I received the same error. I checked all my MultiPolygon using shapely, is_valid return True.", "votes": null } ], "comments": [ { "id": 155897, "author_name": "ironbar", "author_url": "", "post_date": "01/13/2017 06:10:16", "content": "Hi,
\nI'm having exactly the same problem. Yesterday I checked my submission with amaia tool and it was ok. When I submit the file I got this error message:
\n", "votes": null, "replies": [] }, { "id": 156103, "author_name": "alexlu", "author_url": "", "post_date": "01/14/2017 08:37:05", "content": "Evaluation Exception: For image 6100_0_2, class 2, there's an\n exception in geometry NetTopologySuite.Geometries.TopologyException:\n found non-noded intersection between LINESTRING(0.0080353833333333333\n -0.0034745333333333333, 0.008036 -0.003477) and LINESTRING(0.0080369858204119415 -0.0034829149224716504,\n 0.008035597826086956 -0.003474586956521739) [ (0.008036, -0.0034769999999999983, NaN) ] at Kaggle.Metrics.Custom.JaccardDSTL.compareMultipolygon(IGeometry\n predMultipoly, IGeometry truthMultipoly) at\n Kaggle.Metrics.Custom.JaccardDSTL.calculateIoUVector(Dictionary
\n2\n submission, Dictionary2 solution).
Hi,\nI had same problems when I used cv2.findContours() for edge detection. Then I tried to use skimage.measure.findContours() and all errors disappeared. Moreover, most polygons obtained with cv2 were not valid and I had to use buffer(0) method to fix that. Skimage, in turn, produce valid polygons in most cases. I guess the best strategy is to use both of these methods and compare the result. Good luck!
", "votes": null, "replies": [] }, { "id": 156105, "author_name": "ironbar", "author_url": "", "post_date": "01/14/2017 08:44:26", "content": "Hi, \nI have been able to solve the problem by reducing the precision of the submission to only 6 decimals.
", "votes": null, "replies": [] }, { "id": 156195, "author_name": "ironbar", "author_url": "", "post_date": "01/14/2017 20:17:13", "content": "Today using 6 decimals of precission I'm getting the exception in geometry again...
", "votes": null, "replies": [] }, { "id": 157206, "author_name": "ckomaki", "author_url": "", "post_date": "01/19/2017 17:12:01", "content": "This error happens when jts's intersection method is used. One way to cause this error on purpose is to use TopologyPreservingSimplifier.simplify(geometry, tolerance) with a very big tolerance value. A geometry object created in this way passes isSimple() and isValid() methods, but sometimes fails on the intersection method depending on the shape of the other geometry to be intersected with.
\n\nOne thing we can do would be to ask admin to rewrite their evaluation code so that our submitted wkts will be deployed onto a raster and calculate intersection areas on this raster. This prevents errors which is caused by the shape of Kaggle's validation geometry and allows us to control our own submissions by ourselves.
", "votes": null, "replies": [ { "id": 157240, "author_name": "aamaia", "author_url": "", "post_date": "01/19/2017 20:58:43", "content": "[quote=Komaki;157206]
\n\nOne thing we can do would be to ask admin to rewrite their evaluation code so that our submitted wkts will be deployed onto a raster and calculate intersection areas on this raster. This prevents errors which is caused by the shape of Kaggle's validation geometry and allows us to control our own submissions by ourselves.
\n\n[/quote]
\n\nThat's a very good suggestion, I don't see any disadvantages. And it's a lot faster too.
", "votes": null, "replies": [] }, { "id": 157359, "author_name": "cogitae", "author_url": "", "post_date": "01/20/2017 13:37:28", "content": "[quote=Komaki;157206]
\n\nOne thing we can do would be to ask admin to rewrite their evaluation code so that our submitted wkts will be deployed onto a raster and calculate intersection areas on this raster. This prevents errors which is caused by the shape of Kaggle's validation geometry and allows us to control our own submissions by ourselves.
\n\n[/quote]
\n\nGetting the same nasty error on submissions I totally agree with this proposal.
", "votes": null, "replies": [] } ] }, { "id": 157345, "author_name": "ironbar", "author_url": "", "post_date": "01/20/2017 11:28:34", "content": "I agree with you both. The advantage of projecting the polygons to a raster is the speed. That way we could submit bigger files.
\nI have asked Wendy about the size of a \"perfect submission\" in the welcome post, because I think that it will get timeout error right now.
@aj7210\nI also keep running on errors while submitting, and I cannot find either where is the problem coming from. As you said, it gives the impression that it is when the polygons are intersected with the reference solution that the evaluation code is producing invalid polygons. Did you find any improvement?
", "votes": null, "replies": [] }, { "id": 157470, "author_name": "vincentl", "author_url": "", "post_date": "01/21/2017 11:04:29", "content": "I agree that modifying the evaluation code would indeed be great. The minimum would be that it warns us about the errors but just ignore these polygons and still provides a result. But indeed, projecting onto rasters to compute the intersection would even be better.
", "votes": null, "replies": [] }, { "id": 159322, "author_name": "cheowthianliang", "author_url": "", "post_date": "02/01/2017 20:15:55", "content": "I received the same error. I checked all my MultiPolygon using shapely, is_valid return True.
", "votes": null, "replies": [] } ], "raw_markdown_by_id": { "155843": "I keep getting the error \"TopologyException: found non-noded intersection between LINESTRING(...) and LINESTRING(...)\". I tested my output to ensure polygon validity using the [Java-based tool by amaia][1] and found no errors. I also tested it using the [C#-based contest evaluation code][2] (using sample_submission.csv as the \"reference solution\") and again it did not encounter any errors. Likewise, shapely and rgeos also state that the polygons are valid. At this point I can only conclude that my polygons are valid, but when they are intersected with the reference solution the evaluation code is somehow producing invalid polygons. I am stuck, does anybody have any ideas how to proceed? I could just manually remove the bad polygons in the part that is graded immediately, but I have no way of knowing whether there are bad polygons in the private test set.\r\n\r\n\r\n [1]: https://github.com/cxz/tpex\r\n [2]: https://gist.github.com/wendykan/2fcbbf95945faa0f2c89895694069010", "155897": "Hi, \r\nI'm having exactly the same problem. Yesterday I checked my submission with amaia tool and it was ok. When I submit the file I got this error message:\r\n\r\n> Evaluation Exception: For image 6100_0_2, class 2, there's an\r\n> exception in geometry NetTopologySuite.Geometries.TopologyException:\r\n> found non-noded intersection between LINESTRING(0.0080353833333333333\r\n> -0.0034745333333333333, 0.008036 -0.003477) and LINESTRING(0.0080369858204119415 -0.0034829149224716504,\r\n> 0.008035597826086956 -0.003474586956521739) [ (0.008036, -0.0034769999999999983, NaN) ] at Kaggle.Metrics.Custom.JaccardDSTL.compareMultipolygon(IGeometry\r\n> predMultipoly, IGeometry truthMultipoly) at\r\n> Kaggle.Metrics.Custom.JaccardDSTL.calculateIoUVector(Dictionary`2\r\n> submission, Dictionary`2 solution).", "156103": "Hi,\r\nI had same problems when I used cv2.findContours() for edge detection. Then I tried to use skimage.measure.findContours() and all errors disappeared. Moreover, most polygons obtained with cv2 were not valid and I had to use buffer(0) method to fix that. Skimage, in turn, produce valid polygons in most cases. I guess the best strategy is to use both of these methods and compare the result. Good luck!", "156105": "Hi, \r\nI have been able to solve the problem by reducing the precision of the submission to only 6 decimals.", "156195": "Today using 6 decimals of precission I'm getting the exception in geometry again...", "157206": "This error happens when jts's intersection method is used. One way to cause this error on purpose is to use TopologyPreservingSimplifier.simplify(geometry, tolerance) with a very big tolerance value. A geometry object created in this way passes isSimple() and isValid() methods, but sometimes fails on the intersection method depending on the shape of the other geometry to be intersected with. \r\n\r\nOne thing we can do would be to ask admin to rewrite their evaluation code so that our submitted wkts will be deployed onto a raster and calculate intersection areas on this raster. This prevents errors which is caused by the shape of Kaggle's validation geometry and allows us to control our own submissions by ourselves.", "157240": "[quote=Komaki;157206]\r\n\r\nOne thing we can do would be to ask admin to rewrite their evaluation code so that our submitted wkts will be deployed onto a raster and calculate intersection areas on this raster. This prevents errors which is caused by the shape of Kaggle's validation geometry and allows us to control our own submissions by ourselves.\r\n\r\n[/quote]\r\n\r\nThat's a very good suggestion, I don't see any disadvantages. And it's a lot faster too.", "157345": "I agree with you both. The advantage of projecting the polygons to a raster is the speed. That way we could submit bigger files. \r\nI have asked Wendy about the size of a \"perfect submission\" in the welcome post, because I think that it will get timeout error right now.", "157359": "[quote=Komaki;157206]\r\n\r\nOne thing we can do would be to ask admin to rewrite their evaluation code so that our submitted wkts will be deployed onto a raster and calculate intersection areas on this raster. This prevents errors which is caused by the shape of Kaggle's validation geometry and allows us to control our own submissions by ourselves.\r\n\r\n[/quote]\r\n\r\nGetting the same nasty error on submissions I totally agree with this proposal.", "157469": "aj7210\r\nI also keep running on errors while submitting, and I cannot find either where is the problem coming from. As you said, it gives the impression that it is when the polygons are intersected with the reference solution that the evaluation code is producing invalid polygons. Did you find any improvement?", "157470": "I agree that modifying the evaluation code would indeed be great. The minimum would be that it warns us about the errors but just ignore these polygons and still provides a result. But indeed, projecting onto rasters to compute the intersection would even be better.", "159322": "I received the same error. I checked all my MultiPolygon using shapely, is_valid return True." }, "source": "meta" }