<p dir="ltr">Hi Andrew:<br>
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. <br>
Wouldn't it be then a good idea to change the unmil:id=* tag to pcode=* tag?<br>
Cheers,<br>
Rafael.</p>
<div class="gmail_quote">El 25/09/2014 01:56, "Andrew Buck" <<a href="mailto:andrew.r.buck@gmail.com">andrew.r.buck@gmail.com</a>> escribió:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<br>
Hello everyone.  As you are probably aware HOT has been working to map<br>
the areas affected by Ebola in west Africa and to help humanitarian<br>
organizations better use OSM data in their efforts there.  Because OSM<br>
has the best dataset of settlements (towns, villages, etc) in the area<br>
several prominent groups have chosen to standardize on OSM being their<br>
official source for place names and locations.<br>
<br>
Due to the issue that many place names in Africa (and elsewhere) have<br>
many different spellings (due to the local languages not using latin<br>
alphabets) it is common for these organizations to establish a<br>
standardized set of place codes (pcodes for short) which are used to<br>
refer to places in datasets and communications.  The pcodes work<br>
similarly to zip codes in the US or postal codes more generally<br>
elsewhere in the world.  The list of pcodes is generally held by the<br>
UN and is used by almost every large humanitarian organization to<br>
communicate place information as the numerical codes prevent confusion<br>
due to multiple places with the same name, etc (just like postal codes<br>
are used).<br>
<br>
For the three countries in question, no pcodes had yet been generated<br>
so it was decided that the way they would be created was that the OSM<br>
dataset would be exported, a unique pcode generated for each village<br>
in the dataset, and then that would be adopted by these organizations<br>
as the official pcode for that location.  This was done over the past<br>
week and we now have the results in a csv file with columns containing<br>
the OSM id of the place, the version of the place at export, lat/lon,<br>
and then all of the associated name tags and finally a column for<br>
pcode which was filled in by the people generating them.<br>
<br>
Since these newly generated pcodes are now the official pcodes for<br>
these places, we plan to import them back into OSM onto each place in<br>
the pcode=* tag.  This allows the dataset to be much more easily used<br>
in the future, as well as allowing us to re-export and generate pcodes<br>
for newly added villages that do not already have them (since OSM is<br>
always growing).  The exact format of pcodes varies from country to<br>
country due to the specifics of the countries involved.  In some<br>
countries the pcode is chosen to be identical to the already existing<br>
postal codes.  For these specific countries since there was no<br>
existing system the codes are formatted using the three letter country<br>
code, a 2 digit number indicating the significance of the place, and<br>
then a running 5 digit number counting up from 1 to identify the<br>
specific place name, so for example the code for the capital of<br>
Liberia, Monrovia, has the code LBR0400001.<br>
<br>
Since the codes are newly generated and used OSM as the source of<br>
their creation, the import would be very easy to do, and there is zero<br>
risk of the data being "wrong" (it was generated exactly this way, so<br>
it is by definition correct at this point).  Also, there is no issue<br>
of licensing to be concerned about as the data in the file is OSM data<br>
to begin with, with the exception of the pcode, and we have explicit<br>
permission to use that as that was exactly the plan to begin with.<br>
<br>
Given that we have both the id/version pair in the dataset, as well as<br>
the lat/lon there are a couple ways the re-import of the pcodes could<br>
be accomplished.  The easiest would be to use josm and the conflation<br>
plugin, with a very small match distance (like 5 meters or something)<br>
and then just manually conflate the handful of nodes that may have<br>
moved in the last week.  The other possibility (which is more robust)<br>
is to write a simple script that adds the tags to the objects based on<br>
the id/version pair and then generates a list that must be manually<br>
processed for any objects which have a newer version than that at the<br>
time of export.  I think either method will work, but I do think the<br>
script is a bit more robust, and we already have someone interested in<br>
working on the script to make it happen.<br>
<br>
Let me know if you forsee any potential problems with either of these<br>
two methods and how you think they could be addressed.<br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v1.4.11 (GNU/Linux)<br>
<br>
iQIcBAEBAgAGBQJUIwU9AAoJEK7RwIfxHSXbauUP/0kB8puz0iO/szIJMwjPZU8S<br>
8+H1nJnOd7pMmBprWA0od8UDvPLfrjkxboR5OBVzI2oxGRR2SgKFCHUtnrU6NA8B<br>
snpbdJiVHgPPUJHs4YRUjlhQtGoonaQ+ETX1Tmf1ZoLSo7QDPKfI6zqUu/HNZRId<br>
N2toTpYTKodW27wOGg77CVS4l/xYErIF47hO1nYD9H30Cg/yWftyv0lMUps/M8rz<br>
ex8lEZ+60Gzx9TGlEerSH5lIOE/9K7ZfrkNMJNyvBoOMBp8oaeAcC+2l+qDqqO+o<br>
yAJcz4AUgwhfVcr9E4/ZE7vBbnJIORzcKwpwQyqkYuyd5Zm3KD4E51C97EACbIo8<br>
Q/kOaPHE2LbW3uBLqkCgI7XC2t93DaLP8ejFSScwLbA/Mq5uBMj5h7FndijlpQfL<br>
LCbSziv/T7B/p8q60haMWxeL/hQfwsiSJRYmLh05qhCLPQUNNqdX8bWjEwZzCfJC<br>
GFKVtSQGfWipcp93FsnkEhW0o5jMHNWVeSI3VcrQ7AU/fI27jW/Ivag7RVI4iWoZ<br>
Gkk5a5B1/GLYhFYutAFLcdFhQ6632d5cI/iN48VKanQ8hm9FUZJOnQgQvRU7p3Pc<br>
zdsNjXUHJkuJzmTN02L8kjXIMjUiZJDxCkQLTNY30QW81FXbc6KDkI0HnnekwV4+<br>
m8Nv59MV1PrzQXuG/oNJ<br>
=Qet7<br>
-----END PGP SIGNATURE-----<br>
<br>
_______________________________________________<br>
Imports mailing list<br>
<a href="mailto:Imports@openstreetmap.org">Imports@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/imports" target="_blank">https://lists.openstreetmap.org/listinfo/imports</a><br>
</blockquote></div>