[Imports] Manual import of 1,701 Madrid pharmacies

Rafael Avila Coya ravilacoya at gmail.com
Wed Aug 6 01:34:38 UTC 2014

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



> 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.

Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/


More information about the Imports mailing list