Ireland Nearest Analysis (EPA API + EPSG:29903)

Introduction

Nearest-feature analysis is a common requirement in environmental impact assessment, land-use planning, and regulatory screening. Practitioners are frequently required to assess the proximity of a proposed development site to environmental receptors such as protected areas, water bodies, or infrastructure datasets published by regulatory authorities. While QGIS provides tools for proximity analysis on local datasets [1], workflows that involve remote regulatory data typically require multiple manual steps, including data download, coordinate system harmonisation, spatial filtering, and post-processing. These steps are time-consuming, error-prone, and difficult to maintain consistently across projects.

Related work and literature review

From a methodological perspective, nearest-feature analysis is a well-established operation in geographic information systems (GIS), typically implemented using spatial indexing structures and geometric distance calculations. Foundational work in GIScience highlights the importance of spatial relationships and proximity analysis in environmental and planning contexts [2, 3], while efficient nearest-neighbour search methods based on spatial indexing (e.g. R-trees) have been widely adopted to support proximity queries in large spatial datasets [4].

In parallel, research has increasingly focused on workflow automation in GIS to reduce manual processing steps and improve efficiency, including scripting approaches, model-based workflows, and plugin-based extensions within desktop environments [5]. Within this context, QGIS has been widely used to support customised extensions tailored to domain-specific requirements [6]. Recent work has further emphasised reproducibility and standardised processing pipelines in geospatial analysis, highlighting the importance of integrating data acquisition, preprocessing, and analysis into cohesive workflows [7, 8, 9, 12].

Nearest-feature and proximity analysis are also supported in programmatic and database-oriented environments. For example, GeoPandas enables nearest-neighbour operations through spatial indexing and geometric distance calculations in Python-based workflows [10], while PostGIS supports scalable nearest-neighbour queries using spatial indexing and distance operators in spatial databases [11]. These approaches provide flexibility and analytical power but typically require programming expertise or database configuration.

Within desktop GIS, QGIS provides native tools such as ‘Distance to nearest hub’ and ‘Join attributes by nearest’ for proximity analysis on locally available datasets. However, these tools generally assume preprocessed local data and do not natively integrate remote geospatial services into a unified analytical workflow.

Despite these advances, existing approaches – whether desktop-based, script-driven, or database-oriented – generally treat data acquisition, preprocessing, and proximity analysis as separate steps, particularly when remote geospatial services are involved. This results in fragmented workflows that require additional configuration and manual intervention.

The Ireland Nearest Analysis plugin addresses this limitation. Unlike existing QGIS tools and script-based workflows, the proposed approach uniquely integrates remote geospatial API access, CRS standardisation, spatial filtering, and nearest-feature analysis into a single automated workflow within the QGIS environment. This approach bridges the gap between flexible but technically demanding programmatic methods and user-friendly desktop GIS tools, while supporting consistent and reproducible regulatory workflows. Table 1 provides a comparison of the proposed approach with existing methods.

The computational cost of nearest-feature queries remains negligible due to the use of spatial indexing, while the primary performance overhead is associated with remote data retrieval. This behaviour is examined in detail in the Quality control section.

The software is designed for use in Ireland, where EPSG:29903 is the standard CRS for environmental datasets and regulatory reporting. The remainder of this paper is structured as follows: Section 1 provides an overview of the software, including implementation and quality control; Section 2 describes availability; and Section 3 discusses reuse potential and future work.

Implementation and architecture

The plugin is implemented in Python as a QGIS plugin using the QGIS Python API and PyQt5 for the graphical user interface. The system follows a structured data-processing workflow that integrates local data input, remote data acquisition, spatial analysis, and output generation within a single environment.

Local vector data are accessed through the QGIS OGR provider (part of the GDAL – Geospatial Data Abstraction Library), ensuring compatibility with standard geospatial formats such as shapefiles. Remote datasets are retrieved using OWSLib (Open Web Services Library) for WFS and HTTP-based requests for ArcGIS REST Feature Services. This dual data-access approach enables the integration of locally stored application areas with externally hosted regulatory datasets.

All spatial operations are performed using native QGIS classes, including QgsGeometry for geometric processing, QgsSpatialIndex for efficient nearest-feature candidate selection, and QgsCoordinateTransform for coordinate reference system transformations. Nearest-feature search is implemented using QgsSpatialIndex to identify candidate features, followed by exact geometric distance computation.

