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 feu...@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
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
