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