You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current model for Map and MapLayer is intricate, confoluted and unnecesseraly complex. It builds on previous models (GPX*) and now we are managing an overly complex bridge between the MapStore config model, the Map and MapLayer models, and the GPX classes.
At the opposite we have the GeoApp model which is an abstract model which jsut provides a "type" information and access to the BaseResource.blob field which is used by MapStore to do itw own things. The blob field (data as called by the API) is completely opaque to GeoNode, and this is how things should be,
On the other side the MapStore config held inside the blob field must be inspected and recreated by GeoNode and the MapStore adapter to extract / provide the additional informations needed by the current Map model, and here we enter the grey area of parsing, and building the blob content.
However, the MapStore client in master doesn't need this, and we don't have legacy views / templates that need the information the we're currently storing inside the Map and MapLayer (and GXP*) models, so most of the bridging performed by the MapStore adapter and the underlying GeoNode methods is probably useless.
Moreover, previous GeoNode functionalities that used these information are not exposed anymore (download of a map, exposing WMS services for a map, etc.).
My proposal is to make the following experiment on the master branch:
replace the current Map and MapLayer models with the (extremely) simplified models as above
exttend the map API to request and return the MapLayer objects when creating and updating a map
move the urls and embed views away to the GeoNode MapStore client
remove the hooks from the map API (which referencesMapstoreAdapterHook by default, which in tun uses the GeoNodeSerializer)
remove the Serializer and GeoNode converter modules from the Django MapStore Adapter
drop the GXP* classes
drop any view, template and util methods regarding the *_embed pages from GeoNode
In the end the MapStore map config should be opaque to GeoNode, as it is for GeoApps. GeoNode will manage its own models, that are required to drive the core functionalities, and will request any third party client to populate those models
The text was updated successfully, but these errors were encountered:
giohappy
changed the title
Refactoring of Map models, template and APIs and drop legacy code
Refactoring of Map models, template and APIs and removal of legacy code
Nov 8, 2021
The current model for
Map
andMapLayer
is intricate, confoluted and unnecesseraly complex. It builds on previous models (GPX*) and now we are managing an overly complex bridge between the MapStore config model, the Map and MapLayer models, and the GPX classes.At the opposite we have the GeoApp model which is an abstract model which jsut provides a "type" information and access to the
BaseResource.blob
field which is used by MapStore to do itw own things. Theblob
field (data
as called by the API) is completely opaque to GeoNode, and this is how things should be,On the other side the MapStore config held inside the blob field must be inspected and recreated by GeoNode and the MapStore adapter to extract / provide the additional informations needed by the current Map model, and here we enter the grey area of parsing, and building the
blob
content.However, the MapStore client in master doesn't need this, and we don't have legacy views / templates that need the information the we're currently storing inside the
Map
andMapLayer
(and GXP*) models, so most of the bridging performed by the MapStore adapter and the underlying GeoNode methods is probably useless.Moreover, previous GeoNode functionalities that used these information are not exposed anymore (download of a map, exposing WMS services for a map, etc.).
My proposal is to make the following experiment on the master branch:
Map
andMapLayer
models with the (extremely) simplified models as aboveMapLayer
objects when creating and updating a maphooks
from the map API (which referencesMapstoreAdapterHook
by default, which in tun uses theGeoNodeSerializer
)In the end the MapStore map config should be opaque to GeoNode, as it is for GeoApps. GeoNode will manage its own models, that are required to drive the core functionalities, and will request any third party client to populate those models
The text was updated successfully, but these errors were encountered: