Query data [mobile]

[sbrunner]

Questions

• Is the long touch needed?
• When do we tell the user that we have a reponse
  • when all request respond
  • when the first respond, and we feed the result content continuously ?

    Features

The querier is almost always active on the map. It is disabled when there is a draw interaction also active (draw, measure etc...). So it has to be managed via the ngeo.ToolActivateMgr.

When you click (press or long press, it is customisable) on the map, it performs a WMS getFeatureInfo query on all layers of the map (even backgroud layers). The requests are spread between WMS servers (one request per server), and a mapping is done between a WMTS layer and its associated WMS (through metadatas & external resources).

A point is drawn where the request if performed.

When all the queries get a response (or sequencially), we display the results (this is part of another issue). You just need to focus here on how to update the result data structure that will feed the UI.

• [x] One WMS query per server
• [x] WMTS layer -> WMS queries
• [x] Limit result
• [x] Total number of results
• [x] The result order is important
• The info_format that have to be supported are:
  • [x] GML (default, if not defined)
  • GeoJSON no - GeoJSON will not be supported
  • Configure 2 layers with GeoJSON in the theme service demo server to be able to test GeoJSON (@sbrunner). no - GeoJSON will not be supported
• [ ] Allow future multiple views: mobile window, desktop window or grid
• [ ] Allow future multiple ways of query: long touch or touch (TODO decision needed), click, desktop box query

  Layout

Mockups and description of UI workflows

None. See #1800 for UI

External Resources

Services to be used with description of interfaces

• For WMTS layers we have a the following set of UIMetadata:
  • wmsUrl: URL of the WMS server
  • wfsUrl: URL of the WFS server (for box query), use wmsUrl if not provided
  • queryLayers: The layers to use
  • wmsLayers: The layers to use if queryLayers is not provided
  • minResolutionHint: the min resolution
  • maxResolutionHint: the max resolution
• For WMS layer, no UIMetadata will be needed

  Architecture

  QueryService - ngeo

• Create a QueryService in ngeo
• responsible of making the queries, reading the response and create the features
• responsible of looping in the existing visible layers in the map and determine which ones are queryable
• is configured with the limit number of result per request, 50 by default

The QueryService will need to be configured with a list of queryable layers, more specifically a list of queryable sources. In GMF, layers are not always created at the initialization of the application. They are when their according theme gets loaded. The theme contains all the information about how to query the layer: if it is queryable, the url(s) to use, etc.

In order to make the QueryService aware of those, we'll have the following: QueryServiceConfigurator - gmf. When the themes are loaded in GMF, the configurator will create one source config for each queryable layer found in the themes and add them to the QueryService.

Source configuration - example

{
    'infoFormat': 'geojson',
    'label': 'Bus Stop',
    'name': 'bus_stop',
    'layerObj': layer, // optional
    'params': {'LAYERS': 'bus_stop'}, // optional
    'serverType': 'mapserver', // optional
    'url': '' // optional
}

ngeo.QueryResult

The result will be added in an Angular value service that will have the following structure:

gmf.QueryResult = {
    'sources': [
      {
        'features': [], // Array.<ol.Feature>
        'label': 'Bus Stop',
        'name': 'bus_stop',
        'pending: false
      }
    ],
    'total': 0
  }

• Update from 2016-01-19 - There was a discussion about supporting one set of result per map. After discussing this with @pgiraud, we agreed that at this stage this is no required, as the spec doesn't require it (for the moment). So, for now, the service will only contain one set of results and will flush it on each new query, regardless of the map used.

Criterias to launch a request

In order for a request to be launched for a particular layer, it must:

• be visible
• be configured in the sources of the QueryService

Request sending

When a request is asked to the QueryService, for each layer in the map:

1. Find the source configuration. If found:
   • the existing features are removed
   • if the criterias are met, a request will be launched
   • sources that share the same url are combined in a single request
   • the pending property is set

2. If not found, then the layer is not queryable I imagine to have some code in ngeo because a getFeatureInfo querier is often used. The discussion is opened, maybe we could have

   • a ngeo directive on the map that handle a type of event (customizable)
   • on event, parse all layers of the map (can have a filter)
     • build one request per server for all the layers (can create a new service for sharable methods)
     • the behavior on event can be extended (for example for WMTS layer in gmf -> specific things to do)
   • the directive active property is bound with the activateToolManager.

   The total value in gmf.QueryResponse is set to 0 as well.

   NOTE We will ignore minResolutionHint and maxResolutionHint as features should always be returned by the result of a click, even when not visible at any scale level.

Parse Response

• the pending property is set to false
• features are read using the infoFormat
• sources that shared the same url will use the first infoFormat defined

• the total value is updated

  The value ngeo.QueryResult can be watched to show the results

  MobileQueryDirective - ngeo

• receives a reverence to the QueryService
• its active property is attached to the activateToolManager
• when activated, listens the click events of the map and ask the QueryService to launch a request using the coordinates where the click occured

  Example number 1 - ngeo

We'll create an example with hard-coded layers in which the QueryService configs are manually created for each layer.

Example number 2 - gmf

We'll create an example in which we inject the QueryServiceConfigurator for it to automatically configure the QueryService. It will include a layertree to demonstrate the behaviour with different layers.

Configuration

What is configurable, where and by whom (user, integrator)

TODO

Implementation Examples

Existing code, interesting websites

• Multiple possible view mobile / window / grid => send en event ? Events used on CGXP:
  • queryinfos: send number of available results hits request if number of result = maxResult
  • queryopen: sent on open query tool.
  • queryclose: sent on close query tool.
  • querystarts: sent when the query is launched.
  • nolayer: sent when no layer to query.
  • queryresults(queryresult): sent when the result is received queryresult = features: [...], unqueriedLayers: [...] } unqueriedLayers is used to notice the user that some layers will not be queryed.

    Exit-criteria

What must be tested so one can say 'it's done', for example demo example (with checkboxes)

• [x] Do query
  • Select some layers
  • Click / touch on the map
  • The request should be done on all the overlay and background layers
  • We should be able to get the result on the right order
• [x] No query
  • Deselect all the layers
  • Select the blank background layer
  • Click / touch on the map
  • No request should be done

    Documents

Documents to update: test cases, user doc, dev doc (with checkboxes)

• [x] Dev documentation
• [x] Code documentation

[adube]

@ybolognini The query tool is now integrated in the mobile application. The results are not implemented yet, so clicking on a feature issues request(s) but nothing is shown yet.

I'll let you look at the remaining points mentioned here and determine whether this ticket should be closed or not. As for my part, it is officially all completed.