Export .shp from container without geometry attribute, also write the geometry instead of only .dbf

[jipclaassens]

Now when you export an attribute as .shp from a container where the geometry is not explicitly configured. It only writes the .dbf and not also the .shp/.shx/.prj. While GeoDMS already knows the corresponding geometry features (as it can draw them).

See here for example:

container store 
{
	attribute<float32> TransportPerformance (domain)   := TP_g, StorageName = "%LocalDataProjDir%/Results/DestMass.tif";
	attribute<float32> Pop_within_limit1_i  (Prep/Orgs):= ../Pop_within_limit1_i, StorageName = "='%LocalDataProjDir%/Results/Pop_within_'+string(TraveltimeLimit_1)+'min.shp'", StorageType = "gdalwrite.vect";
	attribute<float32> Pop_within_limit2_i  (Prep/Orgs):= ../Pop_within_limit2_i, StorageName = "='%LocalDataProjDir%/Results/Pop_within_'+string(TraveltimeLimit_2)+'km.shp'", StorageType = "gdalwrite.vect";
}

[jipclaassens]

Operator test:
C:\ProjDir\Jip_Tools\GeoDMS-Test\Operator\cfg\Issue_GH170.dms

map view op /store/export_this_attr

[eoudejans]

Issue reproducible.

[eoudejans]

At the moment the behavior is as intended. Only items configured inside the storage container or, depending on the StorageManager, its subcontainers will be exported. @jipclaassens @mtbeek32 @MaartenHilferink should we change this behavior to work as this issue describes?

[eoudejans]

From discussion it follows that in the .shp case geometry should be automatically added, however in the .csv case the geometry should not be taken into account.

This requires added logic to the interest accounting mechanism for the to-be-written dataitems:

• Conditionally during update metainfo if the dataitem is mapviewable and is candidate for storage, interest should be added for the found geometry.
• If the user has configured any dataitem to be stored that is geometry (neither numeric nor string), this should be taken as the geometry of the to be written dataset.