<div dir="ltr"><div><div><div><div><div>Having a place=unknown instead of a place=hamlet won't slow the process down I think.<br><br></div>When the names have a tag that doesn't belong in the DB, you can adapt your workflow to it:<br><br></div>1. Merge all UN names in JOSM into the existing OSM data layer (so you're only working in one layer)<br></div>2. Randomly check nodes.<br>2.1: Look for duplicates, merge them if needed.<br>2.2: Evaluate the place type (hamelet, village or even bigger) and adapt it. If you have a node with place=hamlet on your clipboard, you can simply CTRL+SHIFT+V the tag on the existing node, and lose almost no time.<br></div>3. When it becomes hard to find new nodes, search for "place=unknown" to highlight all nodes that aren't checked (only a CTRL+F and Enter away after your first search)<br></div><div>4. continue working until there are no more place=unknown nodes, or until all place=unknown nodes are under a cloud.<br><br></div><div>This way, you change the tag to mark your work (on that node) as "done".<br><br></div><div>The other workflow would be a bit harder wrt merging nodes. When you use the layer difference to mark nodes as done, and move every node individually from the import layer to the data layer, that costs more work. Having to compare names over different layers also causes more layer switching.<br><br></div><div>So I'm not necessarily against having a place=unknown tag to start. I don't think it will slow down the process at all.<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2014-09-15 18:25 GMT+02:00 Rafael Avila Coya <span dir="ltr"><<a href="mailto:ravilacoya@gmail.com" target="_blank">ravilacoya@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<br>
</span>Hi, Christoph:<br>
<br>
I got your point. In fact, I added place=unknown as the tag you have<br>
to put for those nodes whose place type cannot be verified, like when<br>
lowres imagery, clouds, etc.<br>
<br>
What I don't see is your concern on giving all nodes the default value<br>
of place=hamlet (80-90% of the nodes fall in this type for Liberia)<br>
and not place=unknown, that would make mappers to change almost 100%<br>
of the values (quite annoying). This import is manual, and done<br>
through the HOT Tasking Manager, so we can keep very easily trace of<br>
what every mapper involved is doing. Every task can be validated by a<br>
second mapper, and hopefully I will do some follow up on the first<br>
tasks done by every mapper, so checking if they are doing well, not<br>
only with the place type but with all the steps of the process.<br>
<br>
Moreover, if you pay attention to the workflow, all nodes are checked<br>
by the importing user using the TODO List plugin. Chances that they<br>
miss checking the place type are really low, as they have to mainly do<br>
2 things:<br>
<br>
1. Check if there is any duplicate. In case there is, conflate them.<br>
2. Check that the place=hamlet is correct, and change it if it is not.<br>
<br>
Do 2 or 3 tasks and you find yourself doing a mechanical job that<br>
makes it really difficult to miss that point, if not impossible. I've<br>
participated in several jobs like this, and I find it really hard to<br>
miss any step when trained. And everyone makes a last review of the<br>
task before uploading, whether for this job of for any other one.<br>
Plus, the validation process.<br>
<br>
The aim of giving place=hamlet instead of place=unknown as default is<br>
clear: make easier and faster the import.<br>
<br>
Cheers,<br>
<br>
Rafael.<br>
<span class=""><br>
On 15/09/14 20:44, Christoph Hormann wrote:<br>
> On Saturday 13 September 2014, Rafael Avila Coya wrote:<br>
>><br>
>> Changing the place value is really fast (+/- 5 seconds).<br>
><br>
> You are missing my point here i think - giving nodes a tag based<br>
> on the vague assumption that for the majority of them this will be<br>
> correct is inconsistent with the idea of a responsible import.<br>
> There is no information in this and you cannot determine for a<br>
> node in the database afterwards if its tag has been diligently<br>
> determined from reliable information or if it is just the<br>
> automatic default.  As a result even the hard work of those doing<br>
> actual verification on the data is devalued since a place=hamlet<br>
> does not tell if it has been verified against images/local<br>
> knowledge or if it has just been pushed as it is into the<br>
> database.<br>
><br>
> If you want to responsibly perform this import and appreciate the<br>
> work of those participating in it you should convert the data with<br>
> reasonable defaults that do not imply any knowledge of the places<br>
> you do not have (like place=unknown) and clearly instruct those<br>
> doing the import to only change this after individual assessment<br>
> using reliable information from other sources.  That way you can<br>
> later assume for a node tagged place=hamlet that this has been<br>
> verified (unless it has been uploaded as part of a changeset<br>
> containing 1000 nodes all tagged place=hamlet in which case the<br>
> mapper involved has probably taken the shortcut... ;-)<br>
><br>
<br>
</span><span class="">- --<br>
Twitter: <a href="http://twitter.com/ravilacoya" target="_blank">http://twitter.com/ravilacoya</a><br>
<br>
- --------------------------------<br>
<br>
Por favor, non me envíe documentos con extensións .doc, .docx, .xls,<br>
.xlsx, .ppt, .pptx, aínda podendoo facer,  non os abro.<br>
<br>
Atendendo á lexislación vixente, empregue formatos estándares e abertos.<br>
<br>
<a href="http://es.wikipedia.org/wiki/OpenDocument#Tipos_de_ficheros" target="_blank">http://es.wikipedia.org/wiki/OpenDocument#Tipos_de_ficheros</a><br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v1.4.10 (GNU/Linux)<br>
Comment: Using GnuPG with undefined - <a href="http://www.enigmail.net/" target="_blank">http://www.enigmail.net/</a><br>
<br>
</span>iQIcBAEBAgAGBQJUFxMAAAoJEB3niTly2pPQC38P/0GMBWHVRErDd3abmtC/cipE<br>
uD5U3pEi6rN2UhTDZN2Ib14kyAaUzlV70TTN/f+EKc2CYdtYb/0NsWmZK/YC9fV1<br>
vsovmy9cOrzh6CSkDlU7rvS7H/oVeNjJFjpShCp3EpcAAgdmuUKaGZIusnMCA2Pm<br>
yZUAtYhucm9kzHVFdZCXCxK8Nf+nDztG8HbB80LBnelQ3Oft4EJyFf10em/VP/i4<br>
UErRmzXgHLvy7HnWjgS/EhyK1bWYtCgZXOW9Ez+weVTVZweSB5Ekw63CUwgfWvSf<br>
vtSWyQJHRM6Xd0z47nBf8Zj+EZ52hXfCM1sMcX3YnUypoj6RilywXZuaLI5qLLGW<br>
2wPo+PETmuqd1wgZeBkxYceFah3OXg6oBUqImXIOn8z/UOyIUxJUeN3Zipg3m1zf<br>
fhmTyteRnfzSQSstaexQga3DPIesuyj99wtFk1eopHgFFRDWVvmzsK8XNvFUkuo+<br>
bnh/LqPXNhLEx4U2AIs1SBeedGN1yBhDyhfvFao7C4EwWmLkKi18zjHtaxT5044t<br>
zP3CgLfWNKabQCJWmLokiNyKNS3SrEiU5EZ39Fu8kqlZrLgB8SmVOvoCeWVVNgH8<br>
tvKqtolf/A2VwBoszDDTAECCmUXzGFO4OG3o1yUCWKVP5fCpFPAnzK4KZBIyaGOy<br>
ZtuNN9vOBKNFuWHhbMdj<br>
=ue08<br>
-----END PGP SIGNATURE-----<br>
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
Imports mailing list<br>
<a href="mailto:Imports@openstreetmap.org">Imports@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/imports" target="_blank">https://lists.openstreetmap.org/listinfo/imports</a><br>
</div></div></blockquote></div><br></div>