[gdal-dev] Slow convertion from OSM to PG with -skipfailures

[Martin Feuchtwanger]

No, Even,  i'm certainly not sure. It's just that when i first tried it 
(with flags) it was taking several days to convert a large GDB file, and 
when i tried without flags, only a few hours. (I guess it's only one 
order of magnitude different!) It's quite possible that is was some 
other factor i wasn't aware of. I only posted because it seemed to 
relate to Jukka's issue.

I'm not complaining about ogr2ogr -- it came through for me in the end :-)

Martin Feuchtwanger  feumar at shaw.ca  604-254-0361
http://members.shaw.ca/geomatics.developer
skype: martin.feuchtwanger

On 28/05/2013 11:16 AM, Even Rouault wrote:
> Le mardi 28 mai 2013 19:49:40, Martin Feuchtwanger a écrit :
>> I was having a similar complaint (which i kept to myself at the time)
>> when using *ogr2ogr*.  In my case, converting GDB file to PG database.
>>
>> First i used some flags, -a_srs -lco -nln, but these turned out to be a
>> massive waste of time (several orders of magnitude). So instead i kept
>> to the defaults and made desired changes manually after the fact, in the
>> DB.
> Martin,
>
> Are you really sure about that ? This would be interesting if you could
> demonstrate that with examples. My belief is that -a_srs and -nln cost should
> be near 0 compared not to using them. They are only used to setup layer
> creation. The effect of -lco of course depends on the option and driver used,
> so there's no general rule to draw about this one.
>
>> Maybe there should be some stern warnings in the documentation when
>> "luxury" options are computationally expensive?
> We also accept documentation contributions :-) But performance depends
> sometimes on many factors and it is difficult to capture them.
>
>> Then users would be less
>> likely to judge ogr2ogr as a poor performer.
> I believe that ogr2ogr is generally considered as a good performer. But
> funding can sometimes help implementing improvements :-)
>
> Best regards,
>
> Even
>