[gdal-dev] CopyLayer oddity using GML driver
even.rouault at mines-paris.org
Tue Nov 22 17:57:00 EST 2011
> Hm, after some thinking I think the best approach is to construct the
> original SQL to assign XML-valid column names. The same change
> can/should be done in for the WFS DescribeFeature response. The the
> CopyLayer method should work ok (seems so after initial tests).
My initial thought was : "let's fix/improve CopyLayer() to deal with field
renaming as ogr2ogr is able to do". But for your use case, it is clear that
you want to control precisely what is done, so that GetFeature and
DescribeFeature are consistant. And it is clear that we might expect
CopyLayer() to able to do all what ogr2ogr is able to do, which would be a lot
of long and duplicated efforts.
What follows doesn't directly address your problem, but all the above is an
opportunity to write down an idea I had mentionned very quickly some time ago
on IRC. Basically, it would consist in making a library (a new one
"libgdalutils" or directly integretated in the core GDAL lib) from all the
source code of our C/C++ utilities that other code could call without spawning
a process, and benefit from progress callbacks more easily.
So for the case being discussed above, you would have (very rough idea!) the
following function :
OGRDataSource* GDALUtils_ogr2ogr(const char* pszCommandLine, OGRDataSource*
inDS, GDALProgressFunc pfnProgress, void* pProgressData);
where the pszCommandLine argument would have the same syntax as the current
C++ utility, plus some bonuses like being able to pass directly the input
datasource instead of a real file. In that case, it would be decided as a
convention that [INDS] would be substituted with the provided inDS argument.
outDS = GDALUtils_ogr2ogr("-f \"GML\" /vsimem/out.gml [INDS] ...", inDS, NULL,
Several advantages :
* You can operate on in-memory datasources.
* Such an approach would also be quite suited to be easily incorporated to our
* Generally, new options could be added to utilities without affecting the API
(but perhaps we have already too many options!). But if you want to add new
"[MAGIC_KEY]" options, you have a problem. Not sure there's a perfect solution
for that. A workaround I had imagined would consist in passing a list of
strings like "INDS=0x12345678" where 0x1234578 is a pointer to the datasource.
But this approach it quite unsafe and unusual (although we have a precedant
with http://gdal.org/frmt_mem.html ), and not easily usable by binding
As I said, this is a rough idea that has likely a few shortcomings. But I feel
(perhaps that's just my own imagination) there's often a need for integrating
the capabilities of the current set of utilities into more complex processes.
You generally don't want to :
* reinvent the wheel and copy the source of the utility into your own code.
Which admitedly can be a non trivial task for people not very familiar with
the GDAL/OGR API, and not necessarily feasable for integration into binding
languages as some part of the C++ API are not mapped (*)
* or spawn an external process, for various reasons : no progress bar, no way
of managing transient data you only want in memory, you need to make sure that
PATH is correctly set up, etc ... (On the other hand, in some scenarios, an
external process is a must if you want to be able to stop something that goes
out of control without bringing down the whole app...)
(*) For example, some key parts of gdal_translate.cpp directly call specific
methods of the implementation of VRT driver, so it makes it impossible to
transpose it directly to non-C++ code.
On the other hand, you can actually reimplement 99% of ogr2ogr in other
languages, like the swig/python/samples/ogr2ogr.py exercice. But this is more
a way of testing and checking the completness and good working of the swig
bindings. And a bit of a joke too : you can merely open the ogr2ogr.cpp and
ogr2ogr.py side by side and merge code between them. See disclaimer at the
beginning of the code ;-)
More information about the gdal-dev