[Imports] TMC LCL - help needed

[marcus.wolschon at googlemail.com]

On Fri, 9 Oct 2009 04:44:16 -0700, Sam Vekemans
<acrosscanadatrails at gmail.com> wrote:
>> The concept is the same.
> 1. convert
> 2. share and
> 3. import manual (josm) / automatic (bulk_upload) / semi-automatic
> (road_matcher/automatch)

How does adding tags to existing objects work with regard to
concurrent edits?
Finding the correct object to add something to involves
searches that are only offered on OSM-databases that are
only updated regularly, not constantly.



>> That's what we do for everything that cannot be automatically imported.
>> I had to add even more warnings as despite quite a lot of fat warnings
>> people DID upload some of these reference .osm -files directly.
>>
>> the nature of the beast :).  ... which is why i want to be making the
> rivers (geobaseNHN data) available at the same time, and only for those
> areas that have roads already imported.  (so to save people work)

How would that solve the issue of people uploading the reference .osm
-files
used for a manual compare in JOSM?

I'm just providing the areas in this step. Roads, Segments and Points will
follow later.

>> >          3.2 use bulk_import.pl for direct api load (for large areas,
>> > if given permission to access the API at non-peak hours, and on que)
>>
>> "que"?
>>
> 
> On the status chart

What status-chart? You mentioned a peal-script. Last time I
checked pearl was a programming language and did not provide
any charts ;) .



>> >          3.3 use a postGIS database and use OpenJUMP Automatch to
>> > compare datasets.
>>
>> Never heard of that but the LCL-map if extremely simplified. I don't
>> think
>> the complex matching needed can be done by a generic tool.
>>
>> It just helps by finding exact matches, and highlights where it couldn't
> match right based on a set of rules.
> .... thats why i prefer having the .osm files available, and letting
local
> people copy what they like. (avoiding openJUMP all together)

I see. You would only have exact matches if you had already merged
and applied the new tags to the corresponding element (e.g. a complex
motorway-junction representing a single point that is getting imported).
Thus the tool would require you to do the job that it was intended to
perform in the first place.


>> > The facts that remain are;
>> > 1 -the available data is constantly changing
>>
>> Not much changes to LCLs expected here. But many other countries with
>> lots of TMC-providers may follow. That's why I took so much care my
tools
>> are well written and easy to understand for a developer.
>>
>>
> In Canada it's speratic, and somethings would be 6 months for a partial
> update and 1 year for full update.

I guess you mean "sporadic". That's quite often for an LCL-update.
Given that all manufacturers of navigation-devices need to incorporate
it into their new releases.

>  and sometimes the source features tagging gets changed too.

What do you mean by "source features tagging"?
What do you mean by "source features"?

>>  > utility tool, and having the 'tag matching list' be maintained by 1
>> > person, will make it easier for everyone to work with the data.
>>
>> What do you mean by 'tag matching list'?
>>
>>
> with shp-to-osm the rules.txt lists the tag matches (source=osm)
key/value
> comparisions.

TMC LCLs have nothing to do with shape-files. There is no shp-to-osm.
(Please look at the subject-line of this thread.)


>> > By making it available, we can let the users decide what they want to
>> > add, or omit. and put the emphasis on simply making all available data
>> > available to use when and if we want.
>>
>> Sounds less like hints for people doing an import then general advice
>> for people offering datasets to import.
>>
>> lost me there, it's learning for everyone IMO :)

Well. I'm asking about comments and practical advice on how to
organize this one import.
It's the first time I'm organising such a thing and lots of other
people have already imported lots of other data.

> ... i just ask that they make the .osm files available rather than direct
> upload so local area mappers can copy in the data.  .. so where elements
> are
> existing, its up to the local area mapper to decide on what to add, or
not
> to add, and how or if they want to merge it.  That decision shouldn't be
my
> own to make remotly.  (not having being physically been in the area).

I guess if your import is about adding tags to existing objects then
any .osm you provide will be outdated and no longer match the current
elements in OSM within minutes.

1. search OSM for the correct element
2. add the new tags to import to it
3. upload it
4. goto 1 if another mapper has changed the object between 1. and 3.

Marcus