Message from the BBN OpenMap Team

Hi all,

With the release of OpenMap 4.4.1, I'd like to add some comments about
the current state of OpenMap, and some of the things we hope to
incorporate in the coming months. I was going to preface the release
announcement with these notes, but there were a lot of changes in
OpenMap 4.4.1, and the announcement seemed long enough.

As you can tell by the length of the ChangeLog entry for the 4.4.1
release, the OpenMap codebase continues to mature. BBN Technologies,
and the Distributed Systems and Logistics Department continue to be very
supportive of the OpenMap team. We've had a bit of unbillable time
during this last fiscal quarter, however, and I'm compelled to put out
the message that if anyone has been considering contracting us to
perform feature enhancement, integration or other support services, now
would be a great time to make those arragements.
The team members remain dedicated (time-wise) to the OpenMap program as
long as we can remain billable, but we're obligated to find billable
work on other department programs if we need to. The result of this may
mean less timely helpline responses, and less frequent standard
releases. Bottom line: If you think you'd like to hire us to do
something for you, please let us know.

The OpenMap user community is growing, and it's active. We'd like to
add a page to the website that lets people see what is being done with
OpenMap, a reference page. We'd really appreciate it if you could let
us know how you've used OpenMap - providing a pointer to an applet web
page or description page for your program, along with any icon image
you'd like us to use. There are a lot of neat applications out there,
and it would be great to get more visibility to them. We have a couple
of pointers already, and will be adding the page shortly.

There have been several people expressing interest in contributing new
features to OpenMap. Here are some of the features and changes that
we've discussed for future capabilties, and I offer them as suggestions
to anyone who may be wondering what they can work on. Some if these
will be taken care of during work we have scheduled on current and
future contracts, but you may find them interesting to get an idea of
what to expect in the coming months.

We hope to expand OpenMap's capabilities in several general areas:

• Runtime configuration - reconfigure layers, application at runtime,
save changes
• Spatial analysis capabilities - organize, filter and gather
information based on certain criteria
• Projection handling - Handle pre-projected data, other projection
libraries
• Interface with OGC (Open GIS Consortium) and other standards
• Increase performance for animation, preparation of static maps
• Integrated JDBC support for access to spatial database

To get these capabilities implemented, here are some more specific tasks
we've thought of. This isn't a complete list, or the only way OpenMap
can be upgraded:

      =============================

1) Updating the rest of the Layers and PlugIns to be good
PropertyConsumers. I got as many of them as I could for the 4.4
release, but I just couldn't make it through all of them. The list of
them, as best as I could figure:

        •• LabelLayer
        •• DateLater
        •• AreaHandler via AreaShapeLayer
        •• DTED
        •• VPF
        •• mifLayer
        •• nexRad
        •• terrain
        •• link package layers
        •• DayNight
        •• plotLayer

These are the layers that don't override the Layer's PropertyConsumer
methods, and therefore don't work well with the Inspector. Mainly, the
getProperties() and getPropertyInfo() methods have to be implemented.
Also, the layers have to be checked so that they reset themselves and
reconfigure themselves completely if setProperties() is called. This
may be a problem for older layers, since way back when we didn't figure
that setProperties() may be called more than once. This goes to the
goal of runtime configuration, and frankly, we can use the help updating
all these packages.

      =============================

2) OMGraphic modifications
        • Converting the internals of the OMGraphics to be java.awt.Shape
objects. The OMCircle has been modified, and one thing that turned out
to show is that it simplifies several of the internal methods previously
implemented separately in each OMGraphic type - render, and distance
methods may become generic OMGraphic methods, at least for 'primitive'
OMGraphic types.
        • Implementation of rotation for OMGraphics, but also to implement
a way to have the rotation handled properly within the
EditableOMGraphics. The current OMCircle is a perfect example - the
grab points from the EditableOMCircle don't line up with the bounds of a
rotated OMCircle, even though they actually work. There is code in the
EditableOMCircle where the grab points are rotated as well, but then the
class can't tell that the mouse event happen over them - the mouse
events need to be rotated as well.
        • EditableOMText, EditableOMBitmap, EditableOMRaster. The text
object is coming soon as a result of a BBN project. I have the feeling
that a pixel editor would be really great to have for the OMBitmap, so
you can create your own Icons. Both the OMBitmap and OMRaster should
have some kind of catalog of loaded image files, or at least a file
chooser available to choose the image to load and use.
        • The EditableOMGraphics need to have the undo() capability added,
in case the changes made to the graphic aren't acceptable. Perhaps a
OMGraphic.clone() implementation would make this pretty easy.

This effort will greatly enhance the spatial capabilites of OpenMap,
since the java.awt.Shape objects have operations built into them -
intersects, within, etc. We do have funding that will allow us to do
this effort.

      =============================

4) OMShape and the View Projection extension - I'm going to be creating
an OMShape object, which will refer to graphics that have been projected
(OMGraphic.generate()). Any other OMGraphic, along with a projection
object, will be able to create an OMShape object. OMShape objects will
also be able to be created from pre-projected data points.

The idea to use OMShape objects is to create an extension, or wrapper,
to the Projection class, called View. Over a map with a given
projection, after data has been projected, the View object will be able
to move the map window around, without changing the projection
properties. The View will be using an AffineTransform to zoom and move
over the data.

