[gdal-dev] CopyLayer oddity using GML driver

[Even Rouault]

> 
> 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, 
NULL)

Several advantages :
* You can operate on in-memory datasources.
* Such an approach would also be quite suited to be easily incorporated to our 
python/java/c#/perl bindings.
* 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 
languages. 

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...)

Best regards,

Even


(*) 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 ;-)