You can extend the LuciadFusion Platform with more functionality. For instance, you can add custom services, add support for data types, and customize data styling.
LuciadFusion Studio offers several options for customization and further configuration. For example, you can:
Find out more about loading and managing data in LuciadFusion Studio. This page offers advice about ways to load, process, and publish several data types. Depending on the characteristics of a dataset, and your publication goals for it, you can select the best approach.
Using the LuciadFusion Studio REST API, you can automate your data management operations in the web interface.
Get started with LuciadFusion Studio. LuciadFusion Studio is a web-based end-user application to manage your geospatial data. It:
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.
Learn how to best configure LuciadFusion for use in a cloud environment, such as the Amazon AWS cloud.
Integrate multiple LuciadFusion instances to function as one unit. A multi-node setup has benefits for resource management, service availability, and performance.
Set up your system so that you can start developing with LuciadFusion.
Find out which product tier gets you what functionality, and read some tips for a smooth interaction with our support desk services.
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.
Use the Data Connectivity Manager (DCM) to process your data and store it as LuciadFusion coverages.
Learn how to migrate your server and possible custom development to the latest version of LuciadFusion.
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.
You can make LuciadFusion available through Apache Maven, a development project management and build automation tool.
Find out how the new features and feature updates of this version can benefit you.
A File Server service provides an HTTP File Server so that you can serve the files in geospatial data sets.
Using an HSPC service, you can serve Hexagon Smart Point Cloud (HSPC) data to HSPC clients, such as LuciadRIA.
The HSPC format offers tiled and multi-leveled point cloud data. HSPC is a proprietary Hexagon format. Hexagon Geosystems sensors, such as the BLK2GO or the BLK360, produce HSPC data.
The HSPC format describes a 3D tiles hierarchy, using:
tree.hspc.
Using a Luciad Tile Service (LTS) you can serve elevation data and LuciadFusion coverage data to LuciadLightspeed, Lucy, and LuciadRIA.
You can create LuciadFusion coverages of your data with the Data Connectivity Manager (DCM) or the Tiling Engine. If you add such a coverage to LuciadFusion Studio, you can instantly create a product containing that coverage. Products containing a LuciadFusion coverage do not require any pre-processing. The LTS service serves a product containing a LuciadFusion coverage directly.
If you create a product with elevation data, LuciadFusion automatically pre-processes it into a LuciadFusion coverage when you add the product to an LTS service.
Using an MBTiles service, you can serve MBTiles data to MBTiles clients, such as LuciadCPillar.
Using an OGC 3D Tiles service, you can stream 3D geospatial point cloud and mesh data to clients, such as LuciadLightspeed and LuciadRIA.
Use the Catalogue Service for the Web (CSW) to query the geospatial data and services available in LuciadFusion.
The supported CSW versions are 2.0.2 and 3.0. These requests are supported:
GetCapabilities, to discover the service metadata and offered catalog capabilities.
DescribeRecord (CSW 2.0.2 only), to discover what you can query from the catalog server.
GetRecords, to query the catalog server.
GetRecordById, to query the catalog server by a unique identifier.
OpenSearch web search engine template standard.
Using a Web Coverage Service (WCS), you can serve coverages to WCS clients, such as LuciadLightspeed and Lucy.
The supported WCS versions are 1.0.0, 1.1.0, 1.1.1 and 2.0.1. These requests are supported:
GetCapabilities, to discover the service metadata and offered coverages.
GetCoverage, to request data for a coverage.
DescribeCoverage, to request metadata for a coverage.
Using an OGC Web Feature Service (WFS) service, you can serve vector data to WFS clients, such as LuciadLightspeed and LuciadRIA.
The supported WFS versions are 1.0.0, 1.1.0 and 2.0.0. These requests are supported:
GetCapabilities, to discover the service metadata and offered feature types.
GetFeature, to request data for a feature type.
DescribeFeatureType, to request the XML Schema for a feature type.
ListStoredQueries and DescribeStoredQueries, to respectively
get a list and a description of the available stored queries. You can optionally use those stored queries in GetFeature requests.
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.
Using a Web Map Tile Service (WMTS) you can serve map tiles to WMTS clients, such as LuciadLightspeed and LuciadRIA.
The supported WMTS version is 1.0.0. These requests are supported:
GetCapabilities, to discover the service metadata and offered layers.
GetTile, to request tiles for a layer.
GetFeatureInfo, to request more information for a location on a tile.
Using a Panoramics service you can serve panoramic image data to LuciadRIA.
Decoding data stored in the cloud, such as data made available from an Amazon AWS S3 storage service.
Learn how to:
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.
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.
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.
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.
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.
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.
Develop and deploy your own OGC-compliant web service to serve your 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:
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 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:
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.
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.
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).
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.
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.
The ECW Protocol (ECWP) is a streaming protocol for sending ECW and JPEG2000 images over a network. Using an ECWP service, you can serve ECW and JPEG2000 data to ECWP clients.
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.
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.
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 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 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 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:
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 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:
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:
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: