Lucy allows you to move from an application using a GXY view in an
ILcyMapComponent to an application based on a Lightspeed view. To complete such a migration, you need to:
The first two steps are mandatory. The last step is optional, but recommended for optimal performance.
Each of those steps is explained in more detail below.
The components of a GXY map are created by the
TLcyMapAddOn by means of an
You can customize many settings of that factory by altering the configuration file of the map add-on,
map_addon.cfg. If those customizations are not sufficient, you can replace the default factory with a custom one. To replace the factory,
either set the
mapComponentFactoryName property in the configuration file, or use the API and call
Lightspeed map components are created in a very similar fashion, and allow for the same customizations.
They are created by the
TLcyLspMapAddOn by means of a factory.
In this case, the factory is an instance of
ALcyGUIFactory<ILcyLspMapComponent>, and the default implementation is the
You can customize many settings by altering the configuration file of the Lightspeed map add-on. If those customizations are not sufficient, the Lightspeed map add-on allows replacing the default factory with a custom one. See the Lightspeed Map Add-on documentation for more information.
TLcyMapManager allows you to retrieve the GXY map components in your application: you can iterate over the available maps, and you can can
query it for the active map component. It fires events when maps are added and removed, or when the active map component changes.
This map manager is always available at the Lucy back-end. Call
ILcyLucyEnv.getMapManager() to obtain it.
There is also a map manager available for Lightspeed maps: the
The manager has the same functionality as its GXY counterpart: you can iterate over the available maps, query it for the active
map component, and it will fire events when maps are added and removed, or when the active map component changes.
There is a subtle difference between the Lightspeed map manager and its GXY variant: whereas the GXY map manager is always
available at the Lucy backend, the Lightspeed map manager becomes available only after you have plugged in the
You can also use the
TLcyCombinedMapManager as an alternative to the
The combined map manager is a map manager for all types of maps: GXY maps and Lightspeed maps. You can retrieve the map manager
from the Lucy back-end using
The main benefit of using the combined map manager instead of the Lightspeed map manager is that it is always available at
the Lucy back-end, even if the
TLcyLspMapAddOn has not been loaded yet.
The drawback is that it fires generic map events instead of events specific to Lightspeed maps.
However, if your application only uses Lightspeed map components, it is safe to cast the map components in the generic events
to Lightspeed map components.
A typical application contains a significant amount of code that interacts with the map, the view, and the layers.
If you switch to a Lightspeed map component, the view no longer is an
ILcdGXYLayer instances, but an
The code interacting with those components must be adjusted as such.
LuciadLightspeed offers documentation about migrating from a GXY view to a Lightspeed view. It provides more information on how to migrate to a Lightspeed view, and on the similarities and differences between the two view and layer types. See Moving from a GXY view to an ILspView.
To visualize data, you must firstly decode the data into an
ILcdModel, and secondly, create a layer for that model.
The data is typically decoded by an
ILcdModelDecoder, and the layer is typically created by a layer factory.
GXY layers and Lightspeed layers use the same
As such, you only need to create Lightspeed layer factories to visualize your data on a Lightspeed view.
You can do this by implementing your own custom format, as explained in the Support Custom Data documentation.
The Lightspeed format adds support for layer creation, but not for model decoding. This means that you still need to plug in your GXY format, which is responsible for the model decoding.