Decoding data stored in the cloud, such as data made available from an Amazon AWS S3 storage service.
Learn how to:
Learn how to best configure LuciadFusion for use in a cloud environment, such as the Amazon AWS cloud.
Bing Maps (previously named Virtual Earth) is a web mapping service provided by Microsoft, offering traditional road maps, aerial photo views, and searching capabilities.
The LuciadLightspeed Bing Maps functionality integrates the Bing Maps imagery service into LuciadLightspeed. More specifically, you can do the following:
To convert user input into actions on the view, the LuciadLightspeed API uses the concept of a
ILspController
.
Controllers allow the user to use the mouse, keyboard or touch input to:
To convert user input into actions on the view, the LuciadLightspeed API uses the concept of a
ILcdGXYController
.
Controllers allow the user to use the mouse, keyboard or touch input to:
The LuciadLightspeed API offers a number of ready-to-use UI widgets for a Lightspeed view. Examples are
The LuciadLightspeed API offers a number of ready-to-use UI widgets for a GXY view. Examples are
Geospatial Comma Separated Values (CSV) files are based on the CSV specification. To store the geometry, they use a single column with a Well Known Text (WKT) encoded geometry. For point data, another option is to use separate columns to store the X and Y values.
Decode and visualize data in the DMED and DTED format (*.dmed
, *.dt0
, *.dt1
, *.dt2
).
The LuciadLightspeed API is fully equipped to handle the geodetic aspect of geospatial data with high accuracy: it covers geodetic and Cartesian coordinate reference systems, geodetic datums, transformations and projections, and so on.
LuciadLightspeed Essential allows you to perform geometric calculations on shapes.
The more complex LuciadLightspeed Geometry functionality comes with the Advanced GIS Engine component. It provides support for the calculation of binary topological relations, intersection points, the convex hull, and constructive boolean operations of shapes in 2D spaces. This functionality is useful for various applications, for example:
The Advanced GIS Engine component supports the standard LuciadLightspeed shapes. These shapes can originate from any source.
The Advanced GIS Engine component has implementations for a number of 2D spaces: Cartesian, spherical, and ellipsoidal. The mathematical calculations of each implementation are specialized to work in these spaces. For example, the spherical and ellipsoidal implementations work with geodesic lines.
Decode and visualize data in the GeoTIFF and BigTIFF format (*.tif
, *.tiff
).
Set up your system so that you can start developing with LuciadLightspeed.
Set up your system so that you can start developing with LuciadFusion.
Models are the containers for geospatial data and their properties.
Learn how to:
Learn how to decode your vector data into LuciadLightspeed shapes.
To protect your source code and reduce your application footprint, you can obfuscate your LuciadLightspeed-based applications for deployment. ProGuard is a tool that can be used for this purpose.
Learn about the different options LuciadLightspeed has to offer before you start building your application, and pick the most suitable technology up front.
The service loader mechanism allows you to query all available instances of an interface, and to register your own instances of an interface. This is used for two reasons:
The shapefile format (shp) is a format developed by Esri to store geospatial vector data and attributes. It can contain points, lines and polygons.
The main entry point for visualization in LuciadLightspeed is the view. You start from the view to determine which layers to show on your map, to manage layer object selection, style objects on your map, determine the world position of screen coordinates, and so on. Here you can read about various topics related to the customization of your GXY view, and learn a number of ways to tailor your GXY view to the application you are building.
Find out which data types are supported out-of-the-box, which product tier gets you what functionality, and what some of the commonly used terms mean.
The GXY view implementation is highly optimized. It allows you to paint domain objects asynchronously to guarantee a responsive view.
Learn how to ensure the performance of your GXY views.
The Open Geospatial Consortium's (OGC) Geography Markup Language (GML) is an XML-based data format for describing, storing and exchanging geographical data. LuciadLightspeed provides support for several versions of the GML format. The LuciadLightspeed GML packages allow you to integrate GML data files into LuciadLightspeed applications, encode LuciadLightspeed models to a GML data file, and apply some customizations.
Learn how to display, style and label vector data.
Learn how to display, style and label vector data.
Find out which product tier gets you what functionality, and read some tips for a smooth interaction with our support desk services.
Learn how you can support geospatial data references.
LuciadLightspeed supports a wide range of georeferences. Find out how to integrate your geospatial data reference.
Vector domain objects typically have a geometry as well as other associated properties. An example might be a model containing road data. Its domain objects do not only contain the road geometry, but they also have properties such as the name of the road, or the speed limit for that road.
You can use those properties in various places:
Much of this functionality is generally available in the LuciadLightspeed API.
The only requirement for your model data is that it offers a uniform interface to access those properties.
That is what the com.luciad.datamodel.ILcdDataObject
interface is for.
Here you will learn how to use and interact with this interface, and how to implement it for your own domain objects.
You can set up your development project in a certain way to prepare it for future upgrades of LuciadLightspeed to a new version. Those precautions allow you to maximize the benefit you get from new features and preserve your modifications.
The LuciadLightspeed Database Connectors option provides provides support for seamlessly integrating PostgreSQL PostGIS databases into LuciadLightspeed applications.
PostGIS adds support for geographic objects to the PostgreSQL object-relational database. In effect, PostGIS "spatially enables" the PostgreSQL server, allowing it to be used as a backend spatial database for geographic information systems (GIS). PostGIS introduces additional SQL types for representing various geometries. These can be inserted as single entities into the spatial columns, which can co-exist with traditional non-spatial columns.
The PostgreSQL Manual and PostGIS Manual provide all the necessary information on setting up, maintaining, and using spatial databases. This guide explains how spatial data can be imported from, and exported to, spatial databases.
The LuciadLightspeed Database Connectors component provides support for seamlessly integrating Oracle Locator databases into LuciadLightspeed applications. It includes support for the more complex features that are offered by Oracle Spatial, with the exception of Oracle GeoRasters, for which the LuciadLightspeed Oracle Spatial functionality is also required. Within Oracle Locator, both the Relational Model and the Object-Relational Model are supported.
The Relational Model is based on sets of tables, called layers, containing columns with traditional primitive SQL types. When interpreted correctly, they represent various geometries. This representation is fairly difficult to maintain and to work with. The Relational Model is deprecated and no longer supported by Oracle.
This page focuses on the newer Object-Relational Model. It is based on additional SQL types for representing various geometries. These can be inserted as single entities into spatial columns, which can co-exist with traditional non-spatial columns.
The Oracle Spatial User’s Guide and Reference provides all the necessary information on setting up, maintaining, and using spatial databases. This page explains how spatial data can be imported from, and exported to, spatial databases.
Get started with the LuciadLightspeed API and write your first application.
This page contains a number of tutorials illustrating how you can write your first application using LuciadLightspeed API basics.
LuciadLightspeed allows you to set up a logging framework to generate and handle log messages from its classes. You can also monitor application performance.
LuciadLightspeed offers many options for keeping the amount of data in your map application down. You can set up filters that limit the amount of data loaded into the application. You can also apply filters during the data visualization stage to only show the most suitable data for a given time, location and zoom level on the map.
Learn how to add a grid, such as a typical grid with meridian and parallel lines, to your view with the help of a few grid grid layer implementations in LuciadLightspeed.
LuciadLightspeed can be integrated with many technologies and frameworks. You can find out more about logging, internationalization, application container frameworks, obfuscation, and much more.
Decode and visualize charts containing magnetic north lines. On such a line the declination of the magnetic north vector is constant. Lines are calculated with a certain interval (e.g. every 5 degrees).
There is support for files containing the parameters of the IGRF or the WMM magnetic model.
Learn how you can add support for your own business data in a custom format.
LuciadLightspeed comes with built-in support for a number of data formats like SHP, GeoJSON, DTED, ... . It also allows you to add support for your own data format by implementing a few interfaces.
LuciadLightspeed allows you to combine multiple and large raster datasets into an Earth tileset. An Earth tileset is multi-leveled and tiled, resulting in great visualization performance.
The recommended way to preprocess datasets is using the Tiling Engine API instead of the Luciad Earth tilesets. Luciad Earth tilesets are only included for reasons of continuity and backward compatibility.
Learn how to decode your raster data as images for image models for further processing and visualization. LuciadLightspeed's image processing framework allows you to access images built from raster data, and enhance or highlight certain aspects of the raster data for display. You can make use of various image manipulation operations, including the typical image operations to work with multi-band images, HDR images, and low-quality images.
LuciadLightspeed uses various threads to prepare, process and display data. This way, LuciadLightspeed can take advantage of your computer's multiple processor cores, and keep the UI responsive. There are some basic threading and locking rules for LuciadLightspeed applications that you can apply to prevent concurrency errors and ensure optimal efficiency.
OpenCL enables hardware-accelerated computations. LuciadLightspeed and LuciadFusion use it for line-of-sight computations in the Terrain Analysis Engine component, for instance. OpenCL computations are performed at the model level. This means that OpenCL can be used with Lightspeed views as well as with GXY views.
A limited number of hardware platforms or an outdated graphics driver may cause trouble for the OpenGL and OpenCL components of LuciadLightspeed.
You can secure your LuciadFusion application with authentication, access control, the use of HTTPS and more. Learn how to apply the security measures of your choice.
The idea behind the MVC design pattern is to separate the data, the representation of the data, and the user interaction from each other. This separation results in a simpler design of the application and a higher flexibility and re-usability of code.
The LuciadLightspeed API consists of the following MVC components:
You can make LuciadLightspeed available through Apache Maven, a development project management and build automation tool.
Learn how to decode data with multiple dimensions, such as scientific measurement data, so that its dimensions are preserved for filtering and visualization.
Learn how to prepare and build your LuciadFusion application for a production environment. Secure your application through obfuscation and the setup of a reverse proxy.
To take your application from a single-node setup to a multi-node setup, and run multiple LuciadFusion instances in an integrated system, see the multi-node documentation page.
Make your LuciadLightspeed application compatible with an OSGi framework. For more information about OSGi , see http://www.osgi.org.
Find out how the new features and feature updates of this version can benefit you.
Learn about the different options and components LuciadFusion has to offer before you start building your application. This allows you to pick the ones most suited to your application.
LuciadLightspeed allows you to model your geospatial data for representation in a view that is not a map. Such a view is known as a vertical view, or as a profile view. It is typically used to map altitude points over a cross-section of terrain data.
LuciadLightspeed allows you to model your geospatial data for representation in a view that is not a map. Such a view is known as a vertical view, or as a profile view. It is typically used to map altitude points over a cross-section of terrain data.
The E57 format for point cloud storage consists of two parts:
For more information about the specifics of E57, you can visit the libe57 website at http://libe57.org/.
E57 files can also contain panoramic images. See the Panoramic image data documentation for more information about handling panoramic images.
For many applications, you need to identify a particular subset of a data set by specifying a number of conditions, so that you can take further action on that subset only. LuciadLightspeed allows you to use OGC filters to identify that data subset. OGC filters are based on a specification by the Open Geospatial Consortium (OGC), which represents the OGC filter in the XML format. In addition, the specification document defines a set of OGC expressions for expressing a computed property of a given object.
The OGC filter specification is a flexible, general-purpose filtering language that supports a wide variety of use cases. Within LuciadLightspeed, you can use it:
samples.ogc.filter.model
for an illustration.
The LuciadLightspeed OGC filter API provides a Java object representation of OGC filters and expressions independently from the XML encoding.
The OGC filter specification lists a number of filter functions. Those are pre-defined logical, spatial and comparison operations that you can use to build your OGC filter. On top of that list, Luciad's OGC filter implementation supports a number of custom, vendor-specific functions that you can use out-of-the-box.
If you still need a custom filter operation for your use case, LuciadLightspeed allows you to define your own filter functions in addition to the pre-defined OGC filter operations.
The Fusion client API has two purposes:
Decode and visualize data in the JPEG2000 format (*.jp2
, *.j2k
).
Decode and visualize data from a JPIP data stream (JPEG 2000 Interactive Protocol).
Keyhole Markup Language (KML) is an XML-based file format for storing and visualizing geographic data in Earth browsers. The file format was originally developed by Keyhole Inc. for use with their Earth Viewer application, which is currently known as Google Earth.
An interchange file format for 3D models such as buildings, bridges, and monuments.
The LASer format is an exchange format for three-dimensional point clouds. It uses the .las
extension.
LASer LiDAR files also come in a compressed variant, called LASzip. In that case, they have the
.laz
extension.
The specifications are maintained by the ASPRS foundation. See http://www.asprs.org/Committee-General/LASer-LAS-File-Format-Exchange-Activities.html for more information about the specifications.
The LASer format is a binary format roughly consisting of three parts:
Learn how to display and style raster data.
The main entry point for visualization in LuciadLightspeed is the view. You use a view to determine which layers to show, and to perform functions such as zooming in on particular areas, limiting the area that the user can see or interact with, determining world position of screen coordinates, and so forth. Here you can read about various topics related to the customization of your Lightspeed view, and learn a number of ways to tailor your Lightspeed view to the application you are building.
If you prefer to build your Lightspeed view with JavaFX GUI components instead of Swing, you can use a TLspFXView
. All 2D/3D Lightspeed view and controller functionality
in the LuciadLightspeed API remains available to you, no matter what type of Lightspeed view you use.
Decode and visualize data in the Wavefront OBJ format (*.obj
).
Decode and visualize data in the OpenFlight format (*.flt
).
Find out how and why LuciadLightspeed makes use of the OpenGL API. Also learn about the OpenGL tools offered by LuciadLightspeed to help you develop OpenGL-based applications efficiently.
Lightspeed views support a number of graphical effects which are applied globally, across all layers. These effects serve to improve the realism, sense of depth or scale, or simply the aesthetics of the images produced by the view. The lighting effect, for example, greatly improves the user's perception of the shape of 3D objects.
LuciadLightspeed allows you to print out the maps displayed in a LuciadLightspeed view, by creating printable objects. In addition, you can display a preview of the layout of your print before you start the printout. Exporting the map to a GeoTIFF file is also a possibility.
The OGC 3D Tiles protocol is designed for streaming and rendering massive 3D geospatial content such as Photogrammetry, 3D Buildings, BIM/CAD, Instanced Features, and Point Clouds from a server to a client. It defines a hierarchical data structure and a set of tile formats which deliver renderable content.
In LuciadLightspeed, we support 3D tiles that contain a payload with:
PNTS
format)
B3DM
or Batched 3D Model format)
The OGC 3D Tiles format describes the structure of a 3D tile hierarchy. It consists of:
tileset.json
.
It can link to other tileset.json
files or data files.
Learn how to add a grid, such as a typical grid with meridian and parallel lines, to your view with the help of grid layer builders.
Learn how to display and style raster data.
Decode and visualize data in the Arc/Info ASCII grid format (*.asc
, *.grd
).
Decode and visualize data in the BIL format (*.bil
).
Decode and visualize data in the USGS DEM format (*.dem
).
Decode and visualize data in the ETOPO format (*.ETOPO2.raw.bin
, *.ETOPO2v2_MSP.raw
, ETOPO5.DAT
).
Decode and visualize data in the GeoJSON format (*.json
, *.json.gz
, *.json.zip
, *.geojson
).
Decode and visualize data in the LuciadLightspeed JAI format (*.jai
).
Although LuciadLightspeed consists of a Java-based API, you can embed it into a .NET application, by coupling the .NET application and its UI components to LuciadLightspeed. As a result, the application gains full access to: the LuciadLightspeed functionality and OpenGL-powered performance.
Decode and visualize data in the MapInfo MAP format (*.map
).
Decode and visualize data in the MapInfo MIF format (*.mif
).
Decode and visualize data in the MapInfo TAB format (*.tab
).
LuciadLightspeed allows you to transform a model so that it clusters objects and you can maintain an overview during visualization. Find out how.
Offscreen views are used in testing scenarios or server use cases. On a server, you often want to build images, but you don't want to visualize them directly on screen. You want to render them to an internal memory buffer instead. Off-screen views are also useful when you want to prepare an image for visualization at a later stage.
Decode and visualize OpenStreetMap raster tiles from a tile server or OpenStreetMap vector data from a database.
During the design and implementation phases, you can take several measures to optimize the performance of your LuciadLightspeed application.You can take steps to boost performance at the model level as well as at the view level.
Learn how to ensure the performance of your Lightspeed views.
The visualization of a large data set on a map poses 2 big challenges:
Here you will learn about the different available options in the LuciadLightspeed API to visualize such large vector datasets on a Lightspeed view.
The visualization of a large data set on a map poses 2 big challenges:
Here you will learn about the different available options in the LuciadLightspeed API to visualize such large vector datasets on a GXY view.
Decode and visualize data in the POL format (*.pol
).
LuciadLightspeed allows you to print out the maps displayed in a LuciadLightspeed view, by creating printable objects. In addition, you can display a preview of the layout of your print before you start the printout.
Decode and visualize data in the LuciadLightspeed RST format (*.rst
).
LuciadLightspeed allows you to structure styling information according to OpenGIS Styled Layer Descriptor (SLD)
Profile and Symbology Encoding (SE) standards, and
apply that styling information to an ILcdModel
to create an ILspLayer
or an ILcdGXYLayer
.
As such, you can separate style from content.
Decode and visualize data in the TFW and JGW format (*.tfw
, *.jgw
).
The TLcyAIXM51AddOn
, TLcyLspAIXM51FormatAddOn
and TLcyAIXM51RealtimeAddOn
provide visualization support for
AIXM 5.1 data.
The Aeronautical Information Exchange Model (AIXM) is an XML-based aeronautical data format developed jointly by Eurocontrol and FAA. It is designed to enable the management and distribution of Aeronautical Information Services (AIS) data in digital format. The format contains support for a wide variety of aeronautical data, such as airports, airspaces, routes, navaids, and procedures. It also covers dynamic data, which is known as Digital NOTAM , and electronic Terrain and Obstacle Data (eTOD). Detailed information about the AIXM format and the various specifications can be obtained from Eurocontrol’s website. For more information, please visit http://www.aixm.aero.
The AIXM 5.1 component allows you to:
Lucy is a powerful high-level application framework for rapidly building applications that let you explore, analyze, and edit all kinds of geospatial data. Lucy is based on LuciadLightspeed, and integrates the functionality of LuciadLightspeed and many of its components in a configurable application.
The major Lucy benefit is that it has a lot of functionality common to many GIS applications built in. All that functionality is available in LuciadLightspeed as well, but there you still have to write all the boiler-plate code to tie it all together. If you use Lucy, you get all that code for free.
On this page you find an overview of the Lucy architecture and the most important functionality that Lucy has to offer.
The backend of Lucy (ILcyLucyEnv
) glues the different add-ons together.
Among other things, it exposes:
Learn how to use the Lucy API to load data on a map.
Learn how to add support for your own data format to Lucy.
The TLcyFormatBarAddOn
shows and hides a tool bar which allows to create and edit shapes.
The tool bar is shown on the map, and the contents depends on the selected layer.
This add-on is only responsible for showing and hiding the tool bar when appropriate. The actual contents of the tool bar is provided by the data format add-ons.
Lucy by default comes in three languages: English, Dutch and French. This page explains:
The TLcyLOSAddOn
and TLcyLspLOSAddOn
compute and visualize line-of-sight coverages (LOS coverages) on Lightspeed maps.
LOS coverages show the altitude under which aircraft (or helicopters) have to stay in order not to be detected by the radar.
The maps in Lucy do not only contain an ILcdView
, but also:
All these concepts are bundled in an ILcyGenericMapComponent
.
On this page you find the documentation for working with such maps that contain a Lightspeed view.
The maps in Lucy do not only contain an ILcdView
, but also:
All these concepts are bundled in an ILcyGenericMapComponent
.
On this page you find the documentation for working with such maps that contain a GXY view.
The TLcyMapEditUnitAddOn
adds the UI elements that allows users to switch between different formatting to show physical values in.
The TLcyWCSClientAddOn
allows you to connect to WCS servers, and visualize the data offered by the server.
When working with Lightspeed maps, you also need to include the TLcyLspWCSClientAddOn
.
The TLcyWFSClientAddOn
allows you to connect to WFS servers, and visualize the data offered by the server.
When working with Lightspeed maps, you also need to include the TLcyLspWFSClientAddOn
.
The TLcyWMSClientAddOn
allows you to connect to WMS servers, and visualize the data offered by the server.
When working with Lightspeed maps, you also need to include the TLcyLspWMSClientAddOn
.
The TLcyWMTSClientAddOn
allows you to connect to WMTS servers, and visualize the data offered by the server.
When working with Lightspeed maps, you also need to include the TLcyLspWMTSClientAddOn
.
The TLcyPreviewAddOn
allows you to replay recorded data or to preview simulated moving objects, such as aircraft,
vessels, and so on.
The TLcyPreviewAddOn
is essentially a wrapper around a com.luciad.realtime.TLcdSimulator
.
It has built-in support for having multiple ILcdSimulatorModel
instances at the same time, for filtering those ILcdSimulatorModel
instances, and for filtering the entire time range to a specific time range of interest.
When working with Lightspeed maps, you also need to include the TLcyLspPreviewAddOn
.
The TLcySelectionEditorAddOn
is responsible for showing the Object Properties panel,
and keeping the contents in sync with the currently selected objects on the map.
This add-on creates the ILcyApplicationPane
and populates it with an ILcyCustomizerPanel
for the selected domain object(s). The actual contents (= the ILcyCustomizerPanel
) is delivered by other add-ons
by registering an ILcyCustomizerPanelFactory
as service on the Lucy back-end.
For example the TLcyTreeTableViewAddOn
registers such a factory.
The Lucy backend (ILcyLucyEnv
) provides a mechanism for sharing objects between different
parts of Lucy without creating a hard dependency between those parts.
This mechanism is called the service mechanism.
You can see it as a giant bag: you can put objects in the bag with
ILcyLucyEnv#addService(Object)
,
and remove them from the bag with ILcyLucyEnv#removeService(Object)
.
It is also possible to request from the bag all objects that extend or implement a certain class or interface.
An example use case of why it is important to have such a mechanism involves the Lucy map add-on: the map add-on has an action to load data on the map, which needs to support a lot of data formats. Loading data on the map requires model decoders and layer factories. You can make those model decoders and layer factories available as services. By letting the loading action delegate to the model decoder and layer factory services, the action can support all data formats. You can add support for an extra data format without changing any action code, by adding new model decoders and layer factories to the services.
In this scenario, the data format add-ons are the suppliers of the services, and the open action of the map add-on a consumer of those services.
The TLcyToteAddOn
and TLcyLspToteAddOn
provide a tabular view on
the data in a model.
These add-ons only provide the UI. The action to open the table view for the currently selected layer is
provided by the TLcyModelCustomizerAddOn
.
The TLcyTreeTableViewAddOn
provides a default object properties panel which shows the
properties of an ILcdDataObject
.
This add-on only provides the UI. The action to open the object properties panel for the currently selected
object is provided by the TLcySelectionEditorAddOn
.
The TLcyVerticalViewAddOn
allows to display a vertical (or profile) view along some polyline.
If available, elevation data is displayed as well.
The default Lucy contains a menu bar, several tool bars and pop-up menus. It is possible to customize those menu and tool bars. For example, you can remove entries, change an icon, provide another tool tip, and so on. To solve the most common and basic use cases, you can adjust configuration files. No coding is required.
Other modifications require knowledge and understanding of the Lucy action bar API. For example, you need the API to add your own entry to an existing tool bar, or to create your own tool bar and populate it with your own entries and entries already present in Lucy.
Both scenarios are documented here.
Add-ons are responsible for providing the majority of the functionality to Lucy. This page documents how you can write your own add-ons, and highlights some of the classes you can use as starting point.
The Lucy UI is composed of a number of panels.
For example the map is contained in a panel, the layer control in another panel, the object properties in yet
another panel, ... .
These panels are called ILcyApplicationPane
instances in the Lucy API.
Application panes make abstraction of the actual form of these panels: they can be tabbed panes, internal frames, panels inside a bigger whole or anything else you can come up with. In the out-of-the-box setup, the application panes are the dockable frames inside the Lucy frame.
This abstraction is useful because it allows you to change the Lucy frontend, which defines the form of the application panes, while add-ons can just work with the application panes without knowing where and how they are displayed.
The TLcyAsynchronousPaintAddOn
offers support for painting GXY layers in a thread that differs from the event dispatch thread.
This paint thread draws layers in a special temporary buffer.
The image produced in the buffer is then painted onto the map using the normal drawing routines.
Because a layer is not necessarily thread-safe, some precautions are needed to ensure that the layer is not simultaneously
accessed in different threads.
The asynchronous layer add-on handles most of this work by offering an API for creating and accessing asynchronously painted
layers.
The API is encapsulated in a single facade that implements the abstract class ALcyAsynchronousPaintFacade
.
UI panels often show the current state of an object, and the UI panel is kept in sync with the state of the object:
Lucy contains a number of these panels. Examples are the object properties panel, the tabular view, the layer properties panels, and so on.
All these panels are com.luciad.lucy.gui.customizer.ILcyCustomizerPanel
instances.
This page contains information on how to deploy your Lucy application.
The TLcyDrawingAddOn
adds functionality to Lucy to draw various shapes such as points, polylines, polygons, buffers, and so on, on the map in
multiple drawing layers.
When working with Lightspeed maps, you also need to include the TLcyLspDrawingAddOn
.
The frontend of Lucy is the part that starts Lucy, creates the general user interface and loads the add-ons.
Lucy is delivered with one such frontend, TLcyMain
, which can create two different kinds of user interfaces (one with dockable frames or one with tabbed panes) and put this
in a JFrame
that it creates itself.
This page describes how to completely replace the frontend application by a custom implementation, offering unlimited flexibility over the main class, the user interface, whether to use tabbed panes, how many tabbed panes to use, where to put them, addon loading, position of the frame, number of frames, ... .
TLcyLspMapAddOn
is the Lightspeed counterpart of the TLcyMapAddOn
.
It integrates the Lightspeed technology into Lucy by providing an implementation of
ILcyGenericMapComponent
suited for Lightspeed views: ILcyLspMapComponent
.
The creation of those ILcyLspMapComponent
instances is the responsibility of a
factory: TLcyLspMapComponentFactory
.
Furthermore, it registers the TLcyLspMapManager
, a TLcyGenericMapManager
extension, as a Lucy service.
This manager does the bookkeeping for the created ILcyLspMapComponent
instances.
At last the add-on provides workspace support for the Lightspeed map components.
TLcyMapAddOn
is the GXY counterpart of the TLcyLspMapAddOn
.
It integrates the GXY technology into Lucy by providing an implementation of
ILcyGenericMapComponent
suited for GXY views: ILcyMapComponent
.
The creation of those ILcyMapComponent
instances is the responsibility of a
factory: TLcyMapComponentFactory
.
The TLcyMapOverviewAddOn
and TLcyLspMapOverviewAddOn
provide
an overview map. This overview map:
The TLcyMapOverviewAddOn
is responsible for providing the overview map, and plugs in support for the GXY map components.
The TLcyLspMapOverviewAddOn
only plugs in the support for Lightspeed maps.
The Lucy framework provides an application wide preference mechanism, from which addons can retrieve certain user preferences or store their own, and be notified of changes in these preferences. These preferences typically represent a way in which the user wants to see a feature configured, for example the preferred look and feel of the Lucy application.
The TLcyPersistentPreferencesAddOn
stores and restores the preferences to persistent
storage.
The TLcyPrintAddOn
and TLcyLspPrintAddOn
allow you to print a map.
Next to the actual printing, they also provide a UI to display a preview of the print.
Lucy provides a standard mechanism for lengthy operations to report their progress. At the same time Lucy provides a mechanism to notify listeners of this progress, which can be useful to show custom progress bars in a Lucy-based application.
The TLcyUndoAddOn
adds menu entries to undo and redo the last operations.
This add-on is only responsible for providing those menu entries.
The actual undo and redo functionality is provided by:
ILcyLucyEnv
provides an application-wide
TLcdUndoManager
.
ILcdUndoable
instances they create to that manager.
The menu entries provided by the TLcyUndoAddOn
then instruct the
TLcdUndoManager
to undo or redo the last operations.
Lucy users can store the state of the application in a so-called workspace. Later they can return the application to the state where they left off by reloading the workspace.
They do not have to reset their GUI preferences, nor do they have to reload their maps. The GUI layout is restored as it was in the previous session, maps are opened in their previous positioning, and additional data is reloaded as map layers.
The map-centric version of Lucy uses a custom front-end with a single, centrally placed map. The front-end is available as sample code. This version also uses a few dedicated sample add-ons which have their own customization options.
The TLcyLspCameraLinkAddOn
adds tracking camera functionality to Lightspeed maps.
This allows to for example look at and look from a (moving) object.
The military symbology addons allow you to visualize and edit the symbols defined by the MIL-STD-2525 and APP-6 military standards in Lucy applications.
The TLcyDebugAddOn
adds UI elements to Lucy which facilitates debugging.
Get started with the Lucy API, and write your first addon for Lucy.
This page contains a tutorial illustrating the basic usage of our API to write your first Lucy application addon.
The TLcySearchAddOn
is responsible for creating the UI of the search box,
and providing the search logic that allows Lucy users to search loaded data, coordinates, and a
geo-coding service.
It connects to a public web service GeoNames to look up the location of place names and country names.
Before you can query that web service, you need to create a free account. Each account has a daily limit of requests it can
perform.
If you want to use this service in your own application, it is highly recommended to create your own account and configure
the user name
in the config/lucy/search/TLcySearchAddOn.cfg
file.
The LuciadLightspeed product comes with a number of more elaborate demo or sample applications for which we provide a user guide. The collection of available user guides is found on this page.
MBTiles is a file format for storing tiled data in SQLite databases. LuciadLightspeed supports the loading and
visualization of MBTiles files (*.mbtiles
) and MBTiles services (TileJSON
endpoints) with vector and image tiles.
Find out how LuciadLightspeed implements standards ISO 19115 and ISO19139, which allow you to add standardized metadata to your data models.
OGC GeoPackage is an open, standards-based, platform-independent, portable, self-describing, compact format for transferring geospatial information.
SQLite SpatiaLite is an extension of SQLite adding fully fledged Spatial SQL capabilities to SQLite.
The LuciadLightspeed Database Connectors component provides support for seamlessly integrating DB2 Spatial and Geodetic databases into LuciadLightspeed applications.
The DB2 Spatial Extender and the Geodetic Data Management Feature are extensions for the DB2 database system. They introduce additional SQL types for representing various types of geometries. These can be inserted as single entities into the spatial columns, which can co-exist with traditional non-spatial columns. The extensions then provide additional functions for indexing and querying the spatial data.
The IBM manual DB2 Spatial Extender and Geodetic Data Management Feature, User’s Guide and Reference provides all the necessary information on setting up, maintaining, and using spatial databases. This page explains how spatial data in DB2 can be accessed from LuciadLightspeed.
The Informix Geodetic functionality in the LuciadLightspeed Database Connectors component provides support for seamlessly integrating IBM Informix Geodetic databases into LuciadLightspeed applications.
The IBM Informix Geodetic Datablade (IGD) is an extension for the IBM Informix Dynamix Server. The IGD introduces additional SQL types for representing various geometries. These can be inserted as single entities into the spatial columns, which can co-exist with traditional non-spatial columns.
The IBM Informix Geodetic User’s Guide and Reference provides all the necessary information on setting up, maintaining, and using spatial databases. This page explains how spatial data can be imported from, and exported to, spatial databases.
The Informix Spatial functionality in the LuciadLightspeed Database Connectors component provides support for seamlessly integrating IBM Informix Spatial databases into LuciadLightspeed applications.
The IBM Informix Spatial Datablade (ISD) is an extension for the IBM Informix Dynamix Server. The ISD introduces additional SQL types for representing various geometries. These can be inserted as single entities into the spatial columns, which can co-exist with traditional non-spatial columns.
The IBM Informix Spatial User’s Guide and Reference provides all the necessary information on setting up, maintaining, and using spatial databases. This page explains how spatial data can be imported from, and exported to, spatial databases.
The LuciadLightspeed Database Connectors component provides support for the seamless integration of Microsoft SQL Server databases into LuciadLightspeed applications.
The Microsoft SQL Server Documentation provides all the necessary information on the setup, maintenance and use of spatial databases. This page explains how spatial data can be imported from, and exported to, spatial databases.
Get started with the LuciadLightspeed API and write your first application with a 2D GXY view.
This page contains a number of tutorials illustrating how you can write your first 2D application using LuciadLightspeed API basics.
The LuciadFusion product can preprocess and tile multiple LIDAR data files (LAS/LAZ files) into a single data
set.
This data set is stored in the Luciad Point Cloud (LPC) format, and the entry file is the
tilestore.lpc
file.
The LPC data can be served by LuciadFusion using the OGC 3D Tiles protocol, but it can also be opened directly by LuciadLightspeed.
OSGB is a file format that originates from OpenSceneGraph.
It is supported as an exchange format by various 3D modeling tools.
The format describes a hierarchy of textured 3D models, similar to the OGC 3D Tiles format.
Each tile is stored in a separate .osgb
file, which can use relative paths to reference
its children.
For more information, see http://www.openscenegraph.org.
An OGC Web Coverage Service (WCS) returns coverages. A coverage consists of space-varying information. It is a collection of geospatial data, with property values that vary as geographic locations change. Typical examples of coverages are demographic information like population density, weather charts with temperature information, or elevation maps. The information has not been rendered by the server and is intact.
The OGC WCS specification defines a standard interface for the querying of coverages. The LuciadLightspeed WCS client API provides a simple framework for connecting to a WCS and obtaining coverage data from it.
A OGC Web Feature Service (WFS) service client allows you to insert, update, delete, query and discover geographic features on an OGC server. WFS delivers GML representations of simple geospatial features in response to queries from HTTP clients. Clients access geographic feature data through WFS by submitting a request for just those features that are needed for an application.
The OGC WFS specification defines a standard interface for querying and manipulating geographic data. Queries can be formulated based on various spatial and non-spatial constraints, as defined by the OGC Filter specification.
A WFS provides geographic information in a rich format, without any prior interpretation or rendering, and with full georeferencing. This contrasts with, for instance, the WMS interface, which renders maps on the server side and returns simple images to the client. The default exchange format for geographic features is GML, another OGC standard.
The LuciadLightspeed WFS client API provides a simple framework for connecting to a WFS and retrieving feature data from it. Additionally, support is offered to send transactions to the WFS, enabling users to update, delete and / or insert features on the server.
An OGC Web Map Service (WMS) returns static maps, rendered as images. The WMS specification defines a standard web service interface for the retrieval of maps of geographical data over the Internet. In general, a WMS is accessed by a client application that provides the user with interactive controls.
The LuciadLightspeed WMS client API provides an easy framework to connect with a WMS service and use the available data in an application. You can build programs that access all information published inside the WMS capabilities, choose the desired layers and visualize the resulting data in a 2D and 3D view.
The client supports automatic re-projection of the retrieved maps, when the geographical reference of the client application is not supported by the WMS. In addition, you can choose to retrieve the data using a tiled approach, next to the classic map approach. The styling of a layer can optionally be configured through an OGC Styled Layer Descriptor (SLD), if supported by the server.
Next to the ability to retrieve map data, the LuciadLightspeed WMS Client API supports various other requests defined by the WMS specification. This includes support for GetFeatureInfo requests to retrieve more information about a particular point on a map, GetLegendGraphic requests to acquire legend symbols and DescribeLayer requests to obtain feature/coverage-type information for a layer. Vendor specific requests are also supported and can be easily integrated in the API.
An OGC Web Map Tile Service (WMTS) serves digital maps in the form of predefined image tiles. The OGC WMTS specification standardizes how a WMTS server publishes the available images, as well as how the images are exchanged between a WMTS server and a WMTS client.
Since the structure of the image data is strictly defined, visualizing data from a WMTS server is usually much more efficient than from a WMS server.
The LuciadLightspeed WMTS client API provides an easy framework to connect with a WMTS service, discover the available WMTS layers and visualize them in an application. The API includes a model decoder that connects to a WMTS server and creates a model for the desired WMTS layer, ready for visualization in a 2D and 3D view. Next to visualizing WMTS layers, you can also perform WMTS GetFeatureInfo requests to retrieve more information about a location on a WMTS layer.
An Electronic Chart Display and Information System (ECDIS) is a computer-based navigation system which is used to visualize digital nautical data, as an alternative to paper nautical charts. Nautical data includes all information which may be of assistance for the safe navigation of vessels at sea and harbors, such as sea depth information, positions of buoys, lights, wrecks, and so on. The data to be rendered can be either vector or raster data.
Data for vector-based ECDIS systems are distributed as cells, called Electronic Navigational Charts (ENC). Each ENC cell contains nautical data for a specific region, ranging from very large regions, such as parts of oceans, to small regions, like berthing areas inside harbors.
Multiple ENC cells may be grouped into a catalogue. Catalogues are useful for the efficient distribution and processing of ENC cells: they provide an index of all their ENC cells, together with the spatial extent of each cell. This allows for the efficient retrieval of geographical data for a specific region and scale, without the need to scan each individual ENC file.
The LuciadLightspeed XML binding framework allows you to convert XML documents into Java content trees and the other way around. The framework supports other LuciadLightspeed XML-based formats, such as GML, AIXM and OGC Filter.
Decode and visualize DIMAP data.
Decode and visualize data in the ECW format (*.ecw
, *.ers
).
Decode and visualize data in various raster formats supported by GDAL.
Decode and visualize data in the GeospatialPDF format (*.pdf
).
Decode and visualize data in the GeoSPOT format (*.DSC
, *.REP
).
Decode and visualize data in the MrSID format (*.sid
).
Decode data that contains panoramic images, and convert them to the Luciad Panorama Format. You can let LuciadFusion serve the Luciad Panorama Format for use in LuciadRIA.
Using a Panoramics service you can serve panoramic image data to LuciadRIA.
Decode panoramic image data in the Leica Pegasus data format. For more information about processing panoramic image data, see the Panoramic image data section of the LuciadLightspeed documentation.
Decode and visualize data in the SwissDHM format (*.mlt
, *.mbl
).
Dynamic data introduces a new dimension to existing georeferenced, two-dimensional or three-dimensional data:
time.
To handle the increased complexity that time adds to that kind of data, the Real-time Engine component provides
the com.luciad.realtime
package.
This package contains components for implementing real-time related functionalities and animations on a map.
It provides the ability to play back a simulation in fast or real time, and update one or more map views at
desired refresh rates.
An example of the increased complexity handled by the Real-time Engine component is the decluttering of labels for moving objects. Standard labeling algorithms can cause a label to jump from one location to another when overlap is about to occur. The realtime package provides a highly specialized labeling algorithm that gently moves the labels around to avoid overlap.
Radar feeds in any format can be visualized on a Lightspeed view.
The LuciadLightspeed Database Connectors component extends the LuciadLightspeed Oracle Locator functionality by adding support for decoding GeoRaster data stored in Oracle Spatial tables.
The Oracle Spatial GeoRaster book provides a complete description of the tables and data structures used for rasters. Briefly, Oracle rasters are stored in two related data structures, called SDO_GEORASTER and SDO_RASTER, respectively. The first structure contains raster metadata (format and storage parameters, georeferencing, spatial extent, etc) while the second contains the binary data, in a separate table. See http://download.oracle.com/docs/cd/B19306_01/appdev.102/b14254/toc.htm for more information.
Decode and visualize data encoded in a Google Earth Enterprise repository.
Important: this functionality still has beta status.
The package format.gdf
is part of the LuciadLightspeed Graph and Routing Engine
component, and allows you to access GDF (Geographic Data Files) data.
This developer's guide gives a short introduction to the GDF format, and explains how to incorporate it in your
LuciadLightspeed applications using the format.gdf
package.
With the GDF functionality, you can:
Much geographical data has a network-like structure: roadmaps, railways, or pipelines, for example. The Graph and Routing Engine component offers networking and route planning functionality to support for all kinds of network-related processing. It provides classes for representing graphs and implementations of algorithms for calculating shortest routes in a graph, creating a trace, and so on.
Develop and deploy your own OGC-compliant web service to serve your data.
Using a Web Map Service (WMS), you can serve map images to WMS clients, such as LuciadLightspeed and LuciadRIA.
The supported WMS versions are 1.1.1 and 1.3.0. These requests are supported:
GetCapabilities
, to discover the service metadata and offered layers.
GetMap
, to request maps for one or more layers.
GetFeatureInfo
, to request more information for a location on a map.
The TLcyShapeVisibilityAddOn
and
TLcyLspShapeVisibilityFormatAddOn
compute and visualize what parts of one or more objects can be seen from one or more points.
The TLcyShapeVisibilityAddOn
provides all model-related functionality, and
the TLcyLspShapeVisibilityFormatAddOn
is responsible for visualizing the data on the map.
The TLcyContourAddOn
computes and visualizes height lines for ILcdShape objects.
The TLcyExtremePointAddOn
computes and visualizes highest and lowest points for ILcdShape objects.
The TLcyHypsometryAddon
computes and visualizes hypsometric information for a given layer or the entire view.
The TLcyLOSCoverageAddOn
computes and visualizes line-of-sight coverages (LOS coverages).
LOS coverages show the altitude under which aircraft (or helicopters) have to stay in order not to be detected by the radar.
The TLcyVisibilityAddOn
computes and visualizes what parts of one or more objects can be seen from one or more other objects.
The TLcyTEAControllerAddOn
shows a tooltip for elevation data and allows you to inspect the height of an area specified by a line segment.
The TLcyViewshedAddOn
computes and visualizes visibility for a 3D scene composed of terrain, buildings and 3D meshes.
The Terrain Analysis Engine provides classes to compute the line-of-sight between two points and between a point and its environment. Both direct and radar line-of-sight computations are supported. Due to radar wave properties a radar can look over a hill for example.
The Terrain Analysis Engine provides functionality to compute the visibility from a shape to another shape.
This computation is illustrated in the sample samples.tea.gxy.visibility.MainPanel
.
By using the shape-to-shape visibility computations, the following questions can be answered:
Learn how to work with elevation data in the Terrain Analysis API.
LuciadLightspeed provides several contour finders in the package com.luciad.contour
.
Refer to the javadoc of that package for an overview of the API.
Calculate the lowest and highest points in an area.
The Terrain Analysis Engine provides support to compute and display hypsometric views of elevation data.
The Terrain Analysis Engine provides viewsheds to compute which parts of a threedimensional scene are visible in the presence of obstacles like buildings and terrain. Conceptually a viewshed divides a volume into visible and invisible regions with respect to an observer. For instance it answers the following questions:
In general, a viewshed defines an interface to determine whether any point in threedimensional space is visible or not.
The NetCDF data format describes array-oriented scientific data.
NetCDF scientific weather data is stored as gridded datasets. The types of measurement and the dimensions along which they are measured determine the structure of the datasets. The measurements are referred to as variables. Temperature, humidity, and cloud cover are all examples of variables. The dimensions of the measurements typically consist of the location coordinates of the measurement, the time of the measurement, and other parameters, such as the altitude at which the measurement was taken. For instance, atmospheric temperature can be measured at a specific location, but at multiple times and vertical positions. These measurements results in a NetCDF temperature dataset, with measurement grids organized along the spatial, temporal and vertical dimensions.
By default, NetCDF allows multiple sets of variables in a single file, so one file can contain both salinity and temperature measurements for example.
The NetCDF standard itself does not impose any semantic rules or conventions, just like XML files or comma-separated value files.
LuciadLightspeed mainly uses the NetCDF format to decode data that complies with the Climate and Forecast (CF) Metadata Conventions. The CF conventions define metadata that describe what the data in each NetCDF variable represents, and the spatial and temporal properties of this data. The data model is widely used in climate and weather forecast systems and in other geoscience communities, and has been adopted by the Open Geospatial Consortium.
GRIB (GRIdded Binary or General Regularly-distributed Information in Binary form) is a concise data format. It is commonly used in meteorology to store historical and forecast weather data.
The Binary Universal Form for the Representation of meteorological data (BUFR) format describes weather features and other natural phenomena such as volcanic activity.
BUFR is a binary format that contains the location and other details of weather and other natural phenomena, such as clouds, jet streams, volcanoes, and tropical cyclones. The World Area Forecast System (WAFS) produces Significant Weather (SIGWX) bulletins in the BUFR format. LuciadLightspeed can decode these WAFS SIGWX files as vector features and visualize the data in a manner similar to the SIGWX charts that WAFS also produces.
LuciadLightspeed only supports decoding WAFS SIGWX BUFR files. BUFR files that do not follow this standard cannot be decoded.
The Tiling Engine is a service that organizes geospatial source data in a hierarchical tile structure, called a coverage. This organization into a multi-leveled tile pyramid is called fusion, and optimizes access to the data for the purpose of querying, visualization, and analysis.
The Tiling Engine consists of API that allows you to optimize imagery, elevation, and multi-dimensional data in a pre-processing step. It takes your data, and turns it into a high-performance tile pyramid repository on disk. The resulting multi-leveled coverages allow for a much smoother visualization and analysis experience in Luciad products as well as other OGC clients.
Multi-leveling and tiling data offers advantages in cases similar to these:
The tiles can be stored as individual coverages, or as part of a Tile Store. A Tile Store is a logical structure combining various coverages.
Pre-processing point cloud data consists of taking all the point cloud data sets, splitting them up into manageable chunks, and adding multi-leveling in the form of big, lower-quality tiles. The objective of the pre-processing is to make sure that the data set can be served efficiently from a server to a client. The tiled point cloud coverage can be served with a protocol, such as the OGC 3D Tiles protocol.
The Aeronautical Information Exchange Model or AIXM is an XML-based data format developed by Eurocontrol to encode and distribute aeronautical information. The format contains support for a wide variety of aeronautical data, such as airports, airspaces, routes, navaids and procedures. This developer’s guide focuses on the use of AIXM versions 3.3, 4.0 and 4.5, on which the implementation in the format.aixm package is based. Detailed information about the AIXM format and the various specifications can be obtained from Eurocontrol’s website.
The AIXM component allows you to:
The DAFIF specification defines a data format for a wide variety of aeronautical information, such as air spaces, routes, waypoints, navaids, airports and runways. This page describes how you can decode and visualize this data using the LuciadLightspeed API.
The ARINC 424 specification defines a data format for a wide variety of aeronautical information, such as airspaces, routes, waypoints, navaids, airports, heliports and runways. The ARINC 424 specification can be obtained from the ARINC website.
The ARINC component allows you to:
Decode data in the Binz format (*.binz
), and convert it to OGC 3D Tiles data.
Decode and visualize data in the Microstation DGN format (*.dgn
).
Decode and visualize data in the AutoCAD DWG and DXF format.
The Industry Foundation Classes (IFC) format is an open international standard for Building Information Model (BIM) data that is exchanged between different software applications. This data describes a building or facility, including spatial elements, materials and shapes.
See buildingSMART for more information about the specification.
The IFC data can be served by LuciadFusion using the OGC 3D Tiles protocol. The attributes of the IFC elements can be served by LuciadFusion through a WFS service. It can also be opened directly in LuciadLightspeed, although this is not recommended due to a large memory footprint and high CPU load.
Use a 3D Tiling Engine to tile and multi-level 3D meshes to a 3D Tiles tileset optimized for streaming. You have access to a command line sample that supports OBJ input files and georeferencing, and a more flexible API that allows you to plugin custom mesh formats and custom references.
Decode and visualize data in the Autodesk Revit format (*.rvt).
The Revit data can be served by LuciadFusion using the OGC 3D Tiles protocol. The attributes of the elements can be served by LuciadFusion through a WFS service. It can also be opened directly in LuciadLightspeed, although this is not recommended due to a large memory footprint and high CPU load.
Decode and visualize data in the BCI format (*.matrxmap
).
The LuciadLightspeed Defense Standards component includes the package
com.luciad.format.mgcp
for creating MGCP layers.
The MGCP functionality allows you to:
Decode and visualize data in the CADRG (Compressed ARC Digitized Raster Graphics) format (*.toc
).
Decode and visualize data in the CIB (Controlled Image Base) format.
Decode and visualize data in the ECRG format (TOC.xml
).
Decode and visualize data in the NITF/NSIF (STANAG 4545) format (*.ntf
).
Decode and visualize data in the ASRP/USRP/ADRG format (01.THF
, *01.GEN
, *01.QAL
, .SOU
, *.IMG
).
The LuciadLightspeed Defense Standards component includes the package com.luciad.format.vpf
for decoding and displaying Vector Product Format (VPF) data.
The VPF functionality allows you to:
The package com.luciad.format.asdi
provides the ability to decode and display ASDI data.
It enables to decode ASDI data from a file or from a live stream.
It enables to replay ASDI data from a file as if it came from a live stream.
Finally it offers access to the parsed messages directly, offering fine-grained control.
The FAA provides airlines and other aviation-related organizations with access to near real-time air traffic data from the National Airspace System (NAS) through the ASDI feed of the Enhanced Traffic Management System (ETMS). More information on ASDI can be obtained from http://www.fly.faa.gov/ASDI/asdi.html.
ASTERIX is the EUROCONTROL standard for exchanging ATM surveillance data. More information on the ASTERIX standard can be obtained from EUROCONTROL http://www.eurocontrol.int/asterix/.
The LuciadLightspeed Radar Connectors component offers the com.luciad.format.asterix
package.
The ASTERIX functionality provides the ability to decode and display ASTERIX data.
It allows you to decode ASTERIX data from a file or from a live stream of radar data.
It also allows you to replay ASTERIX data from a file as if it came from a live stream.
The Defense Symbology component provides support for the MIL-STD-2525B, MIL-STD-2525C, MIL-STD-2525D, APP-6A, APP-6B, APP-6C and APP-6D military standards. These standards define a symbol set that is used to plan and execute military operations in support of Command, Control, Communications, Computers, and Intelligence (C4I) functions. The MIL-STD-2525 standards were developed by the United States Department of Defense (DOD), while the APP-6 standards were developed by the North Atlantic Treaty Organization (NATO). Additionally, support is offered for TTA-106 V4. This is a military standard developed by DGA (Direction Générale de l’Armement). It extends the APP-6A symbology with a number of new units and tactical symbols.
The Defense Symbology component allows a LuciadLightspeed user to create MIL-STD-2525B, MIL-STD-2525C, MIL-STD-2525D, APP-6A, APP-6B, APP-6C and a subset of the APP-6D symbols and visualize them on a map. The MIL-STD and APP-6 standards each have a separate package in the API, but their use is completely analogous.
Learn how to add a military grid to your view with the help of grid layers and grid layer builders.
NATO Vector Graphics address the requirement to unambiguously convey and display situational awareness information suitable for a Common Operational Picture (COP).
NVG consists of a data/file format for the encoding of battle space objects into overlays, and protocols for the automated exchange of the overlays.
The NVG functionality in LuciadLightspeed allows you to: