One of the core ideas of FeltGIS is to provide a scalable, cost-effective, and flexible platform for typical field applications. By a typical field application, we mean a mobile app for iOS and Android, mobile and tablet, with map support. The apps must support workflows for areas with and without coverage. As of today, we are live and in production with this system.

We divide our technical approach to this into three main areas:

• Features

• VectorTiles

• RasterTiles

Features

Features are editable objects, with or without geometry. They have a schema that describes fields and data types, and whether the object can be represented as a point, line, or area. Along with the geometry, there is also information about styling, i.e., how the geometry should be drawn on the map.

FeltGIS has built its own system for synchronizing features between cloud services, mobile apps, and our green box (running on a mini-PC connected to the forestry machine PC). We have extensive experience with similar mechanisms (ESRI, Realm, Firebase), but have found it beneficial to develop our own.

A hypothetical example illustrating how we use this system:
Together with the customer, we define a data model. In a simple case, for example, "observed species." This data type has several fields to describe the observation, as well as illustrations for how the species should appear on the map as points.
The system supports roles and access control. For example, we can ensure that field workers can only see their own objects or possibly also create their own registrations. Users in the management team can see all registrations with their logged-in user.
When a field worker logs in to the app for the first time, all available observed species objects will be synchronized and available in full in the app.
As soon as a field worker makes a change to an object, it will sync with cloud services and possibly other users who have access to the object. If there is no coverage, the object will be sent in when the opportunity arises (as soon as the device has coverage again). The app can display the status of the last synchronization with the server, but otherwise does not relate to the fact that the device has no coverage. The app also has the capability to submit data in the background, i.e., when the user does not have the app open.
Notifications: If the customer wishes to set up triggers for notifications, we have the capability to do that. For example, if a colleague registers a particular species near the user's location, we can send out a push notification about this.

The primary motivation for starting to develop this on our own was the lack of flexibility in other solutions. We want to have the ability to make changes to the data model without having to do a full sync of the dataset. We also want to be free from any bindings to licensed components, such as ArcGIS Server. We also want to have full flexibility regarding the map engine in the client, so that we can run other map engines than the ArcGIS runtime SDKs when necessary. Our source code already runs on Windows, Mac/iOS, Android, and Linux.

On top of this synchronization mechanism, we have a map server that the mobile apps use to load features into the map on the mobile clients. The same map engine runs on our green box and is consumed by a web app running on the forestry machine PC. On the cloud side, we have an administration system to manage the individual datasets, as well as the option for the customer to make live connections to their datasets, such as QGIS or ArcGIS Desktop.

VectorTiles

VectorTiles are a way to package together a georeferenced dataset, based on a geographical excerpt. VectorTiles can be cached, so that a client can efficiently retrieve data for larger areas without burdening the underlying database system.

VectorTiles are particularly suitable for datasets that one only wishes to consume without making changes to. We support preparation for offline vector datasets and presentation of these both on mobile and in our web app. VectorTiles also have the advantage that one can dynamically change styling in the client, and zooming in the client is rendered nicely as the map engine can continuously redraw the objects.

We have the ability to cache vector tiles directly from the client. For larger areas, or for areas without coverage, where several users need offline access, it may be advantageous to create a separate map package for these areas in advance and download it to the client as needed.

RasterTiles

RasterTiles have many of the same properties as VectorTiles, but instead of storing complete object information, raster only contains a graphical description of the geographical area.

The advantage is, as with VectorTiles, that it is easy to take offline, the disadvantage is that scaling in the client is not as nice, and that one does not have object information for identify operations (click on a map object for more info) - identify requires internet access to send a new request to the underlying service for more details about the object.

In many cases, one does not have full access to the source datasets but only to a dynamic map service (e.g., WMS). To easily meet the need for offline maps from these services, we therefore have a service that helps us convert such dynamic map services into RasterTiles, so that our client applications can cache them for offline use.

Miscellaneous

In connection with the schemas that define the data models, we also support reports. That is, one can easily define a template for a report, which is populated with registered data for specific objects. These reports can be attached as attachments to the objects or distributed via email. The reports can also contain map excerpts from the relevant geography.

The Way Forward

FeltGIS is a young company, but we are convinced that our solution has its place alongside the major and established players in this market - perhaps especially from a mobile-first perspective. We build our solution to work in conjunction with others and seek a fruitful interplay between different technical solutions to avoid "lock-in".

We are already doing some synchronization with external datasets, but we will expand this as the need arises. For example, it is useful to do a full synchronization with external datasets. Where we currently load this dataset as RasterTiles, we sometimes face challenges with sporadic downtime in their server environment. By doing a full synchronization of this dataset and presenting it as features or vector tiles to our clients, it will provide our customers and users with a better user experience.