Re: [HOT] GNS name merging discussion thread
Thanks Blake for this,
I finished adjusting counties to these boundaries. I imported district
boundaries as well.
Now we are looking for such information for Guinea and Liberia. I contacted a
contributor who added districts in Sierra Leone 2 years ago. He responded
quickly and sent me very detailed shape files coming from the Sierra Leone
Statistical dept. But it seems to be a private copy he received. It would be
good if we could negociate open license for this. But no contacts.
The same in Guinea, Prefecture boundaries have been added. But we dont know
where they come from.
As you saw in the last email to the HOT list, the UN agencies are counting on
OSM except WHO which keep is one Map database. We are looking at adding pcodes
to the place names. But first, a lot of work to do.
Blake, I dont know how exactly the file for Liberia came to us. If you had a
contact in the Liberia Statistical office, please inform them that the
boundaries for counties and districts are now available in OSM. And a great
thank to them.
About names that we see on LISGIS maps. Do we have files with geolocated place
name? This would be an other tool to validate our info.
Pierre
De : Jean-Guilhem Cailton j...@arkemie.com
À : Blake Girardot bgirar...@gmail.com
Cc : hot@openstreetmap.org
Envoyé le : Samedi 23 août 2014 11h04
Objet : Re: [HOT] GNS name merging discussion thread
Le 20/08/2014 16:13, Blake Girardot a écrit :
[...]
I would love another map source for Liberia.
And it seems that you found it. :)
8 georeferenced County maps from LISGIS (from this page:
http://www.lisgis.net/page.php?7d5f44532cbfc489b8db9e12e44eb820=NDQ%3D
) that include villages (with population larger than 200) names and
locations, in addition to counties and districts boundaries are
available as TMS.
Their URLs for JOSM are:
Ebola LISGIS Bomi
tms[15]:http://imagery.openstreetmap.fr/tms/1.0.0/bomi_lisgis/{zoom}/{x}/{y}
Ebola LISGIS Bong
tms[15]:http://imagery.openstreetmap.fr/tms/1.0.0/bong_lisgis/{zoom}/{x}/{y}
Ebola LISGIS Gbarpolu
tms[15]:http://imagery.openstreetmap.fr/tms/1.0.0/gbarpolu_lisgis/{zoom}/{x}/{y}
Ebola LISGIS Grand Bassa
tms[15]:http://imagery.openstreetmap.fr/tms/1.0.0/grand_bassa_lisgis/{zoom}/{x}/{y}
Ebola LISGIS Grand Cape Mount
tms[15]:http://imagery.openstreetmap.fr/tms/1.0.0/grand_cape_mount_lisgis/{zoom}/{x}/{y}
Ebola LISGIS Grand Gedeh
tms[15]:http://imagery.openstreetmap.fr/tms/1.0.0/grand_gedeh_lisgis/{zoom}/{x}/{y}
Ebola LISGIS Grand Kru
tms[15]:http://imagery.openstreetmap.fr/tms/1.0.0/grand_kru_lisgis/{zoom}/{x}/{y}
Ebola LISGIS Lofa
tms[15]:http://imagery.openstreetmap.fr/tms/1.0.0/lofa_lisgis/{zoom}/{x}/{y}
My understanding of the letter from LISGIS that you forwarded to us is
that their content is in the public domain.
(LISGIS should be mentioned as source.)
The remaining 7 maps from that page only show counties and districts
boundaries. Since the split is on alphabetical order, maybe it was just
an oversight that they do not contain the villages. (In case someone is
interested, they are available as WMS only, not TMS for now, from
http://imagery.openstreetmap.fr/wms)
I'll look into setting up the polling station data.
Best wishes,
Jean-Guilhem
___
HOT mailing list
HOT@openstreetmap.org
https://lists.openstreetmap.org/listinfo/hot___
HOT mailing list
HOT@openstreetmap.org
https://lists.openstreetmap.org/listinfo/hot
Re: [HOT] GNS name merging discussion thread
Hi, If anyone else found the recent update to JOSM making GNS name merging more difficult, I found the change that made the biggest difference to how I work on the process: https://josm.openstreetmap.de/wiki/Help/Dialog/MapPaint#Stylesettings Less obtrusive node symbols at low zoom I had to turn that off, I need the obtrusive node symbols to help me see residential areas when the OSM data layer is inactive. Cheers, Blake ___ HOT mailing list HOT@openstreetmap.org https://lists.openstreetmap.org/listinfo/hot
Re: [HOT] GNS name merging discussion thread
Le 20/08/2014 16:13, Blake Girardot a écrit :
[...]
I would love another map source for Liberia.
And it seems that you found it. :)
8 georeferenced County maps from LISGIS (from this page:
http://www.lisgis.net/page.php?7d5f44532cbfc489b8db9e12e44eb820=NDQ%3D
) that include villages (with population larger than 200) names and
locations, in addition to counties and districts boundaries are
available as TMS.
Their URLs for JOSM are:
Ebola LISGIS Bomi
tms[15]:http://imagery.openstreetmap.fr/tms/1.0.0/bomi_lisgis/{zoom}/{x}/{y}
Ebola LISGIS Bong
tms[15]:http://imagery.openstreetmap.fr/tms/1.0.0/bong_lisgis/{zoom}/{x}/{y}
Ebola LISGIS Gbarpolu
tms[15]:http://imagery.openstreetmap.fr/tms/1.0.0/gbarpolu_lisgis/{zoom}/{x}/{y}
Ebola LISGIS Grand Bassa
tms[15]:http://imagery.openstreetmap.fr/tms/1.0.0/grand_bassa_lisgis/{zoom}/{x}/{y}
Ebola LISGIS Grand Cape Mount
tms[15]:http://imagery.openstreetmap.fr/tms/1.0.0/grand_cape_mount_lisgis/{zoom}/{x}/{y}
Ebola LISGIS Grand Gedeh
tms[15]:http://imagery.openstreetmap.fr/tms/1.0.0/grand_gedeh_lisgis/{zoom}/{x}/{y}
Ebola LISGIS Grand Kru
tms[15]:http://imagery.openstreetmap.fr/tms/1.0.0/grand_kru_lisgis/{zoom}/{x}/{y}
Ebola LISGIS Lofa
tms[15]:http://imagery.openstreetmap.fr/tms/1.0.0/lofa_lisgis/{zoom}/{x}/{y}
My understanding of the letter from LISGIS that you forwarded to us is
that their content is in the public domain.
(LISGIS should be mentioned as source.)
The remaining 7 maps from that page only show counties and districts
boundaries. Since the split is on alphabetical order, maybe it was just
an oversight that they do not contain the villages. (In case someone is
interested, they are available as WMS only, not TMS for now, from
http://imagery.openstreetmap.fr/wms)
I'll look into setting up the polling station data.
Best wishes,
Jean-Guilhem
___
HOT mailing list
HOT@openstreetmap.org
https://lists.openstreetmap.org/listinfo/hot
Re: [HOT] GNS name merging discussion thread
There appears to be a problem in the GNS import task #619. In particular, the OSM data of tile #258 cannot be downloaded. The server says it's too big, like when I try to make a manual download from JOSM with a big area. Other tiles had no problem so far, and I just now could download tile #252 but, again, not #258. The error in JOSM: The OSM server 'api.openstreetmap.org' reported a bad request. The area you tried to download is too big or your request was too large. Either request a smaller area or use an export file provided by the OSM community. Just FYI. Regards, ___ HOT mailing list HOT@openstreetmap.org https://lists.openstreetmap.org/listinfo/hot
Re: [HOT] GNS name merging discussion thread
Hi Ralf I tested this task 258 and had this same problem while trying to transfer OSM data to JOSM. Pierre Giraud is working on a more permanent solution where it would be possible to split such task. Here is a solution in the meantime that works easily . One you tried to dowload the box surrounding the square is loaded into JOSM. Then from JOSM Menu File / Download from a OSM Mirror, use the following query asking only for place names : [place=*] This works nicely. To my point of view, this makes also easier the process of comparing the data from the two layers. We could eventually integrate directly into the Task Manager such request for Import Tasks. Pierre De : Ralf Stephan gtrw...@gmail.com À : Cc : HOT Discussion list hot@openstreetmap.org Envoyé le : Mercredi 20 août 2014 2h21 Objet : Re: [HOT] GNS name merging discussion thread There appears to be a problem in the GNS import task #619. In particular, the OSM data of tile #258 cannot be downloaded. The server says it's too big, like when I try to make a manual download from JOSM with a big area. Other tiles had no problem so far, and I just now could download tile #252 but, again, not #258. The error in JOSM: The OSM server 'api.openstreetmap.org' reported a bad request. The area you tried to download is too big or your request was too large. Either request a smaller area or use an export file provided by the OSM community. Just FYI. Regards, ___ HOT mailing list HOT@openstreetmap.org https://lists.openstreetmap.org/listinfo/hot___ HOT mailing list HOT@openstreetmap.org https://lists.openstreetmap.org/listinfo/hot
Re: [HOT] GNS name merging discussion thread
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Note that in order for the instructions that Pierre gave you will need the 'mirrored download' plugin in josm. That will put the 'download from mirror' option in the file menu. The [place=*] thing is optional, without it it will work just like the normal OSM download functionality, only it allows much bigger areas (whole countries if you want). The other possibility is to just download the area piece by piece using the normal download tool, and then merge them into a single layer in josm. Either way will work. In any case though it is important not to split the tasks, as that will break the download of the GNS file at this time. - -AndrewBuck On 08/20/2014 08:03 AM, Pierre Béland wrote: Hi Ralf I tested this task 258 and had this same problem while trying to transfer OSM data to JOSM. Pierre Giraud is working on a more permanent solution where it would be possible to split such task. Here is a solution in the meantime that works easily . One you tried to dowload the box surrounding the square is loaded into JOSM. Then from JOSM Menu File / Download from a OSM Mirror, use the following query asking only for place names : [place=*] This works nicely. To my point of view, this makes also easier the process of comparing the data from the two layers. We could eventually integrate directly into the Task Manager such request for Import Tasks. Pierre De : Ralf Stephan gtrw...@gmail.com À : Cc : HOT Discussion list hot@openstreetmap.org Envoyé le : Mercredi 20 août 2014 2h21 Objet : Re: [HOT] GNS name merging discussion thread There appears to be a problem in the GNS import task #619. In particular, the OSM data of tile #258 cannot be downloaded. The server says it's too big, like when I try to make a manual download from JOSM with a big area. Other tiles had no problem so far, and I just now could download tile #252 but, again, not #258. The error in JOSM: The OSM server 'api.openstreetmap.org' reported a bad request. The area you tried to download is too big or your request was too large. Either request a smaller area or use an export file provided by the OSM community. Just FYI. Regards, ___ HOT mailing list HOT@openstreetmap.org https://lists.openstreetmap.org/listinfo/hot ___ HOT mailing list HOT@openstreetmap.org https://lists.openstreetmap.org/listinfo/hot -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJT9J+nAAoJEK7RwIfxHSXbg2QQAKpxKfeHZA4s7L+DQYLGHF2j 23dPvfZAQOnokNx8wm/KjpL3BnUSzgOxuqyMLPY+GXdvigKNVg1iXaHVV15ZiqsB 2ibksEZ2EuQECYBOl/Chh8tFwgRXVJ3n7toSKHeR3bdDCwUqtQfi4Q8uSqv+AHo+ d0zl4QMTQBivfHGvED7b0srGQ+5BpP8a4uShrqNBOPE2btfWWlX7WkTyxz/oXSWo myX104SwI+vZEhkKb0geThigb2I6L/TXmSoRF4Fm/UfPr6SDH0Bjqpi3y1awbBRG 8QUosyR8yyMxI0lyTOLA9eQBab8weLkJxa92vnVy/fkIRzA0YsIBd6NerjKO9Vdz R5fMwIobA8uk9agUXILH/9QKKgPy+7fU2CzXX3e4SH6+6KxNXl24sZwSP1b3fTbb iEBJgdtHGV6x20xEfjpcqXE+4QHObrEfXBXCFgVVQysoZVUITVMuyuB21nxXs6pV hdJloKoyg9iDXnWe/Vy0S560aC1BPDBSY3Qljl8xZcC8F9u3tKFsHWswXrPaJc+h 0+lwawLwoZM6uex2w0rFm3hspej/+Mb5KiWex1zzovqW4oytGa8GPUeh0UJVPdZj x66yO1gewVkHKAegiYv7GV/ULgC3OtqLo0aTADp/NIKMiwIEkcZClB7nAaABa5vS T1SYmCzvIICO0X4GGg/x =NiYZ -END PGP SIGNATURE- ___ HOT mailing list HOT@openstreetmap.org https://lists.openstreetmap.org/listinfo/hot
Re: [HOT] GNS name merging discussion thread
The work I've done so far has been easy because someone else did most of it. However, I have noted source discrepancies: JOG, AMS-2 (don't know what that is), but not the US Army Topo maps. In fact, JOG is fairly sparse and the latter are the prime source. Would AMS-2 be the US Army reference? Example: Node: Tangahun (2967629931). Tom Taylor TomT5454 ___ HOT mailing list HOT@openstreetmap.org https://lists.openstreetmap.org/listinfo/hot
Re: [HOT] GNS name merging discussion thread
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Yeah, AMS I think is Army Maps Service, not sure what the 2 means, but I think those are the white, US Army Topo Maps in that other layer. - -AndrewBuck On 08/20/2014 08:45 AM, Tom Taylor wrote: The work I've done so far has been easy because someone else did most of it. However, I have noted source discrepancies: JOG, AMS-2 (don't know what that is), but not the US Army Topo maps. In fact, JOG is fairly sparse and the latter are the prime source. Would AMS-2 be the US Army reference? Example: Node: Tangahun (2967629931). Tom Taylor TomT5454 ___ HOT mailing list HOT@openstreetmap.org https://lists.openstreetmap.org/listinfo/hot -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJT9KkLAAoJEK7RwIfxHSXbDPAQAJvwVc0FjEfLCk2HAG67wWYy dMk+/gA9Z3QJfPf0VdwyK/A5+xmx9BOQ7dJaO7Llql3WPd/cL7ceDuKu7WIuIUGB dhpy79dVDcY0JVCDioLMfnsmMcyy9IumpsxBzYCyIVV1I4/yT51H5x4BiJUd0N8J Gn6gcNkF6Oa7bhQ5R/qbN4kNEjbZvCRqkW+ZVqmn168edYKpzacve7qhe8qzqWY7 Q1ItOB9kAUhrtAYAya4sdc/Eth9TF7PC5wpH8Ze1QGgRES1x2kusizAF/VgCR8ch lQH3uy3qIdxebgCLU1sIACaFFgkPzmv745WS/wVVfsKzJ3zhAGJTR9xYOweeyYkX JWKyGZ723WUWlvRilv+Ch6zilgjznMLpywo0+0h23VN/oEmsia3TsRdo31XWE5ul Pu25+cmagn5hk1TB5YQrg1WvTVUGPKtSK6DvhevL4AteO5W21GiMk94yM+PyYCI6 SnINZUAcfDLMIayG+VNZ+9JGdTaz3i5KpI9mM8STo3QxDy48hmA3qcFNdw13qj/N P45GwhvTb7rA2n0yj/IWegf/uKayrtooetLt82kMlYA07jYMgt+ikDIJLByN0Npg M7gMoejCttZjVlzncdSWLEHGEWqaUVCfUALZDqaVYp2S0vPaL5vF5Qqe8hPmBWkA HDS/WJKGwHhP8oPeMK49 =HFVT -END PGP SIGNATURE- ___ HOT mailing list HOT@openstreetmap.org https://lists.openstreetmap.org/listinfo/hot
Re: [HOT] GNS name merging discussion thread
Yes, AMS-2 is for US Army Map Service (AMS), Series G504, 1955-
(1:250,000) (Actually many from 1963).
Unfortunately, its available maps only cover the extreme north of
Liberia (beside Sierra Leone and Guinea):
https://www.lib.utexas.edu/maps/ams/west_africa/txu-oclc-6595921-index.jpg
There is also an older AMS Series G541, from 1942, which is apparently
available only for Sierra Leone - that it covers entirely, and has been
set up in layer 167:
http://mapwarper.net/layers/167
available as TMS (in JOSM syntax) as:
http://mapwarper.net/layers/tile/167/{zoom}/{x}/{y}.png
It is the only layer (among the three layers of US topographic maps,
JOG, AMS-2 and AMS) that includes a map over Bonthe District. It can
also be interesting to see the historic evolution, and sometimes
old_name or alt_name.
Best wishes,
Jean-Guilhem
Le 20/08/2014 16:44, Andrew Buck a écrit :
I am working on rectifying some more of the white AMS maps, but if I
recall correctly, even the ones that cover liberia are basically
blank. I do not know of any other sources that are free of copyright
for the area.
You can see the map layer and which maps have yet to be rectified here:
http://mapwarper.net/layers/150
Note that when new maps come online you might have to right click in
josm and do the 'flush tile cache' before they will show up for you.
For the ones that you are not sure of, even just getting a fixme tag
on them and leaving them where they are is an improvement. They tend
to be within a mile or two of their correct position anyway so just
having them in the DB for nominatim is already a step forward.
-AndrewBuck
On 08/20/2014 09:13 AM, Blake Girardot wrote:
The white maps only seem to cover SL and northern Liberia.
The JOG map seems to be the only locating reference for the
majority of Liberia.
If there is some other good source for location in Liberia I'd love
to know about it. The JOG map is good for the items it has, but
there are a lot not on that map.
The square I am working on now has 280 nodes imported from GNS (the
most I have seen so far), but only about 80 are on the JOG map
leaving the other 200 to basically be just guesses based on what is
nearby and since they are all marked as skip=yes just going by
proximity is not very good.
Most of them I am just going to leave exactly where they imported
and mark them fixme=location approximate
I would love another map source for Liberia.
On 8/20/2014 9:45 AM, Tom Taylor wrote:
The work I've done so far has been easy because someone else did
most of it. However, I have noted source discrepancies: JOG,
AMS-2 (don't know what that is), but not the US Army Topo maps.
In fact, JOG is fairly sparse and the latter are the prime
source. Would AMS-2 be the US Army reference? Example: Node:
Tangahun (2967629931).
Tom Taylor TomT5454
___ HOT mailing list
HOT@openstreetmap.org
https://lists.openstreetmap.org/listinfo/hot
___ HOT mailing list
HOT@openstreetmap.org https://lists.openstreetmap.org/listinfo/hot
___
HOT mailing list
HOT@openstreetmap.org
https://lists.openstreetmap.org/listinfo/hot
___
HOT mailing list
HOT@openstreetmap.org
https://lists.openstreetmap.org/listinfo/hot
Re: [HOT] GNS name merging discussion thread
On 17/08/2014 5:03 AM, Tom Taylor wrote: ... I also note from memory that there is a Palima without attributed source on the east side of the Sewa River and one further west that I took from GNS and verified against the US Army Topo map. TomT5454 Tom Taylor Sorry, I take this one back. Both appear to have been GNS nodes. ___ HOT mailing list HOT@openstreetmap.org https://lists.openstreetmap.org/listinfo/hot
Re: [HOT] GNS name merging discussion thread
Hi Tom, I agree about the duplicate names, I just ran into a few in Liberia. But I have another question related to how we should handle names. I am running into several nodes where the name tag is one name, but the JOG map shows another name. Now this other name is almost always listed as an alternate name, and if it is not I for sure add it as an alternate name. My question is: If the main name tag is different than the JOG label should we: 1. Change the name to match the JOG map, and make sure the GNS import name is listed as an alternate name ? 2. Leave it as it comes in from GNS making sure JOG map name is listed as an alternate? 3. Make it as fixme=Confirm name after doing either one of the two above option? Sorry to be so picky, but as long as we going through and cleaning up data, I'd like to get it as good as we can. Regards, Blake Girardot On 8/17/2014 5:03 AM, Tom Taylor wrote: Scary time last night and this am. It appears I got cut off from the Internet from Toronto outward around 9:30 pm EDT and couldn't submit the results of several hours' work. I opened a changeset, but it got closed at the other end before anything went up. This caused a couple of glitches this morning, but eventually everything worked. Checking over OpenStreetMap, it looks like everything is OK. I was concerned to notice at least four distinct instances of Baoma scattered over the map in Task square 619#187 and maybe also #205. I'll have to verify on the US Topo maps when I reopen JOSM. This must complicate life for the map users -- they would have to use the GNS UFI to distinguish. I also note from memory that there is a Palima without attributed source on the east side of the Sewa River and one further west that I took from GNS and verified against the US Army Topo map. TomT5454 Tom Taylor ___ HOT mailing list HOT@openstreetmap.org https://lists.openstreetmap.org/listinfo/hot ___ HOT mailing list HOT@openstreetmap.org https://lists.openstreetmap.org/listinfo/hot
Re: [HOT] GNS name merging discussion thread
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 For these I have just been making sure it gets in as an alternate name and not been putting a fixme on them. The spelling of these names is not generally fixed, and the names seem to be fairly fluid over time. Without local knowledge to know which one is currently (or most widely) in use, we can't do any better than make sure we list all of the options. - -AndrewBuck On 08/17/2014 08:58 AM, Blake Girardot wrote: Hi Tom, I agree about the duplicate names, I just ran into a few in Liberia. But I have another question related to how we should handle names. I am running into several nodes where the name tag is one name, but the JOG map shows another name. Now this other name is almost always listed as an alternate name, and if it is not I for sure add it as an alternate name. My question is: If the main name tag is different than the JOG label should we: 1. Change the name to match the JOG map, and make sure the GNS import name is listed as an alternate name ? 2. Leave it as it comes in from GNS making sure JOG map name is listed as an alternate? 3. Make it as fixme=Confirm name after doing either one of the two above option? Sorry to be so picky, but as long as we going through and cleaning up data, I'd like to get it as good as we can. Regards, Blake Girardot On 8/17/2014 5:03 AM, Tom Taylor wrote: Scary time last night and this am. It appears I got cut off from the Internet from Toronto outward around 9:30 pm EDT and couldn't submit the results of several hours' work. I opened a changeset, but it got closed at the other end before anything went up. This caused a couple of glitches this morning, but eventually everything worked. Checking over OpenStreetMap, it looks like everything is OK. I was concerned to notice at least four distinct instances of Baoma scattered over the map in Task square 619#187 and maybe also #205. I'll have to verify on the US Topo maps when I reopen JOSM. This must complicate life for the map users -- they would have to use the GNS UFI to distinguish. I also note from memory that there is a Palima without attributed source on the east side of the Sewa River and one further west that I took from GNS and verified against the US Army Topo map. TomT5454 Tom Taylor ___ HOT mailing list HOT@openstreetmap.org https://lists.openstreetmap.org/listinfo/hot ___ HOT mailing list HOT@openstreetmap.org https://lists.openstreetmap.org/listinfo/hot -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJT8L1+AAoJEK7RwIfxHSXbj8EP/18XVPogQ6OWUMpGF1wxb7Du 1hblH8+O+KEzNwZavvHbAvWIu8vKpJaZaIb1g3B00qtQq2yZzluIhoxY91lRtFEt 2Vg4KYRyyiFI6Xft06ysPECwO3O/u42cJkqUsAhBQt/IsT1748muK72hw/CPqgea 934g99rJSVampPp2SFUmHMfjiCDGnyY91cge+C+yixUBiN+Hu6nS6EXhCQN0MSYJ YfjDha0pk2+cQ9OssjLFREsZeQxnpJh42mcgvxtY/1DoDRNf65hB2VVpnZx3zI7c nH45qUPrak25Z4txHNyTIqKaMezzFHJKVrNgFMACG4SILlgoEyls606ovhKpruiu AwlDsTTwvpzWxt+1VtpIPhPfeqtVPr2DuGhwYypSin1eWxz4LgaIQv+Dj5kGG8e9 7bKkIlZg3u6XAoFYNZijkqYPbAC2hBi+jjNKgOyUvibCJ0N2gP2nQv+7oSyCSn0u urPi5n1Sxz7qtw9/0yJBRKv2d/Q0dYUsBO1AopIUZrQf4LIej0nCl8ypPy5Bp7B3 0g2nPFoq+HU4wgDQiY++5VuwuAeBlImLZ1DiWdaKuH80l8i/nObuw2Rbab+85bGv 0YeFu/m2F4OSycg0UE/oOr1RgOtbk+IEnsy9fp+AarSdT/Ro7NVXLwcXT3RsFhS9 9uDnxPvAbpO6pWx18R/Q =Z/VJ -END PGP SIGNATURE- ___ HOT mailing list HOT@openstreetmap.org https://lists.openstreetmap.org/listinfo/hot
Re: [HOT] GNS name merging discussion thread
On 8/17/2014 10:34 AM, Andrew Buck wrote: For these I have just been making sure it gets in as an alternate name and not been putting a fixme on them. The spelling of these names is not generally fixed, and the names seem to be fairly fluid over time. Without local knowledge to know which one is currently (or most widely) in use, we can't do any better than make sure we list all of the options. - -AndrewBuck Perfect, that is what I am going to do too then. I am leaning toward using the GNS/JOG name as I just ran into a situation where the same name (no source listed) was on the OSM for 3 different settlements 10km apart, but the name from GNS and on JOG was unique for each of the 3 so I went with the GNS/JOG names for each and put the existing name as an alt with a note. ___ HOT mailing list HOT@openstreetmap.org https://lists.openstreetmap.org/listinfo/hot
Re: [HOT] GNS name merging discussion thread
Hi, when trying to load GNS from a split square in task #619, nothing is loaded (unsplit squares do work). Also, trying to download data directly from the given link http://dev.camptocamp.com/files/hotosm/ebola_sierra_leone_gns_import/gns_12_1921_2139.shp.csv will yield a 404. Can someone please help, at least by unsplitting the Kenema square? Regards, On Thu, Aug 14, 2014 at 5:56 PM, Blake Girardot bgirar...@gmail.com wrote: Hi, I propose this thread or some other forum where folks working on the GNS name importing could discuss issues directly related to that type of mapping. I would like to share how I do things and / or ask questions of how others are doing things. The more consistently we can all do the GNS name mapping the better it will be for people in the field. If this thread is ok, or if there is a better place to share information about this type of mapping, please let me know. Regards, Blake Girardot ___ HOT mailing list HOT@openstreetmap.org https://lists.openstreetmap.org/listinfo/hot ___ HOT mailing list HOT@openstreetmap.org https://lists.openstreetmap.org/listinfo/hot
Re: [HOT] GNS name merging discussion thread
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 No, it is not that, it is because the task tile itself was split and we don't have a file for that. Blake Giradot has worked out a solution and will do these squares himself. - -AndrewBuck On 08/16/2014 08:07 AM, Pierre Béland wrote: Ralf, if you select a square at the border of the country, it is possible that there is nothing there. If this is the case, the tool to split the original GNS file do not create a file for this square. In JOSM, looking at the imagery for this square should confirm that there is no village in thi area of Sierra Leone. regard Pierre De : Ralf Stephan gtrw...@gmail.com À : Cc : HOT Discussion list hot@openstreetmap.org Envoyé le : Samedi 16 août 2014 3h10 Objet : Re: [HOT] GNS name merging discussion thread Hi, when trying to load GNS from a split square in task #619, nothing is loaded (unsplit squares do work). Also, trying to download data directly from the given link http://dev.camptocamp.com/files/hotosm/ebola_sierra_leone_gns_import/gns_12_1921_2139.shp.csv will yield a 404. Can someone please help, at least by unsplitting the Kenema square? Regards, On Thu, Aug 14, 2014 at 5:56 PM, Blake Girardot bgirar...@gmail.com wrote: Hi, I propose this thread or some other forum where folks working on the GNS name importing could discuss issues directly related to that type of mapping. I would like to share how I do things and / or ask questions of how others are doing things. The more consistently we can all do the GNS name mapping the better it will be for people in the field. If this thread is ok, or if there is a better place to share information about this type of mapping, please let me know. Regards, Blake Girardot ___ HOT mailing list HOT@openstreetmap.org https://lists.openstreetmap.org/listinfo/hot ___ HOT mailing list HOT@openstreetmap.org https://lists.openstreetmap.org/listinfo/hot ___ HOT mailing list HOT@openstreetmap.org https://lists.openstreetmap.org/listinfo/hot -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJT71hBAAoJEK7RwIfxHSXb0q4P/2/pprPJrLWY5Kx1QWqi2/GK XiYv03RwI7DEAc8gadb31KDXLhQK1b9NkZOaqEqDQs2yOXxRNywV1CO5qI3jbJj9 qpcGdO/dEskWhjfo25bHM9EOyLGekuUG0CyB3fcoFTB2J3UNHwlE2UjMeiOrBjBM 925FmEjhRr3czSJNfc0UFBccVRuLE3ARziCNGqzzNLP2Dz/t1KhqwgjZr0s1Wvwn 0XF/sL0gJjaXkIYuc5vHXnTojiGvnsbLdVh27pZ6OF2DmG0R84nNV9CrCWumdXuM wR8KtmiinNuWflrKVat08iIa+aH91mm6/Pt+za2ppLI3SHSMneL6sTeX4Mji8wjU iRrSL1EgHMFefV02MvXqsUGy08RbZYpekluOvKdAnly4m6EQfk/UQCPOlFAk9Nao +3gWnWyS1m6hDz4qbmA2bxBxVRvRRdykakEkZHEViAE7or6WlhMTzqSpld/bRcKV Zcngkb6JSF7cLC9/Qsf6mOnnDyrfETyY4hvhmKhZSHh/QNlM7qauIpS8a3X3XabX piS38eHQNRZUB2PK1wwtBy0HW3n4CWgMJYaqerEv6CoT+B586lPyitahWCY1ObUX CzRbKL73xBHP6GoLAqf+EMfNTkITgAZQnf25Viea+5Epba+TOlDT2NaJo/Gqsuvk OBUQKc/LOiMMV6/bxgoR =emls -END PGP SIGNATURE- ___ HOT mailing list HOT@openstreetmap.org https://lists.openstreetmap.org/listinfo/hot
Re: [HOT] GNS name merging discussion thread
Oups! did not spot splitted square. I go back to my morning coffee! Pierre De : Andrew Buck andrew.r.b...@gmail.com À : hot@openstreetmap.org Envoyé le : Samedi 16 août 2014 9h10 Objet : Re: [HOT] GNS name merging discussion thread -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 No, it is not that, it is because the task tile itself was split and we don't have a file for that. Blake Giradot has worked out a solution and will do these squares himself. - -AndrewBuck On 08/16/2014 08:07 AM, Pierre Béland wrote: Ralf, if you select a square at the border of the country, it is possible that there is nothing there. If this is the case, the tool to split the original GNS file do not create a file for this square. In JOSM, looking at the imagery for this square should confirm that there is no village in thi area of Sierra Leone. regard Pierre De : Ralf Stephan gtrw...@gmail.com À : Cc : HOT Discussion list hot@openstreetmap.org Envoyé le : Samedi 16 août 2014 3h10 Objet : Re: [HOT] GNS name merging discussion thread Hi, when trying to load GNS from a split square in task #619, nothing is loaded (unsplit squares do work). Also, trying to download data directly from the given link http://dev.camptocamp.com/files/hotosm/ebola_sierra_leone_gns_import/gns_12_1921_2139.shp.csv will yield a 404. Can someone please help, at least by unsplitting the Kenema square? Regards, On Thu, Aug 14, 2014 at 5:56 PM, Blake Girardot bgirar...@gmail.com wrote: Hi, I propose this thread or some other forum where folks working on the GNS name importing could discuss issues directly related to that type of mapping. I would like to share how I do things and / or ask questions of how others are doing things. The more consistently we can all do the GNS name mapping the better it will be for people in the field. If this thread is ok, or if there is a better place to share information about this type of mapping, please let me know. Regards, Blake Girardot ___ HOT mailing list HOT@openstreetmap.org https://lists.openstreetmap.org/listinfo/hot ___ HOT mailing list HOT@openstreetmap.org https://lists.openstreetmap.org/listinfo/hot ___ HOT mailing list HOT@openstreetmap.org https://lists.openstreetmap.org/listinfo/hot -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJT71hBAAoJEK7RwIfxHSXb0q4P/2/pprPJrLWY5Kx1QWqi2/GK XiYv03RwI7DEAc8gadb31KDXLhQK1b9NkZOaqEqDQs2yOXxRNywV1CO5qI3jbJj9 qpcGdO/dEskWhjfo25bHM9EOyLGekuUG0CyB3fcoFTB2J3UNHwlE2UjMeiOrBjBM 925FmEjhRr3czSJNfc0UFBccVRuLE3ARziCNGqzzNLP2Dz/t1KhqwgjZr0s1Wvwn 0XF/sL0gJjaXkIYuc5vHXnTojiGvnsbLdVh27pZ6OF2DmG0R84nNV9CrCWumdXuM wR8KtmiinNuWflrKVat08iIa+aH91mm6/Pt+za2ppLI3SHSMneL6sTeX4Mji8wjU iRrSL1EgHMFefV02MvXqsUGy08RbZYpekluOvKdAnly4m6EQfk/UQCPOlFAk9Nao +3gWnWyS1m6hDz4qbmA2bxBxVRvRRdykakEkZHEViAE7or6WlhMTzqSpld/bRcKV Zcngkb6JSF7cLC9/Qsf6mOnnDyrfETyY4hvhmKhZSHh/QNlM7qauIpS8a3X3XabX piS38eHQNRZUB2PK1wwtBy0HW3n4CWgMJYaqerEv6CoT+B586lPyitahWCY1ObUX CzRbKL73xBHP6GoLAqf+EMfNTkITgAZQnf25Viea+5Epba+TOlDT2NaJo/Gqsuvk OBUQKc/LOiMMV6/bxgoR =emls -END PGP SIGNATURE- ___ HOT mailing list HOT@openstreetmap.org https://lists.openstreetmap.org/listinfo/hot___ HOT mailing list HOT@openstreetmap.org https://lists.openstreetmap.org/listinfo/hot
Re: [HOT] GNS name merging discussion thread
Just a tip for someone starting out on this task using JOSM. After stetting up the GNS and image layers (including the US Topo and JOG maps in the area I'm working on), my work cycle is this: - activate the GNS layer - select a point - copy it to the Data 1 layer using Shift-Ctl-M - activate the Data 1 layer - make visible the US Army Topo map, which has more places than the JOG map I have. I only use the JOG map for verification. - place the point where it seems right. In the task I was working on, someone had done a lot of the work already, so it was a matter of checking. I changed one or two of the other person's placements, merged nodes once or twice where there was a naming clash, and deleted my copied point when it was clearly redundant. - reactivate the GNS layer - delete the original point so I know what's done. It's this last step that caused me a bit of trouble. I wiped out my GNS layer several times before I realized I had to make sure I returned focus to the edit screen before hitting Delete. TomT5454 Tom Taylor ___ HOT mailing list HOT@openstreetmap.org https://lists.openstreetmap.org/listinfo/hot
Re: [HOT] GNS name merging discussion thread
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I am aware of the problems with using residential areas for village outlines, however using the place=* instead of landuse=residential on the outline doesn't really solve the problem either. Many African towns are composed of numerous clusters of buildings. For these we map each as a separate area, which gives a much better picture of the layout of the town. But it would not make sense to do a separate place=* for each of these. A good example of this is Gueckedou. For this town we have actually gotten neighborhood polygons from MSF. Notice that they _almost_ match up with the residential areas we have mapped now, but not always exactly. Even some neighborhoods have many residential areas mapped. http://www.openstreetmap.org/#map=15/8.5607/-10.1297 What we really need is a new landuse type for 'built up area' or something like 'populated place'. This accurately describes what we are tracing, without implying that we know it is actually residential (and not commercial or industrial or something). I don't know what to use for such a thing and it would need discussion as well. Does this sound like something that would make sense to take to the tagging mailing list? Should a proposal on the wiki be started? And most importantly, is there someone who wants to lead the effort to get such a tag worked out? Keep in mind that since other orgs that don't understand tags and rendering issues are using our maps currently and making use of the residential polygons; so any changes to the tagging need to get reflected in the OSM carto and also the HOT HDM rendering as well. They cannot just all dissappear. - -AndrewBuck On 08/14/2014 05:32 PM, Paul Norman wrote: On 8/14/2014 3:12 PM, Pierre Béland wrote: As a general rule, we outline residential landuse areas using the tag landuse=residential. There might be many for one village. Sure - the only problem is when you can't be reasonably certain that what you're tracing is only residential. In those cases, landuse=residential is wrong. And we use a node to describe places. Exchanging such infos with various humanitarian organizations, I think that we are better to keep a data model where we make distinction between the nodes places=* and the residential areas polygons. Place tags on an area where that place has clearly defined bounds are not incorrect. Data consumers have to be prepared for either. For what it's worth, openstreetmap-carto doesn't handle this correctly and there are a couple of issues about it. ___ HOT mailing list HOT@openstreetmap.org https://lists.openstreetmap.org/listinfo/hot -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJT7g/GAAoJEK7RwIfxHSXbAcQP/38nFnzCDbxN0c7Gn4fD+ZUq NAgwocH/AAERR0yNz2Z02xYw5/FcRswbMYs5x4FKo/0GwGE8AO999rENkmZVZ3xO cjcf9E9kBwc1d++eya62xxg4SMrTKqUfU+fsj5QKCZgNnMgtd1EijzMKPJm7WkH8 7rXJo3oxx7QO9+gGmt+OIyCSn2ndSl/L5vL3qxv0BLadBvyVaDeSegJLT2ffaAEe /f9oOykbZLoZu7kcoa2qi/+Z2ZRccVI6ct5tP7Yhhtohm5PhY1staTlal92cFTsz lBHyq4bkRNdJiEsuVB26O3Q/BxcrNrjjAeL78MYl2W8N+ihh68dUPgWTntmIZFgR qO5lJA2RGbrcUaCSKHVNTgwL5/Hd+R6Go/Xry+Lq0xfJ5f7FbkIQj08X+S8cDJb3 x0lY8AsQzqV/WMYX7x/btOZA82uKpr9icpXL4SvG7dQw4L86RAgj3z4RRrhKxqIk eCc0yg9nGdGgfP0m3Wn5d4Dk5H2hrkxh0urSZOS7vE1/AO9N4wgynLv5mUUI0r0y gIwcrCvcDmMkAjVdP4yhpaeC82GnEg1zWDwMgPqn/pYgKH3IFRx0L4AUHmuc2R0w DKRA70HsAfhQGkjX0qqcYA46R+pNEacyFgrAtoHuZRkEPl8/l76vlau8n3IO3AKD 8p0J79wxjZwFALCnwOYF =JCxY -END PGP SIGNATURE- ___ HOT mailing list HOT@openstreetmap.org https://lists.openstreetmap.org/listinfo/hot
Re: [HOT] GNS name merging discussion thread
Hi, When I see a name on a city on the JOG map and see it clearly in the imagery, but it is not in my GNS import, I will place a hamlet node on it and name it manually. I also generally quickly put a landuse=residential area on top of any settlements that I am merging if I have good clear imagery to outline it. If anyone wants to review any squares I have marked done (bgirardot) or comments I make here and provide feedback, I welcome it all. Regards, Blake Girardot ___ HOT mailing list HOT@openstreetmap.org https://lists.openstreetmap.org/listinfo/hot
Re: [HOT] GNS name merging discussion thread
Hi, my main problem so far is that I ended up with quite a few places in the GNS import that I can't clearly assign to any of the residential areas that I can see on the map. Ever so often there are two or three places about equally far from the marker. And that's even for places without a skip flag. I've been adding Fixme and a note to it for now. clara ___ HOT mailing list HOT@openstreetmap.org https://lists.openstreetmap.org/listinfo/hot
Re: [HOT] GNS name merging discussion thread
On 8/14/2014 1:52 PM, clara wrote: Hi, my main problem so far is that I ended up with quite a few places in the GNS import that I can't clearly assign to any of the residential areas that I can see on the map. Ever so often there are two or three places about equally far from the marker. And that's even for places without a skip flag. I've been adding Fixme and a note to it for now. That is exactly the main challenge I have as well. And like you I have been making them all fixme=Location approximate and then putting in a detailed note like where the nearest settlement is, or that there were too many tiny settlements nearby to decide. Basically if the location is not on the JOG map or it doesn't come in really close to an obvious settlement I have been reluctant to call it properly placed and put a fixme with a note on it. For some squares there are a great deal of fixme's and for others very few. It is almost a two edged sword how good many of the GNS nodes come in, usually within 50 or 100 meters of a settlement, that I get afraid to move one 1.5km to the nearest settlement. There is a measurement plugin I added to my JOSM, that while not perfect, I have been using to put distances in my notes. ___ HOT mailing list HOT@openstreetmap.org https://lists.openstreetmap.org/listinfo/hot
Re: [HOT] GNS name merging discussion thread
Oh, one other thing. When I am putting a fixme=Location approximate node in place, if there are tiny settlements or individual buildings in the area I will make sure I mark them properly as buildings or residential areas on the OSM map so someone in the field could at least have an idea of where things might be near the node. cheers, blake On 8/14/2014 1:52 PM, clara wrote: Hi, my main problem so far is that I ended up with quite a few places in the GNS import that I can't clearly assign to any of the residential areas that I can see on the map. Ever so often there are two or three places about equally far from the marker. And that's even for places without a skip flag. I've been adding Fixme and a note to it for now. clara ___ HOT mailing list HOT@openstreetmap.org https://lists.openstreetmap.org/listinfo/hot
Re: [HOT] GNS name merging discussion thread
As a general rule, we outline residential landuse areas using the tag landuse=residential. There might be many for one village. And we use a node to describe places. Exchanging such infos with various humanitarian organizations, I think that we are better to keep a data model where we make distinction between the nodes places=* and the residential areas polygons. Pierre De : Blake Girardot bgirar...@gmail.com À : Paul Norman penor...@mac.com Cc : hot@openstreetmap.org Envoyé le : Jeudi 14 août 2014 17h44 Objet : Re: [HOT] GNS name merging discussion thread I also generally quickly put a landuse=residential area on top of any settlements that I am merging if I have good clear imagery to outline it. You should only add a landuse=residential if you're fairly sure that the entire area is residential. You might want to add the area of the settlement as place=* instead, and not use a node. Someone can correct me if I am mistaken, but for this GNS merging task, we are generally outlining the small settlements as landuse=residential for most of the villages according to the instructions. Sometimes there is clearly something else out side the larger villages and I'll just leave that out of my circling of the village. And we are specifically merging in a single node that has a place=hamlet for every one in most cases. On the occasion where I am bumping into existing single nodes with a place=village|town, depending on the size I will usually over write it with hamlet in the conflict dialog, unless it is usually large and then I will leave it as whatever the existing place tag had it specified as. But single nodes for sure with a place=hamlet and a name= tag are what we are importing and merging into the existing OSM data. Our main goal is to get named nodes on the map in as exact a location as possible, the outlining areas I think is secondary to the main task. ___ HOT mailing list HOT@openstreetmap.org https://lists.openstreetmap.org/listinfo/hot___ HOT mailing list HOT@openstreetmap.org https://lists.openstreetmap.org/listinfo/hot
Re: [HOT] GNS name merging discussion thread
On 8/14/2014 3:12 PM, Pierre Béland wrote: As a general rule, we outline residential landuse areas using the tag landuse=residential. There might be many for one village. Sure - the only problem is when you can't be reasonably certain that what you're tracing is only residential. In those cases, landuse=residential is wrong. And we use a node to describe places. Exchanging such infos with various humanitarian organizations, I think that we are better to keep a data model where we make distinction between the nodes places=* and the residential areas polygons. Place tags on an area where that place has clearly defined bounds are not incorrect. Data consumers have to be prepared for either. For what it's worth, openstreetmap-carto doesn't handle this correctly and there are a couple of issues about it. ___ HOT mailing list HOT@openstreetmap.org https://lists.openstreetmap.org/listinfo/hot
Re: [HOT] GNS name merging discussion thread
Hi,
For what it is worth, I am finding these additional imagery sources very
helpful in northern Liberia, I have no idea what their coverage is for
other parts, but so far they are great for my current square and have
already been used in that area as they show up in the source fields of
existing nodes:
tms[22]:http://imagery.openstreetmap.fr/tms/1.0.0/ebola_spot6/{zoom}/{x}/{y}
tms[22]:http://imagery.openstreetmap.fr/tms/1.0.0/ebola_spot6_nir/{zoom}/{x}/{y}
These are URLs for JOSM, and you must accept the Astrium / OSM license
(http://tasks.hotosm.org/license/6) before accessing them.
Use source=Spot-6, Airbus
They are cleared for at least some use on this project per the wiki page:
http://wiki.openstreetmap.org/wiki/2014_West_Africa_Ebola_Response#Spot-6
Is there any reason we can't use these where they help for the GNS
naming project?
Regards,
Blake Girardot
___
HOT mailing list
HOT@openstreetmap.org
https://lists.openstreetmap.org/listinfo/hot
Re: [HOT] GNS name merging discussion thread
Blake
There is no problem to use these imageries. They have been provided by Airbus
Space Defence for this activation.
For the source reference, simply specify this imagery if you use it to
geolocate the places.
Pierre
De : Blake Girardot bgirar...@gmail.com
À : hot@openstreetmap.org
Envoyé le : Jeudi 14 août 2014 21h54
Objet : Re: [HOT] GNS name merging discussion thread
Hi,
For what it is worth, I am finding these additional imagery sources very
helpful in northern Liberia, I have no idea what their coverage is for
other parts, but so far they are great for my current square and have
already been used in that area as they show up in the source fields of
existing nodes:
tms[22]:http://imagery.openstreetmap.fr/tms/1.0.0/ebola_spot6/{zoom}/{x}/{y}
tms[22]:http://imagery.openstreetmap.fr/tms/1.0.0/ebola_spot6_nir/{zoom}/{x}/{y}
These are URLs for JOSM, and you must accept the Astrium / OSM license
(http://tasks.hotosm.org/license/6) before accessing them.
Use source=Spot-6, Airbus
They are cleared for at least some use on this project per the wiki page:
http://wiki.openstreetmap.org/wiki/2014_West_Africa_Ebola_Response#Spot-6
Is there any reason we can't use these where they help for the GNS
naming project?
Regards,
Blake Girardot
___
HOT mailing list
HOT@openstreetmap.org
https://lists.openstreetmap.org/listinfo/hot___
HOT mailing list
HOT@openstreetmap.org
https://lists.openstreetmap.org/listinfo/hot
