VRML Features

This portion of the API supports the integration of VRML features into the geographical scene. Although general-purpose in nature, a typical application is to incorporate building models from a site into the scene.

The subsystem must be initialized first with a call to FeatureInit(), before any of the other functions described here may be invoked.

Several steps are required for loading features. First, FeatureAlloc() is called with the URL of the desired VRML file. This initializes and returns an opaque pointer that is associated with the contents of the VRML file for later reference (ISSUE: actually, this is not so opaque, as the client code needs to get a hold of the "id" field, which is used for all other operations; see ISSUES discussion below). The VRML file is not actually load until the function FeatureLoad() is called with the opaque pointer as an argument.

Visibility of the features in a scene is controlled independently of loading via calls to FeatureAddToWidget() to turn on drawing of features from a particular VRML file, and FeatureRemoveFromWidget() to turn them off.

Several querying functions are provided. GetFeatureFromUrl() may be used to test if a particular URL has been previously loaded. Alternatively, the URL may serve as a key to obtain the opaque pointer of preloaded VRML features. FeatureGetItem() is used to obtain the handle to loaded features based upon ID.

Finally, resources in use by a loaded VRML file may be released via a call to FeatureUnload() (ISSUE: note this does not appear to release any OpenGL textures which may have been created when the VRML file was loaded).

(ISSUE: Are there special requirements on the VRML files, in order to be used here? There's the following comments taken from the code:
/* currently we require a geoname field so that we can associate */
/* a feature file with a terrain dataset. In the future, we will */
/* want to have feature files that are not associated with any */
/* dataset and have the absolute geocentric or lat/long coords. */
).

(ISSUE: The coupling and interaction between the UI side and the backend side are rather tight, in part driven by the fact that on the Motif side, loading is done as part of a separate "busy thread". The backend in turn wants to post updates to the associated dialog. Not sure how this could be refactored, but its a bit awkward to describe to a newbie -- like me --RLB. (see functions FeatureGet() and FeatureLoadCB() in FeatureFE.c; functions FeatureLoad(), GetFeatureFromURL(), FeatureAlloc(), FeatureInlineTraverse() in Features.c).
A suggested refactoring is to hide FeatureAlloc() from the public interface, and have FeatureLoad() call it upon invocation. There looks to be a memory leak currently in cases were/if FeatureLoad() fails.)

(ISSUE: Note that FeatureInlineLoad(), which is called indirectly by FeatureLoad(), recursively allocates new FeatureItems, bypassing FeatureAlloc() in the process!).

API