Using web maps in ArcGIS Runtime: Simple architecture on ArcGIS Online
In this post, I will explain the web map and data architecture that I will use to while going through the basic features and concepts when using web maps in ArcGIS Runtime. Using a simplistic approach makes things easier to understand and later in the series, I will show how things change or compare when the backend structures get more complex.
This post is part of “using web maps”-series.
- Using web maps in ArcGIS Runtime on high-level
- Using web maps in ArcGIS Runtime: Simple architecture on ArcGIS Online
- Using web maps in ArcGIS Runtime: Accessing groups and items
Scenario and setup
As a scenario, I will use a water hydrant maintenance inspection use case as follows:
The Hydrant Maintenance Inspection solution modernizes the paper report for Hydrant Maintenance Inspections by using an ArcGIS Runtime application on a Windows device. By using a map view of hydrants, field crews are able to record scheduled or ad hoc Hydrant Maintenance Inspections. The data contains the location of hydrants and detailed inspection table.
I created the service using “Hydrant Maintenance Inspections”-template on the ArcGIS Online. See documentation for more details on how to create services by using templates if you are new to it. After creating the service, I created a web map to contain the map configuration for my ArcGIS Runtime application. I chose to use the navigation basemap, added hydrants feater layer and maintenance inspections table from the feature service I just created. Then I changed the visualization of the hydrants a little bit. The last step was to share both feature service and the web map to the target audience which in this case was public.
After creating the map I made sure to enable it for offline use and divided the work area to two different pre-planned offline areas. By enabling offline use, we can use the map in an ad-hoc/on-demand offline workflow and pre-planned offline workflow.
See this group for the example service and webmap.
Architecture
In this scenario, I ended up having an architecture which is purely hosted in ArcGIS Online.
The central part of the architecture is the web map that aggregates all required configurations to a single document. The web map definition contains a set of layers and a table that refers to the service endpoints by their URL. The basemap uses a tile service (tile layer endpoint) that knows where the tiles are cached and how to fetch them. The feature layer and the table points use feature layer endpoints (technically they are the same thing except that one has a geometry and another doesn’t) that are hosted in the same feature service and are stored in the same database.
Web map
As mentioned in the previous post, the role of the web map is to have a single document that describes the map and it’s contents.
Web maps are identified and accessed by their itemId. You can find the id from the item URL or from the item description. The example map has an itemId of “c9fbe40a90a7474988bbba12fe7de04d“. APIs, such as ArcGIS Runtime, also uses the itemId to access the web map.
The web map gets the data from two different data endpoints:
| Base structure | http://{portal}/sharing/rest/content/items/{ItemId} | |
| Item description | ?f=json | Json representation of the item |
| Item content | /data | Json representation of the map |
The web map item description contains metadata what the map is about. Its data structure is the same as the ArcGIS Portal Items in general since web maps are stored in the Portal as such. The information model contains things like title, snippet, description, thumbnail, tags and license information. You can find the full definition from here.
Here is a link to the “Naperville water hydrant inspections” item description
http://www.arcgis.com/sharing/rest/content/items/c9fbe40a90a7474988bbba12fe7de04d?f=pjson
The web map data contains a description of the map. It follows an open specification. By its most basic form, it has a reference to the used layers which contains all the information related to it. You can also override base settings on the web map level. The concept of overrides is very important when we start to have more complex setups and I might have a specific post just to cover them.
Here is a link to the map definition
http://www.arcgis.com/sharing/rest/content/items/c9fbe40a90a7474988bbba12fe7de04d/data
If you look to the map definition, you can see that layers and tables refer to the service directly by service endpoint URLs.
“operationalLayers”:[
Example how layers refers the service endpoint
{
“id”:”Water_hydrant_inspection_926″,
“layerType”:”ArcGISFeatureLayer”,
“url”:”https://services2.arcgis.com/VDO6wzqjr9Wm8rpy/arcgis/rest/services/Water_hydrant_inspection/FeatureServer/0″,
“visibility”:true,
“opacity”:1,
“title”:”Water Hydrants”,
…snip…
}
Feature Service
Feature Services provides access to your vector data. You can see them as a (micro) services published through the ArcGIS stack (ArcGIS Online, ArcGIS Enterprise). You can control what users can do with the feature services by defining their capabilities. You can, for example, enable editing and offline functionalities or allow the data export to different formats. Services will tell which capabilities are supported by the service so clients can dynamically adapt their interfaces if required.
Feature services can contain both feature data and non-spatial tables like in the example service. They also contain descriptions and templates about the content and how the data is structured. For example, you can find field information or how geometries should be visualised (renderer). When I created the service using the template, all of these settings were configured to the service for me.
Here is a link to the hydrants feature service endpoint (json-description)
In general, you should focus on publishing your services as complete as possible so that clients can just point to the service endpoint and start using it. There are use-cases where you want to override some of these values or limit access to the data but more about those later.
When feature service is published, the data connection will be burned into the service. You cannot typically see this from outside (as part of the service json). All the feature layers from a single feature service will be sharing the database behind the scenes.
Raster Tile Service
Esri provides multiple types of basemaps for its users through ArcGIS Online. They are used to provide a geographical context for your application and operational data. In this architecture, I used a raster tile layer, which provides data as images (ie. jpg or png) that have been pre-rendered and stored on the backend. The service used is one of the official basemaps hosted in ArcGIS Online so they will be maintained by Esri.
See all official basemaps here (also contains vector tile basemaps).
Rasters are very easy to use and they work well in most of the cases. They work on a very wide range of devices and doesn’t require a lot of processing to be rendered. One of the typical use is to provide imagery as rasters for example. Rasters also can contain high-level cartography and labelling. They have couple challenges since they can be large to transfer over the HTTP and they will take quite a bit of space when taken offline for larger areas with lots of levels of detail. Another downside is since the images are already created, they don’t adapt to the high-resolution displays.
Here is a link to the used Streets basemap service endpoint
https://services.arcgisonline.com/ArcGIS/rest/services/World_Street_Map/MapServer
Summary
I think that this is more or less the simplest usable architecture to use. A single raster basemap to provide geographical context, one feature layer to provide operational data and one table to provide non-spatial data. This dataset should be good to showcase the usage from the ArcGIS Runtime client and still do it in a “real-project”-style.