sly (sylvain letuffe) wrote:
The 'mechanisms' that we use MUST be managed centrally,
What are you talking about ? What "mechanisms" are you refering to ?
Simply the methods by which data is added to the database.
And all I am trying to understand now is why if we HAVE digital data to work
with for which further versions will be provided over the coming decades someone
has to manually check every line every year or so? This data was in the
database, so only the changes needed to be posted, but a mistake was made. We
learn from mistakes and so what I am trying to learn is if we could have HELPED
by reducing the chance of the mistake? By providing tools that take advantage of
the data and process it in a way that it is more useful ... in a format that is
compatible with later importing to OSM.
I know there is something of a 'cultural' thing here and that has some
involvement in the recent problems, but at the end of the day we all just want
to help, and 'diving for the shelter' does not help. Fresh eyes and computing
power can provide an alternative view ... but it would still be nice if we had a
core mechanism that said 'this is a raw import from xxx and it's id is yyy'?
It's the 'id is yyy' that seems to be the stumbling block with some people? But
I currently see no way to develop an automated update process without.
I see no reason that even if the raw data has no internal id we can't add that
via the import process? I do it all the time with the raw data I'm being
supplied, and now the sources are using my id's to improve their end.
Unfortunately not usable mapping stuff though.
--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
_______________________________________________
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
