[OSM-talk] Identical Duplicate buildings

[Joseph Eisenberg]

I have certainly seen problems like this with JOSM when attempting to
upload changes via an unreliable internet connection (in a remote part of
Indonesia). I've also had issues with uploads via iD when the upload
connection quality was poor.

Perhaps there is a way to add a quality control check to make sure that
identical nodes have not already been uploaded? Unfortunately this can also
be difficult when the internet connection is slow or unreliable.

-- Joseph Eisenberg

On Thu, Jan 28, 2021 at 2:17 PM Pierre Béland via talk <
talk at openstreetmap.org> wrote:

> Hi Stephan,
>
> good news that you can manage to fix this in the iD editor. Discussion
> about quality did not focus on the Editor tools.
>
> OSMCha let observe changesets content. It did show more general quality
> problems then the duplicates. Discussion about the quality was  about the
> impact to promote Mapathons with insufficient support to groups and
> individuals and the necessity to develop Monitoring tools that let identify
> deficiencies and organize to correct them.
>
> Pierre
>
>
> Le jeudi 28 janvier 2021 16 h 44 min 23 s UTC−5, Stephan Knauss <
> osm at stephans-server.de> a écrit :
>
>
> On 28.01.2021 00:24, john whelan wrote:
> > The thing that mystifies me is where the second buildings are coming
> > from.  Once iD has put them up to the database then they should no
> > longer be tagged as uploadable unless it is something really stupid like
> > close iD down before it confirms the edits have been uploaded.  On that
> > case iD will think they still need to go and next time it does an upload
> > it will upload them again.
>
> I think we spotted a bug in iD here. I recently fixed a lower two-digit
> number of duplicates which fit well into this pattern.
> All duplicate the exact same geometry that the same user had uploaded a
> bit earlier. Just upload message did differ and on second upload
> additional objects had been touched.
>
> Maybe some hickup during upload tricks iD into thinking they hadn't been
> uploaded yet.
>
> I would generally agree that HOT edits are quite frequently of not so
> great quality, but this time it seems to more of an editor problem than
> HOT process.
>
> Stephan
> _______________________________________________
> talk mailing list
> talk at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20210128/2b9603e1/attachment-0001.htm>