To ensure consistency of spatial measurements, all geometries are transformed to EPSG:29903 (Irish National Grid) prior to distance and azimuth calculations. This standardisation is particularly important for regulatory GIS workflows, where consistent coordinate systems are required for reporting and analysis.

The processing workflow proceeds as follows: the local application area is first transformed to EPSG:29903, after which a user-defined analysis distance is used to construct a buffer region. Remote features are then retrieved and spatially filtered within this region, reducing the number of candidate features prior to analysis. Nearest-feature computation is subsequently performed using spatial indexing and geometric distance calculations, and azimuth values are derived to indicate directional relationships.

Results are exported as structured CSV files for reporting and verification. In addition, optional graphical visualisation is generated using Matplotlib, allowing users to produce map-based outputs that illustrate the application area, nearest feature, and computed spatial relationships.

The architecture follows a modular design that separates user input handling, data retrieval, spatial processing, and output generation, ensuring maintainability and extensibility within the QGIS environment.

The overall system architecture is illustrated in Figure 1, which highlights the interaction between the main components of the plugin. The architecture consists of four principal layers: (i) a user interface layer implemented using PyQt5 within QGIS, (ii) a data acquisition layer responsible for retrieving both local vector data and remote datasets via WFS and ArcGIS REST services, (iii) a spatial processing layer that performs CRS transformation, spatial filtering, nearest-feature computation, and azimuth calculation using native QGIS classes, and (iv) an output layer that generates structured CSV reports and graphical visualisations. External geospatial services and the QGIS core environment are integrated within this architecture to support efficient and consistent processing. In this context, the term ‘API’ refers to publicly accessible geospatial web services, including WFS and ArcGIS REST Feature Services, which provide programmatic access to spatial datasets hosted by external providers such as the EPA.

Figure 1

The term ‘nearest feature’ is defined as the spatial feature within the selected remote dataset that minimises the Euclidean distance to the input application area after all geometries have been transformed to a common coordinate reference system (EPSG:29903). The distance is computed as the shortest distance between the boundary of the application area and the nearest point on the target feature geometry.

Azimuth is defined as the directional angle from the centroid of the application area to the nearest point on the target feature, measured in degrees relative to geographic north. The nearest-feature computation follows a two-stage process: candidate selection using spatial indexing (QgsSpatialIndex), followed by exact geometric distance evaluation. In cases where the application area lies within or overlaps a polygon feature in the remote dataset, the computed distance is zero and directional information is not meaningful. In such situations, the system assigns the direction label as ‘Inside’, and the azimuth value is omitted.

Figure 1 presents the system architecture of the plugin, illustrating the main components and their interactions. In contrast, Figure 2 presents the user-oriented workflow, demonstrating how these components operate sequentially during analysis.

Figure 2

As shown in Figure 2, the workflow begins with plugin activation within QGIS, followed by selection of a local application layer and a remote dataset accessed via WFS or ArcGIS REST services. The user then defines the analysis distance, after which the plugin executes the analysis workflow, including coordinate transformation to EPSG:29903, remote data retrieval and filtering, spatial indexing, and nearest-feature computation.

Subsequently, the workflow proceeds to the calculation of azimuth values to determine directional relationships between the application area and the identified nearest feature. Finally, the results are exported as structured CSV outputs and optional graphical representations, including map visualisations and plots generated using Matplotlib.

The core workflow consists of the following stages:

Input selection: The user selects a local vector layer representing the application area and specifies a remote dataset accessed via a WFS endpoint or an ArcGIS REST Feature Service.

Coordinate standardisation: All spatial operations are normalised to EPSG:29903 to ensure consistent distance and azimuth calculations.

Remote data retrieval: Features are spatially filtered to a user-defined buffer region around the application area (30 km by default).

Proximity computation: The nearest feature is identified using spatial indexing and geometric distance calculations. Distance and azimuth are computed using standard geometric methods.

Output generation: Results are exported to CSV format and optionally visualised using Matplotlib.

Design decisions prioritise robustness, transparency, and practical applicability in regulatory GIS contexts.

Quality control

The software has been tested in QGIS 3.40 and QGIS 3.44 environments on Windows 10/11 systems.

