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 <[email protected]> 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 <[email protected]> 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 >> ([email protected]) 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 >>> [email protected] >>> 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 _______________________________________________ Imports mailing list [email protected] http://lists.openstreetmap.org/listinfo/imports
