9 ms·

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

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/step-by-step-guide.md#step-4-review-filter-and-upload-the-new-polygons-to-openstreetmap https://github.com/mozilla-ai/osm-ai-helper/blob/main/docs/s...

daavoo 1y ago
> 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)
- karlgkk 1y ago
  adding a "created_by" tag is not opt in. it's opt out. you are de facto choosing how OSM volunteers must approach their work, without their consent.
- deleted 1y ago
  [deleted]
- banana_dick_2 1y ago
  [dead]
- AyyEye 1y ago
  Can I suggest also adding a tag for ML originated features that's not specific to your demo/app? Maybe this can help put extra eyes on them and/or help prevent them from polluting the DB wholesale. Maybe client apps could have a toggle to allow/reject them.
- xorcist 1y ago
  If the upstream project thinks there may be a potential problem with this, that is a problem in itself. Try not to get defensive about it, just pull the project and have another go at the problem in collaboration with upstream. Perhaps parts of the project and be useful for upstream? Perhaps another workflow could make the project better? We all strive for better open data. I upstream feel there is a risk that automated uploads could be easier with this project, creating more boring work for them which is already enough of a problem, that animosity will be a net negative for everyone in this space. Technical solutions such as new tags or opt out schemes will not solve the problem.
  - hartator 1y ago
    Mozilla engineers think they are way better than the rest of us though. Don’t need to follow the same rules.
  - frozenseven 1y ago
    [flagged]
    - crooked-v 1y ago
      The "good reason" is that OSM is supposed to contain real data, not wobbly AI guesswork data.
      - frozenseven 1y ago
        [flagged]
        wiml 1y ago
        That's not an assertion I'm going to take seriously without evidence.
        frozenseven 1y ago
        [flagged]

daavoo 1y ago

> 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)

karlgkk 1y ago
adding a "created_by" tag is not opt in. it's opt out. you are de facto choosing how OSM volunteers must approach their work, without their consent.
deleted 1y ago
[deleted]
banana_dick_2 1y ago
[dead]
AyyEye 1y ago
Can I suggest also adding a tag for ML originated features that's not specific to your demo/app? Maybe this can help put extra eyes on them and/or help prevent them from polluting the DB wholesale. Maybe client apps could have a toggle to allow/reject them.
xorcist 1y ago
If the upstream project thinks there may be a potential problem with this, that is a problem in itself. Try not to get defensive about it, just pull the project and have another go at the problem in collaboration with upstream. Perhaps parts of the project and be useful for upstream? Perhaps another workflow could make the project better? We all strive for better open data. I upstream feel there is a risk that automated uploads could be easier with this project, creating more boring work for them which is already enough of a problem, that animosity will be a net negative for everyone in this space. Technical solutions such as new tags or opt out schemes will not solve the problem.
- hartator 1y ago
  Mozilla engineers think they are way better than the rest of us though. Don’t need to follow the same rules.
- frozenseven 1y ago
  [flagged]
  - crooked-v 1y ago
    The "good reason" is that OSM is supposed to contain real data, not wobbly AI guesswork data.
    - frozenseven 1y ago
      [flagged]
      - wiml 1y ago
        That's not an assertion I'm going to take seriously without evidence.
        frozenseven 1y ago
        [flagged]