Setting up GIS functionality

GIS (Geographic Information System) functionality for Axiell Collections allows for an application to be customized to allow users to register locations and areas by means of their location on a geographical map and also to search for records by a variety of map manipulations to select places, precise spots or areas of different shapes.

It supersedes the deprecated geographical map functionality as described in the previous topic but you could use them side-by-side if needed (because of existing data in Geolocation fields for example). The functionality does require SQL Server 2017 or higher.

Without proper configuration, users won’t notice anything of this functionality. This configuration has a some important variables which require consideration, such as which location/place fields in your databases would you like to have this functionality? Would you like registered locations and areas to be stored in their own records in a separate database with a unidirectional or reverse link to associated catalogue records or is it enough to store a location or area in the catalogue record directly? And which maps and overlays will you be offering? Let’s deal with these questions one by one.

Choosing maps and overlays

So which maps and overlays do you need? It all depends on the pupose you have in mind. If it is enough to pinpoint locations or areas on a standard geographical map, for a production place field for example, then OpenStreetMap is all you need. But if you need more environmental details you may require a topographical map (as well), for example. Such base geographical maps are made available online by third-party web services. These web services can be free, as with OpenStreetMap which is the default base map the Axiell Collections GIS functionality should always offer, or paid (in which case the costs need to be considered). When considering map web services, know that Axiell Collections uses the OpenLayers library to retrieve map tiles, but the only currently supported map source types are OpenStreetMap and WMTS (Web Map Tile Service).

So-called overlays are map types which add an extra layer to a base map. They show graphical data that a base map typically doesn’t show, like municipality borders, historical sites, demographic data etc. As with base maps, overlays are made available online (often as downloads too) by third-party map providers. These web services or downloads can be free or paid.

For Axiell Collections these overlays (which are of course optional), need to be available as locally stored (on the customer web server) GeoJSON files (with the .json extension).

So you can choose multiple maps and overlays. While registering or searching for a location in Collections, you can always quickly switch between these maps and overlays as your current need requires.

When working with the map display, you’ll also see an entry field with a Search button next to it. This could allow the user to enter a place name and have the map zoom in on that location automatically. This is so-called geocoding functionality and is usually not included in a map service and must be licensed separately by a third-party like Google or other geocoding web service.

Selecting fields

Most Place fields in records are linked to a thesaurus, to allow users to select a place name, like Amsterdam or London, which is sufficient for most cases. But for archeological finds or other historical sites you may need to register their location more precisely or more general than a place name. The Field collection screen for object records for example, offers a Coordinates field group to register a find location more precisely. If there’s no data in this field group anywhere in the database, you could consider replacing it partially with a GIS field. However, if the coordinate fields already contain data in multiple records, some custom conversion procedure would be required to convert that data to the GeoJSON format used by GIS fields before you could replace the coordinate fields. In any case it’s probably best to add extra fields for the GIS functionality and leave existing place fields as they are.

The appearance of a GIS field

In the Collections user interface, a GIS field (of data type Geo-json actually) has a peculiar appearance: it may have a field label but no entry field, just a map icon. The icon is empty if the field contains no data, while it has a map pointer when the field is filled. The user will never see the actual (GeoJSON formatted data) that is stored in the field, only the icon will appear.

   

Clicking the empty icon when the record is in edit mode will allow the user to select a new location on a map (which opens in a separate window) whilst clicking the icon with the map pointer in either display or edit mode will show the earlier selected or stored location on the map. Emptying a filled-in GeoJSON field can be done by clicking the Clear button in the map display.

To link or not to link

So now the question is: where would you like the GeoJSON field data to be stored. In the collect database you could simply add a field of this type, add it as a text field to the Field collection screen for example and be done with it: then you would need to pick a location per object record and the GeoJSON data would be stored in that record as well.

For large amounts of objects that need to be associated with the same location that is not a very practical solution though. A linked field in object records linking to a separate geolocation or geothesaurus database in which geolocations themselves, with a useful name and other metadata, are stored would then be a better solution. That would also allow for a location hierarchy which could be very handy for subdividing large archeological sites, but also for naming locations and for finding all objects associated with the same location. Then you would not only have to add a GeoJSON field to the collect database, but also a linked field linking to the separate geolocation or geothesaurus database, allowing the user to pick a named location from an earlier specified location collection or hierarchy.

Sample implementation

As an example we’ll implement a reverse link between your collect.inf and a new geolocation.inf. Download your sample files here. In the .zip file you’ll find a geolocation.inf and a maps.inf. The maps.inf is the only actually required extra database structure file for the GIS functionality. You only need something like the geolocation.inf if you’d like to store geolocations in their own database and you do not already have some geothesaurus that could be extended a little for this purpose.

At least create a record for Open Street Map, with the following data. (Note that for this particular base map a Source URL is not required because the OpenLayers library used for the GIS functionality already knows where to find the relevant web service.)

 

Example of an overlay record for WMTS:

 

Example of an overlay record for Vector:

Working with the sample implementation

So now you’re finally ready to start working with your GIS implementation. In our sample we have a Geolocation data source which you can start filling with records. A single point or shape is typically called a feature while a collection of points or shapes is called a feature collection. You could create a feature collection as the parent of a list of features, if you find it useful. The name you choose for the location can be abstract or descriptive, whatever makes sense. Click the empty map icon to select the location on the map. See the relevant Collections online Help topic for more information about how to use the map interface. You could also link this location to one or more objects. Note that the possibility to link to objects from within this data source is no requirement in general at all. In a custom implementation of your own you may find it better to leave it out if thousands of objects will be linked to a single location: it might have a serious performance impact when such a record is opened.

This sample implementation also has an access point in the Geolocation data source. You may have to select the GIS access point via the Settings button before you can use it. Clicking the map icon allows you to draw an area in which you’d like to search for locations registered in the Geolocation records.

In the Object catalogue you can also find a GIS location access point, so you can find objects within a certain area once you’ve linked object records to a Geolocation record.

In new or existing internal object records you could now link to a Geolocation record, as well as you can link a Geolocation record to multiple object records, because in the sample implementation we created a reverse link between these databases. So once you link to an existing Geolocation record, the map icon will get a location pointer because the actual location is merged in. And since we made the GeoJSON field a write-back field too, you could even change the location on the map here and save the object record to have the new location written back to the Geolocation record. Of course this would mean that all other object records linking to that record would also be associated with that new location. In a real-life implementation you may not want make the GIS field a write-back field at all. The sample implementation is just to make you aware of the possibilities. From the object record here you could even create a new linked Geolocation record with an appropriate map location, by creating the new name in the Find data for the field window first and then adding the map location…