[Imports] Manual import of 1,701 Madrid pharmacies

Wed Aug 6 01:34:38 UTC 2014

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Jason. Thanks for sharing. My comments inline:

On 05/08/14 01:16, Jason Remillard wrote:
> Hi,
> 
> This is the best I can do with the online translation to
> English...

The import wiki page is in English, and as I explained in my last
email, there isn't nothing in the workflow wiki (Spanish) that isn't
in the import wiki, except some screenshots.

> 
> - The source,  source:date tags on the node is not needed since it
> is in the change-set.

This has been discussed several times for other imports, like the
UNICEF health facilities, schools and water points for Central African
Rep., or several eHealth Africa imports in Nigeria. The outcome of the
discussion is that source:date can be dropped, but source is nice to
keep it for some and not needed for some others. So it is kept.

In the CAR import they put the following reason, that I agree upon:
"it is useful to let the source tag for each object as the changeset
information is not forcefully got from any OSM extract tool and UNICEF
could be disappointed not to be mentioned for this data + the metadata
can disappear easily once the information is shared and shared, and
the source can be a very useful information for people who will work
with this data."

About the pharmacies, the Madrid City Council puts almost no
constraints, except that they have to be attributed. Although they
would be attributed with the changeset tag, they will much better
having the source tag in the nodes. And this is not a big deal, as
they are only 1701 nodes. So my proposal is: keeping the source tag in
the nodes and changeset tags, and keep the source:date in the
changeset tag only.

> 
> - The process of replacing the existing nodes with the new nodes
> is not ideal. The new data should be merged in with the old node so
> the history is not lost.

OK. I agree. I will change the workflow accordingly. I think in fact
that it will get more simple, as everything will be done with the
import account, instead of the two steps of the current one (one with
the import account and the second with the regular OSM account).

> 
> - The process should talk about messaging the authors of the OSM
> data to sort out what data to keep if it is not otherwise clear.
> Just taking the new data over the existing OSM data is going to
> get everybody grumpy.

Well. That's why I assessed all the current data in the OSM database,
to see all tags present in all nodes, and proposing what to do with
the tags of the old nodes, tag by tag. The proposal is very respectful
with the existing data. Do you find any tag deletion or modification
unrespectful with the data already in the OSM database?

> 
> - The process should be prepared for duplicates pharmacies that are
> on ways, not just nodes.

All pharmacies for the area that can are a duplicate of the nodes to
be imported are on nodes only as of today. No existing pharmacy is on
any way or relation ( http://overpass-turbo.eu/s/4t0 ). In fact, there
was one in a way, but not a duplicate of any of the 1,701 new nodes.
Moreover, it was duplicated itself, with a way and a node few meters
to the East. I just merged them, leaving the way as building and the
pharmacy as node: http://www.openstreetmap.org/changeset/24566970

Regards,

Rafael.

> 
> Thanks Jason
> 
> On Sun, Aug 3, 2014 at 5:39 PM, Rafael Avila Coya
> <ravilacoya at gmail.com> wrote: Hi all:
> 
> The Madrid city council is releasing some of their data as open
> data. One of the datasets is a list of 1,807 pharmacies, of which
> 1,701 are geolocalized.
> 
> The purpose of this import [1] is to process that data to produce
> 34 osm files with 50 nodes each (the last one with 51), so the
> interested mappers can import manually those pharmacies, following
> a detailed workflow [2], one file at a time, and therefore adapting
> the import to their own time availability.
> 
> After finishing a task, they will have to write it down in a wiki
> [3], commenting any issues.
> 
> The import was submitted for comments in the talk-es mailing list.
> The only issue mentioned was about dropping the addr:city and 
> addr:province tags, in which I also agree.
> 
> The workflow wiki is a translation into Spanish of the Workflow 
> section in the Import wiki, plus some screenshots.
> 
> In the progress section, I put an example to make more clear how
> to proceed with the import.
> 
> All scripts are ready, and can easily be tweaked to adapt to any 
> tagging modifications that we may agree upon.
> 
> Key points to focus on are tagging and merging with existing OSM 
> pharmacies in the area.
> 
> You can download the resulting file in CSV and OSM formats here:
> [4]
> 
> I wait for your comments.
> 
> Cheers and have a nice week,
> 
> Rafael Ávila Coya (edvac).
> 
> [1] https://wiki.openstreetmap.org/wiki/Madrid_Pharmacies_Import
> 
> [2]
> http://wiki.openstreetmap.org/wiki/Madrid_Pharmacies_Import_Workflow
>
>  [3]
> https://wiki.openstreetmap.org/wiki/Madrid_Pharmacies_Import_Progress
>
>  [4] http://ge.tt/1na4njp1
> 
>> 
>> _______________________________________________ Imports mailing
>> list Imports at openstreetmap.org 
>> https://lists.openstreetmap.org/listinfo/imports

- -- 
Twitter: http://twitter.com/ravilacoya

- --------------------------------

Por favor, non me envíe documentos con extensións .doc, .docx, .xls,
.xlsx, .ppt, .pptx, aínda podendoo facer,  non os abro.

Atendendo á lexislación vixente, empregue formatos estándares e abertos.

http://es.wikipedia.org/wiki/OpenDocument#Tipos_de_ficheros
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQIcBAEBAgAGBQJT4YYdAAoJEB3niTly2pPQargP/i5O/fMka+hg1xizqcUmsq8k
YS4J4Id9/VkNeZj1bJsTZrzmnsPZgxyk6MUdxWI8W6PFX/QZHBS3jgeDJReXkyK1
+T+tTkhwxGb8bvlodoCOUvRiOX2j8ZaBwid5PxC0Ys/iinud5KjBttMyr/tVJcyL
u1c9Dg/rae5yFoo8B/ImdAvJbOXO61HrZKb0AcOTBm/gekM5PSpSatVBbM6nV7V1
pFMkO5+h1tVX8knBhpQCC9/l3dkcx2dHvh1ymU79MuAZcIcwR6KeNGF2IcznkiKM
1MWFcAVZXejFWgHDLGSlYLrFT/MB8z4wgxwm8e0WoGpK/1gtlruKRE9mz7JCZaBE
KIXZp92yuBxW5C5Kk5w+ZmCECNRsTAEfIIEjkOvPmnPv+vEnNpBsPcWsOwdHN8DS
kANeY66Z85y9Jo08EUce1JW6L/tmhCtt4hOsV5G35n8bN7mGPj7Iv3UPACKVlkwu
XfRASUvIDZDSJ6xZeIS3xcV4tH4D/ECCALQGnjONLf44+aOKXjyB7tLZoG0fKcPR
z/LynLqKPOiApNXLmfbwp9GExAxttBB906+rSMdOHbQYXGeGNcyW63xUP0y3mLjW
Co9H2JEc/dKIX+q0/LeW01fAQAhzQjbdzzmBe4t8jq36VbnpHN71waekDUVGF9IG
z1p1N1m+jwy6IHid+gmA
=B5nL
-----END PGP SIGNATURE-----