![\"raster](\"http://funvert.com/kaggle/class4_6129_2_2.png\" "\\"\\"")
Hello, after finding an anomaly for a label I thought I'd start a thread where we could post image ids + pic + class where we think there is an issue. I know having some bad labels is something that we need to account for so I'm not expecting that the admins re-publish the data but we can deal with it as a group. I have not gone through every image (so it's possible that there are not many errors).
\n\nOne possible way to deal with it is to come up with a list of hole polygons and/or extra polygons to add to the dataset. If it's out in the open, perhaps everyone can use it. (?) Training pixel/patch based classifiers could be affected by these types of errors...this is why I'm concerned.
\n\nJeffh https://www.kaggle.com/jeffhebert/dstl-satellite-imagery-feature-detection/the-many-faces-of-6120-2-2 and Gabriel Altay https://www.kaggle.com/gabrielaltay/dstl-satellite-imagery-feature-detection/polygons-over-images-and-5x5-mosaics/comments#151216 and myself found an issue with:
\n\nimage-id: 6120_2_2
\n\nclass: 4
\n\nissue: looks like a portion is filled in when there should be a couple of holes
\n\nI would suggest looking at the other thread's images as they're prettier than mine. The large white rectangle in middle-right top is the culprit.
\n\nhere's my version nonetheless:\n
Hello, after finding an anomaly for a label I thought I'd start a thread where we could post image ids + pic + class where we think there is an issue. I know having some bad labels is something that we need to account for so I'm not expecting that the admins re-publish the data but we can deal with it as a group. I have not gone through every image (so it's possible that there are not many errors).
\n\nOne possible way to deal with it is to come up with a list of hole polygons and/or extra polygons to add to the dataset. If it's out in the open, perhaps everyone can use it. (?) Training pixel/patch based classifiers could be affected by these types of errors...this is why I'm concerned.
\n\nJeffh https://www.kaggle.com/jeffhebert/dstl-satellite-imagery-feature-detection/the-many-faces-of-6120-2-2 and Gabriel Altay https://www.kaggle.com/gabrielaltay/dstl-satellite-imagery-feature-detection/polygons-over-images-and-5x5-mosaics/comments#151216 and myself found an issue with:
\n\nimage-id: 6120_2_2
\n\nclass: 4
\n\nissue: looks like a portion is filled in when there should be a couple of holes
\n\nI would suggest looking at the other thread's images as they're prettier than mine. The large white rectangle in middle-right top is the culprit.
\n\nhere's my version nonetheless:\n
Many images have this issue with Class 4. See image 6120_2_0, 6100_1_3, 6110_4_0, 6110_1_2, 6140_1_2, etc... Some like 6100_1_3 and 6120_2_0 are quite bad (cf. attachment).
", "rawMarkdown": "Many images have this issue with Class 4. See image 6120_2_0, 6100_1_3, 6110_4_0, 6110_1_2, 6140_1_2, etc... Some like 6100_1_3 and 6120_2_0 are quite bad (cf. attachment).", "votes": null }, { "id": "151349", "postDate": "12/20/2016 08:40:28", "content": "Maybe is not a bug, is a feature. AND if the test data is labelled using the same principles as above, well, we should stick to their representation.
", "rawMarkdown": "Maybe is not a bug, is a feature. AND if the test data is labelled using the same principles as above, well, we should stick to their representation.", "votes": null }, { "id": "151353", "postDate": "12/20/2016 09:03:19", "content": "@visoft, what is that feature/representation according to you? I can not give any meaning to it, other than some unknown glitch in polygon formation. Understanding the cause of the glitch might be helpful.
", "rawMarkdown": "visoft, what is that feature/representation according to you? I can not give any meaning to it, other than some unknown glitch in polygon formation. Understanding the cause of the glitch might be helpful.", "votes": null }, { "id": "151360", "postDate": "12/20/2016 09:50:25", "content": "Gentlemen,
\n\nSee attached image (seen by QGIS) for class #4, look at 6122-2-2:\n002_TR_L4_POOR_DIRT_CART_TRACK.geojson,\n002_TR_L6_FOOTPATH_TRAIL.geojson
Use gdal/ogr libs don't waste time with other non GIS land libraries. Clearly your approach for multi-polygon handling fails to properly interpret inner/outer rings that can form the collection.
Their images are fine. This is a difference between the geojson and wkt formats. Load train_wkt_v3.csv into qgis and you will see the large blob in the upper right of 6120_2_2 for Class 4. It does look like an error though since the geojson doesn't have it, and the area clearly isn't one giant track.
\n\nIf you look in this script there are a bunch of these for class 4. Definitely something that needs to be addressed. \nhttps://www.kaggle.com/randel/dstl-satellite-imagery-feature-detection/polygons-over-images/code
", "rawMarkdown": "Their images are fine. This is a difference between the geojson and wkt formats. Load train_wkt_v3.csv into qgis and you will see the large blob in the upper right of 6120_2_2 for Class 4. It does look like an error though since the geojson doesn't have it, and the area clearly isn't one giant track. \r\n\r\nIf you look in this script there are a bunch of these for class 4. Definitely something that needs to be addressed. \r\nhttps://www.kaggle.com/randel/dstl-satellite-imagery-feature-detection/polygons-over-images/code", "votes": null }, { "id": "151378", "postDate": "12/20/2016 13:08:40", "content": "@shawn ,
\n\n(1) You are right regarding CSV vs. GEOJson ! GEOJson expose a correct geometry !
\n\n(2) Also, regarding CSV vs GEOJson I found that GEOJson have more polygons in some undocumented categories (see my collected list below).
\n\n@wendykan ,
\n\nTo whom report such discrepancy ?
\n\nGEOJson seems to be much complete, but then what to do with these undocumented classes ?
\n\n001_MM_L3_EXTRACTION_MINE
\n\n001_MM_L4_BRIDGE
\n\n003_VH_L4_AQUATIC_SMALL
\n\n004_UPI_L5_PYLONS
\n\n004_UPI_L6_SATELLITE_DISHES_DISH_AERIAL
\n\n005_VO_L6_MASTS_RADIO_TOWER
\n\n005_VO_L7_FLAGPOLE
\n\n006_VEG_L2_SCRUBLAND
\n\n007_AGR_L2_DEMARCATED_NON_CROP_FIELD
\n\n007_AGR_L2_ORCHARD
\n\n007_AGR_L7_FARM_ANIMALS_IN_FIELD
\n\n008_WTR_L3_DRY_RIVERBED
\n\n@CristianBalint,
\n\nTo answer your second question: you are correct that there are more information in geojsons, but these files are not counted because of labels weren't complete enough. They were removed from the competition, but we included them in the dataset in case anyone finds them useful.
\n\nFor the list of files that are actually used, go to the data page and find the filename_to_classType to map the file names to class types.
@shawn, @zerozero, @Davor, @Cristian,
\n\nThanks for reporting this. I think there may have been a bug in shapely when we tried to join the list of polygons into a multipolygon. I was using cascaded_union() and that may have caused some polygons being filled. Looking into it now.
For any interest, some snippets of code we used:
\n\ncoordslist = list(good_polygon.exterior.coords)\ngp.append(Polygon(coordslist))\n\nmergedpoly = cascaded_union(data_dict[(imageId, classType)])\n\nif isinstance(mergedpoly, Polygon):\n mp = MultiPolygon([mergedpoly])\nelif isinstance(mergedpoly, MultiPolygon):\n mp = MultiPolygon(mergedpoly)\n\ndatawriter.writerow([imageId, classType, mp.wkt]) \n[quote=Wendy Kan;151418]
\n\n@shawn, @zerozero, @Davor, @Cristian,
\n\nThanks for reporting this. I think there may have been a bug in shapely when we tried to join the list of polygons into a multipolygon. I was using cascaded_union() and that may have caused some polygons being filled. Looking into it now.
...quote removed...
\n\n[/quote]
\n\nThanks for looking into this Wendy!
", "rawMarkdown": "[quote=Wendy Kan;151418]\r\n\r\n@shawn, @zerozero, @Davor, @Cristian, \r\n\r\nThanks for reporting this. I think there may have been a bug in shapely when we tried to join the list of polygons into a multipolygon. I was using `cascaded_union()` and that may have caused some polygons being filled. Looking into it now. \r\n\r\n...quote removed...\r\n\r\n[/quote]\r\n\r\nThanks for looking into this Wendy!", "votes": null }, { "id": "151514", "postDate": "12/21/2016 04:37:14", "content": "Can confirm this issue. And this is probably not a Shapely-specific bug either, as I have observed the same problem when plotting class labels with GDAL/OGR. Most likely it is because the WKT data do not distinguish between \"rings\" and two overlapping polygons in some cases. This issue does not seem to happen with the GeoJSON data.
", "rawMarkdown": "Can confirm this issue. And this is probably not a Shapely-specific bug either, as I have observed the same problem when plotting class labels with GDAL/OGR. Most likely it is because the WKT data do not distinguish between \"rings\" and two overlapping polygons in some cases. This issue does not seem to happen with the GeoJSON data.", "votes": null }, { "id": "151548", "postDate": "12/21/2016 09:17:10", "content": "Hi!
\n\nI approached the problem differently. Because I will follow deep learning paradigm I need well, pixel based labels. I used shapely.wkt.loads descartes.patch.PolygonPatch, geojson.loads and geojson.utils.coords to read the wkt and geojson files. From OpenCV (2.7 i think) cv2.fillPoly() to print the polygons to a raster.
Test file, of course, 6120_2_2 and only 002_TR_L4_POOR_DIRT_CART_TRACK from geojson data.
\n\nI got the same pictures as @Mithrillion and the rest of us. I noted that in 6120_2_2/002_TR_L4_POOR_DIRT_CART_TRACK there are \"complex\" polygons (i.e. poly with holes). I don't know how to handle them, geojson.utils.coords() method returns all coordinates indiscriminately.
\n\nExcept doing it manual:
\n\nfor k in gs.features:\n if len(k.geometry.coordinates) > 1:\n store inner and outer perim # beats me how, except hard-accessing the object using k.geometry.coordinates[i]\n else \n store only outer perim\nFor wkt library is less work and more clearly documented API. list(poly.exterior.coords) and for pi in poly.interiors: \\ interior = list(pi.coords)
I think we should wait for Wendy Kan to clear the data and post the train_wkt_v4 file
\n\nMy 2 cents about this.
", "rawMarkdown": "Hi!\r\n\r\nI approached the problem differently. Because I will follow deep learning paradigm I need well, pixel based labels. I used ```shapely.wkt.loads``` ```descartes.patch.PolygonPatch```, ```geojson.loads``` and ```geojson.utils.coords``` to read the wkt and geojson files. From OpenCV (2.7 i think) ```cv2.fillPoly()``` to print the polygons to a raster.\r\n\r\nTest file, of course, 6120_2_2 and only 002_TR_L4_POOR_DIRT_CART_TRACK from geojson data. \r\n\r\nI got the same pictures as @Mithrillion and the rest of us. I noted that in 6120_2_2/002_TR_L4_POOR_DIRT_CART_TRACK there are \"complex\" polygons (i.e. poly with holes). I don't know how to handle them, geojson.utils.coords() method returns all coordinates indiscriminately. \r\n\r\nExcept doing it manual: \r\n\r\n for k in gs.features:\r\n if len(k.geometry.coordinates) > 1:\r\n store inner and outer perim # beats me how, except hard-accessing the object using k.geometry.coordinates[i]\r\n else \r\n store only outer perim\r\n\r\nFor wkt library is less work and more clearly documented API. ```list(poly.exterior.coords)``` and ```for pi in poly.interiors: \\ interior = list(pi.coords)```\r\n\r\nI think we should wait for Wendy Kan to clear the data and post the train_wkt_v4 file\r\n\r\nMy 2 cents about this.", "votes": null }, { "id": "151566", "postDate": "12/21/2016 10:26:16", "content": "[quote=Wendy Kan;151416]
\n\n@CristianBalint,
\n\nTo answer your second question: you are correct that there are more information in geojsons, but these files are not counted because of labels weren't complete enough. They were removed from the competition, but we included them in the dataset in case anyone finds them useful.
\n\nFor the list of files that are actually used, go to the data page and find the filename_to_classType to map the file names to class types.
[/quote]
\n\nThank You Wendy !
\n\n It is clear now. To reiterate, one can ignore these parent/class-less extra polygons present only in GEOJson data. Regarding first issue with the CVS/WKT polygons that won't render properly one can use GEOJsons until CVS/WKT will be cured and cleared.\nYes, the \"filename_to_classType\" is very useful for those who might go use GEOJsons (e.g myself). GEOJsons carry no explicit label ID, so need to lookup in the mentioned catalog.
", "rawMarkdown": "[quote=Wendy Kan;151416]\r\n\r\n@CristianBalint,\r\n\r\nTo answer your second question: you are correct that there are more information in geojsons, but these files are not counted because of labels weren't complete enough. They were removed from the competition, but we included them in the dataset in case anyone finds them useful. \r\n\r\nFor the list of files that are actually used, go to the data page and find the `filename_to_classType` to map the file names to class types. \r\n\r\n[/quote]\r\n\r\nThank You Wendy !\r\n\r\n It is clear now. To reiterate, one can ignore these parent/class-less extra polygons present only in GEOJson data. Regarding first issue with the CVS/WKT polygons that won't render properly one can use GEOJsons until CVS/WKT will be cured and cleared.\r\n\r\n Yes, the \"filename_to_classType\" is very useful for those who might go use GEOJsons (e.g myself). GEOJsons carry no explicit label ID, so need to lookup in the mentioned catalog.", "votes": null }, { "id": "151731", "postDate": "12/21/2016 23:27:58", "content": "[quote=zero zero;151420]
\n\nThanks for looking into this Wendy!
\n\n[/quote]
\n\nSome updates on my front: I think I have found the problem. It's probably in the use of polygon.exterior.coords. The geojsons have interior rings that should be accommodated. I will do a bit more testing on this, and if this fixes the problem, I'll update train_wkt_v4 as well as the solution file.
Thanks for your patience.
", "rawMarkdown": "[quote=zero zero;151420]\r\n\r\nThanks for looking into this Wendy!\r\n\r\n[/quote]\r\n\r\nSome updates on my front: I think I have found the problem. It's probably in the use of `polygon.exterior.coords`. The geojsons have interior rings that should be accommodated. I will do a bit more testing on this, and if this fixes the problem, I'll update train_wkt_v4 as well as the solution file. \r\n\r\nThanks for your patience.", "votes": null }, { "id": "151746", "postDate": "12/22/2016 00:46:30", "content": "train_wkt_v4.csv uploaded. It should fix the filled-holes problem.
P.S. the geojson files didn't change since they don't have this problem.
", "rawMarkdown": "`train_wkt_v4.csv` uploaded. It should fix the filled-holes problem. \r\n\r\nP.S. the geojson files didn't change since they don't have this problem.", "votes": null }, { "id": "151793", "postDate": "12/22/2016 04:47:04", "content": "thanks Wendy,
\n\n![\"v4](\"http://funvert.com/kaggle/v4.png\" "\\"\\"")
Using same method, the new WKT file now creates a much better looking raster.
", "rawMarkdown": "thanks Wendy,\r\n\r\n![v4 data][1]\r\n\r\n [1]: http://funvert.com/kaggle/v4.png\r\n\r\nUsing same method, the new WKT file now creates a much better looking raster.", "votes": null }, { "id": "152877", "postDate": "12/28/2016 22:17:15", "content": "Hi, \nIn the image 6110_4 there is a strange label for water. I think it's a mistake.
\n\n![\"enter](\"http://i.imgur.com/ioQ0G05.png\" "\\"\\"")
It's the lake in the middle.
", "rawMarkdown": "Hi, \r\nIn the image 6110_4 there is a strange label for water. I think it's a mistake.\r\n\r\n![enter image description here][1]\r\n\r\nIt's the lake in the middle.\r\n\r\n\r\n [1]: http://i.imgur.com/ioQ0G05.png", "votes": null } ], "comments": [ { "id": 151348, "author_name": "davorjosipovic", "author_url": "", "post_date": "12/20/2016 08:31:04", "content": "Many images have this issue with Class 4. See image 6120_2_0, 6100_1_3, 6110_4_0, 6110_1_2, 6140_1_2, etc... Some like 6100_1_3 and 6120_2_0 are quite bad (cf. attachment).
", "votes": null, "replies": [] }, { "id": 151349, "author_name": "visoft", "author_url": "", "post_date": "12/20/2016 08:40:28", "content": "Maybe is not a bug, is a feature. AND if the test data is labelled using the same principles as above, well, we should stick to their representation.
", "votes": null, "replies": [ { "id": 151353, "author_name": "davorjosipovic", "author_url": "", "post_date": "12/20/2016 09:03:19", "content": "@visoft, what is that feature/representation according to you? I can not give any meaning to it, other than some unknown glitch in polygon formation. Understanding the cause of the glitch might be helpful.
", "votes": null, "replies": [] } ] }, { "id": 151360, "author_name": "cbalint", "author_url": "", "post_date": "12/20/2016 09:50:25", "content": "Gentlemen,
\n\nSee attached image (seen by QGIS) for class #4, look at 6122-2-2:\n002_TR_L4_POOR_DIRT_CART_TRACK.geojson,\n002_TR_L6_FOOTPATH_TRAIL.geojson
Use gdal/ogr libs don't waste time with other non GIS land libraries. Clearly your approach for multi-polygon handling fails to properly interpret inner/outer rings that can form the collection.
Their images are fine. This is a difference between the geojson and wkt formats. Load train_wkt_v3.csv into qgis and you will see the large blob in the upper right of 6120_2_2 for Class 4. It does look like an error though since the geojson doesn't have it, and the area clearly isn't one giant track.
\n\nIf you look in this script there are a bunch of these for class 4. Definitely something that needs to be addressed. \nhttps://www.kaggle.com/randel/dstl-satellite-imagery-feature-detection/polygons-over-images/code
", "votes": null, "replies": [] }, { "id": 151378, "author_name": "cbalint", "author_url": "", "post_date": "12/20/2016 13:08:40", "content": "@shawn ,
\n\n(1) You are right regarding CSV vs. GEOJson ! GEOJson expose a correct geometry !
\n\n(2) Also, regarding CSV vs GEOJson I found that GEOJson have more polygons in some undocumented categories (see my collected list below).
\n\n@wendykan ,
\n\nTo whom report such discrepancy ?
\n\nGEOJson seems to be much complete, but then what to do with these undocumented classes ?
\n\n001_MM_L3_EXTRACTION_MINE
\n\n001_MM_L4_BRIDGE
\n\n003_VH_L4_AQUATIC_SMALL
\n\n004_UPI_L5_PYLONS
\n\n004_UPI_L6_SATELLITE_DISHES_DISH_AERIAL
\n\n005_VO_L6_MASTS_RADIO_TOWER
\n\n005_VO_L7_FLAGPOLE
\n\n006_VEG_L2_SCRUBLAND
\n\n007_AGR_L2_DEMARCATED_NON_CROP_FIELD
\n\n007_AGR_L2_ORCHARD
\n\n007_AGR_L7_FARM_ANIMALS_IN_FIELD
\n\n008_WTR_L3_DRY_RIVERBED
\n\n@CristianBalint,
\n\nTo answer your second question: you are correct that there are more information in geojsons, but these files are not counted because of labels weren't complete enough. They were removed from the competition, but we included them in the dataset in case anyone finds them useful.
\n\nFor the list of files that are actually used, go to the data page and find the filename_to_classType to map the file names to class types.
[quote=Wendy Kan;151416]
\n\n@CristianBalint,
\n\nTo answer your second question: you are correct that there are more information in geojsons, but these files are not counted because of labels weren't complete enough. They were removed from the competition, but we included them in the dataset in case anyone finds them useful.
\n\nFor the list of files that are actually used, go to the data page and find the filename_to_classType to map the file names to class types.
[/quote]
\n\nThank You Wendy !
\n\n It is clear now. To reiterate, one can ignore these parent/class-less extra polygons present only in GEOJson data. Regarding first issue with the CVS/WKT polygons that won't render properly one can use GEOJsons until CVS/WKT will be cured and cleared.\nYes, the \"filename_to_classType\" is very useful for those who might go use GEOJsons (e.g myself). GEOJsons carry no explicit label ID, so need to lookup in the mentioned catalog.
", "votes": null, "replies": [] } ] }, { "id": 151418, "author_name": "wendykan", "author_url": "", "post_date": "12/20/2016 17:55:57", "content": "@shawn, @zerozero, @Davor, @Cristian,
\n\nThanks for reporting this. I think there may have been a bug in shapely when we tried to join the list of polygons into a multipolygon. I was using cascaded_union() and that may have caused some polygons being filled. Looking into it now.
For any interest, some snippets of code we used:
\n\ncoordslist = list(good_polygon.exterior.coords)\ngp.append(Polygon(coordslist))\n\nmergedpoly = cascaded_union(data_dict[(imageId, classType)])\n\nif isinstance(mergedpoly, Polygon):\n mp = MultiPolygon([mergedpoly])\nelif isinstance(mergedpoly, MultiPolygon):\n mp = MultiPolygon(mergedpoly)\n\ndatawriter.writerow([imageId, classType, mp.wkt]) \n[quote=Wendy Kan;151418]
\n\n@shawn, @zerozero, @Davor, @Cristian,
\n\nThanks for reporting this. I think there may have been a bug in shapely when we tried to join the list of polygons into a multipolygon. I was using cascaded_union() and that may have caused some polygons being filled. Looking into it now.
...quote removed...
\n\n[/quote]
\n\nThanks for looking into this Wendy!
", "votes": null, "replies": [ { "id": 151731, "author_name": "wendykan", "author_url": "", "post_date": "12/21/2016 23:27:58", "content": "[quote=zero zero;151420]
\n\nThanks for looking into this Wendy!
\n\n[/quote]
\n\nSome updates on my front: I think I have found the problem. It's probably in the use of polygon.exterior.coords. The geojsons have interior rings that should be accommodated. I will do a bit more testing on this, and if this fixes the problem, I'll update train_wkt_v4 as well as the solution file.
Thanks for your patience.
", "votes": null, "replies": [] } ] } ] }, { "id": 151514, "author_name": "mithrillion", "author_url": "", "post_date": "12/21/2016 04:37:14", "content": "Can confirm this issue. And this is probably not a Shapely-specific bug either, as I have observed the same problem when plotting class labels with GDAL/OGR. Most likely it is because the WKT data do not distinguish between \"rings\" and two overlapping polygons in some cases. This issue does not seem to happen with the GeoJSON data.
", "votes": null, "replies": [] }, { "id": 151548, "author_name": "visoft", "author_url": "", "post_date": "12/21/2016 09:17:10", "content": "Hi!
\n\nI approached the problem differently. Because I will follow deep learning paradigm I need well, pixel based labels. I used shapely.wkt.loads descartes.patch.PolygonPatch, geojson.loads and geojson.utils.coords to read the wkt and geojson files. From OpenCV (2.7 i think) cv2.fillPoly() to print the polygons to a raster.
Test file, of course, 6120_2_2 and only 002_TR_L4_POOR_DIRT_CART_TRACK from geojson data.
\n\nI got the same pictures as @Mithrillion and the rest of us. I noted that in 6120_2_2/002_TR_L4_POOR_DIRT_CART_TRACK there are \"complex\" polygons (i.e. poly with holes). I don't know how to handle them, geojson.utils.coords() method returns all coordinates indiscriminately.
\n\nExcept doing it manual:
\n\nfor k in gs.features:\n if len(k.geometry.coordinates) > 1:\n store inner and outer perim # beats me how, except hard-accessing the object using k.geometry.coordinates[i]\n else \n store only outer perim\nFor wkt library is less work and more clearly documented API. list(poly.exterior.coords) and for pi in poly.interiors: \\ interior = list(pi.coords)
I think we should wait for Wendy Kan to clear the data and post the train_wkt_v4 file
\n\nMy 2 cents about this.
", "votes": null, "replies": [] }, { "id": 151746, "author_name": "wendykan", "author_url": "", "post_date": "12/22/2016 00:46:30", "content": "train_wkt_v4.csv uploaded. It should fix the filled-holes problem.
P.S. the geojson files didn't change since they don't have this problem.
", "votes": null, "replies": [] }, { "id": 151793, "author_name": "zerozero", "author_url": "", "post_date": "12/22/2016 04:47:04", "content": "thanks Wendy,
\n\n
Using same method, the new WKT file now creates a much better looking raster.
", "votes": null, "replies": [] }, { "id": 152877, "author_name": "ironbar", "author_url": "", "post_date": "12/28/2016 22:17:15", "content": "Hi, \nIn the image 6110_4 there is a strange label for water. I think it's a mistake.
\n\n
It's the lake in the middle.
", "votes": null, "replies": [] } ], "raw_markdown_by_id": { "151236": "Hello, after finding an anomaly for a label I thought I'd start a thread where we could post image ids + pic + class where we think there is an issue. I know having some bad labels is something that we need to account for so I'm not expecting that the admins re-publish the data but *we* can deal with it as a group. I have not gone through every image (so it's possible that there are not many errors).\r\n\r\nOne possible way to deal with it is to come up with a list of hole polygons and/or extra polygons to add to the dataset. If it's out in the open, perhaps everyone can use it. (?) Training pixel/patch based classifiers could be affected by these types of errors...this is why I'm concerned.\r\n\r\nJeffh https://www.kaggle.com/jeffhebert/dstl-satellite-imagery-feature-detection/the-many-faces-of-6120-2-2 and Gabriel Altay https://www.kaggle.com/gabrielaltay/dstl-satellite-imagery-feature-detection/polygons-over-images-and-5x5-mosaics/comments#151216 and myself found an issue with:\r\n\r\n\r\nimage-id: 6120_2_2 \r\n\r\nclass: 4\r\n\r\nissue: looks like a portion is filled in when there should be a couple of holes\r\n\r\n\r\nI would suggest looking at the other thread's images as they're prettier than mine. The large white rectangle in middle-right top is the culprit.\r\n\r\nhere's my version nonetheless:\r\n![raster mask of 6120_2_2 class 4][1]\r\n\r\n [1]: http://funvert.com/kaggle/class4_6129_2_2.png", "151348": "Many images have this issue with Class 4. See image 6120_2_0, 6100_1_3, 6110_4_0, 6110_1_2, 6140_1_2, etc... Some like 6100_1_3 and 6120_2_0 are quite bad (cf. attachment).", "151349": "Maybe is not a bug, is a feature. AND if the test data is labelled using the same principles as above, well, we should stick to their representation.", "151353": "visoft, what is that feature/representation according to you? I can not give any meaning to it, other than some unknown glitch in polygon formation. Understanding the cause of the glitch might be helpful.", "151360": "Gentlemen,\r\n\r\n* Regarding 6122-2-2 tile, I can confirm that data is OK for label #4.\r\n* See attached image (seen by QGIS) for class #4, look at 6122-2-2:\r\n002_TR_L4_POOR_DIRT_CART_TRACK.geojson,\r\n002_TR_L6_FOOTPATH_TRAIL.geojson\r\n\r\n- Use gdal/ogr libs don't waste time with other non GIS land libraries. Clearly your approach for multi-polygon handling fails to properly interpret inner/outer rings that can form the collection.", "151374": "Their images are fine. This is a difference between the geojson and wkt formats. Load train_wkt_v3.csv into qgis and you will see the large blob in the upper right of 6120_2_2 for Class 4. It does look like an error though since the geojson doesn't have it, and the area clearly isn't one giant track. \r\n\r\nIf you look in this script there are a bunch of these for class 4. Definitely something that needs to be addressed. \r\nhttps://www.kaggle.com/randel/dstl-satellite-imagery-feature-detection/polygons-over-images/code", "151378": "shawn ,\r\n\r\n(1) You are right regarding CSV vs. GEOJson ! GEOJson expose a correct geometry !\r\n\r\n(2) Also, regarding CSV vs GEOJson I found that GEOJson have more polygons in some undocumented categories (see my collected list below).\r\n\r\n@wendykan ,\r\n \r\nTo whom report such discrepancy ? \r\n\r\n GEOJson seems to be much complete, but then what to do with these undocumented classes ?\r\n\r\n------------\r\n\r\n 001_MM_L3_EXTRACTION_MINE\r\n\r\n 001_MM_L4_BRIDGE\r\n\r\n 003_VH_L4_AQUATIC_SMALL\r\n\r\n 004_UPI_L5_PYLONS\r\n\r\n 004_UPI_L6_SATELLITE_DISHES_DISH_AERIAL\r\n\r\n 005_VO_L6_MASTS_RADIO_TOWER\r\n\r\n 005_VO_L7_FLAGPOLE\r\n\r\n 006_VEG_L2_SCRUBLAND\r\n\r\n 007_AGR_L2_DEMARCATED_NON_CROP_FIELD\r\n\r\n 007_AGR_L2_ORCHARD\r\n\r\n 007_AGR_L7_FARM_ANIMALS_IN_FIELD\r\n\r\n 008_WTR_L3_DRY_RIVERBED\r\n\r\n--------------------", "151416": "CristianBalint,\r\n\r\nTo answer your second question: you are correct that there are more information in geojsons, but these files are not counted because of labels weren't complete enough. They were removed from the competition, but we included them in the dataset in case anyone finds them useful. \r\n\r\nFor the list of files that are actually used, go to the data page and find the `filename_to_classType` to map the file names to class types.", "151418": "shawn, @zerozero, @Davor, @Cristian, \r\n\r\nThanks for reporting this. I think there may have been a bug in shapely when we tried to join the list of polygons into a multipolygon. I was using `cascaded_union()` and that may have caused some polygons being filled. Looking into it now. \r\n\r\nFor any interest, some snippets of code we used:\r\n\r\n coordslist = list(good_polygon.exterior.coords)\r\n gp.append(Polygon(coordslist))\r\n \r\n mergedpoly = cascaded_union(data_dict[(imageId, classType)])\r\n \r\n if isinstance(mergedpoly, Polygon):\r\n mp = MultiPolygon([mergedpoly])\r\n elif isinstance(mergedpoly, MultiPolygon):\r\n mp = MultiPolygon(mergedpoly)\r\n\r\n datawriter.writerow([imageId, classType, mp.wkt])", "151420": "[quote=Wendy Kan;151418]\r\n\r\n@shawn, @zerozero, @Davor, @Cristian, \r\n\r\nThanks for reporting this. I think there may have been a bug in shapely when we tried to join the list of polygons into a multipolygon. I was using `cascaded_union()` and that may have caused some polygons being filled. Looking into it now. \r\n\r\n...quote removed...\r\n\r\n[/quote]\r\n\r\nThanks for looking into this Wendy!", "151514": "Can confirm this issue. And this is probably not a Shapely-specific bug either, as I have observed the same problem when plotting class labels with GDAL/OGR. Most likely it is because the WKT data do not distinguish between \"rings\" and two overlapping polygons in some cases. This issue does not seem to happen with the GeoJSON data.", "151548": "Hi!\r\n\r\nI approached the problem differently. Because I will follow deep learning paradigm I need well, pixel based labels. I used ```shapely.wkt.loads``` ```descartes.patch.PolygonPatch```, ```geojson.loads``` and ```geojson.utils.coords``` to read the wkt and geojson files. From OpenCV (2.7 i think) ```cv2.fillPoly()``` to print the polygons to a raster.\r\n\r\nTest file, of course, 6120_2_2 and only 002_TR_L4_POOR_DIRT_CART_TRACK from geojson data. \r\n\r\nI got the same pictures as @Mithrillion and the rest of us. I noted that in 6120_2_2/002_TR_L4_POOR_DIRT_CART_TRACK there are \"complex\" polygons (i.e. poly with holes). I don't know how to handle them, geojson.utils.coords() method returns all coordinates indiscriminately. \r\n\r\nExcept doing it manual: \r\n\r\n for k in gs.features:\r\n if len(k.geometry.coordinates) > 1:\r\n store inner and outer perim # beats me how, except hard-accessing the object using k.geometry.coordinates[i]\r\n else \r\n store only outer perim\r\n\r\nFor wkt library is less work and more clearly documented API. ```list(poly.exterior.coords)``` and ```for pi in poly.interiors: \\ interior = list(pi.coords)```\r\n\r\nI think we should wait for Wendy Kan to clear the data and post the train_wkt_v4 file\r\n\r\nMy 2 cents about this.", "151566": "[quote=Wendy Kan;151416]\r\n\r\n@CristianBalint,\r\n\r\nTo answer your second question: you are correct that there are more information in geojsons, but these files are not counted because of labels weren't complete enough. They were removed from the competition, but we included them in the dataset in case anyone finds them useful. \r\n\r\nFor the list of files that are actually used, go to the data page and find the `filename_to_classType` to map the file names to class types. \r\n\r\n[/quote]\r\n\r\nThank You Wendy !\r\n\r\n It is clear now. To reiterate, one can ignore these parent/class-less extra polygons present only in GEOJson data. Regarding first issue with the CVS/WKT polygons that won't render properly one can use GEOJsons until CVS/WKT will be cured and cleared.\r\n\r\n Yes, the \"filename_to_classType\" is very useful for those who might go use GEOJsons (e.g myself). GEOJsons carry no explicit label ID, so need to lookup in the mentioned catalog.", "151731": "[quote=zero zero;151420]\r\n\r\nThanks for looking into this Wendy!\r\n\r\n[/quote]\r\n\r\nSome updates on my front: I think I have found the problem. It's probably in the use of `polygon.exterior.coords`. The geojsons have interior rings that should be accommodated. I will do a bit more testing on this, and if this fixes the problem, I'll update train_wkt_v4 as well as the solution file. \r\n\r\nThanks for your patience.", "151746": "`train_wkt_v4.csv` uploaded. It should fix the filled-holes problem. \r\n\r\nP.S. the geojson files didn't change since they don't have this problem.", "151793": "thanks Wendy,\r\n\r\n![v4 data][1]\r\n\r\n [1]: http://funvert.com/kaggle/v4.png\r\n\r\nUsing same method, the new WKT file now creates a much better looking raster.", "152877": "Hi, \r\nIn the image 6110_4 there is a strange label for water. I think it's a mistake.\r\n\r\n![enter image description here][1]\r\n\r\nIt's the lake in the middle.\r\n\r\n\r\n [1]: http://i.imgur.com/ioQ0G05.png" }, "source": "meta" }