[Imports] TMC LCL - help needed

[Sam Vekemans]

It should really be called 'gml2osm' as its not the shp files that get used.
Gml files are dealt with slightly differently than shp.

On 10/8/09, Sam Vekemans <acrosscanadatrails at gmail.com> wrote:
> 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
>


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