Direction de l'information policière et des moyens ICT Directie van de operationele informatie en de ICT-middelen DRI - Business Unit Fonctionnement Local PoliceMaps Webservices v1.0.1 Access and usage David Dabin [email protected] Version of May 9, 2016 2 Keywords GDI - PoliceMaps - Software - Map - WebServices - GIS Summary The Geo Data Infrastructure (GDI) project aims to distribute a coherent set of spatial data, spatial web services and spatial APIs in order to optimize the collection, processing and usage of high quality geographical data at operational, tactic and strategic level of the Police. PoliceMaps is the rst application deployed by the GDI project. GDI provides a collection of Lego building blocks where each brick is a spatial data, a spatial functionality or a spatial tool which can be freely used by developers to integrate spatial objects into Police App. It's up to each application to use wisely the dierent pieces to match its needs regards spatial functionalities. This document describes all the web services distributed by the GDI project through PoliceMaps. Developers will nd here how to connect to web services and how to submit requests for web maps, geocoding, reverse- geocoding, routing and re-projection. Contents 1 Technical standards 5 2 Architecture 9 2.1 Overview . .9 2.2 Servers description . 11 2.3 Portal generation . 12 2.4 Web Services generalities . 12 3 Mapping Web-services 15 3.1 Tiled Map Service . 15 3.1.1 Web service call . 15 3.2 Web Feature Service . 17 4 Geocoding & reverse-geocoding web services 21 4.1 Overview . 21 4.2 Geocoding principle . 22 4.3 Web service call . 22 4.3.1 Geocoding . 23 4.3.2 Reverse geocoding . 28 5 Routing web service 33 5.1 Overview . 33 5.2 Web service call . 33 6 Projection web service 35 6.1 Overview . 35 6.2 Web service call . 35 7 Geolister web service 37 7.1 Overview . 37 7.2 Web service call . 37 3 4 CONTENTS Chapter 1 Technical standards The Open Geospatial Consortium (OGC) and the International Organization for Standardization (ISO) dened many technicals standards in order to facilitate the communication between the dierents components of the SDI (data servers - service servers - clients) but also between dierent SDI (Tait, 2005; Davis, 2009). The main standards impacting SDI are (i) the data distribution standards • Web Map Service (WMS) (de la Beaujardiere, 2006); • Web Feature Service (WFS) (Vretanos, 2010); • Web Map Tile Service (WMTS) (Masò et al., 2010); (ii) the data format standards • Simple Feature Spécication for SQL (SFSQL) (Open Geospatial Consortium, 1999); • Geography Markup Language (GML) (Portele, 2012); (iii) the research engine standards • Catalogue Service (CSW); • ISO 19115 on metadata of geographical data; • the INSPIRE directive (2007/2/EC, European parliament and Council, 14 march 2007); About web services, the OpenGIS Location Services (OpenLS) Core Ser- vices (Open Geospatial Consortium, 2008, p3-4) gives more insight on stan- dards of geocoding, reverse geocoding and routing: 5 6 CHAPTER 1. TECHNICAL STANDARDS Abstract Data Type (ADT) The basic information construct used by the GeoMobility Server and associated Core Services. Consists of well- known data types and structures for location information. Dened as application schemas that are encoded in XML for Location Services (XLS). Address ADT Address ADT contains address information for a geographic place. Addresses reference and uniquely identify particular points of interest and can serve as the basis for aggregating data for that loca- tion. The Address ADT consists of a street address (or intersection), place name (e.g. country, municipality, etc.), postal code, street loca- tor, building locator, and supplemental address information. As used here, addresses are the means of referencing primarily residences and buildings (of all types, where a subscriber may conduct business). Directory Service A network-accessible service that provides access to an online directory (e.g. Yellow Pages) to nd the location of a specic or nearest place, product or service. Gateway Service A network-accessible service that fetches the position of a known mobile terminal from the network. This interface is modeled after the Mobile Location Protocol (MLP), Standard Location Imme- diate Service, specied in OMA 3.0 (see Open Mobile Alliance). Geocoding service A network-accessible service that transforms a descrip- tion of a location, such as a place name, street address or postal code, into a normalized description of the location with a Point geometry (see OGC GML Encoding Standard for OGC geometry). Address => P osition(x; y) + NormalizedAddress According to the requirements of the OGC described in the Open LS Core Services, a geocoding service: • Must be capable of using an address matching Geocoding algo- rithm to determine a position for the specied Address ADT. • Must be capable of performing geocoding using an incomplete address and return the complete set of address information (i.e., a normalized address). • Must be able to indicate the number of matches in the response (possibly zero) for a particular address supplied in the geocoding request. • Must be capable of processing one or more addresses in a single geocoding request. • May provide information on the quality of the result using a 'match code'. 7 Point of Interest (POI) A location (with a xed position) where one can nd a place, product or service, typically identied by name rather than by address and characterized by type, which may be used as a reference point or a target in a location based service request, e.g., as the destination of a route. Presentation (Map Portrayal) Service A network-accessible service that portrays a map made up of a base map derived from any geospatial data and a set of ADT's as overlays. Reverse Geocoder Service A network-accessible service that transforms a given position into a normalized description of a feature location (Address with Point), where the address may be dened as a street address, intersection address, place name or postal code. P osition(x; y) => NormalizedAddress + P osition(x; y) A reverse geocoding service should meet the following requirement: • Must be able to return one or more locations (i.e., Address ADTs with associated Point geometries), and optionally, the ranges of these locations from the given position, as it is dened in the Position ADT. • Must be based upon the user's preference, as stated in the re- quest, to select the form of the returned address(es) . The user should be able to specify a preference of Street Address, Street Intersection, or Position Of Interest (Place and/or PostalCode). If not specied, the service should default to Street Address. • Must be capable of returning all location information of a pre- ferred type within an area of interest (AOI ADT - a Circle, Poly- gon or Box). • Must be able to indicate the number of matches in the response (possibly zero) for a given request. Route Service A network-accessible service that determines travel routes and navigation information between two or more points. 8 CHAPTER 1. TECHNICAL STANDARDS Chapter 2 Architecture 2.1 Overview During the session of the 18/09/2013, the Architects group of DST (GAG) decide to implement and to deploy the centralized architecture of the GDI project illustrated in Figure 2.1. This decision was approved and conrmed by the Isis group, GAG group and CGO direction on the sta meeting of the 28/07/2014. Briey,the characteristics of the centralized architecture are: 1. data of external providers (Région Wallonne, Vlaanderen, Bruxelles) are centralized on a raw data called Map File Server. 2. a Spatial Geo DataBase (SGDB) pumps all information of the Map File Server to create a global mapping database for the police. 3. a service server runs on the SGDB to expose geo web services to the GI. The service server uses the SGDB as back-oce to provide web maps (vector and raster formats), geocoding service, routing, heatmaps. 4. the clients interact with the service server using Http requests, aka through Restful web services, directly form a web-browser or from a specialized sofwtare such as GIS. Whereas the implementation of web services seems dicult, it presents many advantages against all others possibles solutions including: 1. independence of the application layer against the database layer. Ap- plications connect to web services through standardized requests and 9 10 CHAPTER 2. ARCHITECTURE Figure 2.1: Architecture centralisée 2.2. SERVERS DESCRIPTION 11 receives always the same response structure (WMS, WFS, JSON, XML, KML) whatever the format of the underlying data in the database or the server which responds. 2. possibility to implement internally only a very few limited number of web services. Indeed, many partners of the Police already oers web services that we can easily reuses directly on our systems. 3. availability of open source software for each item needed to develop those geo web services (Steiniger and Hunter, 2012). The ope source softwares considered here are even better rated than some commercial solutions. 4. no dedicated developement needed at local/decentralized units. the results returns by the service server are directly integrable into police applications. 2.2 Servers description The 3 production servers of the GDI project are hosted on the RACBLAD03 infrastructure. The 3 virtual servers are installed in Linux Red Hat 6.5 (RHEL 6.5) and are hosted on the same physical server (BLADE). The software conguration of each server is: 1. Dumont (IP:10.27.1.92->racgdidb001.pol.be) - up and operational • Import engine GDAL • Server SGDB PostgreSQL9.2 with spatial extension PostGIS v2.1.1 2. Magellan (IP:10.27.1.93->racgdimap001.pol.be) - up and opera- tional • Import engine GDAL • Tiling engine Mapnik v2.2.x • Web Feature Service Geoserver 2.7.4 3.