How Nominatim Powers OpenStreetMap Search
Geographic searching is an essential part of today’s GIS, web maps, and location-based services. People usually expect to be able to type in a city, street, house, postal code, or POI and get a geographic coordinate of that feature. The Nominatim geocoding engine, based on OpenStreetMap data, allows one to perform these searches.
The Nominatim geocoder translates human-friendly location names into geographic coordinates by means of geocoding and translates coordinates back to human-friendly addresses by means of reverse geocoding.
To understand the process performed by Nominatim, one should analyze the architecture of its data loading pipeline, spatial database, indexing, and searching.
What is Nominatim?
Nominatim is an open-source geocoding solution used for finding geographic objects from the OpenStreetMap database via text searching. This tool parses text requests and correlates them with geographic features such as administrative boundary lines, roads, buildings, settlements, and POIs.
In contrast to standard search engines, which work only with keywords, Nominatim analyzes geographic context and hierarchies of addresses. So, for instance, a query with a street name, city, and country can be correlated with several address parts to find the appropriate place.
The key functions of Nominatim include:
Forward geocoding: conversion of a text request into geographic coordinates and metadata.
Reverse geocoding: processing of geographic coordinates and finding a suitable object with an address on OpenStreetMap.
Nominatim is often applied to map applications, GIS systems, address search tools, and geospatial data processing chains.
How Nominatim Processes OpenStreetMap Data
Nominatim does not search the OpenStreetMap raw data on every request received from users. The program imports and processes geographic information to create a searchable database structure.
Overall, there are the following steps in the Nominatim workflow: data acquisition, parsing, normalization, indexing, query processing, candidate ranking, and results serialization.
OpenStreetMap Data Acquisition
The geographic information for Nominatim is acquired from OpenStreetMap data extracts or other OSM data sources. There are geographic objects within such datasets, which are described using the following three primitives:
Nodes: Describe individual geographic points, such as points of intersection, landmarks, and points of interest.
Ways: Describe ordered collections of nodes, i.e., roads, building outlines, and other linear or area objects.
Relations: Describe logical groupings of objects, such as multipolygons, routing networks, and administrative boundaries.
Tags are also included in OSM objects, which describe some properties of objects. For example, the road can have highway=residential; the building can have building=yes and a name tag.
This is how Nominatim uses tags to understand which OSM objects can be searched and how geographic and address attributes of these objects should be represented.
Data Import and Preprocessing
At import time, Nominatim analyzes OSM objects, works with the required tags, and creates searchable data for geographic objects.
These operations include:
Extraction of names, alternative names, and address-related tags.
Determination of objects that should be indexed.
Processing of administrative boundaries and addresses.
Generation of address details from tags and geographic context.
Creation of representative geographic coordinates for indexable objects.
Creation of database entries and searchable structures.
The processing of addresses is especially important since OpenStreetMap data is not always equipped with the full address for each object. Nominatim may use the geographic context, such as streets, neighborhoods, cities, and administrative regions, to create an address description if there is enough information.
But the quality of the address created in this way depends on the quality of OSM data.
PostgreSQL and PostGIS Database Architecture
The Nominatim geocoder uses PostgreSQL as its main relational database management system, combined with the PostGIS extension, which allows storing geographical information and performing some additional operations.
The PostgreSQL database contains data on imported OSM objects, names, addresses, and search results, while PostGIS supplies support for geographical data types and geographical computations.
Geographical operations may involve proximity computations, manipulations of geometries and geographical coordinates, as well as spatial relationship assessment. Database indexing makes it possible to limit the number of records that need to be considered for particular queries.
However, Nominatim not only uses spatial indexes but also creates special search structures, since the location search based on names and addresses involves efficient textual matching. Thus, its database design includes textual search algorithms along with geographical data.
This allows building a geocoding system capable of processing location descriptions within the context of geographical information.
Search Indexing and Text Normalization
In addition to keeping a database of place names, efficient geocoding also requires a method of mapping geographic attributes to searchable formats that can be compared to user queries.
Indexing and normalization performed by Nominatim allow the system to handle variations in spelling, formatting, and naming of geographic features. Based on what is being indexed and how the system is configured, the searchable data can include official names, alternative names, road names, and components of addresses.
For example, when a user searches for a place using its local language name, alternate spelling, or as a component of an address, this is handled using Nominatim’s query processing facilities.
The task is different from general-purpose web search, where there is no concern about geography and names of geographic objects.
Integrating Nominatim With Python
Nominatim can be incorporated into Python-based geospatial workflows using HTTP clients such as requests. Its output can then be processed with tools such as pandas, GeoPandas, Shapely, and other GIS libraries.
The following example performs a single forward-geocoding request:
import requests
url = "https://nominatim.openstreetmap.org/search"
params = {
"q": "Central Park, New York",
"format": "jsonv2",
"limit": 3
}
headers = {
"User-Agent": "ExampleGISApplication/1.0 (contact: gis@example.com)"
}
response = requests.get(
url,
params=params,
headers=headers,
timeout=30
)
response.raise_for_status()
results = response.json()
for result in results:
print("Name:", result.get("display_name"))
print("Latitude:", result.get("lat"))
print("Longitude:", result.get("lon"))
print("OSM type:", result.get("osm_type"))
print("OSM ID:", result.get("osm_id"))
print("---")Ensure you replace the example application name and its contact address with valid information about your application.
This is an illustration of the request and response process. The solution doesn’t include batching, retries, caching, and any other validation processes for production-level applications.
In case of large geospatial data sets, the developer may convert the coordinates into geometrical shapes and join the output with the existing records. The developer needs to be sure that he checks the reference systems, handles bad or ambiguous matches, and retains the source ID.
The public Nominatim services have certain limitations on the use. Your application will need to adhere to the current usage policy, identify itself by the means of User-Agent or proper referrer, observe limits on request rate, and avoid excessive or invalid requests to the service.
Nominatim Limitations and Best Practices
Firstly, Nominatim is a geocoding tool only, and not a full-blown GIS toolset or a source of authoritative address information.
Secondly, its results depend on the coverage and quality of OpenStreetMap data, which can be limited both spatially and in terms of consistent tagging of certain types of features. Furthermore, OpenStreetMap can be out-of-date and doesn't necessarily contain an up-to-date survey of certain geographical objects.
Thirdly, developers need to understand that geocoding accuracy isn't the same thing as coordinate precision, because the presence of many decimal places in the result doesn't necessarily mean that the feature has been surveyed to such accuracy.
To use Nominatim reliably:
Perform validation and normalization of query parameters.
Evaluate the relevancy of the result rather than taking the first candidate without thinking.
Use authoritative sources of data when there's a legal, cadastral, or high-precision positioning requirement.
Consider how to deal with incompleteness of the result and possible API errors.
Check for any attribution requirements and licensing conditions for OpenStreetMap data, including the latest Nominatim usage policy.
Choose an appropriate deployment scenario depending on the expected load.
Nominatim is used to perform searches on OpenStreetMap through the process of geographical data processing, use of PostgreSQL/PostGIS, special search indexes, address parsing, candidate ranking, and HTTP API access. Forward geocoding and reverse geocoding features make the tool applicable for use in web mapping, address enhancement, mobile GIS, and geospatial data preprocessing.
The efficiency of Nominatim relies on two components – indexing and searching techniques as well as the quality of the data contained in OpenStreetMap. With knowledge of its architecture, data output types, constraints, and requirements for using the tool, developers can create better processes for performing location searches.
To learn more about Nominatim and its geospatial capabilities, click here.
For more information or any questions regarding Bokeh for GIS Data, please don't hesitate to contact us at
Email: info@geowgs84.com
USA (HQ): (720) 702–4849
Comments