Hi,

The behaviors of CDB version is dictated by the CDB specification. For a given location, a given dataset, a gicen file, there can only be one valid data. Two files with the same name will have one file "hide" the second as you experience. The CDB API applies this rule. A complete chain of CDB provides one representation of the world.

In your case, it looks like you have two CDBs of the world with different data in them. I believe the only way to query a specific CDB it to avoid using the CDB version mechanism. You have to remove your CDB chain configuration and, in your application, make two calls to CDB open, one on each version. You then use those CDB objects to query the version you want. 

Alternatively, you could create with CDB API a special merge tool that would read both files and mix them with the algorithm you want (apparently, you do not want a simple file replacement but some merge replacement). In the case of min-max elevation, it has to follow the elevation dataset. So, if you have a problem with min/max, you have the same problem with elevation!

I am still not clear why you would want this behavior. It is non-standard and seems like the CDB version mechanism is not what you need. However, if you are trying to simulate CDB changes over time (called dynamic terrain), CDB API can collaborate with a dynamic terrain engine. This solution is available via consulting @ Presagis.

Hi ,

I’ve looked into the specification (CDB Specification Volume 1, chapter 3.2), and I see that CDB standard supports two mechanisms:

The CDB Configuration and CDB Version mechanisms allow users to manage the Common Database (CDB). The two mechanisms permit the users to implement Configuration Management (CM) and versioning by offering the following capabilities:

 The Common Database (CDB) can have multiple simultaneous independent CDB Configurations.

 Each CDB Configuration is defined by an ordered list of CDB Versions.

Section 3.2.2 CDB File Replacement Mechanism relate to CDB Versions mechanism (I Think), which in this case the API is working correctly. However I’m unable to find any specification for the first mechanism (“The Common Database (CDB) can have multiple simultaneous independent CDB Configurations. ”), which in this case the source repositories are independent (so if I understand correctly they may overlap, and should be merge rather than replaced), my question targets the configuration management, not the versioning one. Does the API support configuration management mechanism?

Hi Andrey,

CDB API support "simultaneous independent CDB configuration" by doing "CDB open" calls on each. A CDB open call is really an open on a configuration which is defined a s ordered list of version. As such, you really need to use the chain defined in Metadata/Configuration.xml and avoid using the "previous" entry in the Version.xml. With configuration.xml you can have multiple configurations linking the same CDB differently.

Configuration 1:  CDB A -> CDB B -> CDB C

Configuration 2:  CDB B -> CDB A -> CDB D

A configuration can simply be a CDB folder with a Metadata sub-folder (including the Configuration.xml) and en empty Tiles sub-folder. The configuration defines the chain of CDBs.

I hope this answers your question.

Hi Herman,

Not sure I understand, If I use Metadata/Configuration.xml file, with the API, what is the behavior in case two repositories contain matching tiles, will the API merge the content of the tile or will it select one of the tiles based on the configuration list order?

The specification covers this case for versioning, but no specification for listed repositories (configuration.xml).

Thanks

Hi Andrey,

You are correct that any CDB chain will return the first file its finds. The chain can be specified in version.xml (pointing next CDB) or in Configuration.xml (pointing to the complete chain in one file). Those are two ways to configure a chain. The use case of configuration management is covered by the configuration.xml which allow you to define a complete CDB chain from one file. Look at it as any source version management tool where you have a tag on a version or on a branch. The configuration.xml is the tag which select a version of each file in the repository. When you access a file with this tag/label on file check out, you only get one file, the version pointed by the tag/label. 

Clearly, you do not want to leverage the CDB chain as it hides files. If you want to select which repository the files comes from, you need to perform two "CDB open" calls in your application and perform your operation on each. In such case, you might not even have a CDB chain (no configuration.xml and a version.xml that does not point to another CDB).Upon return from each call, you can decide which file to open and read.

CDB API does not index all files in a CDB to allow you to query which one you want. This would be highly inefficient on large CDBs. CDB API perform the search for a file upon each request and stops when it finds a matching file.

If you are willing to share your objective, I would be happy to help find a solution.