Chair(s):

Abhayaratna, Jo (PSMA Australia)

Group Charter:

Download Charter document

Group Description:

It is common in applications that use location data (whether as their primary interface or as a means of personalisation) for a user to be entering locations via text or selections on a map. Such functionality is commonly enabled via Geocoding APIs and web services but the lack of standardisation makes interoperability, portability and aggregation a challenge for application developers. OGC has identified the need for standardised interfaces for Geocoding.

There is a large gap between user requirements that aim at taking data within systems, or as a method of validating data before it is entered into systems, and geocoding it in order to obtain its location on the earth and the systems that hold data or manage its input that is not currently addressed by other standards within OGC's standards baseline.

The purpose of the Geocoding API SWG is to develop a candidate standard for a Geocoding API.

Geocoding is a core activity for linking a string to a location on earth. It is in many cases the entry point into the location dimension, unlocking the application of location to many problems including business intelligence, mapping, and routing. There are a number of different APIs on the market for doing this, and a variety of different algorithms for translating strings into locations. The standardisation of a Geocoding API is aimed at simplifying interoperability between business intelligence, mapping, and routing tools, and the services that geocode strings, and adds the capability to easily replace services or chain them together to improve searching success rates.

The OGC had previously been using OpenLS as the standard for performing geocoding. OpenLS was aimed at location services for mobile applications. However, the standard is no longer supported by modern web based tools, which have moved to implementing RESTful APIs for geocoding instead. This problem is outlined in section 2.1 of the OGC's Open APIs White Paper (16-019r4): "The recent proliferation of APIs for geospatial applications has degraded the interoperability previously established by open standards. This degradation is d[ue] both to the variability of API practices across the IT industry as well as variability in geospatial APIs specifically." This extends to the process of geocoding, and has resulted in the proliferation of a large number of different Geocoding APIs, each with their own strengths and weaknesses, but all with different interfaces. This results in a large amount of interoperability code for geocoding front end applications to access multiple backend services for geocoding - for example see this list of javascript files included with a popular Leaflet geocoding plugin to allow the use of various companies geocoding services.

In addition, the need for geocoding is recognised by the W3C and OGC Spatial Data on the Web Best Practices - specifically Best Practice 12: Expose spatial data through 'convenience APIs' which notes: "Users will often look for a particular Spatial Thing without knowing its identifier, too, in which case a fault-tolerant, free-text search on the name, label or other property may be useful."

Many front end applications have successfully limited the amount of code required for map presentation through the use of other OGC standards such as WMS, WMTS, etc., This standard aims, in support of the Open APIs White Paper, to similarly "promote wide spread interoperability based on open API design, while maintaining competitive opportunities" [16-019r4] for organisations with a geocoding API offering.

The scope of work for this SWG is to develop a new OGC candidate standard from scratch for access to geocoding services and to progress it to the state of an adopted standard by usintg the OGC RFC process as follows: 

1.    Develop use cases for geocoding;

2.    Develop a candidate standard;

3.    Gather comments from SWG members on the draft candidate standard and address them in the candidate standard;

4.    Submit the candidate standard to OAB for review and subsequent release for the 30-day public comment resolving the comments from OGC members; and

5.    Submit the final version of the candidate standard to the OGC TC for voting.

4.1    Statement of relationship of planned work to the current OGC standards baseline

The aim of this standard is to address a gap in the existing standards baseline to facilitate the modern geocoding use cases described above under Business Value Proposition.

4.2    What is Out of Scope?

• Algorithms for matching free text to location text strings
• Identification of specific reference datasets, or the types of reference datasets that should be searched (e.g., address points, lines using linear interpolation, gazetteer data, etc.)
• Presentation of search results to users (including but not limited to formatting, localisation, map views of results etc)
• Aggregation strategies for multiple geocoding services (either in terms of engineering, architecture or presentation of results to users)
• Utlisation of location data within applications
• Technology implementations and their architectures

4.3    Specific Contribution of Existing Work as a Starting Point

The work of this SWG will start from a discussion paper; OGC 17-001, Geocoding API Discussion Paper.

4.4    Determination of SWG Completion

The Geocoding API SWG will be dissolved after the following three milestones have been achieved:

1. The SWG has completed evaluation and incorporation into the candidate standard of all comments received during the public comment period;
2. Approval by the SWG membership of a recommendation to submit the document to the TC for consideration as an OGC Adopted Standard; and
3. The candidate standard has been approved by the OGC Technical and Planning Committees as an Adopted OGC standard.

4.5    Is this a persistent SWG?

X Yes    No

4.6    When can SWG be made inactive?

See criteria in section 4.4. The SWG may be reactivated to develop new versions of the standard or to address Change Requests and bugs.

The deliverable of the Geocoding API SWG will be a new candidate standard Geocoding API and eventually best practices documents.

A preliminary schedule of activities is as follows.

1.     Three months: review current Geocoding APIs and collect input from OGC members and the implementing community. Use this input to draft a standard.

2.     Three months: SWG review and approval of candidate standard. OGC internal review (OAB and OGC-NA) and public comment.

3.     Three months: OGC TC and PC approval of standard.

X RAND-Royalty Free.    RAND for fee

The target participants of the Geocoding API SWG include the following:

·       Current users and implementers of Geocoding APIs;

·       Linked data experts;

·       Geostatisticians;

·       Demographic data analysts and managers; and

·       National / regional / defense mapping and addressing agencies.

a. Similar or Applicable Standards Work (OGC and Elsewhere).

Apache Lucene

Apache Solr

ElasticSearch

IETF HTTP

IETF GeoJSON

ISO 19160-1 Addressing Conceptual Model

OpenSearch

OASIS BPEL

OGC WFS (with and without gazetteer profile)

OGC OpenLS

Joint OGC – World Wide Web Consortium (W3C) Spatial Data on the Web Working Group (SDWWG) output: Spatial Data on the Web Best Practices [OGC 15-107r1].

W3C output: Data on the Web Best Practices (https://www.w3.org/TR/dwbp/).

W3C JSON

W3C XML

W3C CORS

The SWG intends to seek and if possible maintain liaison with each of the organizations maintaining the above works.

b. Details of the First Meeting

The first meeting of the Geocoding API SWG will be a web conference within four weeks after approval of the SWG charter. Call-in information will be provided to the SWG's e-mail list and on the portal calendar in advance of the meeting.

c. Projected On-going Meeting Schedule

The work of the Geocoding API SWG will be carried out primarily by email and conference calls / web conferences, possibly every two weeks, with face-to-face meetings at each of the OGC TC meetings.

d. Supporters of the Proposal (Charter Members)

The following people support this proposal and are committed to the Charter and projected meeting schedule. These members are known as SWG Charter members. The charter members agree to the Statement of Work and IPR terms as defined in this charter. The charter members have voting rights beginning the day the SWG is officially formed. Charter Members are shown on the public SWG page.

e. Convener(s)

The following individuals started the SWG process.