Abel,
I am interested in proportionate 3 ways of proceeding when a used calls
translation from one format to our format.
way 1: force to write V1.1 and stop writing features if the limit is reached.
way 2: force to write V2.0 (and stop writing features if the limit is reached
(it will no happen in a near future, I think)).
way 3: leave that the program decides if V1.1 is not enough and then it changes
automatically to V2.0. It does it in the middle of the process, when FID or
some used internal offset gets the limit.
Not knowing anything about the ecosystem of the miramon format, but
ideally I would bend on the side of simplicity if possible, and I would
just write V2.0 if V1.1 can be considered as a legacy format, that
deserves perhaps only read-only support (at our times of terabytes+
storage capacity, the saving of 4 bytes per feature seems like a
anachronic concern). But if you really want to use V1.1 when possible
and V2.0 only when possible, and provided that you implement the writing
of the final file only at dataset closing as it was my understanding,
then you know already the max(FID) of features that have been passed to
CreateFeature, so you could decide automatically the version needed. I
would strongly discourage starting writing a V1.1 file and then
switching to V2.0 in the middle of the writing. That sounds like a
serious complication.
So, my questions:
1.- Which ogr2ogr parameter is the best for doing that?
-f? specificating "MiraMon V1.1" or "MiraMonV2.0" or "MiraMon"
(automatic way).
If you really need to implement the 2 formats, a dataset creation option
in a single driver would probably be better.
Or there is another way I haven't seen (I've read all options in
https://gdal.org/programs/ogr2ogr.html#ogr2ogr)
2.- When using -progress some points appear on screen informing the progress.
At the end of the progress (or sometimes driver requires) there is a gap of
time that driver is writing some pendant information.
-progress works by counting the number of features in the source layer,
and computing the progress percentage at each call to CreateFeature()
There is any way to inform the user what the process is doing?
Not really. You could possibly implement it using CPLDebug() statements
if you want to monitor the progress in debug mode (the GeoPackage driver
implemets something similar during spatial index writing, which can be a
long operation), but there's nothing dedicated in the OGR API or ogr2ogr
to monitor the progress of long operations occuring during dataset
closing, as most drivers don't need that.
Even
--
http://www.spatialys.com
My software is free, but my time generally not.
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
