Land and building register (EGiB)
The Land and Building Register is maintained by heads of counties, which results in 380 units being responsible for maintaining them. The EGiB data, and in particular the data on cadastral parcels, are the primary reference data for the presentation of various other objects and features collected in spatial information databases. In addition, a parcel number in conjunction with a district number is often assigned as an attribute to many objects that are located on that parcel. Then, if we are able to find a parcel, we are able to access the objects located on it at the same time. It is also significant that registered parcels are the second important spatial location reference of objects after addresses. The capability to convert the parcel number (identifier) to its spatial location (geometry) is an important feature for developers of any systems related to spatial information, because it allows easy implementation and sharing.
Fragmentation of land and building register databases does not mean, however, that at the national level we have to deal with the resulting difficulties. Adequate aggregate services became the solution to this problem since they allow operating across the country.
In the second half of 2018, GUGiK integrated the publication of land and building register data from the counties in aggregate services. The purpose of the project was to provide commonly available web services to enable the use of land and building register data in the national information systems and systems created by commercial companies. The services in question include:
- KIEG – (National Integration of Land Records) – a WMS service which allows users to generate land and building register maps for any area of the country.
- ULDK – (Cadastral Parcel Location Service) – a service for the location of cadastral parcels which enables spatial location of a specific parcel based on its identifier, district name and parcel number, or based on X,Y coordinates of any point within it.
Complete technical details of these services can be found at their respective websites, namely:
KIEG is a WMS aggregate service which allows its users to generate a land and building register map for any area of the country, and its essence is the feature that allows them to download information from one of the 380 county servers. The concept of the KIEG is presented in the diagram below (Fig. 1).
Figure 1. KIEG functional diagram
The actions presented in the diagram above can be described by the following sequence of actions required to use the KIEG:
- the user uses only one address of the WMS aggregate service (i.e.: https://integracja.gugik.gov.pl/cgi-bin/KrajowaIntegracjaEwidencjiGruntow) and does not have to remember the addresses of each service at a county level;
- the user of the aggregate service sends thereto a map generation request for the browsed area, including his or her own defined configuration of information layers;
- based on its register of information concerning county services, the aggregate service queries respective services in the user's area of interest to generate data image (map) from particular counties;
- when all responses from one or more counties are well received, a combined data image (map) is created for the query and returned to the user as an appropriate graphic file.
Figure 2. Example of a piece of map returned by the KIEG
An example of a query used to generate the image shown in Fig. 2 is at:
Queries that require data from the area of more than one county are simple for KIEG users because the service automatically gets images from all the counties included in a query pane (Fig. 3).
Figure 3. Example of a piece of map returned by the KIEG
By appropriately configuring the KIEG query parameters, you can obtain a land and building register map image from any area of Poland.
The ULDK is a cadastral parcel location service. It enables the spatial location of any parcel situated in the territory of Poland based on its identifier, district name and parcel number, or based on X,Y coordinates of any point within it. Figs. 4 and 5 show ULDK functional diagrams for the location using both an identifier and coordinates.
Figure 4. Diagram of ULDK parcel location based on a parcel identifier (request=GetParcelById)
Figure 5. Diagram of ULDK parcel location based on coordinates (request=GetParcelByXY)
Here are the respective queries:
The query may include a coordinate system ID along with spot coordinates (by default, the coordinate system is EPSG:2180, i.e. PUWG1992). By default, the parcel geometry is returned in WKB format implemented in most of the dedicated systems for spatial data processing. Typically, a parcel location query with no additional parameters returns a resulting file which consists of two lines.
Figure 6. Typical response from ULDK
The first line refers to the response status, whereas the second one represents a parcel geometry in WKB format. Parcel geometry is only returned if the parcel is found, i.e. when the response status is zero. Otherwise, the file contains only a single line with the query status.
Results can be different for queries based on a district name and parcel number which are not always unambiguous and might return more parcels due to duplicate district names, e.g. a query for parcel 756 in district Stara Wieś:
returns a file containing information about six parcels from different counties:
Figure 7. Search results for query Stara Wieś 756
If you make queries which include district names, apart from more than one result, you can also expect a longer response time because the query must be processed by all the counties with districts of the specified name. For example, the query „Dąbrowa 12” returns as many as 57 parcels that meet the search criteria.
Apart from basic location-related functionalities of the ULDK, it also supports some additional functions. One of them is snapping to the closest point of a cadastral parcel. An example of a query is specified below and the result is shown in Fig. 8
Figure 8. Snapping to the points of a cadastral parcel
The result is a file which consists of three lines:
The first line contains the response status, the second one contains point coordinates in WKB format, and the third one contains the actual distance between the returned point and the point whose coordinates are provided in the query.
Another functionality is the aggregation of a few objects included in the register (parcels, districts or communes) into a single geometry. An example of a query is specified below and the result is shown in Fig. 9.
Figure 9. Aggregation of objects into a single geometry
For all the technical details on how to use the ULDK, including the description of all the query parameters, see https://uldk.gugik.gov.pl.
Figure 10. ULDK website
Figure 11. Website with description of ULDK detailed parameters
EGiB data can be browsed using a WMS aggregate service which is by default connected to www.geoportal.gov.pl. However, the service can also be connected to any software that supports such standard (WMS address: https://integracja.gugik.gov.pl/cgi-bin/KrajowaIntegracjaEwidencjiGruntow). The results obtained by connecting the service in QGIS are shown in Fig. 12.
Figure 12. WMS for land and building register data connected to QGIS software
Connected service should display land and building register details for any area of Poland per layer configuration set by the user. The most significant layers include: Cadastral parcels from each county, parcel numbers, buildings, and in the areas for which there are no complete geometric data available, the "Działki – uzupełnienie z LPIS" (Parcels – LPIS supplementary data) layer can be useful. The service also provides the classification contour and usable land layers but, at the moment, not all the counties provide access to this data.
The best solution for searching parcels is to install a plug-in by EnviroSolutions Sp. z o. o. which uses the ULDK to find any parcel.
Figure 13. Searching for parcel in QGIS using EnviroSolutions plug-in
Generally, data from the Land and Building Register is made available in return for payment, but some part of it, i.e. geometry of cadastral parcels and buildings, along with basic attributes is available free of charge for any purpose. This data can be downloaded using WFS web services of respective counties which are intended for downloading vector data based on user-defined criteria. GML format is used for data transfer.
Information about counties that share the WFS service can be found in the Register of Collections and Services on www.geoportal.gov.pl, tab "Registers".
Figure 14. Register of Collections and Services website
If the respective county offers WFS downloading, you can download its address from the list by clicking "Pokaż" (Show) to access detailed data for the collection and to copy a WFS address that may be available.
Figure 15. Access to details of the Register of Collections and Services
Then, based on such service, define a data source in QGIS to create an information layer of the shared data in a QGIS project at any time.
Figure 16. Application of WFS in QGIS
When the layer is created in a QGIS project, the service generates an image of cadastral parcels for the browsed area. Use the export option illustrated below to save the on-screen piece of data as a file.
Figure 17. Export of land register data to SHP file
As a result, you get a local file consistent with the settings which represents the respective fragment of cadastral parcels from the county. This way, you conveniently download required data from the county database without submitting any requests or involving employees of the county authorities.