Shape Models and The Bigger Picture

1
Shape Models and The Bigger Picture

• Tony Farnham
• Michael AHearn

2
Background / History

• Several recent SBN data sets have involved
  triangular plate shape models (TPSM) of small
  bodies
• Data have been submitted in several different
  formats
• Only minor variations between them
• Some only provide latitude/longitude/radius
  points
• Some include connectivity of triangular plates on
  the surface
• Some are regular grids, others are not, etc
• Limited community currently uses them
• Becoming more popular
• In the past, shape models have been difficult for
  reviewers to evaluate
• Need specialized tools to visualize the data
• NAIF tools, IDL packages, customized routines,
  etc.

3
Recent Advances

• While working with Deep Impact, Brian Carcich
  produced a VRML version of the shape model of
  comet Tempel 1
• Can use browser-based VRML software to view the
  model, allowing rotation, lighting changes, etc.
• Easy to visualize the object and evaluate the
  model
• Proved very popular with the reviewers!
• Also popular with the general community

Comet Tempel 1
4
VRML Models

• The VRML version is straightforward to create
• Uses basic information from TPSM
• Locations of points on the surface, with
  connectivity of triangles between the points
• Additional commands to describe lighting,
  positioning, etc.
• It was proposed that we create VRML versions of
  all the TPSMs for general use

Comet Wild 2
5
Standardized Model

• In order to create this VRML version a standard
  format was needed
• VRML requires cartesian coordinates and
  connectivity
• Easily created from all the currently existing
  TPSMs in the archive
• As part of this work, it was also proposed that
  the archive of TPSM models be presented in a
  standardized file format
• Adapt all models to include surface points as
  well as connectivity
• Because formats are currently similar, users who
  dont require all the information (e.g.
  connectivity) can ignore the unnecessary pieces
• Standardization was to be done internally at the
  SBN, if needed
• Wouldnt require this format for the submission
  of models

6
Feedback

• Before implementing, I sent this proposal out to
  the community to get feedback
• Most feedback was favorable
• Complements the NAIF shape model routines
• Presents the data in a common form that everyone
  can use
• One user opposed this proposal ? Brian Carcich
  (who started the snowball rolling by introducing
  the VRML model)

7
Brians Opposition

• Brians opposition was based on his vision of PDS
  and how it should work
• PDS should not set standards
• Should not require a specific format, but accept
  data in any format
• Details of the format are defined in the PDS
  label
• The role of PDS should be to provide the
  infrastructure for converting from one format to
  another
• As many formats as possible (VRML, STL, OOGL,
  POVray, Rayshade, etc.)
• All major platforms
• Data are ingested in any format and can be
  extracted in any format
• Reminiscent of the NAIF node products

8
PDS Philosophy

• This discussion raised the question about the
  Big Picture
• How do we respond to Brians comments?
• What is the basic role of PDS?
• Is the PDS basically a data repository?
• Accept and distribute a limited number of
  pre-defined formats
• Community defines the common formats
• Should PDS provide the tools for accessing data
  in multiple formats?
• Accept and distribute data in any major
  format/platform
• Are the resources for this support available?
• Shape models are only one of many types of data
  that need to be addressed