prepare and store FeatureCoverage leads to a crash

[ridoo]

Does work:

Resource resource(connectionString,itCOVERAGE);
IFeatureCoverage fcoverage;
if ( !fcoverage.prepare(resource)) {
    QFAIL("Could not prepare coverage.");
}
fcoverage->connectTo(makeOutputPath("rails.shp"), "ESRI Shapefile", "gdal", IlwisObject::cmOUTPUT);
        fcoverage->store();

This does not work (ILWIS crashes):

Resource resource(connectionString,itCOVERAGE);
FeatureCoverage fcoverage(resource);
if ( !fcoverage.prepare()) {
    QFAIL("Could not prepare coverage.");
}
fcoverage.connectTo(makeOutputPath("rails.shp"), "ESRI Shapefile", "gdal", IlwisObject::cmOUTPUT);
        fcoverage.store();

In the latter case it seems that the actual data binding is not done by the framework which leads to problems when the FeatureCoverage is used later, i.e. when store()ing the coverage (e.g. no SRS leads to a crash).

Besides the crash (which I think is more a bug, than wrong usage), we should discuss if we want to have different behavior for FeatureCoverage and IFeatureCoverage at all (which would probably lead to wrong usage)

[ridoo]

In effect this is similar to the above:

This do not initialize an ICatalog correctly

Resource dbCatalog(connectionString, itCATALOG);

ICatalog cat(dbCatalog);
if ( !cat.prepare()) {
    QFAIL("Could not prepare catalog!");
}

while this seem to be ok

Resource dbCatalog(connectionString, itCATALOG);

ICatalog cat;
if ( !cat.prepare(dbCatalog)) {
    QFAIL("Could not prepare catalog!");
}

[MartinSchouwenburg]

The ICatalog( "Resource") does an implicit prepare. The prepare without parameters unitializes any previous configuration and makes an empty, though valid IlwisObject of the specified type. So it reverses the prepare from the constructor. The cat.prepare should not return false though. The object maybe empty, but it is still a valid IlwisObject which can be filled by other means.

[ridoo]

got your point ... wasn't aware that this would reset the state prepared from the constructor beforehand.