User talk:Claire Halleux

From OpenStreetMap Wiki
Jump to navigation Jump to search

Age span 2015-01-01..2019-11-05

Dear Claire,

please explain, which benefit the generic age span 2015-01-01..2019-11-05 poses.

Kind regards, Mineki (talk) 21:54, 20 October 2020 (UTC)


Dear Mineki,
When comparing the import data with the current Bing imagery (which is often from 2014 in the area) or with paid imagery from January 2020 (which an organization obtained for a part of Ituri), the age span can be helpful. It was aimed to be generally indicative while the more detailed information is stored at the object level. However, since your message there have been exchanges with contributors from both the DRC and Uganda about this and there is an agreement on adapting the age span interval to the actual data included in the edited task. The instructions have been adapted accordingly. -- Claire Halleux 23:58, 26 October 2020 (UTC)

Continuing large scale damage to the map in UG and DRC due to the Eastern_DRC_/_Western_Uganda_Maxar-Ecopia_Buildings_Import project

Dear Claire,

Despite multiple efforts to communicate and improve the tagging and mapping practices in the related projects, activities and damage to existing data is increasing and escalating. Please provide justifications and solutions for the following issues:

  1. The project description doesn't provide a link to the source imagery, license or waiver. The data neither the license is verifiable by other OSM community members. We can't verify if their are any licensing issues or incompatibilities with the ODbL ({https://www.openstreetmap.org/copyright}) or the "MAXAR and Ecopia.AI have given permission" and internal documentation you refer to. As you state it concerns a data license, possibly non-compatible (see {https://wiki.openstreetmap.org/wiki/Category:Licenses_compatible_for_OSM_data_imports}) for compatible licenses for imports), the license or waiver should be files and published on the OSM wiki and publicly available to the OSM community. Please be aware that failure to do,justification and consensus by the community might result in License violation and take down of all the contributions.
  2. The import describes that ONLY BUILDINGS are imported. However, over the past months I have noticed multiple deletions, some large scale instead of the importing and merging procedure you described. Any deletions are dis-respectful without at least notification and feedback from the previous editors, exceptions aside for clearly proven incorrect mapping. However, I have seen no action to communicate with the editors, which might be international or local, after the initial attempts on the talk pages of the UG and DRC communities.
  3. ONLY BUILDINGS: I noticed multiple (by the hundreds) changes to existing roads. I am not talking about incorrect tagging but changes in alignment, positions, additions, deletions. This without any additional description in the changesets of these "non announced" actions.
  4. ONLY BUILDINGS: Recently major issues are arising about deletions and changes to administrative boundaries. The international border between the DRC and UG has gotten displaced by 30m at the Toligamago point ({https://www.openstreetmap.org/#map=18/3.48162/30.85900}). The border suppose to run along a road, which by the way also has been shifted. The problem seems to arise from 4 subsequent imports, starting from an edit in project 5823 (correction in tagging), subsequent 3 edits in project 8886 (its identified like this in the changeset however cannot find it in HOT Tasking Manager). If this would have been noticed before, through validation (none of the tasks are validated) f.i. we could have reverted it. However, another import in 10416 , a revert by you on another changeset (103340738), and another 2 imports of HOTOSM without even mentioning the project number has taken it beyond of possible reverting. This caused misalignment with detailed land-use in the area, buildings shifting countries, roads ending up on the opposite side of the border ! Another issue was the deletion of the Kiryandongo (ID 3497965 ) district in UG, which was discussed on the OSM Africa channel. Fortunately I could track this back and was reverted by User icon 3.svgShamillah (on osm, edits, contrib, heatmap, chngset com.), and shown that it was another import by a user not experienced with relations.
  5. Recently you started adding boundary=health relations. This tag is not documented, I've seen a largely incomplete proposal made by you in 2016 which was never presented to the community, nor is there any consensus from the community. Other non documented or mentioned project specific tags. As far as I am concerned it concerns boundaries which are not verifiable, neither by ground truth or a reference to an authoritative organism (you mention DSNIS) without URL. Besides the violation of the community guidelines it might also be a license violation.
  6. Recently in the UG Isingiro TC, Isingiro district, I reverted major edits and deletions made on buildings, especially on 3D buildings, of which we have multiple in the project area, but 3D tagging also seems to be unknown to the contributors. Leading again to blunt deletions, overlapping buildings without any communication with the community. This is again a deletion problem of in-experienced users.
  7. Imagery offsets: Existing map item offsets are generally disregarded by the contributors. Large portions of the map are shifted on a "HOT task" basis, in many cases causing major issues outside the borders of the tasks. Long time existing GPS data available on OSM like OSM uploaded GPS tracks, Mapillary, OpenStreetCam (=Kartaview) Strava and Public Domain licensed Government data are disregarded. I did my best in UG to improve on this issue by online sessions with project managers and providing calibration points in the Imagery Offset Database, however I do not see improvements, in the contrary large portions of the map get displaced and damaged.
  8. No replies on changeset comments. They are numerous, yet no one of the contributors answers the comments. It's like the OSM community outside HOT is completely disregarded, local procedures and communication channels are not respected. In the mean time we see MILLIONS of changes ongoing and continuing by the same contributors.
  9. Lagging validation: validation in HOT is lagging for months, if it will ever happen on this large amount of data. These delays cause actions by non HOT members trying to resolve issues and thus making large scale reverts difficult without loss of data or stop them from mapping in the affected project area since their contributions get deleted anyway by yet another import. Multiple subsequent imports happen on the same areas.
  10. Insufficient and non-compliant changeset comments and tagging. The standard comments added to these large changesets are largely meaningless to the community. This was already mentioned by Andy from the DWG and referenced to the Good Changeset comments guideline. On top of that, even after the project is running for almost 10 months now, multiple changesets have no project number references at all, for example: some of the ones mentioned in the boundary issue. Others have incorrect and non-existent source URL's (different from the one source you list), no date references as stated in your project description... f.i. #10076.

Looking forward to your solutions and kind request to temporarily hold all your project activities. The changes and issues are in the millions and no longer manageable. @SomeoneElse Bert Araali (talk) 01:39, 18 May 2021 (UTC)