Misc. Discussion Topics

Data model, Concepts

Before being able to successfully design a standard format it seems necessary to reach concensus on a common data model. In parallel to a discussion of XML-specific issues we need to define a set of data structures to represent cave survey data. It seems fruitful to first concentrate on data of approaches currently used and leave more ambitious future oriented concepts for the next releases. We could divide the discussion into two branches. One that works on short-term and another on long-term goals. The first concentrates on current development and implementation of a standard compatible with existing software and current survey methods. The other one does not need to bother yet for standardization but should freely experiment with novel approaches and seek for future solutions. We should not try to burden the first attempt by including concepts that still need further research and development of sophisticated algorithms.

As an example we would like to mention the handling of complex cross-sections. While a description of arbitrary cross-sections would be quite straightforward in XML, either as a library of parameterized templates or as polygons/splines, it is beyond the capabilities of todays software to combine them automatically into intersecting galleries, halls and shafts. The first XML version might therefore not include them but should be designed in a way that allows advanced modeling primitivs in the future without an entire redesign.

Ideally, a comprehensive data model and format to represent cavities would include the original survey data as well as the derived 3D-model and the resulting visualizations. It would make sense to separate the data into three entitities: Survey, Model and View. Survey includes the raw survey data, observations, and attributes; the Model defines morphological units, describes how to build their geometrical description and links them with attributes. Finally, the views define visual representations, such as perspective views, and the detailed maps and extended profiles as typically drawn in a CAD or illustration-package. One of the major challenges will be to include all the manually drawn map elements back into the model - and ideally have them reajusted in every loop closing process.

This is, of course, far too ambitious in a first step. We should focus on the original survey data but keep the advanced entities in mind. One of the main architectural issue seems to be the different ways the current data is structured in the various existing data-sets and programs. Most current programs offer some capability to structure data in hierarchical manner, but they differ in the main organisation of the data: most programs structure it chronologically so the records closely resemble the survey data on paper. A few other programs, such as Toporobot and CaveRender structure it morphologically into series; data comes in sequences and describes passages. In this approach, some basic modelling aspects are already considered while surveying. The resulting data contains intertwined modelling information that cannot be derived automatically from the chronologically structured data. We ought to support both philosophies and create a standard format that resembles the original data in both forms closely. We therefore need two different grouping tags, one for data-sets organised as series and one for data-sets organised as surveys. While it is straightforward to transform series-data combined with the chronological attributes into surveys, the inverse requires additional modelling information. Toporobot can structure surveys into series automatically, but the process is very complex to implement and the result can never be as good as manually structured data. CaveXML should therefore have the capability to represent series directly or through an additional modelling section. Such structure information, in a separate model tag, could gradually be enhanced to finally allow not only sequences of cross-sections, but representation of arbitrarily shaped polyhedra or NURBS patches.

Martin Heller, Andreas Neumann

Modeling of Cross-Section

It should be possible to model with or without cross-sections. Cross-Sections would include simple approximations (left, right, up and down; or 8 directions), and more complex ones like those acquired with Profile Measuring Systems, photogrammetric methods or detailed sketches. We should support both, perpendicular and bisector cross-sections. The usefulness of cross-section libraries is currently discussed in the list.

Martin Sluka, Julian Todd, Ken Grimes

Comments

It should be possible to add comments to stations, survey shots, morphological units (series, pits, rooms and domes, etc.) and folders. With the help of XPointer it is possible to add hyperlinks to related data and documentation material.

Paul Hill, Martin Laverty, Devin Kouts, Richard Knapp

More issues: to be continued ...

Please send suggestions for additional discussion topics and unresolved issues.