Validation focused on coordinate transformation accuracy, distance computation, and azimuth calculation. In addition to workflow-level validation, individual components such as CRS transformation and distance computation were tested independently to ensure correctness. Distance results were compared against measurements obtained using the QGIS ‘Measure Line’ tool across multiple datasets and showed agreement within sub-metre tolerance. To provide quantitative validation, computed distance values were evaluated against measurements obtained using the QGIS ‘Measure Line’ tool across multiple test cases. The observed differences were generally below 0.5 metres, with an average deviation of approximately 0.2 metres based on representative test cases. Coordinate transformations to EPSG:29903 were verified using known reference datasets to ensure correct reprojection behaviour.

Azimuth calculations were validated by comparing computed directions with measurements obtained using the QGIS ‘Measure Bearing’ tool. The calculated directions were consistent with expected geographic orientations, with differences within 0.5 degrees across tested cases.

Edge cases, including multipart geometries and empty geometries, were tested to ensure stable and predictable behaviour under varying input conditions.

Performance observations were conducted on workflows involving remote datasets with hundreds of features. In the tested examples, nearest-feature queries using QgsSpatialIndex completed in a fraction of a second, while overall processing time was primarily influenced by remote data download and preprocessing.

Validation was conducted using representative datasets from WFS and ArcGIS REST services across varying spatial scales, with feature counts ranging from fewer than 10 to over 600.

Distance and azimuth outputs were validated against QGIS native measurement tools (e.g. Measure Line and Measure Bearing), with results showing consistent agreement across tested cases.

Performance behaviour was also assessed using runtime logs. For smaller datasets (tens of features), total preprocessing time was typically below one second, while larger datasets (hundreds of features) required several seconds to complete, primarily due to remote data retrieval and filtering operations. The use of spatial indexing ensured that nearest-feature queries remained computationally efficient.

Edge-case handling was verified through execution logs. Cases where no features were found within the specified buffer were handled gracefully without interrupting the workflow. Additionally, caching mechanisms were implemented to avoid redundant computation when analysis inputs remained unchanged, significantly improving performance in repeated runs. When invalid CRS inputs were encountered, the system logged the issue and preserved the original geometry to ensure continued execution.

Performance evaluation was conducted using representative WFS datasets from the EPA, with varying buffer distances and dataset sizes. As shown in Table 2, total preprocessing time ranged from 0.16 s for small datasets to 18.82 s for larger datasets (646 features), with processing time primarily dominated by remote data retrieval and filtering operations.

The nearest-feature query itself remained computationally negligible (<0.01 s) across all tested cases due to the use of QgsSpatialIndex. This confirms that the computational bottleneck lies in remote data access rather than spatial indexing or distance computation.

In addition, caching of preprocessed data significantly improved performance for repeated analyses with unchanged inputs, reducing preprocessing time from several seconds to effectively zero while maintaining identical results.

Case 5 represents a repeated execution with identical input parameters, where cached preprocessed data were reused. In this case, preprocessing time was reduced to zero, demonstrating the effectiveness of the caching mechanism in improving performance for repeated analyses.

The workflow consists of four stages – installation, configuration, execution, and output generation – as illustrated in Figures 3, 6. Figure 3 shows plugin installation via the QGIS Plugin Manager.

Figure 3

Following installation, Figure 4 presents the configuration stage of the analysis. In this interface, the user selects the local application area, specifies the remote dataset via WFS or ArcGIS REST services, chooses relevant output fields, and defines the analysis distance. This stage consolidates all required inputs into a single interface, reducing the need for manual preprocessing and tool switching.

Figure 4

The execution and output stages are illustrated in Figures 5 and 6. Figure 5 shows the spatial results generated after running the analysis, including the application area, the identified nearest feature, and the computed distance, azimuth, and directional relationship. Figure 6 presents the corresponding structured CSV output, which enables verification, reporting, and further analysis. Together, these stages demonstrate how the plugin transforms user inputs into reproducible analytical outputs through an integrated and automated workflow.

Figure 5

Figure 6

Operating system

Windows (tested on Windows 10/11; while the plugin may run on Linux systems, this has not been formally validated and may require environment-specific configuration).

Programming language

Python (QGIS 3.x Python environment)

Additional system requirements

QGIS 3.x installation with network access for querying remote geospatial services

Dependencies

OWSLib [13]; Matplotlib [14]; requests (within the QGIS Python environment)

List of contributors

