OK, I'll retest with these changes. Thanks!
Mike On 7/24/12 6:08 PM, "Even Rouault" <even.roua...@mines-paris.org> wrote: >Le lundi 23 juillet 2012 19:25:22, Smith, Michael ERDC-CRREL-NH a écrit : >> Even, >> >> [osmusr@bigserver-proc osm]$ ogr2ogr -progress -f oci >> oci:user/pass@tns:tmp planet-latest.osm.pbf -lco dim=2 -lco srid=4326 >>-lco >> geometry_name=geometry -lco launder=yes --debug on 2>osm_debug.log >> 0...10...20...30...40...50...60Š70 >> [osmusr@bigserver-proc osm]$ >> >> >> >> From the debug output >> > >Michael, > >The debug output would suggest that there was no more data to process, >which >is strange. I've tested a bit with a planet file dating back to a few >weeks, >with a modified OSM driver that does basically no processing except the >parsing, and it managed to parse until the end of file. So in your >situation, >I'd assume that there was a parsing error, but I'm not 100% positive >(might be >something wrong in the "interleaved reading" mode ?) > >I've commited in r24707 a change that is mainly a custom indexation >mechanism >for nodes (can be disabled with OSM_USE_CUSTOM_INDEXING=NO) to improve >performances (Improve them about by a factor of 2 on a 1 GB PBF on my PC) >Along with that change, I've added some facility for extra error outputs. >If a >parsing error occured, an error message will be printed. And, before >recompiling, you can edit ogr/ogrsf_frmts/osm/gpb.h and uncomment (by >removing >the // at the beginning of //#define DEBUG_GPB_ERRORS) line 40. This >should >report a more precise error if there's something wrong during the GPB >parsing. >You might also retry with --debug OSM and, at the end of the processing, >you'll see a trace "Number of bytes read in file : XXXXXXXXXXX" : you can >check >that the value is the same as the size of the PBF file. > >Even _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
