Home Page
Goals & Issues
News & Milestones
FAQ
GeoVRML 1.1 NEW!
Specification
Install Run-time
Examples
Tools
Source Code
Other Versions
GeoVRML 1.0
GeoVRML 2.0
Resources
GeoTransform
Related Work
VRML Examples
Software
Data Sources
Publications
Mailing List
Joining
Mail Archives



GeoVRML.org


GeoVRML Development

This page is meant to be a focus for further GeoVRML developments, labeled GeoVRML 2.0 for the time being. It will contain a wish list of new features or modifications that the group is considering. This page also includes a link to the latest development implementation of the GeoVRML nodes so that any interested parties can download this and work on adding new functionality.


GeoVRML Wish List

Below is a list of new features that have been raised on the GeoVRML mailing list or included as possible further directions in the GeoVRML 1.0 specification. If you have a suggestion to add to this list, then please post a message with this suggestion to the GeoVRML mailing list.

  • X3D Profile Implementation : We need someone to commit to producing a GeoVRML Profile for X3D. X3D is the next generation VRML with support for XML and improved extensibility. [Start of thread]

  • Supporting the Planets : Add support for ellipsoid definitions of all the planets. This includes working out a naming convention for each ellipsoid (maybe SEDRIS has this?), and updating the Java sources appropriately. [Start of thread]

  • URN Support : Integrate with Universal Media to provide support for a URN mechanism to access GeoVRML EXTERNPROTOs. Also specify and alternative recommended local directory for non-networked use. [Start of thread]

  • GeoLocation with no elevation : It should be possible to provide a GeoElevationGrid to a GeoLocation and have it work out the elevation to use in order to locate objects automatically on the terrain.

  • Rotations : Add an orientation field to GeoLocation. Provide support for doing planetary rotations. [Start of thread]

  • Geoid Support : We have geoid support in 1.0, but it is not implemented yet. Need to get the SEDRIS sources for this. [Start of thread]

  • More Coordinate Systems : It would be good to support more geographic coordinate systems such as Transverse Mercator (TM), Lambert Conformal Conic (LCC), Polar Stereographic (PS), and British National Grid (BNG).

  • View-dependent GeoOrigins : GeoVRML 1.0 requires explicity GeoOrigin nodes, this represent Level 1 from the RFC. Level 2 would allow the GeoOrigin, and all related coordinates, to be recalculated based upon the camera location. [RFQ]

  • Binary format and Dynamic LOD for GeoElevationGrid : Suggestion to provide a binary format to make GeoElevationGrids more compact (and potentially streamable), and to implement some form of dynamic level of detail so that large GeoElevationGrids can be handled without the need to chop them up manually. [Start of thread]

  • GeoProximitySensor : Introduce a new ProximitySensor node where the location can be specified with a geographic coordinate and the returned position is provided in also geographic coordinates. [Start of thread]

  • Time Referencing : GeoVRML 1.0 has no notion of time, e.g. the date range that a geospatial entity refers to. Support for time encoding would be a great addition to a future version. We need to be able to encode time ranges in the order or minutes up to millions of years.

  • Bug Fixes : Fix any bugs raised with the 1.0 implementation, e.g. the far clipping plane is not updated (visibilityLimit) when we bind a new GeoViewpoint node.

  • Stability : Issues have been raised with GeoVRML stability under Internet Explorer and Cortona. We need to work out what is causing the unstability under IE and fix these problems (N.B. these fixes can be fed into the GeoVRML 1.0 release also). [Start of thread]

  • Support kilometers : All elevations are currently given in units of meters. A useful addition would be a "KM" string in the geoSystem string to specify that elevations are in units of kilometers.

  • Georeferenced Lights : In GeoVRML 1.0 there was no way to place a light source at a specific geographic location. In addition to this capability, a user should be able to specify a date/time and have the light source positioned correctly.

  • GeoElevationGrid spec issue: note that a texture image does not need to flipped when used with a GeoElevationGrid, unlike the standard ElevationGrid node.


Development Specification

From here you can browse the latest version of the GeoVRML spec. and see what changes have been made over. This is a working draft. Please feel free to make comments to the list on spec changes.


Development Implementation

From here you can download that latest development release of the GeoVRML implementation. If you would like to see a new feature or new node added to a future release of GeoVRML, then the best way to have this happen is to download this distribution and make the modification. When completed, please notify the group (via the mailing list) of the availability of the update and it will be merged into this mainline.


Martin Reddy / Lee Iverson

www.geovrml.org


Home Page | GeoVRML 1.1 | GeoVRML 1.0 | Specification | Download | Examples | Source | Tools | Goals & Issues | News & Milestones | FAQ | Related Work | VRML Examples | Software | Publications | Join | Mail Archives