Overview and Concepts
This chapter aims to give a overview of the architecture and main features of Polaric Server.
Anything still unclear? Feedback is welcome!
Software architecture overview
Polaric-Server is a client/server application, where users run the client-app in their web-browsers or as smartphone apps. The figure below shows the most important parts of this. A server typically serves the Polaric-Webapp2 (client) component which is mainly written in Javascript. It functions as a GIS client that can browse map-layers from various sources, let the user draw featurs on the map, etc. It is based on OpenLayers.
Polaric-Webapp2 sets up a (Apache) webserver to serve the application itself (as a kind of a homepage); we call it the ‘frontend-server’. It can also function as a cache for map-tiles for various sources by using Apache and the Mapcache plugin. Mapcache can handle standard map-tile sources like WMS, etc. The Webapp2 client can use map-tile sources, but also vector sources like WFS, GPX, GeoJSON, etc. We can use the very rich capabilities of OpenLayers for this.
It is also a client for the Polaric-aprsd; the ‘backend-server’. It is a http server that may run on a different port than the frontend. Polaric-aprsd handles more dynamic position information, typically moving objects. It provides a REST API to clients for performing various operation, as well as a Websockets to push updates and notifications asynchronously. It offers an innovative way of filtering what the user sees (and how), and a way to use tags to help filtering and searching items. It offers user-login and role-based authorization.
Aprsd is primarily an APRS client (and even an APRS igate if configured to do so); it can use a radio or the APRS-IS network to send or receive APRS packets. It is not limited to APRS; it can handle other datasources like e.g. AIS by using plugins. Plugins is a way to extend aprsd’s functionality. A special and important plugin is the database-plugin which uses a PostgreSQL database (with PostGIS extension) to extend the capabilities of aprsd. It can store tracking-data and let users search historical trails or see snapshots at particular time-instants. It can store user-defined features and it can synchronize some information with other server-instances.
Offline operation
Polaric Server is designed to support offline operation and is well-suited for deployment in field scenarios where internet connectivity is limited or unavailable. The system was originally developed for use by radio amateurs in voluntary search and rescue operations in Norway, where it can be brought into the field on portable computers with their own LAN, APRS modems, and radios.
Key offline capabilities include:
Local Network Operation: The server can operate on a standalone LAN without internet access, serving web clients on the local network. Users can still access the full web interface and functionality through their browsers when connected to the local network.
Map Tile Caching: The system supports caching and local storage of map tiles using the Mapcache plugin. Map data can be pre-downloaded and stored locally, allowing full map browsing capabilities even when disconnected from external map tile services. This ensures that users can view and navigate maps without requiring access to WMS, WMTS, or other online map sources.
Radio-Based Tracking: The APRS daemon can continue to receive and display tracking information using radio communications (typically APRS). This allows the system to track and display positions of radio-equipped participants, vehicles, or assets in the field, completely independent of internet connectivity.
Multi-Instance Synchronization: Multiple Polaric Server instances can synchronize labels, tags, and other data using authenticated APRS messages.
Local Data Storage: When the database plugin is installed, tracking data, user-defined features, and other important information can be stored locally in a PostgreSQL database. This ensures that no data is lost during offline operation and provides full access to historical tracking information. A local-fist philosophy is applied and some data can be automatically replicated with other instances when connectivity allows it, applying a Strong Eventual Consistency approach and CRDT techniques (still in an experimental stage).
Messaging Support: APRS messaging and bulletins continue to function via radio, enabling communication between field participants even without cellular or internet connectivity.
Graceful Degradation: The system is designed to degrade gracefully when transitioning between online and offline modes. Features that require internet access (such as synchronization with other server instances or access to external data sources) become unavailable, but core functionality for tracking, mapping, and local operations remains fully operational.
The system is suitable for deployment on small devices such as Raspberry Pi, making it practical for mobile and field use where resources are constrained. This offline-first design philosophy ensures that critical tracking and mapping capabilities remain available regardless of network conditions, which is essential for emergency response, search and rescue operations, and other field activities.
Interoperability and extensibility
Polaric Server is a free and open-source client/server application that supports interoperability and extensibility. Interoperability refers to the ability of different systems, applications, or components to exchange information and work together effectively. Extensibility is the ability to add functionality with minimal need to change the core application. All this can be achieved through:
Standardized Protocols: The client and server communicate using standardized protocols, such as HTTP or WebSocket, which allow systems developed by different vendors or using different technologies to interact seamlessly.
Data Formats: The application uses common data formats, like JSON for exchanging information. These formats can be easily parsed and processed by various systems, regardless of the programming language or platform used.
Application Programming Interfaces (APIs): The server component exposes well-defined RESTful APIs that can be consumed by different clients. APIs provide a consistent and standardized way for applications to communicate and share data, facilitating interoperability.
This means that alternative clients to the system is possible (and encouraged). The system can utilize open GIS data from various source through open protocols like WMS or WFS. Different instances of the backend-server can exchange and synchronize information and other applications can communicate with the aprsd backend server in order to share information.
Supported geographical objects
Polaric aprsd is designed to handle geographical points and display them on a map.
- Tracker objects.
APRS stations or objects. AIS vessels, etc.. They can be moving and can have significant metainformation attached, including timestamp. They have trails of movement. A trail is a list of updates (each with a timestamp and position) covering a timespan.
- Signs.
Simpler “Lightweight” objects that are static (non moving). They can be shown with smaller icons and have typically no label on the map. A sign can provide a link to an image or web-page.
- Other types of objects.
For example non-moving objects with more semantics than simple signs. Defined by plugins.
A database (if using the database plugin) can store signs or updates to tracker-objects. If this plugin is installed and active, it can provide historical seach and show locations on earlier time-instants or trails of movements in given time-spans.
Clients like Polaric Webapp2 are GIS applications that can handle maps and map-layers, as well as more static geographical features to be drawn on maps, in addition to more dynamic information from aprsd backends.
Filters
To deal with information overflow, we can define filters that configure what dynamic geographical objects are to be shown on the map and how those are shown. The user can select among pre-defined filters. Filters are defined in a special script containing rules and can be based on tags or other properties. For such filters we may also define what groups of users the filters are available for, i.e. we can define who are allowed to see what.
In the filter script we can also define rules for auto-tagging (see above).
The webapp client get a list of available filters from the server and present those in a menu to allow the user to select.