[OpenMap Users] Loading non-conforming VMap VPF data

From: Koh, Shalin <Shalin.Koh_at_thalesgroup.com.au>
Date: Thu, 11 Mar 2010 12:12:13 +0800

Hi everyone,

 

My company has developed a Java application that uses OpenMap to parse
directories of VMap data. The application retrieves the OMGraphics
representing the features (e.g. roads, oceans), converts them to a
custom format, then displays them on a map using its own display
framework.

 

Our customer has provided us with VMap data that does not conform to the
"Interface Standard for Vector Product Format" (MIL-STD-2407). This is
not an ideal situation, however we have a requirement to support this
non-conforming data. The following are the issues we have discovered:

(1) The mandatory LAT (library attribute table) file is missing from the
database directory (see section 5.3.6.1 of MIL-STD-2407 for info about
the LAT file).

(2) The TILEREF.AFT (area feature table) and FBR (face bounding
rectangle) files within the TILEREF directory are referring to tile
directories that do not exist within the coverage directories (see
section 5.3.5.4.1 for info about the area feature table).

 

Our application uses the com.bbn.openmap.layer.vpf.LibrarySelectionTable
class to determine the features that are available in the VMap database
directory. As the LibrarySelectionTable#addDataPath(String) method uses
the LAT file to retrieve the names of the library directories, our
application could not load the VMap source. We worked around the issue
and discovered that our application still could not draw the features on
the map - this was due to the TILEREF.AFT problem. A FormatException was
being thrown in the
com.bbn.openmap.layer.vpf.CoverageTable#drawFeaturesFromThematicIndex(..
.) method due to trying to access tile directories that did not exist on
the file system. We also managed to work around this issue.

 

We were wondering if anyone else had encountered non-conforming data
like this before. Please let me know if being able to handle this data
would be useful to the community. If so, I would be happy to spend some
time working on a more generic solution and submit a patch for OpenMap.

 

Regards,

Shalin Koh.

 




DISCLAIMER:---------------------------------------------------------------------------
This e-mail transmission and any documents, files and previous e-mail messages
attached to it are private and confidential. They may contain proprietary or copyright
material or information that is subject to legal professional privilege. They are for
the use of the intended recipient only. Any unauthorised viewing, use, disclosure,
copying, alteration, storage or distribution of, or reliance on, this message is
strictly prohibited. No part may be reproduced, adapted or transmitted without the
written permission of the owner. If you have received this transmission in error, or
are not an authorised recipient, please immediately notify the sender by return email,
delete this message and all copies from your e-mail system, and destroy any printed
copies. Receipt by anyone other than the intended recipient should not be deemed a
waiver of any privilege or protection. Thales Australia does not warrant or represent
that this e-mail or any documents, files and previous e-mail messages attached are
error or virus free.
--------------------------------------------------------------------------------------



--
[To unsubscribe to this list send an email to "majdart_at_bbn.com"
with the following text in the BODY of the message "unsubscribe openmap-users"]
Received on Wed Mar 10 2010 - 23:29:58 EST

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