-----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.b...@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@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----- _______________________________________________ Imports mailing list Imports@openstreetmap.org https://lists.openstreetmap.org/listinfo/imports
