[HN Gopher] Map Features in OpenStreetMap with Computer Vision
___________________________________________________________________
Map Features in OpenStreetMap with Computer Vision
Author : Brysonbw
Score : 148 points
Date : 2025-03-22 17:42 UTC (5 hours ago)
(HTM) web link (blog.mozilla.ai)
(TXT) w3m dump (blog.mozilla.ai)
| ks2048 wrote:
| I did some work in this field, although years ago. There is a
| huge amount of existing models, datasets, tools, etc.
|
| https://github.com/satellite-image-deep-learning
| nativeit wrote:
| This is an amazing set of resources, thanks for sharing. I have
| been tinkering with QGIS, and signed up for a slew of
| public/private satellite imagery APIs to bring in data to play
| with. The EU's space agency has a lot of really good data
| sources with fully open access (no user accounts necessary). I
| am looking forward to working with this new collection of ML-
| specific tools.
| daavoo wrote:
| > really good data sources with fully open access (no user
| accounts necessary)
|
| 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.
| stereo wrote:
| Hi from the OpenStreetMap Foundation. Please don't add AI-
| detected features directly to the database.
|
| The algorithms have problems with false positives, and with
| mapping straight or rectangular objects as wobbly, as shown in
| the second-to-last screenshot.
|
| As a helper to detect missing features, this is a precious tool.
| But we still need human intervention to make sure the detected
| objects are drawn correctly.
|
| See also: https://wiki.openstreetmap.org/wiki/Import/Guidelines
| and
| https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_...
| daavoo wrote:
| > But we still need human intervention to make sure the
| detected objects are drawn correctly.
|
| 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.
| halosghost wrote:
| I am afraid your "human in the loop" isn't [0].
|
| You acknowledge the problem of AI slop up-front, but seem to
| have chosen to plow forward anyway. Please do consider your
| actions and their effects carefully [1]. You are in a
| position of potential influence; try not to squander it.
|
| All the best,
|
| -HG
|
| [0]: https://pluralistic.net/2024/10/30/a-neck-in-a-noose/
|
| [1]: https://web.cs.ucdavis.edu/~rogaway/papers/radical.pdf
| Vinnl wrote:
| "plow forward" and implying they didn't consider their
| actions and their effects seem ungenerous, given the list
| of precautions in the comment you're replying to.
|
| You can disagree on whether the measures are effective, of
| course, but they're clearly not thoughtless.
| benatkin wrote:
| It was the equivalent of vibe coding:
|
| > 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.
|
| https://news.ycombinator.com/item?id=43448498
| necovek wrote:
| I believe your critique would be more valuable if you've
| actually uncovered cases where the human in the loop missed
| these issues and bad or "wobbly" data ended up in the OSM
| database: did this happen? (the other comment from another
| person confirms it has)
|
| Otherwise, you are discounting their effort based on a
| prejudice -- others might be unable to supervise an AI, but
| someone who's actually developed it might have a better
| chance of success.
| yorwba wrote:
| The screenshot in the article shows wobbly data. You may
| need to zoom in and look closely to notice.
| hgomersall wrote:
| Tracing satellite data is really boring to do but easy to
| check. I would describe AI acting as a centaur here, or
| perhaps a pairing of equals.
| yorwba wrote:
| > Happy to hear and implement any ideas on how to improve the
| process to prevent automated features to be uploaded.
|
| Idea: do not automatically create features that a human can
| simply approve, instead require them to draw the polygon
| themselves.
| IshKebab wrote:
| That kind of defeats the point surely?
| echoangle wrote:
| Well it can still detect features in the satellite image
| that are missing on the map. That would already be a
| large help, no?
| daavoo wrote:
| That is what I will implement before bringing back the demo
| https://news.ycombinator.com/item?id=43448649
| K2h wrote:
| long time editor of osm here. what you describe is what the
| rapid [1] editor from meta does where user is forced to
| manually select objects overlayed sat imagery. is limited
| to 50 objects before user must push. a great method i think
|
| [1] https://rapideditor.org/
| boredpudding wrote:
| I don't understand the 'human verification' aspect.
|
| Your docs show a simple image where the user can choose to
| keep a new object or not. [0] Afterwards it says: "The ones
| you chose to keep will be uploaded to OpenStreetMap using
| upload_osm.". This is uploading features automatically. The
| fact that it asks 'are you sure' is just silly. We all know
| if humans have to click yes 90% of the time, and no 10% of
| the time, they'll miss a lot of no's.
|
| The image also proofs that:
|
| - You don't see any polygons properly. You just see a an
| image of where the pool is. Already on the image I can see
| that if the polygons align to that image, it will be a total
| mess.
|
| - You don't see any polygons further away from the object.
|
| Both these points are in stereo's reply that the resulted
| data was a mess.
|
| Please consider pulling the project. This will generate a lot
| of data that volunteers will have to check and revert.
|
| [0] https://github.com/mozilla-ai/osm-ai-
| helper/blob/main/docs/s...
| daavoo wrote:
| > This will generate a lot of data that volunteers will
| have to check and revert.
|
| 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)
| daavoo wrote:
| > 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 wrote:
| Hi! 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 wrote:
| Can you link the (now reverted) changesets? I can't seem to
| find them.
| stereo wrote:
| https://www.openstreetmap.org/changeset/163855992 and
| https://www.openstreetmap.org/changeset/163863954 are the
| ones I've reverted. There are more in daavoo's changeset
| history.
| daavoo wrote:
| Hi, 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`. 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 wrote:
| > 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/
| Aachen wrote:
| 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 wrote:
| 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.
| orbital-decay wrote:
| Experiencing automated mapping first-hand makes me extremely wary
| of it. I've travelled across South America on a motorcycle, and
| OSM has a large amount of edits there that look automated
| (particularly in Brazil), making it barely usable in certain
| places. I'm not even talking about rural roads but also fairly
| large cities.
| pastage wrote:
| Armchair mapping will always result in bad maps. I usually try
| to use mapwithme and leave photo notes describing issues when I
| travel, I take photos of fences and play grounds, other people
| take scenic pictures.
|
| So it might very well be automatic mapping, just saying that I
| know my armchair mapping can be pretty bad when I gonand check
| it OTG.
| Aachen wrote:
| By bad, do you mean incomplete or that it's often actually
| wrong? Because my experience is that it's very complementary
| and I see things on aerial that I didn't irl and of course
| also vice versa. Mapping from the air seems to work well to
| me
|
| North Korea should be an interesting example, I guess we have
| no chance of anyone commenting on it but there's people
| who've been mapping it from actual satellite imagery, so very
| poor quality compared to the airplane-based georeferenced
| photographs we're used to in most countries. If armchair
| mapping makes bad maps, that will be the best example to have
| someone check out, but alas. (The visitor-accessible parts
| may not count as much because a mapper could have visited
| those)
| pierotofy wrote:
| Worked on something similar a few months ago (albeit for smaller
| scale geographic data): https://github.com/uav4geo/GeoDeep
| qwertox wrote:
| Google would not allow this, but Mapbox seems to be OK with this,
| if it is used for non-commercial purposes or OSM, and only if
| their satellite data is used (not their vector data):
| 1.6. No Tracing, Deriving, or Extracting. Customer shall not
| trace or otherwise derive or extract content, data
| and/or information from the Service Offerings except that
| Customer may use Studio or third-party software to
| trace Mapbox Maps solely comprised of satellite imagery to
| produce derivative vector datasets (i) for non-
| commercial purposes or (ii) for OpenStreetMap.
|
| Kind of nice from them.
| mtmail wrote:
| Bing also allows OpenStreetMap mappers to use their aerial
| imagery for tracing.
| https://wiki.openstreetmap.org/wiki/Bing_Maps#Aerial_imagery
| ecommerceguy wrote:
| We used to call this heads up digitizing.
___________________________________________________________________
(page generated 2025-03-22 23:00 UTC)