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

Reply via email to