Hi Andrew, I agree taht pairing the OSM Ids will be the most simple and robust solution. Regarding the Pcodes methodology, seems an old method (that was used eg in Haiti) has been abandonned (or you did not mention it), whas is really fortunate: concatenate admin level IDs (every admin level having an integer number between 1 and x). Seems practical at first glance, but a real nightmare as admin boundaries can change. Basically this system created unique IDs but not for unique objects. And in Haiti, where admin level had been reorganized by the government a few years before the Earthquake, GIS people were more fighting against the pcodes than able to use them.
Sincerely, Severin Date: Wed, 24 Sep 2014 12:54:12 -0500 > From: Andrew Buck <andrew.r.b...@gmail.com> > To: "Imports OpenStreetMap.org" <imports@openstreetmap.org> > Subject: [Imports] Adding pcodes to villages in Liberia, Sierra > Leone > and Guinea > Message-ID: <54230544.6040...@gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > -----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. >
_______________________________________________ Imports mailing list Imports@openstreetmap.org https://lists.openstreetmap.org/listinfo/imports
