I have re-implemented a CDB tile viewer using the CDB API and have a few things to mention. The viewer just generates a regular mesh from elevation and then applies the imagery to it, no 3d models or other layers.
1. It took me about 3-4 hours to adapt the test app to using the CDB API
2. There is no simple search mechanism in the CDB API so I left my own. CDB API only allows opening a specific file. It might be useful to be able to check if a sub-tree was available and even enumerate members, e.g. what layers are available for tile LAT,LONG. i.e. the sample project explicitly specifies the lat long, what if this was not known?
3. I don;'t think that the error reporting is sufficient, i.e. if the JP2K dll is not present then any files reliant on it seem to just report a 'not found' error.
4. Running the application either requires adding the CDB dll paths to my project environment settings or copying the dlls into my bin directory. As both debug and release CDB dlls have the same name then I can't do this (although I realise that many people have seperate debug and release directories). Personally I prefer that debug dll's are appended with a *_d.dll to explicitly differentiate them.
I think it would be useful to have some sample applications that do something a bit more adventurous with the CDB data than copy it too! Maybe some basic OpenGL viewer or attribute dumper or similar.
Something like a CDB browser that shows the CDB as a tree view and when a file is selected it is displayed in the viewing pane would be useful, and would demonstrate use of each data type quite well in isolation.
Thank you Roland for the information provided. We will evaluate your comments as part of our planning for the next revision of the CDB API release. We will keep you informed on this forum as we get more information on the planned functionality.