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ó:
> -----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 > [email protected] > https://lists.openstreetmap.org/listinfo/imports >
_______________________________________________ Imports mailing list [email protected] https://lists.openstreetmap.org/listinfo/imports
