[Imports] TMC LCL - help needed

[Sam Vekemans]

Ya, but the concept is still the same.

Making the complete.osm out of practice, so then it becomes part of
the package that is available. It also serves as a record in the
archives, so incase someone wants to create an extract and/or remove
that data, by having the origional available, its a simple process.

And if a separate tile render openlayer needs to be made, it can be
set up rather   easily.

In other words, its creating a 'reciept -paper trail' of the
contributing data. And doubles up on the 'attribution' requirement.

And ya, i'll rework the wording :)

Sam

On 10/8/09, Michael Barabanov <michael.barabanov at gmail.com> wrote:
> Regarding 3.3, I don't think the current workflow supports working with
> .osm.
> IIRC, Steve Singers's scripts rely in .gml being available at the time of
> RoadMatcher result processing.
>
> On Thu, Oct 08, 2009 at 10:56:27AM -0700, Sam Vekemans
> (acrosscanadatrails at gmail.com) wrote:
>> Hi,
>> in the next week, i'll update the wiki 'importing government (bulk
>> provider) data' and list the 3-step approach.
>>
>> If i get through on the conference call today, i'll try to explain it,
>> and maybe someone else who is a better wikipedian can fix it. :-)
>>
>> Step 1: Data conversion
>> -using eithor 'shp-to-osm.jar' or 'shp2osm.py' or 'mp2osm' or 'other'
>> we make a conversion script
>> -1 person is in charge of editing this script (as users will submit
>> errors) (just as for other programs)
>>
>> Step 2: data sharing
>> -the person that is running the conversion script would make these
>> .osm files available to the community so people can see it.
>> -available on a server somewhere like mediafire.com
>>
>> 3 -data import
>> eithor a.1 use josm and copy the features over
>>                 -if using shp-to-osm, the coversion script can create
>> .osm files that are smaller than 2,000 points so it's nice for the API
>> to handle
>>          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)
>>          3.3 use a postGIS database and use OpenJUMP Automatch to
>> compare datasets.
>>
>> Note:
>> the steps above put emphasis on simply making the data available, and
>> creating a custom conversion utility tool.
>>
>> The facts that remain are;
>> 1 -the available data is constantly changing, so creating a conversion
>> utility tool, and having the 'tag matching list' be maintained by 1
>> person, will make it easier for everyone to work with the data.
>>
>> 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.
>> Rather than the current emphasis on "Hey there's more data, lets import
>> it".
>>
>> Hope that makes sense,  I'll work at it more later :)
>>
>> Cheers,
>> Sam
>>
>> --
>> Twitter: @Acrosscanada
>> Blog:  http://Acrosscanadatrails.blogspot.com
>> Facebook: http://www.facebook.com/sam.vekemans
>>
>> _______________________________________________
>> Imports mailing list
>> Imports at openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/imports
>


-- 
Twitter: @Acrosscanada
Blog:  http://Acrosscanadatrails.blogspot.com
Facebook: http://www.facebook.com/sam.vekemans
OpenStreetMap IRC: http://irc.openstreetmap.org
@Acrosscanadatrails