Re: [OpenMap Users] I am attempting to create a geotiff layer

From: Don Dietrick <>
Date: Fri, 30 Sep 2005 13:48:53 -0400

HI Jason,

On Sep 30, 2005, at 3:10 AM, Butler, Jason wrote:

> Hello everyone,
> I have been asked by my clients to support the geotiff file format,
> so I am attempting to develop a geotiff layer for openmap. I just
> thought I would run my thought process past you all to check that I
> am on the right track as I am a novice when it comes to geographic
> terminology and maths.
> So far I have wirtten some prototype code that can load and display
> a geotiff as a normal tiff using the jai image io code provided by
> sun. (
> download-iio-1_0_01.html) This api includes a reader for tiffs,
> that allows access to the tiff's meta data through an xml document
> tree, including the geotiff meta data. From the meta data tree, I
> have been able to parse the geo tiff speciffic keys into a helper
> object. So far so good. I should be able to get all the info I need
> for placing the geo tiff by implementing some helper methods based
> on the geo tiff specification. (
> geotiff/spec/geotiffhome.html)
> My roadmap for the next few steps is
> 1. create a Layer that takes a path to a geotiff file as a
> property, and renders it as a raster OMGraphic at (0,0).
> 2. extract the upper left and lower right coordinates of the tiff
> from the meta data and render the tiff as a scaling raster
> omgraphic within these confines.
> As far as I can tell from reading the openmap mail archives, this
> is about where most people have gotten in past attempts. The next
> step is
> 3. write some code to render the geotiff directly into the current
> openmap projection. Sounds easy, but I think this is going to be
> difficult to implement.
> This is the bit that I would like some confirmation in my thinking.
> First I had better define a couple of terms to try and make sure I
> am communicating clearly.
> - Raster Space: The data in the tiff. Lets say the coordinate
> system is I, and j and the notation R(i,,j) defines a point in the
> raster space.
> - Geocentric Space: The coordinates on a sphere or elipsoid (like
> the earth). The coordinate system is La (latitude) and Lo
> (Longitude), and the notation G(La,Lo) defines a point on the
> elipsoid.
> - Device Space: The data being displayed in the mapbean. Lets say
> the coordinate system is X and Y and the notation D(x,y) defines a
> point on the screen in the mapbean (or a layer if you want).
> - Projection: A function P the maps G(La,Lo) -> D(x,y). I am not
> sure that this function is always reversible. Does anyone know if
> this function is always reversible?
In OpenMap, the Projection is an Object that translates coordinates
from your Geocentric Space to your Device Space (projection.forward
(lat, lon)). The function is reversible, called with the inverse()
function (projection.inverse(x, y). The MapBean's main
responsibility is to manage the current Projection object and make
sure the active Layers get a projection notification when it changes.
> The main problem is we need to convert the tiff from its current
> coordinate sytem (Raster Space) into Device Space. At the moment I
> am thinking that perhaps the best approach is to initally convert
> the tiff into Geocentric space and then buffer this for between
> projection changes. This raises the question about what is the best
> grainularity for the lat and longs in the buffer, but that should
> be easy to adjust based on parameters. I am not so sure how easy it
> is to actually do the conversion from raster space to geocentric
> space. Any helpful pointers for resources on this would be most
> welcome.
> Then we just have to render the geocentric buffer into device
> space. There are two possible approaches to this.
It really depends on the projection of the image in Raster Space,
which may be different for every image. If you automatically convert
all images to be re-projected into Geocentric Space, then all the
layer has to do after that is the same operation for all images. You
probably don't want to hold the original image data in memory after
the first conversion.

Depending on the size of the original images, you may want to tile
the geocentric images and manage them separately.

The com.bbn.openmap.plugin.earthImage.EarthImagePlugIn is an brute-
force example of converting images that cover the entire earth
(-180/180, -90/90, Mercator Projection) to the current OpenMap
projection. It takes a pixel-by-pixel approach for the projection
image space, inverse projection the pixel location to find the lat/
lon location, and then going into the image to get the pixel color
for that lat/lon (which is why it only works for Mercator projections
with the total extents, it assumes these dimensions in order to do
that pixel color lookup). It's not all *that* slow, and it
automatically determines the granularity needed for the given

The other thing that's on my list to try out is to use the class in JAI to do some of the re-
projecting, using values set by the projection to do translation for
the entire image.

Hope this helps,


> A) If P is always reversible, then whenever a projectionChange
> event occurs I should be able to draw the tiff by doing a reverse
> mapping from D(x,y) to G(la,lo), sampling at each D(x,y). The
> problems I can see with this is that it may be slow. (Have to
> sample each and every pixel in the bounding box each time a
> projection changes) Also D(x,y) may map to more than one R(i,,j),
> so may need to code for multiple samples per pixel to avoid
> aliasing artifacts, etc. Especially as scaling occurs. The more
> samples per pixel, the slower things are going to be.
> B) Otherwise, I will just have to loop though the Geocentric buffer
> and build up a picture that way.
> Have I missed anything out so far in my thinking? Any comments or
> help you can give me is greatly appreciated.
> Best regards,
> Jason Butler.

Don Dietrick,
BBN Technologies, Cambridge, MA

[To unsubscribe to this list send an email to ""
with the following text in the BODY of the message "unsubscribe openmap-users"]
Received on Fri Sep 30 2005 - 13:50:17 EDT

This archive was generated by hypermail 2.3.0 : Tue Mar 28 2017 - 23:25:07 EDT