[Imports] [HOT] MSF data shred to OSM

Sat Aug 7 11:42:37 UTC 2021

Hi Roxana,

Maybe an alternative solution is to change the workflows and get the mission
approvals earlier in the process. Then ‘non sensitive data’ could be
determined in advance and collected immediately in apps that support direct
to OSM capabilities. Depending on what you are collecting, using the right
apps could get this to many devices quickly (depending on devices, apps and
connectivity issues). Where an app cant be used then maybe field staff
adding notes that are actively actioned in OSM by the GIS folks back at some
other base could be a solution. Personally I find a desktop, over a handheld
field device, much more efficient for adding anything other than POI’s.

Bulk data could be collected by alternate means (as you are doing now) and
if later its decided to add them to OSM you can go through the normal import
process, however there is no quick path – it’s a set process that has been
worked out by the community over many years. It’s a process that ensures
quality future data for MSF as well.

Cheers - Phil

From: Roxana NAZARIE <Roxana.NAZARIE at geneva.msf.org> 
Sent: Friday, 6 August 2021 9:49 PM
To: imports at openstreetmap.org
Cc: hot at openstreetmap.org
Subject: [HOT] MSF data shred to OSM

Dear all,

I’m writing to you concerning the best way for MSF and for OSM community to
share MSF data to OSM.

As MSF is a high consumer of volunteered geographic information as well as
GIS data shared on different humanitarian platforms, we’ve been working
lately on defining an internal Data Sharing Policy for what we call
“non-sensitive geospatial data”, so that at our turn we share the data we
collect/produce with the geospatial community. The “non-sensitive geospatial
data” refers to Populated places, Roads, Buildings with no classification,
Bridges, Water surfaces and Water points. Eventhough a dataset coming from a
field mission might be considered at a first sight a “non-sensitive
geospatial data”, before sharing it to OSM we need to have the local mission
approval – which is  an .xls file that we keep internally. 

Last year we had a rush request from the field to upload to OSM a dataset
with buildings extracted from imagery (by one of our units), so that the GIS
Officer in the field could see them as background in OsmAnd, and thus ease
the data collection in the field in the context of a Mosquito indoor
spraying campaign - instead of having to manually upload the dataset on each
mobile device. In the end the project was cancelled in the field, but we
wanted to pursue with the data sharing, and we launched an import process.
We realized soon that passing through all the steps of an import (especially
the Community buy-in, Wiki page and the Import review) is a time consuming
process, and it doesn’t prove at all to be as operational as we would need
in a rush context. 

Our conclusion was that for us it would be more straightforward to share
data as an edit process, with the help of advanced editors.

The approach we would like to have is:

*	Have the mission approval for the datasets we want to share
*	Check the data we want to share against the existing OSM data
*	Do the necessary geometry corrections
*	Convert the GIS attributes to osm tags
*	Generate the .osm files
*	Add them in JOSM > edit accordingly > Push the data to OSM (using
individual accounts, and source data as “MSF”, or using an MSF account)

This process can take 2-3 days max, instead of an import process which might
take at least 1-2 weeks. 

We have now on-pending to share data for Nigeria, Madagascar and Sudan. It
would be very helpful to define the best way to do it so that the process is
clear and straightforward for everyone involved. 

Many thanks for your advice,

Roxana

Roxana Nazarie

GIS Data Manager | GIS Centre

Médecins Sans Frontières

Email:  <mailto:roxana.nazarie at geneva.msf.org> roxana.nazarie at geneva.msf.org
| Web:  <https://geo.msf.org/home> https://geo.msf.org/home 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/imports/attachments/20210807/ecc30268/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 17340 bytes
Desc: not available
URL: <http://lists.openstreetmap.org/pipermail/imports/attachments/20210807/ecc30268/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 12658 bytes
Desc: not available
URL: <http://lists.openstreetmap.org/pipermail/imports/attachments/20210807/ecc30268/attachment-0003.png>