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