Thanks Richard for attending that call :) (i wanted to, but wasnt humanly possable) That request is not unreasonable, right now my "data conversion script" says 5,000 but i can change that to 2,000. Ian's simple shp-to-osm.jar can now handle any arbitrary number. When the script 'chokes' its because its a big polygon of 'water' or 'wood', and thats fine to even exclude as (most of the time) that estimate is way off (trees were cut since survay). And its also why the basic 'building=yes' nodes are requested to be removed. (as stated in the README file)
Also, making the roads.OSM files available to copy, instead of 'direct import' was the 'method to my madness' (of needing detailed chart to handle the fun) :-) Thanks again, Sam On 9/10/09, Frank Steggink <stegg...@steggink.org> wrote: > Hi Richard, > >> This approach makes for many more change sets and each change set is >> likely to be a single object of some sort. They still have to break >> these up further if the single relation is too big, but they aim for a >> changeset of about 1,000 items total. >> > Too bad that the NTS tiles usually contain more data, even in rural > areas. But I can understand the reasoning. It keeps imports more > manageable. Importing data is not just making sure the data gets on the > server, but also verification, eventually clean up, making connections, etc. >> I'm finding frequent upload failures when dealing with changesets >> larger than about 16,000 nodes. Because of the nature of these change >> sets, I can end up dropping thousands of unconnected nodes all over >> the place. Messy. ;-) >> > Did you use the bulkload script? I had the same issue with my very first > import attempt last week, and cleaned up the 7000 nodes by downloading > the changeset, adjust the XML, and upload that with JOSM. > > Since that, I've used JOSM, but uploading is very slow. On average it > takes about 1 hr to upload 8000 changes, but so far it has only hung on > me once. That happened last Saturday. Probably there was some > maintenance going on. >> One other approach that the French community is taking is to use >> postGIS to detect objects that overlap similar objects that already >> exist. This is analogous to roadMatcher and it works on more object >> types, directly in the (local) database. >> > Sounds interesting. Did they mention how they would do it? When buffers > are used for example, it is easy to exclude roads which happen to run > parallel along existing ways... But anything better than Roadmatcher is > actually a win ;) >> There promises to be more information coming from the French community >> and the rest of the import group in the next while. I hope that those >> in the Canadian community, particularly those developing tools can >> consider these two approaches. >> > Keep up informing us about it :) > > Regards, > > Frank > > > _______________________________________________ > Talk-ca mailing list > Talk-ca@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-ca > -- Twitter: @Acrosscanada Facebook: http://www.facebook.com/sam.vekemans _______________________________________________ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