Obviously, there are several details to work out - but I think this is
the best path to provide OpenMap with a way to display pre-projected
data. This effort goes to the goal of enhanced projection handling. We
do have funding to do this effort, or at least a good part of it.

      =============================

5) ProjectionFactory - The projection factory needs to be modified to
act more along the lines of the other MapHandler objects. Presently, it
only knows about the projections that are coded into it. It should find
projection descriptions from the MapHandler dynamically, so that new
projection types can be added and removed from the ProjectionFactory.
To do this we need to come up with another way to describe projection
types.

This effort falls under enhanced projection handling.

      =============================

6) Finish updating Link package, specifically the LinkGraphic, to
perform complete OMGraphic->LinkGraphic conversions.

      =============================

7) DTED conversion to services
        • DTEDCacheManager/DTEDCacheHandler/DTEDFrameCache needs to be
separated out from the DTEDLayer, and access to the data should be made
available to all OpenMap components as a service.
        • The components of the TerrainLayer should be services that find
the new DTED service.
        • The DTEDLayer may be able to use OMGrids to hold on to the data
for representation. Using OMGridGenerators, the images made from the
data could be customized - the color table changed, or the altitudes for
color changes adjusted.

      =============================

8) Integration of external packages
        • GML4java - this package, available on sourceforge, could be
integrated to read GML documents. GML is the upcoming (and
OGC-supported) standard for representing vector map data information.
        • Batik SVG - this package could be integrated pretty easily - the
Batik package contains a SVG Graphics object, and that could be used
inside a com.bbn.openmap.image.SVGFormatter to create SVG documents from
an OpenMap map.

      =============================

9) Java 3D - I'm working on a project that will allow OMGraphics to be
fed into a Java 3D engine so they can be rendered in a 3D viewer. This
might be an external package, because it will rely on the Java 3D
external package.

      =============================

10) Image Tile Generator and TileLayer/TilePlugIn. OK, so I have this
idea that some people might find useful, but I haven't had a change to
implement it. It's based on the way that DTED data is loaded and
cached - the DTED data is stored on disk and located according to a
simple naming convention. So the idea is to provide a similar naming
convention to a generic plugin, and have it be able to located image
files in the same way, reusing the raster caching mechanism already in
OpenMap. There might be limitations for projection type (Mercator,
CADRG), but the idea is to have a naming convention that specifies scale
and location.

Once you have a generic layer to read these images in, you can mofidy
the com.bbn.openmap.image.ImageMaster class, or create another object
that uses the ImageServer class to create the image files with any
assortment of other layers, creating a set of customized background
image tiles.

The combination of the tile generator and generic plugin would be useful
for fast web servers, etc.

      =============================

11) Integration of a MIL-STD-2525 icon library and icon
builder/chooser. I would think this would be implemented as a service
available via the MapHandler.

      =============================

12) Group Layer, Background Layer. I think there is a need for being
able to create a buffered image for a set of layers for information that
doesn't really change. This would help performance for repainting
during animation, so that each layer doesn't have to cycle through all
its graphics to paint themselves when nothing changes. The layers
providing the background image would be painted with a single image, and
then the layers with moving objects would paint themselves on top of it.

We could come up with a BufferedLayer/BufferedPlugInLayer to create an
image buffer for each layer, but that would have a pretty big memory
footprint for applications with several layers. It's an option.

12) Doug Van Auken has started updating his recent esri package with a
query() capability, and it's a nice precursor to some of the
functionality that would be interesting to have in a new Queryable
interface. A Queryable component should be expected to do a couple of
things - filter its display based on some criteria, or return a
selection of graphics based on some criteria are a couple of actions
that come to mind. I've been thinking that the methods implemented in a
Queryable interface might look something like:

/** Filter would mean limiting the component's display, or input to the
contents within or outside of a boundary described by a java.awt.Shape
object. */
void filter(Shape boundary, boolean inOrOut);
/** Limit the component's display based on a SQL statement. */
void filter(String SQLCondition);

/** Gather graphics within or outside a shape, and create an OMGraphic
list to add them to. */
OMGraphicList fetch(Shape boundary, boolean inOrOut);
/** Gather graphics within or outside a shape and add them to a provided
OMGraphicList. */
OMGraphicList fetch(Shape boundary, boolean inOrOut, OMGraphicList
listToAddTo);

/** Gather graphics described by a SQL statement, create an
OMGraphicList to return them. */
OMGraphicList fetch(String SQLCondition);
/** Gather graphics described by a SQL statements, add them to a
provided OMGraphicList. */
OMGraphicList fetch(String SQLCondition, OMGraphicList listToAddTo);

/** If the object can interpret SQL */
boolean supportsSQL();

Can anyone think of more use cases for an interface like this? How
would you try to use it, and how would this limit what you would use it
for?

      =============================

OK, so this turned out to be pretty long. I apologize for that, but I
also hope this was somewhat helpful, too.

Feedback is appreciated on any part of this email.

Cheers,

Don

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Donald Dietrick, dietrick@bbn.com
BBN Technologies, Cambridge, MA
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

--
[To unsubscribe to this list send an email to "majdart@bbn.com"
with the following text in the BODY of the message "unsubscribe openmap-users"]