[gdal-dev] CopyLayer oddity using GML driver

[Ari Jolma]

In general, from my point-of-view limiting the growth of utility code, 
which is not available to bindings, or making some of that code 
available to bindings is a good thing.

Ari

On 11/23/2011 12:57 AM, Even Rouault wrote:
>> 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 ;-)