I've been trying to defend railway since we built our initial prototype there and I wanted to avoid the cost of migrating to some "serious infra" until proven needed, but they have been making their defense a really hard job (without mentioning that their overall reliability has been really bad the past weeks)

Comments URL: https://news.ycombinator.com/item?id=46324180

Points: 7

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=43673079

Points: 6

# Comments: 1

From that code, we have built and just released a small library called `any-agent`.

Comments URL: https://news.ycombinator.com/item?id=43622705

Points: 1

# Comments: 0

Hi there, I agree that is a valuable usage of a model trained with OSM data.

I didn't have the time to release the code but I am/was doing exactly that to refine the training dataset. I take the trained model and run it against the ground truth from OSM. Any heavy mismatch between the two almost always result in an useful edit to be made in OSM.

Hi there! There is no SAM2 finetuning involved in the project. The segmentation data from OSM doesn't have enough quality to properly train a segmentation model from it.

What I am using here is a YOLO model for bounding box prediction. The bounding boxes from OSM are good enough for this. I then pass the each individual bounding box as a "prompt" to SAM2 for a segmentation of what is inside.

I also tried to pass the centroid of the box as a "prompt" for SAM but it gave worse results.

I have published a new release where any code to directly upload to OSM has been replaced with an export to OsmChange format.

I hope this is a step in the right direction, I will continue the discussion on the dedicated thread in the OSM forum.

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.

Hi, I didn't know about this possibility. I should have better researched what were the different options. I will be taking a look on implementing this approach.

This is just not true. The data can be easily identified with the `created_by` tag. And I have been reviewing myself any data uploaded with the demo (with a clear different criteria on what is good enough)

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.

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`. 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.

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.

Hi, I am the author.

The demo app and any provided code example includes a step asking a human to verify the detected features. You can't upload them automatically unless you modify the source code.

I reiterate the human verification across the docs, linked post, and any code samples.

I haven't ever uploaded features automatically. In fact I manually edited and labeled hundreds of swimming pool samples myself before even training the first version.

Happy to hear and implement any ideas on how to improve the process to prevent automated features to be uploaded.

I know some people might say: just don't publish the tool, I think we can do better at embracing AI and having an open discussion.

Ola!

I am the author of the repo, worked in satellite projects for the Galician goverment some years ago.

You don't need an account to download the data from OSM (you do need to contribute back, which makes sense IMO). You don't need an account to download tiles from some publicly available sources (i.e. https://pnoa.ign.es/ in Spain) but I prefer to made the code work with MapBox and let them pay the infra (until they stop free offering). Happy to share a simple snippet to use a different tile provider.

Any public dataset (that I am aware) is not really meant to be frequently updated, at best you get a second version release a year later. A lot of public money (I know because have been payed a small portion of these budgets) is spent on building datasets that are used for a couple of research papers, uploaded to the web and then become outdated.

If I want to help updating them or correcting label mistakes, in most (all?) cases, there is no practical way for me to do it.

I believe that OpenStreetMap has the potential to be the best publicly available spatial "dataset" for (some specific) CV use cases.

If we focus on creating ways to contribute with quality data (the idea behind this small project), it will just keep getting a better dataset, that anyone can contribute to be up-to-date.