[Imports] Import of 14, 020 United Nations Mission in Liberia place nodes

Rafael Avila Coya ravilacoya at gmail.com
Tue Sep 16 17:36:56 UTC 2014


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi, Sander:

On 16/09/14 02:00, Sander Deryckere wrote:
> Having a place=unknown instead of a place=hamlet won't slow the
> process down I think.
> 
> When the names have a tag that doesn't belong in the DB, you can
> adapt your workflow to it:
> 
> 1. Merge all UN names in JOSM into the existing OSM data layer (so 
> you're only working in one layer) 2. Randomly check nodes.

If you read the workflow wiki (
https://wiki.openstreetmap.org/wiki/Import_Liberia_UNMIL_Places_Workflow
) you'll see that we don't check the nodes randomly, but one by one
using the JOSM TODO List plugin. So it is not possible to miss any.
This has been done already for other similar imports.

Cheers,

Rafael.

> 2.1: Look for duplicates, merge them if needed. 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. 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) 4. continue working
> until there are no more place=unknown nodes, or until all
> place=unknown nodes are under a cloud.
> 
> This way, you change the tag to mark your work (on that node) as
> "done".
> 
> 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.
> 
> 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.
> 
> 2014-09-15 18:25 GMT+02:00 Rafael Avila Coya <ravilacoya at gmail.com 
> <mailto:ravilacoya at gmail.com>>:
> 
> Hi, Christoph:
> 
> I got your point. In fact, I added place=unknown as the tag you
> have to put for those nodes whose place type cannot be verified,
> like when lowres imagery, clouds, etc.
> 
> What I don't see is your concern on giving all nodes the default
> value of place=hamlet (80-90% of the nodes fall in this type for
> Liberia) and not place=unknown, that would make mappers to change
> almost 100% of the values (quite annoying). This import is manual,
> and done through the HOT Tasking Manager, so we can keep very
> easily trace of what every mapper involved is doing. Every task can
> be validated by a second mapper, and hopefully I will do some
> follow up on the first tasks done by every mapper, so checking if
> they are doing well, not only with the place type but with all the
> steps of the process.
> 
> Moreover, if you pay attention to the workflow, all nodes are
> checked by the importing user using the TODO List plugin. Chances
> that they miss checking the place type are really low, as they have
> to mainly do 2 things:
> 
> 1. Check if there is any duplicate. In case there is, conflate
> them. 2. Check that the place=hamlet is correct, and change it if
> it is not.
> 
> Do 2 or 3 tasks and you find yourself doing a mechanical job that 
> makes it really difficult to miss that point, if not impossible.
> I've participated in several jobs like this, and I find it really
> hard to miss any step when trained. And everyone makes a last
> review of the task before uploading, whether for this job of for
> any other one. Plus, the validation process.
> 
> The aim of giving place=hamlet instead of place=unknown as default
> is clear: make easier and faster the import.
> 
> Cheers,
> 
> Rafael.
> 
> On 15/09/14 20:44, Christoph Hormann wrote:
>> On Saturday 13 September 2014, Rafael Avila Coya wrote:
>>> 
>>> Changing the place value is really fast (+/- 5 seconds).
> 
>> You are missing my point here i think - giving nodes a tag based 
>> on the vague assumption that for the majority of them this will
>> be correct is inconsistent with the idea of a responsible
>> import. There is no information in this and you cannot determine
>> for a node in the database afterwards if its tag has been
>> diligently determined from reliable information or if it is just
>> the automatic default.  As a result even the hard work of those
>> doing actual verification on the data is devalued since a
>> place=hamlet does not tell if it has been verified against
>> images/local knowledge or if it has just been pushed as it is
>> into the database.
> 
>> If you want to responsibly perform this import and appreciate
>> the work of those participating in it you should convert the data
>> with reasonable defaults that do not imply any knowledge of the
>> places you do not have (like place=unknown) and clearly instruct
>> those doing the import to only change this after individual
>> assessment using reliable information from other sources.  That
>> way you can later assume for a node tagged place=hamlet that this
>> has been verified (unless it has been uploaded as part of a
>> changeset containing 1000 nodes all tagged place=hamlet in which
>> case the mapper involved has probably taken the shortcut... ;-)
> 
> 
> 
> _______________________________________________ Imports mailing
> list Imports at openstreetmap.org <mailto:Imports at openstreetmap.org> 
> https://lists.openstreetmap.org/listinfo/imports
> 
> 

- -- 
Twitter: http://twitter.com/ravilacoya

- --------------------------------

Por favor, non me envíe documentos con extensións .doc, .docx, .xls,
.xlsx, .ppt, .pptx, aínda podendoo facer,  non os abro.

Atendendo á lexislación vixente, empregue formatos estándares e abertos.

http://es.wikipedia.org/wiki/OpenDocument#Tipos_de_ficheros
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQIcBAEBAgAGBQJUGHUoAAoJEB3niTly2pPQHY4P/02ftiH/Wd86G5nqWHhxjQvw
fk6pBMwBxmUNc6/fEXh/rRFPoAkzIh3Xaw59iTqY0FU9cnKKI4zmt/m7TDsOau68
Um8bU1r/ZSEd5i+UVbsa9xScNK/LL34jTCuLG/qrJMj1mh5NMR73DlitVvHncz7P
4JJdGX0ae9JFrR+5ZXezMKTeNYTlnk6xFO498r5/9ZOtA/B9aHfhkqag/HNXTMgo
Fk9xrz9pGIHvLRiI8xX7MZr/5mk3vXkJw95WyMH4w+mv5mupfM9OhxYrkACOGyBg
UGRApf5Dm+kF76PgmNrT7FaflTKilzFyse8RmzkrfVidRnKNxFae62NMVWv7JnUM
ck653BWATx9h4y71fZJA94OyNxvt+x7BH9m6cgYuPLm3PoDrzsaKaW+LHT4kya0P
FXK69NzEm9L2vQQ61+kLoXuJCSWoC4n7I0ZteTpeyGi1tnyRfdWYF3oEZm7CPfui
+cT7dk56bmI80871s4v5qpgXdKFAZKTzb3Lj5TR5vuwPJJr53HkjJj+ZMsieRjlR
3+fRs1SXV+QNp+yTWXT9cWQF2y7Jzq1joFmZ5Ge4JaWSGABq9wB+NVdc7ooxW2Yy
y3+EgvLw/v1QFgaD3Q8AdQce90tEeAomWPBcZiyGuI8ECgGGRz3kbAsma0+NFRAk
gLbwxznTD7njAu4x0Vk4
=LOu9
-----END PGP SIGNATURE-----



More information about the Imports mailing list