Overarching RAMP 4 Design Doc

[james-rae]

Writeup by @spencerwahl with help from @AleksueiR

The primary design philosophy surrouding this doc is to allow for replacement and extensibility of as much of RAMP as possible. This is meant to allow for easier modifications for individual projects.

Core

There are pieces of RAMP that are non-negotiable. The core is the central part of RAMP where the map will not run without it, everything else is varying levels of optional.

• Config processing
  • with this comes state storage, will be talked about more later
• Layer display on map (basemaps included), geoapi
• Mouse and keyboard map interactions

API

The API surrounds the core of RAMP and facilitates interaction between the different modules. By default there are no APIs surrounding modules directly everything communicates through the central channel. Plugins (anything non-default) are free to expose their own API but RAMP will not know about it.

This is also the API that will facilitate interaction with the host page. By having internal and external info go through the same channels RAMP will have the same behaviour whether "hide this layer" came from a settings panel a legend panel or a button outside of the app altogether.

Panel API

Shape of this API is to be determined, may or may not look like current RAMP's panel API. At the very least we expect to have a store of panels with their states as well as some ability to close, open, minimize, etc.

Modules

The rest of RAMP is split into modules. These modules should be replacable and RAMP core will not know either way. Within the modules themselves functionality is very likely to be the same as current RAMP.

• Legend
• Settings
• Details
• Table
• Geosearch
• Basemap Selector
• Export
• Help
• About Map
• Map Navigation (buttons in the bottom right of current RAMP)

Technically:

• North arrow
• Scalebar
• Map attribution

Modules will have their "base" state held by RAMP core. They will then listen to that state as needed. If a module is replaced and requires "extra" state, the module should store it within itself. This is due to the fact that RAMP core will not know how to interact with it and there will be no api functions to modify it, etc.

Menus

Side menu, appbar...

Early thoughts are just having them be configurable (and removable). Not sure if it makes sense to replace directly.

Plugins

To match the naming of current RAMP, plugins can be written to add extra functionality to RAMP. Things such as time sliders.

All plugin state is "extra" state as there is no default. This means plugins are responsible for their own state. However, at startup core will include plugin configuration and any bookmark as part of its startup state.

Core will not know what plugins exist, there is no direct registration.

• At startup plugins will take config as needed from RAMP
• If a panel is created then an entry will be added to panel state
• During runtime plugins will "commit" bookmark state to RAMP as needed

Core will only ever see the plugin as a key in a few key, value pairs.

Mobile

Early thoughts; designing the app and panel API to display either the map or a singular panel.

Minimize panel functionality to allow map to be seen? Peek?

[james-rae]

Propose Bookmarking can also be a Module. I.e. we provide a basic module that works in a simple no-setup fashion, but allow a different module to be swapped in to handle fancier things (e.g. storing state with a service, custom properties for a custom project)

[AleksueiR]

Test reply to test notifications.