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

Rafael Avila Coya ravilacoya at gmail.com
Tue Sep 16 18:09:30 UTC 2014


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

Hi, Frederik:

I agree completely that an import doesn't have to be fast. In fact, I
already said that in the last email answering you about this.

I think it's my fault that I didn't explain myself well. When I was
telling why I think it's a good solution to set all nodes with
place=hamlet as default, and said that the reason is to make the
import "easier and faster", I really wanted to say that it makes
easier and less tedious the work for each mapper with each HOT TM
task. But this, of course, doesn't mean the import will be faster or
slower. The time we will need to complete the import will depend on
how many volunteers contribute, how much time they dedicate per day,
etc. If you read the workflow, you can see that the main goal of the
import is to do it the most accurate and consistent as possible.
Whether it results faster or slower is secondary.

I think Andrew already said that this data is already available for
the humanitarian orgs in the field. That's not the question. This
import is interesting because:

1) It will add thousands of new nodes to the OSM database.
2) It will correct and add info to the UNMIL data (like place type)
that is not present in the UNMIL original data, and that info will be
in the OSM database.
3) It will merge with the current OSM data (that has plenty of GNS
sourced nodes), and therefore enrich the OSM data.

In other words, the result of the import will be a database (OSM)
richer and more correct than UNMIL or GNS databases themselves.

Cheers,

Rafael.

On 16/09/14 04:25, Frederik Ramm wrote:
> Hi,
> 
> On 09/15/2014 06:25 PM, Rafael Avila Coya wrote:
>> The aim of giving place=hamlet instead of place=unknown as
>> default is clear: make easier and faster the import.
> 
> An import does not, and should not, have to be fast. As I said
> before - if you need the data fast, don't (ab)use OSM as a
> transport medium, transport it without OSM instead and you can have
> a random hacker convert it in a day. If, for example, your target
> was Garmin maps, you could simply mix-in the data with OSM at the
> mkgmap stage.
> 
> Of course OSM would benefit from having good data as well, but not 
> from having fast data.
> 
> Bye Frederik
> 
> 
> _______________________________________________ Imports mailing
> list 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/

iQIcBAEBAgAGBQJUGHzPAAoJEB3niTly2pPQjA4P/0GMizMrU7GWgS5tio/Jvgn2
M+Mn9Wj1kLXhZsMcW31KvcERSIIPFHKdK34HvUKBxh59e+3on4x2HhU1pNpAVvqa
I0z4W0dzEjTcvi3dBL5SL7QoXYqvE3DNFf4sLQdEQkwAG59wC7MDoBMyunV/4PzF
ojtu11U5HhQ4W2Z1O4hNnMZdvqvWHDP7E82p6ZJvKYeZhlbK0HtXHUgHy1p7pwSC
nRnKhFPKuD98uD9vi29/nw17Fm0OqP1GJfmLsnMZaK4oY0ttf+pPkHXQcktQCgVL
6zx90Sj3V6Gf5w7wYfZsVCUi3Eoyi6G3ZEyjOH8mIWRrPdpBSW8H0eOxcxJD9dPe
bEMzZISWMJm0rPEA5w6ipyHtXKppz5sDHrSnkmEmh3EkiMexYIL8nz3CPEZ8PAIl
ynrtU3EWVhTBRhQJRJDatWeSsBEMY9Ovavf5rYhZCgyvNt7WHJxsghvVzH60E5Uq
H8H9SCKsX4ehX7PeBk1u+jjS6tn/7I5sxisf9E86EBSSaQZupOeLbXOOIhh9/g+l
lv+cAviI47ElvD+S2F8Ce/AVHGR7vmky+VCq/FmuDIjtq0++Mxa1teduvcLUw0Ho
XHCstZEuk6tTKsiOhcxOVHQ3omrJLJpTrlTEPNUhzyn40pyMxgExAbqTXVEUX2nI
7EPJV27E4lDrBj4cgn8J
=G4aT
-----END PGP SIGNATURE-----



More information about the Imports mailing list