The concepts and modules discussed in this article are all part of the
LuciadRIA is based on the Model-View-Controller (MVC) architecture. The underlying concept of the MVC architecture is to separate the data (model), representation of the data (view), and the user interaction (controller) from each other. This separation results in a simpler design of the application and a higher flexibility and re-usability of code.
The MVC parts of LuciadRIA are defined as follows:
A LuciadRIA model stores and describes geospatial data irrespective of how to visualize and interact with the data. For example, a model has the location of some cities together with information such as the city name.
A LuciadRIA view has all information for the representation of the data in LuciadRIA models. A view does not have the data itself. For example, cities may be visualized by an icon of which the size varies with the size of the city population, but the model has the location of the city and the population size.
A LuciadRIA controller interprets user interaction and performs the required action on LuciadRIA models and views irrespective of the type of model and view.
Separating the different parts of the application allows you to reuse objects for different purposes and redefine objects without changing other objects. You can, for example, change a view without making changes to the models represented in the view. Similarly, you can redefine user interaction on a view without changing the view. The reuse of objects shortens the time to develop the application. It also enhances the functional consistency and design of all your applications.
The model API in LuciadRIA deals with the representation, retrieval, and storage of geospatial data. It is designed to be compatible with the HTML5/W3C IndexedDB Object Store API.
The LuciadRIA Store API is designed to be a small subset of the HTML5/W3C IndexedDB Object Store API. This approach offers three main benefits:
Asynchronous data downloading.The Store API is specifically designed to take advantage of some unique properties of a web-based LuciadRIA application:
Remote data is always downloaded in an asynchronous manner.
Data is often filtered, sorted, or otherwise pre-processed on-the-fly by a server-side component.
As a result of its design, the model API provides transparent access to data, regardless of the location and transfer method of the data. The data may be fetched asynchronously, from a REST web service for example, or it may be fetched synchronously, from the browser’s local storage, or from application memory.
Compatible with an open standard.The LuciadRIA Store API is based on the HTML5/W3C IndexedDB object store API. The use of an open standard facilitates the reuse of existing code.
Integration of third party services.You can integrate third party services using a minimum of code. The Store API has been kept small and simple on purpose to make implementation easier.
The main concepts inside the
model/* module are the
model/store/*: the Store API describes the interface for retrieving data, based on query parameters for adding, updating, retrieving, and removing individual objects. This component provides abstraction of the underlying communication protocols and storage mechanisms to ensure uniform access to the data.
model/codec/*: a Codec is used to translate between the server-specific format and the LuciadRIA model elements. A Store can use a Codec to convert a server response into LuciadRIA model elements, and to encode a LuciadRIA model element into a format which is understood by the server before sending the data to the server. Codecs for well-known data formats, such as GeoJSON\ or GML , are available. This allows for a clean separation between the actual client-server communication and the interpretation of the server format.
Featureallows developers to model an individual vector data object. It has a
.propertiesmember to store attribute information and a
.shapemember to describe the shape of the object. Example shapes are:
shape/Point: an individual point
shape/Polyline: a line expressed by a collection of connected points
shape/Polygon: a closed polygon without holes
shape/ComplexPolygon: a polygon that may have holes
shape/Bounds: a 3D axis-aligned box with a location, height, width, and depth.
shape/ShapeList: a collection of any the shapes in this list.
Please refer to Introduction to features (vector shapes) for a complete list of supported geometries.
Each LuciadRIA model needs a coordinate reference. With a
you can specify the spatial reference in which the geometries of objects in the model are defined. A model needs to be referenced
before you can visualize it on a
Views in LuciadRIA are responsible for the visualization of model data.
The most important components in the
view/* module are:
view/Mapor the hardware-accelerated
view/WebGLMap: the main view component which takes care of the visualization of model data. It is defined by a spatial reference system to display data in 2D or 3D.
Layerallows you to organize the visualization of model data in a
Map.LuciadRIA allows you to specify distinct visual representations - or
PaintRepresentationinstances - of a model object in a single
BODY: the main representation of the object, for example, an icon, or the shape of the object
LABEL: the representation of the label of the object
view/style/GeoCanvas: provides a canvas for drawing and styling feature objects with a
Because LuciadRIA is designed to run in the browser without plugins, the view has a representation in the Document Object Model (DOM) of the web page running the application. Other web standards, such as CSS, may be used to style, scale, and position the view.
A LuciadRIA controller manages the interactions that the user performs on a view, or
on the objects visualized in the view. Such interactions are triggered by mouse
instructions, but also by gesture events on touch devices. LuciadRIA provides support
Map operations, such as panning, zooming, and selection of
objects on screen.