Chao Gong – software design, implementation, testing, and documentation

Software location

Archive

• Name: Zenodo

• Persistent identifier: https://doi.org/10.5281/zenodo.18262401

• Licence: MIT License

• Publisher: Chao Gong

• Version published: v1.0.0

• Date published: 15/01/2026

Code repository

• Name: GitHub

• Identifier: https://github.com/chao515737/nearest_analysis_plugin

• Licence: MIT License

• Date published: 17/11/2025

Installation and quick start

The plugin can be installed directly through the QGIS Plugin Manager by searching for ‘Ireland Nearest Analysis (EPA API + EPSG:29903)’ under: Plugins → Manage and Install Plugins.

Alternatively, the plugin can be installed manually from the GitHub repository by downloading the source code and copying the plugin folder into the QGIS plugin directory. On Windows systems, this directory is typically located at: C:\Users\<username>\AppData\Roaming\QGIS\QGIS3\profiles\default\python\plugins.

After installation, QGIS should be restarted and the plugin enabled via the Plugin Manager.

The plugin is primarily tested on Windows systems. While it may be used on Linux systems by copying the plugin folder into the corresponding QGIS plugin directory (e.g. ~/.local/share/QGIS/QGIS3/profiles/default/python/plugins), this has not been formally tested and may depend on the local QGIS configuration.

Quick start

1. Load a local vector layer representing the application area in Ireland (e.g. a shapefile). If the input layer contains multiple features or covers a large spatial extent, users may optionally select a subset of features within QGIS prior to running the analysis. Alternatively, a pre-filtered layer representing the specific application area of interest can be provided as input to ensure that the analysis is performed on a defined subregion.

2. Open the Ireland Nearest Analysis plugin from the QGIS Plugins menu.

3. Select a remote dataset via WFS or ArcGIS REST.

4. Run the analysis to compute nearest-feature distance and azimuth.

5. Export results as CSV and optional map output.

The plugin is designed to run within the standard QGIS Python environment and does not require additional installation of external Python libraries (e.g. GeoPandas), ensuring compatibility with default QGIS installations on Windows systems.

Detailed installation instructions and example datasets are provided in the GitHub repository.

Language

English

Limitations

However, the current implementation is geographically constrained to Ireland due to its reliance on EPSG:29903 and national data services.

Reuse Potential

Ireland Nearest Analysis is designed for environmental assessment and planning workflows within Ireland, where EPSG:29903 is the standard coordinate reference system used by regulatory authorities. The plugin enables practitioners to perform nearest-feature analysis using authoritative Irish geospatial datasets (e.g. EPA services), supporting consistent and transparent workflows in a regulatory context.

The software is intended for use by GIS practitioners, consultants, and researchers working with Irish environmental datasets. Typical use cases include proximity assessment of proposed developments to environmental receptors, screening analysis in environmental impact assessments, and regulatory reporting workflows where consistent methodology is required.

The functionality of the plugin reflects standard practices in Ireland, integrating remote data access and spatial analysis into a single workflow. This reduces manual preprocessing steps and minimises potential sources of user error, particularly when working with multiple external datasets.

To adapt the workflow for use outside Ireland, users must modify the CRS transformation component (QgsCoordinateTransform) to match the target coordinate system and replace EPA WFS endpoints with equivalent geospatial services relevant to the target region.

Future Work

Future work may include extending the plugin beyond EPA data sources to support additional Irish geospatial services, such as those provided by Tailte Éireann (formerly Ordnance Survey Ireland) and GeoHive Ireland, further enhancing integration with the national geospatial data ecosystem.

In addition, future development may consider extending support to neighbouring regions, particularly for cross-border analyses between Ireland and Northern Ireland. This would require support for additional coordinate reference systems used in Northern Ireland (e.g. EPSG:27700, British National Grid), enabling more flexible analysis in border areas.

While the workflow is standardised to EPSG:29903, this design choice does not limit reproducibility but rather constrains the geographic scope of applicability. Reproducibility in this context refers to the ability to obtain consistent results given the same input data and parameters within the defined coordinate system.

The use of a fixed CRS ensures that distance and azimuth calculations are performed consistently across analyses, which is particularly important in regulatory GIS workflows. However, reuse of the software outside Ireland would require adaptation of the coordinate reference system and associated data sources.

Users may report issues or contribute improvements via the GitHub repository.