[Imports] Adding pcodes to villages in Liberia, Sierra Leone and Guinea

Thu Sep 25 02:07:32 UTC 2014

Ah! I see.
Cheers,
Rafael
El 25/09/2014 09:46, "Andrew Buck" <andrew.r.buck at gmail.com> escribió:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I don't think the unmil id in that file is actually a pcode, I think
> that is just their own internal identifier in the database.  I was
> told that pcodes hadn't yet been generated for the place names for
> these countries so that is what I am going on.
>
> It is possible that this is a case of miscommunication within the
> organizations we are working with but I am not sure.  In any case the
> new pcodes that are being generated are what are being used by these
> orgs now, so having both tags on the same objects will then allow them
> to map the old unmil id onto the new pcode system if that is what they
> decide to have happen.
>
> - -AndrewBuck
>
>
> On 09/24/2014 08:41 PM, Rafael Avila Coya wrote:
> > Hi Andrew: As I see, this pcodes seem the same as the unmil:id we
> > are adding to the nodes of the ongoing  Liberia UNMIL place nodes
> > import. Wouldn't it be then a good idea to change the unmil:id=*
> > tag to pcode=* tag? Cheers, Rafael. El 25/09/2014 01:56, "Andrew
> > Buck" <andrew.r.buck at gmail.com> escribió:
> >
> > Hello everyone.  As you are probably aware HOT has been working to
> > map the areas affected by Ebola in west Africa and to help
> > humanitarian organizations better use OSM data in their efforts
> > there.  Because OSM has the best dataset of settlements (towns,
> > villages, etc) in the area several prominent groups have chosen to
> > standardize on OSM being their official source for place names and
> > locations.
> >
> > Due to the issue that many place names in Africa (and elsewhere)
> > have many different spellings (due to the local languages not using
> > latin alphabets) it is common for these organizations to establish
> > a standardized set of place codes (pcodes for short) which are used
> > to refer to places in datasets and communications.  The pcodes
> > work similarly to zip codes in the US or postal codes more
> > generally elsewhere in the world.  The list of pcodes is generally
> > held by the UN and is used by almost every large humanitarian
> > organization to communicate place information as the numerical
> > codes prevent confusion due to multiple places with the same name,
> > etc (just like postal codes are used).
> >
> > For the three countries in question, no pcodes had yet been
> > generated so it was decided that the way they would be created was
> > that the OSM dataset would be exported, a unique pcode generated
> > for each village in the dataset, and then that would be adopted by
> > these organizations as the official pcode for that location.  This
> > was done over the past week and we now have the results in a csv
> > file with columns containing the OSM id of the place, the version
> > of the place at export, lat/lon, and then all of the associated
> > name tags and finally a column for pcode which was filled in by the
> > people generating them.
> >
> > Since these newly generated pcodes are now the official pcodes for
> > these places, we plan to import them back into OSM onto each place
> > in the pcode=* tag.  This allows the dataset to be much more easily
> > used in the future, as well as allowing us to re-export and
> > generate pcodes for newly added villages that do not already have
> > them (since OSM is always growing).  The exact format of pcodes
> > varies from country to country due to the specifics of the
> > countries involved.  In some countries the pcode is chosen to be
> > identical to the already existing postal codes.  For these specific
> > countries since there was no existing system the codes are
> > formatted using the three letter country code, a 2 digit number
> > indicating the significance of the place, and then a running 5
> > digit number counting up from 1 to identify the specific place
> > name, so for example the code for the capital of Liberia, Monrovia,
> > has the code LBR0400001.
> >
> > Since the codes are newly generated and used OSM as the source of
> > their creation, the import would be very easy to do, and there is
> > zero risk of the data being "wrong" (it was generated exactly this
> > way, so it is by definition correct at this point).  Also, there is
> > no issue of licensing to be concerned about as the data in the file
> > is OSM data to begin with, with the exception of the pcode, and we
> > have explicit permission to use that as that was exactly the plan
> > to begin with.
> >
> > Given that we have both the id/version pair in the dataset, as well
> > as the lat/lon there are a couple ways the re-import of the pcodes
> > could be accomplished.  The easiest would be to use josm and the
> > conflation plugin, with a very small match distance (like 5 meters
> > or something) and then just manually conflate the handful of nodes
> > that may have moved in the last week.  The other possibility (which
> > is more robust) is to write a simple script that adds the tags to
> > the objects based on the id/version pair and then generates a list
> > that must be manually processed for any objects which have a newer
> > version than that at the time of export.  I think either method
> > will work, but I do think the script is a bit more robust, and we
> > already have someone interested in working on the script to make it
> > happen.
> >
> > Let me know if you forsee any potential problems with either of
> > these two methods and how you think they could be addressed.
> >>
> >> _______________________________________________ Imports mailing
> >> list Imports at openstreetmap.org
> >> https://lists.openstreetmap.org/listinfo/imports
> >>
> >
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
>
> iQIcBAEBAgAGBQJUI3PnAAoJEK7RwIfxHSXbzE4P/2uZufQ+WgE6pjBMCwvSUQ5W
> bfBpyQ+6uKDcBrHQqcoP+0q2R6NW3MQrv9d32XlFWESTmvX4nlpf1J4GCim/Jndf
> 1NdkYsFDJMxN6c6Z5B54m+OZXlF2nFMnS923KJ3MeU1ezgSsf7UhDKkq1cBYIBXV
> FF14b7iFV6JYVyQwMHY61HceqIHTZp6KihVxdSh0TjmVKnJKzxLu/3rgnS3jfP5C
> jw6cn4OcXbVPNPEH/cluv/kbH0F0xDgayFBoYGy61BqEYrUrHrZNgSuYNb+dWy54
> 154zCG5k5RKAsSOF3gGP/c8RUSfSkQ6LEbAnD0AiV721Ul0XNA5jIGvAzyDH8IEw
> moaxdIacq/kFo1xcjJFLRqQlrDkYSwoVyYuCMIazUJNcM8weWKAu/TR6mTPD13ae
> +ontkA4FY8d/jz8tRq7yAdkvVsI8jHRIJzYA7VR1AwAm/H+XrezEZQltFOhAloY2
> BCqbwzhAj+qhWx5MVW6XsiTXYUgtnt1Tuf6LYQHKMnG5A67vjelT87DjGB/5EjwR
> PCBw9OcxbFs1Hu5ibdc2OLhsFN/c4ZaooE7MjoPH6VaGiJspqWwev3dk9ir1opDI
> +osVWI11uZpt0WUVqSjxek5YD03uXsyW4yJ35xBwoHZBdoP3g7nZT2Jxd3tRJdBB
> ahztnSme7wvb6fbfKTLf
> =ijcs
> -----END PGP SIGNATURE-----
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/imports/attachments/20140925/9b81b431/attachment-0001.html>