Ah! I see. Cheers, Rafael El 25/09/2014 09:46, "Andrew Buck" <[email protected]> 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" <[email protected]> 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 [email protected] > >> 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 [email protected] https://lists.openstreetmap.org/listinfo/imports
