-----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
