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

Thu Sep 25 01:41:20 UTC 2014

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ó:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> 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.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
>
> iQIcBAEBAgAGBQJUIwU9AAoJEK7RwIfxHSXbauUP/0kB8puz0iO/szIJMwjPZU8S
> 8+H1nJnOd7pMmBprWA0od8UDvPLfrjkxboR5OBVzI2oxGRR2SgKFCHUtnrU6NA8B
> snpbdJiVHgPPUJHs4YRUjlhQtGoonaQ+ETX1Tmf1ZoLSo7QDPKfI6zqUu/HNZRId
> N2toTpYTKodW27wOGg77CVS4l/xYErIF47hO1nYD9H30Cg/yWftyv0lMUps/M8rz
> ex8lEZ+60Gzx9TGlEerSH5lIOE/9K7ZfrkNMJNyvBoOMBp8oaeAcC+2l+qDqqO+o
> yAJcz4AUgwhfVcr9E4/ZE7vBbnJIORzcKwpwQyqkYuyd5Zm3KD4E51C97EACbIo8
> Q/kOaPHE2LbW3uBLqkCgI7XC2t93DaLP8ejFSScwLbA/Mq5uBMj5h7FndijlpQfL
> LCbSziv/T7B/p8q60haMWxeL/hQfwsiSJRYmLh05qhCLPQUNNqdX8bWjEwZzCfJC
> GFKVtSQGfWipcp93FsnkEhW0o5jMHNWVeSI3VcrQ7AU/fI27jW/Ivag7RVI4iWoZ
> Gkk5a5B1/GLYhFYutAFLcdFhQ6632d5cI/iN48VKanQ8hm9FUZJOnQgQvRU7p3Pc
> zdsNjXUHJkuJzmTN02L8kjXIMjUiZJDxCkQLTNY30QW81FXbc6KDkI0HnnekwV4+
> m8Nv59MV1PrzQXuG/oNJ
> =Qet7
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Imports mailing list
> Imports at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/imports
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/imports/attachments/20140925/f44401da/attachment.html>