5 ms·
> straight or rectangular objects as wobbly, as shown in the second-to-last screenshot. This is a because the polygon is drawn as a mask in order to overlay it
by daavoo 1y ago
> straight or rectangular objects as wobbly, as shown in the second-to-last screenshot.
This is a because the polygon is drawn as a mask in order to overlay it on the image. The actual polygon being uploaded doesn't have the wobbly features.
It is True there are cases were the predicted polygon is wobbly and I encourage people to discard them. However I didn't publish this demo until I got a first version of the model that reached some minimum quality.
There is logic in the code to simplify the shape of the predicted polygon in order to avoid having too many nodes.
- stereo 1y agoHi! The Data Working Group had a look at the data, and decided to revert the two pool changesets. The polygons the algorithm had drawn were consistently of poor quality with stray nodes and nodes far outside the pool boundaries, and the imports hadn't been discussed with local communities.
- boredpudding 1y agoCan you link the (now reverted) changesets? I can't seem to find them.
- stereo 1y agohttps://www.openstreetmap.org/changeset/163855992 https://www.openstreetmap.org/changeset/163855992 and https://www.openstreetmap.org/changeset/163863954 https://www.openstreetmap.org/changeset/163863954 are the ones I've reverted. There are more in daavoo's changeset history.
- daavoo 1y agoHi, thanks for the feedback. I have disabled the hosted demo for now, and will remove the uploading part from the code in favor of showing an URL that will open the editor at the location. If its of any help, you can find any contributed polygon with the tag `created_by=https://github.com/mozilla-ai/osm-ai-helper https://github.com/mozilla-ai/osm-ai-helper`. Feel free to remove all of them (or I can do it myself once I access a PC). I will be happy to continue the discussion on what is a good prediction or not. I have mapped a lot of swimming pools myself and edited and removed a lot of (presumably) human contributed polygons that looked worse (too my eyes) than the predictions I approved to be uploaded.
- lmc 1y ago> I will be happy to continue the discussion on what is a good prediction or not. I have mapped a lot of swimming pools myself and edited and removed a lot of (presumably) human contributed polygons that looked worse (too my eyes) than the predictions I approved to be uploaded. Something else you need to be mindful of is that the mapbox imagery may be out of date, especially for the super zoomed in stuff (which comes from aerial flights). So e.g., a pool built 2 years ago might not show up. https://docs.mapbox.com/help/dive-deeper/imagery/ https://docs.mapbox.com/help/dive-deeper/imagery/
- banana_dick_3 1y ago[dead]
- joshvm 1y agoThis is a general problem when trying to compare OSM data with aerial imagery. I've worked a lot with orthos from Open Aerial Map, whose stated goal is to provide high quality imagery that's licensed for mapping. If you try and take OSM labels from the bounding boxes of those images and use them for segmentation labels, they're often misaligned or not detailed enough. In theory those images ought to have the best corresponding data, but OAM allows people to upload open imagery generally and not all of it is mapped. I've spent a lot of time building models for tree mapping. In theory you could use that as a pipeline with OAM to generate forest regions for OSM and it would probably be better than human labels which tend to be very coarse. I wouldn't discount AI labeling entirely, but it does need oversight and you probably want a high confidence threshold. One other thought is you could compare overlap between predicted polygons and human polygons and use that as a prompt to review for refinement. This would be helpful for things like individual buildings which tend to not be mapped particularly well (i.e. tight to the structure), but a modern segmentation model can probably provide very tight polygons.
- stereo 1y agoHi, thanks for replying! I was looking at your source code, and wondering how easy it would be to create a .osm file instead of uploading the data. The JOSM editor’s todo list plugin would make it easy to plough through all the polygons or centroids, and do any refinement necessary. For example, I’m curious to try this out to detect crosswalks, and those need to be glued to the highway being crossed.
- Aachen 1y agoI tried this out like a week ago and I was wondering the same so I tried to upload and... it's definitely uploading crap. I don't know what to tell you but all the clearly square ones I saw have bends on the straight lines It's useful for finding ones that haven't been mapped but not for drawing them. It can get the 4 corners pretty accurate for pools that are square, many are half round at the ends though
- daavoo 1y agoHi, sorry if the project or narrative gave the wrong impression but my idea was to show the potential, not providing a polished solution. As disclaimed in the demo and code, the example model was trained only with data from Galicia on a Google Colab. A robust enough models would require more data and compute. > it's definitely uploading crap. What was uploaded was what a human approved. > It's useful for finding ones that haven't been mapped but not for drawing them. It can get the 4 corners pretty accurate for pools that are square, many are half round at the ends though I couldn't dedicate enough time on the best way to refine the predictions, but happy to hear and discuss any ideas. Ideas I have are: - Try an oriented bounding box model instead of detection + segmentation. It will not be useful for not square shapes but will definitely generate more accurate predictions. - Build some sort of https://es.wikipedia.org/wiki/RANSAC https://es.wikipedia.org/wiki/RANSAC that tries to fits rectangles and/or other shapes as an step to postprocess the predicted mask.
- Aachen 1y ago> What was uploaded was what a human approved. Yes, I hit approve on the best one because I was curious to see the actual final polygon. (I then went and fixed it.) You wrote above / I was responding to: >> This is a because the polygon is drawn as a mask in order to overlay it on the image. The actual polygon being uploaded doesn't have the wobbly features. Now you're saying it's my fault for selecting a wonky outline. What's it gonna be, is the preview bad or the resulting polygons? (And the reviewer is bad for approving anything at all?) > my idea was to show the potential, not providing a polished solution I can appreciate that, but if you're aware of this then it shouldn't have a button that unauthenticated users can press to upload the result to the production database. OSM has testing infrastructure if you want to also demo that part (https://master.apis.dev.openstreetmap.org/ https://master.apis.dev.openstreetmap.org/ is a version I found on https://wiki.openstreetmap.org/wiki/API_v0.6 https://wiki.openstreetmap.org/wiki/API_v0.6)
- banana_dick_1 1y ago[flagged]