[Aachen]

I 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]

Hi, 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 that tries to fits rectangles and/or other shapes as an step to postprocess the predicted mask.

[Aachen]

> 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/ is a version I found on https://wiki.openstreetmap.org/wiki/API_v0.6)

[daavoo]

> You wrote above / I was responding to:

I apologize. I read `it's uploading` and misunderstood like you were saying the tool itself was uploading things.

> is the preview bad or the resulting polygons? (And the reviewer is bad for approving anything at all?)

It can be one, the other, or both.

I was replying to a reference about a specific example in the blog post.

In that example, I see wobbly features due to rendering alongside the edges that make it look like the polygon is going to have dozens of nodes. Then, there is an over-simplification of the polygon around the top-right corner (which I didn't consider an error based on my criteria from reviewing manually created pools).

> And the reviewer is bad for approving anything at all?

I didn't say that. I was trying to assert that the UI/X can be improved to better show what will be uploaded.

> 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

You are right. I was manually reviewing the profile created for the demo every day, but I didn't realize the impact/reach until I saw the first comments here. As soon as I read the first comment, I shut down the demo.

As I said in other comments, I will make alternative changes to the demo.

> if you want to also demo that part (https://master.apis.dev.openstreetmap.org/ is a version I found on https://wiki.openstreetmap.org/wiki/API_v0.6)

Thanks for the suggestion, I don't know why I didn't thought about that earlier.