A LuciadLightspeed model is a container for a set of geographical data of the same type, for example, cities, roads, elevation data, flight plans, and so on. There are two types of geographical data:
Vector data that consists of geometries, such as points, lines, circles, and polygons. Examples of vector data are streets, buildings, airports, radars, and so on.
Raster data that consists of a grid of cells. Examples of raster data are aerial photographs, satellite images, weather data, elevation data, and so on.
In the LuciadLightspeed API, it is represented by the
Typically, the model is the result of decoding a data source by means of an
Examples of data sources are:
A file: you decoded a SHP file, for example.
A database: you connected to a PostgreSQL PostGIS database, for example.
A URL: you connected to an OGC WMS web service, for example.
The contents or elements of an
ILcdModel are called domain objects.
For example, when you are decoding roads data, one road could be a single domain object.
Associated to each
A model reference (
com.luciad.model.ILcdModelReference) that specifies the coordinate reference system used for locating the model data on earth. All LuciadLightspeed models need to be associated with a reference system. Otherwise, it is not possible to determine the location of the data.
This also implies that the geometry or location of every domain object in an
ILcdModelmust be defined in the same reference system, for example WGS84.
A model descriptor (
com.luciad.model.ILcdModelDescriptor) that provides additional information, or metadata, about the model. Each model descriptor describes:
The source of the model. For example when the model was created by decoding a file, the source would be the file path.
The type or format of the model. For example when decoding a SHP file, the type information exposed by the model descriptor indicates the data is SHP data.
A display name for the model which can be shown in the UI to the user. For example when you are decoding a file called
rivers.shp, the display name for the model could be
Some model descriptors expose extra information. For example:
The model descriptor can expose whether the model contains raster or vector data.
For models representing vector data, the model descriptor can expose which properties are available in the data. For example, the domain objects in a roads data set may not only contain the road geometry, but also properties like the road name. In this case, the model descriptor would describe that the road name property is available on each domain object.
For models representing data in a database, the model descriptor can expose database-specific information: from which table the data is derived.
You almost never have to implement the
ILcdModel interface yourself.
When you need to create an
ILcdModel, when you are writing an
ILcdModelDecoder for your own data format for example,
you typically choose one of the existing implementations:
TLcd2DBoundsIndexedModelis an implementation that stores the domain objects in a spatial index. The domain objects are indexed based on their coordinates, or bounds, and can be retrieved using spatial queries.
It is recommended to use this model in the following two cases:
Most of the time, only a subset of the data will be used.
For example, when adding the data on a map, you configure the layer in such a way that the data only appears when the user zooms in. When the user zooms in, the layer will request only the relevant data from the model because the model allows for spatial queries.
The data is (almost) static.
Building up the spatial index comes with a slight cost. Each time elements change in the model, the spatial index must be updated.
TLcdVectorModelis an implementation that stores the domain objects in a vector, allowing for fast integer-based queries. It does not allow for efficient spatial queries, however, as there is no spatial index.