OpenStreetMap

CartONG and RefugeeSiteMappingDataGlobalStandardization

Posted by Øukasz on 24 July 2020 in English (English)

Below is a description of two interactions I recently had with CartONG.

Tagging schema

Late last year I noticed that the place=refugee_camp tag that was unknown to me was used on hundreds of OSM elements. Failing to find any documentation for it, I left a comment on one of the changesets that introduced the tag. The changeset author requested that I contact CartONG’s Missing Maps project (which I thought was a HOT initiative, but no matter) by email, which I did. I received a response from the Project Coordinator who kindly explained the thinking behind the tagging and that a tag proposal is in the works. A few months of discussions and two tag proposals later (first of which seemed to raise a concern about rallying last-minute votes from “colleagues and friends”), we all arrived at an approved tag.

I thought that it would have been best to first launch a proposal and have the tag approved, rather than tag features in OSM and then try to push through a proposal that conforms to the de facto tag usage, but that’s just my opinion. We are all working towards the same goal, and in the end I congratulate CartONG and Missing Maps on the result.

Data imports

Fast forward two months, yesterday I came across what looks to me like an import of non-cleaned UNHCR refugee camp data into OSM done by CartONG in two parts (1, 2), both of which had already attracted comments on their quality, and one of which had been reverted. The revert seems to have been preceded by direct communication that ended without satisfactory explanations from CartONG. I have contacted the user who reverted the changeset to see if the second changeset raises similar concerns, and they have promptly reverted that one as well.

As best as I can tell, these imports were not documented or discussed beforehand, and thus do not follow the Import Guidelines. In my opinion an effort could be also done to improve compliance with the Organised Editing Guidelines, though I am grateful for the #RefugeeSiteMappingDataGlobalStandardization hashtag, which is the one way I have of finding all the related edits. Following the hashtag through OSMCha, I found a few further edits that seem, to me, questionable. In particular, existing valid tags (like landuse=residential) are occasionally removed. This, in my opinion, looks like CartONG through this effort cares only about the refugee camp tags, sometimes (infrequently) doing damage to other valid data.

Overall the process looks to me as if the idea was to have a non-cleaned UNHCR database dump imported into OSM, and then take the time to go through the imported features one-by-one and check them, effectively turning OSM into a data cleaning platform. In my opinion the cleaning should be done first, and only then data should be uploaded to OSM. As a side effect to this approach, the import changesets can now be queried to get email addresses of a dozen or so UN employees, which I imagine was not intentional.

Conculsion

I think CartONG is doing some very useful and needed work, however these two examples of their use of OSM show potential for better communication. I request CartONG to be more transparent about their intentions and processes in advance, conduct discussions through community channels rather than private emails, and to follow the Import and Organised Editing Guidelines. I’m sure the issues of the second example will be resolved just as in the first one, and I look forward to having documented, standardised, and well-tagged humanitarian data in OSM.

Comment from Léonie Miège on 29 July 2020 at 12:56

Dear Ouskasz,

Léonie, the new Missing Maps coordinator at CartONG, replacing Manon during her maternity leave. We have read the post you published on July, 24th with attention.

First of all, we want to thank you for reverting the problematic changeset and for noticing the involuntary import of UNHCR refugee camp data into OSM. It was a mistake from one of our volunteers, this data should not have been imported in OSM in the first place, in fact we are not planning any import at all linked to this process. Our volunteer imported by mistake data that was supposed to help the contribution but not end up in OSM (more details below).

After the tag amenity=refugee_site has been approved by the community, we started this summer a process of data cleaning meaning replacing the temporary tag (place=refugee/IDP_camp/settlement) by the new tag (amenity=refugee_site). We are coordinating this work between CartONG staff and volunteers (the matrix is not public because it requires specific briefing to edit it according to the proper format and avoid messing up the coordination).

By the way, I totally share you opinion that the order of things should have been : tag proposal > tag approved > identifying the sites with the approved tag. We didn’t fully master the process when we started it hence the use of the temporary tag we are now replacing.

Over the course of the data cleaning, e.g. replacing the temporary tag by the new one, 2 things you noticed happened : • The removal of valid tags (mostly landuse=residential): we hadn’t discussed the issue before launching the volunteer task. To us, if the camp was clearly identifiable and mapped, there was no need to keep the landuse tag on the polygon. We thought both tags (amenity=refugee_site and landuse=residential) were not compatible. Therefore the volunteer were instructed to keep only two tags in this instance: amenity=refugee_site as well as name=. For your information, the landuse tag was not removed in instances where the camp boundaries were not clearly identifiable, in such cases, the tag amenity=refugee_site has been applied on a node alongside with the tag name= and the tag landuse=residential kept. You noticed it, told us and one of my colleagues replied to you and we instructed the volunteers to keep both the valid tags. We will of course put the erased ones back into OSM.

• Concerning the “import” that was reverted and that contained improper information: it was a mistake from one of our volunteers. Our volunteers were given a layer with the locations of the camps and settlements as well as other information that are not to be imported in OSM. They are supposed to use it ONLY if the nominatim system doesn’t work to locate the sites. The layer was given to help them do the data cleaning, not to be imported in the OSM database. This was stated in the instructions but probably not strongly enough. So there was in fact no import documentation since no data was supposed to be imported in the first place (just “traditional” manual mapping). Once again, you noticed it, thanks for taking the time. We then told our volunteers to be extra careful with that layer and reviewed our documentation. I’ll also give them a cleaned layer with minimum info (just the nodes locating the sites with the names) to work with instead of the old one with all that UNHCR database, to reduce the risk of errors. Finally, the data is already available on UNHCR-curated public database so there is not risk on their privacy here.

Regarding the communications aspect, we are well aware this can be improved, it is linked with multiple factors, such as dissemination and one could even argue disorganization of OSM communication channels (for instance we didn’t instruct our volunteers specifically to watch their OSM messages), working with volunteers that don’t have all the same awareness of open communities, new projects we are building on the go with multiple stakeholders, etc. The key improvement we want to build over the coming months is being compliant with the overall Organized Editing policy, we are very aware we are late on this, but various reasons (including movements in the team, competing priorities, not to mention the Covid19 impact…) have slowed us in implementation. It remains however a high priority and would help other contributors get a better overview of our activities. That being said, we are always welcoming feedback and trying to improve. Promoting open data and participation is among CartONG’s core value and it is good the community takes us accountable on it. We would in fact like to use the opportunity we gained on this project to improve the global documentation on the various process we’ve been confronted that are not always crystal clear to newcomers – if our resources allow us to have time to do it!

Best regards,

Léonie for the CartONG Missing Maps team

Comment from Øukasz on 1 August 2020 at 20:12

Thank you Leonie for taking the time for this detailed explanation, it is very appreciated.

Indeed, as you say, I would recommend Organized Editing policy compliance, as it would likely address both the issues I’ve noticed, as well as at least some of your internal challenges.

Thanks for all your work, and looking forward to seeing more results of camp/site mapping in OSM.

Comment from Jean-Marc Liotier on 2 August 2020 at 15:00

Do not believe that dirty data once imported will ever be cleaned. The UNICEF Mali education import has school positions all so approximate that all they are useful for is to hint that a school exists in the vicinity of that village - not useless but it is has no place in Openstreetmap. And the names are in fucking uppercase. It has been six years since this horror. https://wiki.openstreetmap.org/wiki/Import_MALI_UNICEF_Education

Comment from Léonie Miège on 3 August 2020 at 09:45

Hi @Jean-Marc Liotier,

If the imported data has the same changeset comments, a revert is doable, it’s what’s been done in our case thanks by Oukasz who noticed it in the first place. For the UNICEF import, I’m afraid that it’s not too old to revert it without damaging even more the datase. Despite we’ve worked with UNICEF on completely different contexts, we don’t have more information than you on this particular import: I suppose you tried to contact the person who did the important back then?

We are sorry if some organizations (same as individual contributors in fact) mess up from time to time. At CartONG, are trying to improve by working to be more compliant with the overall Organized Editing policy and by welcoming feedback and constructive criticism (like the diary post written by Oukasz) in order to improve our processes in terms of communication and documentation, and we encourage other humanitarian (and others) organizations to do the same!

Best regards,

Léonie for the CartONG Missing Maps team

Comment from Jean-Marc Liotier on 3 August 2020 at 12:42

My apologies for not specifying that CartONG has of course nothing to do with the UNICEF Mali education import.

Comment from Øukasz on 4 August 2020 at 08:13

@Léonie Miège

On your point:

Finally, the data is already available on UNHCR-curated public database so there is not risk on their privacy here.

Could you please point me to the specific database and layer you are referring to here?

Many thanks in advance

Comment from Léonie Miège on 10 August 2020 at 06:51

Hello @Øukasz,

Sorry for the delay, I was referring to that db : https://hub.arcgis.com/datasets/aa22618c72ef47148401e3518307c19f_0

Best,

Léonie for the CartONG Missing Maps team

Comment from Øukasz on 14 August 2020 at 08:22

Thank you for the link Leonie, most helpful.

Can you please say if there’s a plan to fix the temporary place=refugee_camp tags? There are still hundreds of them in OSM, and literally the first one I checked today is an example of actual damage done to the valid tagging system by replacing place=village with place=refugee_camp.

Regards

Comment from Léonie Miège on 7 September 2020 at 08:12

Hi Øukasz,

Yes we are currently having volunteer updating the “temporary” tag to the approved tag. It’s taking some time though and we are a little bit delayed since it was the holidays and our volunteers were less available during that time. We’ll make sure that what’s been erased (mostly the tag place=*) wiil be back where it was valid.

Best regards,

Léonie

Login to leave a comment