ADMINISTRATIVE BOUNDARY DATA SERVICE AS PART OF SPATIAL DATA INFRASTRUCTURES Dr. Mihály Szabolcs Institute of Geodesy, Cartography and Remote Sensing (FÖMI)

ADMINISTRATIVE BOUNDARY DATA SERVICE AS PART OF

SPATIAL DATA INFRASTRUCTURES

Dr. Mihály SzabolcsDr. Mihály SzabolcsInstitute of Geodesy, Cartography and

Remote Sensing (FÖMI)Hungary

6th GSDI ConferenceSeptember 16-19th 2002

Budapest

Dr. Mihály Sz.: Administrative boundary data services as part of spatial data infrastructures6th GSDI Conference, September 16-19th 2002, Budapest

SUMMARY (1)

Transition towards the information Society is the challenge of our time. Geographic information systems play special role in forming the national, continental and global spatial data infrastructures because larger part of any kind of information can be linked to its location by direct or indirect positioning.

For a big deal of users and information the co-ordinate systems are too specific. Indirect positioning, e.g. is linking the information to administrative territorial units suits much more users’ requirements.


SUMMARY (2)Geometrically, the administrative territorial units can be represented by their boundaries. Addition of attributes to them widens the circle of interest to them. The registry of boundaries and some attributes, the data capture and compilation of the administrative boundary database as well as the data services are generally the task of the national mapping agencies and partly those of the statisticians, all representing a part of the National Geographical Data Infrastructure. The globalisation and the increasing number of crossborder co-operations require unified interoperable data for any region and at global level.


SUMMARY (3This awareness in Europe led to the creation of SABE (Seamless Administrative Boundaries of Europe) by the European mapping agencies to be part of the continental spatial data infrastructure. Later, under the support of the European Commission R+D framework – as a kind of geographic extension and in the same time a technological innovation – the ABDS for the CEEC (Administrative Boundary Data Services for Central and Eastern European Countries) project advanced in the topic.

The paper presents how the ABD services can be managed to fulful the requirements of the Information Society and gives example how to go from national platform to continental and global ones in a comprehensive way.


ABD as part of spatial data infrastructure (1)

Provision of reliable up-to date basic data infrastructure is generally the task of the government. Nowadays this task is even more important, when the transition towards the Information society takes place.


The Administrative boundary data – being the base information infrastructure for different kind of analysis when spatial reference is required – are core part of the NSDI. The number of potential users is practically indefinite, range from statistics to economic analysis, from environment to logistics, from business administration to marketing, etc. A wide spread use of such kind of information can greatly contribute to modernisation of the whole infrastructure of a country, or a region. The provision and integration of such data and services seems indispensable for the modern electronik governance.



What are the key requirements for ABD service? • Firstly, the service must be reliable. It means that it must exactly reflect the

actual legal status of the territorial units. • Secondly, it must be relatively cheep and accessible for a wide range of users

(with certain products to be served for the public free of charge). • Finally, it must be interoperable in respect of merging the different data

sources as well as user friendly such that the user could specify the product wished to purchase.

Obviously, such criteria can be met only by on-line real-time service accessible via internet, all based on interoperation between the authorised data providers, on harmonising the data content, on adequate data and quality assurance, on well automatised data handling as well as on right service and data policy.



ABDS for the CEEC project (1)• As preparatory phase of a future service, the ABDS for the CEEC project, was

supported by the INCO Programme of the European Commission.

• The project aimed at the preparation and partial implementation of on-line delivery of administrative boundary data collected, processed and delivered with defined rules for data model and products, using the new European and ISO standards.

• The project was co-ordinated by the Institute of Geodesy, Cartography and Remote Sensing (FÖMI), Hungary and was implemented by a consortium of 19 organisations from 12 countries, representing the national mapping agencies, statistical offices and other public and private organisations mainly of the central and Eastern European Countries.


Participants sssssstordd CCountryCosssssss

Institute of Geodesy, Cartography and Remote Sensing (FÖMI) HungaryTechnical University of Sofia BulgariaResearch Institute of Geodesy, Topography and Cartography (VÚGTK) Czech RepublikStatistical Office of Estonia (ESA) EstoniaMEGRIN (an organisation of European NMA’s data services) FranceHellenic Cartographic and Cadastral Organisation (HEMCO) GreeceNational Service of Geodesy and Cartography LithuaniaCentral Statistical Bureau of Latvia LatviaGEOBID PolandResearch Institute for Informatics, RomaniaMinistry for Regional Development Czech RepublikMasaryk University, Brno Czech RepublikPlancenter Ltd. FinlandHungarian Association for Geoinformation (HUNAGI) HungaryMapping Agency of Hungarian Defence Forces (MH TÉHI) HungaryCentral Statistical Office (KSH) HungaryHungarian Public Utility for Regional Development and Town Planning (VÁTI) HungaryPrime Minister’s Office HungaryGISIG (a EU-supported international consortium) Italy

ABDS for the CEEC project (2)

Country


Tasks fulfilled:• Inventory• Generalisation• Memorandum of Undrstanding• Horizontal activities

– Standard conformity checking

– Quality assurance

– Legal protection

ABDS for the CEEC project (3)


INVENTORY (1)• What are the data sources in different countries?

• What is the administrative hierarchy in the different countries?

• What is the legal background of different administrative territorial units?

• Who are the data owners in different countries?

• What kind of data are available in different countries?

• What are the formats of delivery AB data and their atrributes?


INVENTORY (2)Sources of elementary datasets• Legally based: registered and maintained by cadastre• Technically based: on topographic or ther maps.

Data resolution consolidation levels• The kind of source of AB data greatly defines the accuracy and

influences directly on the largest possible resolution of the service. Therefore, each country can join the service depending on the quality of their available data.

• Consolidation levels which can serve as data of basic resolution to be used for different products of the common ABD servise:– 1st consolidation level: 2 m resolution (1:50 000 scale)– 2nd consolidation level: 10 m resolution (1:50 000 scale) (countries with

topographic or other maps)


INVENTORY (3)Hierarchy of administrative units:

Country NUTS 11 NUTS 2 NUTS 3 NUTS 4 NUTS 5

Bulgaria (BG) Geographic regions

Region County Municipality2

Czech (CZ) Group of regions Region District Municipality

Estonia (E) Region County Municipality

Finland (SF) Province Region County Municipality

Greece (GR) Group of regions Development region

County Municipality

Hungary (H) Statistical region County Small region Municipality

Latvia (LA) Province County Districts Municipality

Lithuania (LI) County Municipality

Poland (PL) Province Municipality

Romania (RO) Development region

County Municipality


Generalisation (1)• The objective of this work package was to elaborate generalisation

rules for the ABDS using a model oriented approach, formulating the requirements, coming to agreement on scales/resolutions and elaborating recommendations on the base dataset derivation. All with the aim to give the answer to the question on how we can convert our data into a product.

• Since the objective of the ABDS for the CEEC project is to deliver digital datasets of the administrative boundaries and not to produce maps, a model generalisation approach has been decided to be used rather than a cartographic one. That means in fact a simplification procedure using well elaborated and accurately tested algorithm(s).


Steps of model generalization for ABD service:Generalisation (2)

Procedure Step ResultsSegmentation Formal checking of the dataset List of errors and corrections

Visual checking of the geometry Corrections

Graphical checking by software and interactively List of errors, list of first order segmentation points

Hierarchical segmentationby software and interactively Definition of the triple boundary points and their attributes

Hierarchical and thermatic segmentation of state boundary points by bilateral agreement using software tools

List of state boundary points with attributes

Thematic segmentation – optional, to be supported by software tools List of segmentation points with thematic significance

Generalisation simplification

Lengthening straight lines (two adjacent vertexes is smaller than 1/3 of the band with used for the simplification for the given resolution must be eliminated)

Linger straight lines

Filtering of characteristic rectangular break of lines These points marked as additional segmentation points of safeguarding geometry

Simplification (Douglas-Peucker with Duda-Hart mofification or other optional algirithms e.g. Whirpool)

Simplified set of the set of coordinates

Interactive visual checking for self-intersection or other topological irregularity

Manual elimination of the irregularity, or definition of additional segmentation points(s) at this place, then repeating the simplification

Definition of the generalisation constant for seamless resolution generalisation Seamless simplification of the dataset

Product tailoring Addition of attributes to the dataset Data about area, population, etc.

Data conversion into pre-defined GIS formats (including XML, .txt) User-friendly products

Addition of metadata Complete information to the user about the product


Generalisation (3)• In the model generalisation process a geometry driven approach is applied. The

commonly used method of production guarantees the unified quality all over the area of participating countries.

• This method is to– Primary (elementary) datasets– Consolidation level datasets– ABD products: - standard products; tailored datasets– Guarantee the integrity, topological consistency at all resolution,– Produce predictable and repeatable results,– Reduce at maximum the data volume for the chosen resolutions,– Minimise the deviation of the boundary lines from the original position,– Allow on-line delivery of the tailored dataset,– Allow parameterisation of the main rules by the users (scroll menu with visualisation

of the effects of the chosen parameter),– Allow the calculation of the deviation from the area of the ATU.


Generalisation (4)Standard product

Resolution (m) Scale Corridor of simplification (m)

Precision (m)

0,1 1:1000 0,2 0,1

1-2 1:10 000 4 1

10 1:50 000 20 10

50 1:250 000 100 10

100 1:500 000 200 100

200 1:1 000 000 400 100

500 1:2 500 000 1000 100

1000 1:5 000 000 2000 1000


ABDS: Data model, Service model (1)

Factors considered

• Results of inventory

• Results of elaboration on generalisation

• International GI standartisation

• Quality aspects

• Legal and organisational issues


Principles of Data model (1):

• The objects of the service and databases are the ATU-s (Administrative Territorial Units) of different level the properties of which are given by the attributes. The attributes and their values are related to the objects and to each other in a relational description. This idea expresses the object oriented database model.

• The main groups of the attributes are the followings: spatial identification, the thematic properties of ATU-s, the attributes of the co-ordinates delimiting the ATU-s and the data quality parameters.

• Based on international GI standardisation the spatial schema follows the geometrical description and topological description.

• The ATU-s geometrically are expressed with surfaces, bordered by boundaries, consisting of boundary lines, the last being described by points. The points are given by their plain co-ordinates and optionally by their height.



Principles of Data model (2):

• The topological description of ATU-s is done with faces, edges and nodes.

• In case of data quality the data origin, accuracy certification and actuality are involved into the database as attributes. There are additional information in the metadata.

• The thematic properties of ATU-s are the results of agreement between the countries. The thematic properties are the dominant attribute elements in databases.

• Starting points of the data to be supplied are the primary (elementary) data sources. Here the clear knowledge on data quality is the purpose rather than only the accuracy or data collection simplicity.



Principles of Services model:

• The data service is based on the concept of distributed databases of the countries, at so called National Portals, established and managed by the National Focal Points. The International Portal is assuring the unique search facilities and all kind of harmonised Value Added Services based on the connected country data set.

• The future ABD supplier consortium is expected to be interfaced to the user community with a web-site at the National portal of each country being linked to each other by Internet and being connected to their own product database by LAN through fire-wall.

• The service model foresees the following products: gazetteer, free of charge products, standard (catalogued) products, customised products and value added services, as well as providing the data in national projection systems, in 2D geographical coordinates of ETRS’89 (GRS80 ellipsoid) and in data formats of dominant GI softwares.



Data flow and on-line service in ABDS - proposal

Primary data sources

Geometry data

Attribute data

Process of consolidation

Master

database

F

I

R

E

W

A

L

L

International portal

National portals

users

users

Portal


MEMORANDUM OF UNDERSTANDINGThe project was finalised by the signature of the Memorandum of Understanding at the Prague closing review meeting.

It describes the technical, organisational, and some other aspects of the future service.

It regulates the relationship between the SABE and the future ABDS.

The ABDS will be not a competitive product to the SABE, but rather a complementary one, as regarded the geographical scope, the technological innovation and the resolution of the data to be supplied.

On one hand the experience of SABE in managing of such kind of databases, on the other hand the geographical and resolutional extension and the technological innovations of the ABDS open together a good base for joint thinking and actions at European level, too.


Conclusion (1)

The „Administrative Boundary Data Services for the CEEC project implemented a work in harmony of general trends of Geographic Information Infrastructure and the Information Society. Its main objective, to define framework for implementation of a new ABD service in the region was achieved.


The innovative approach on comparing with other existing

services of the same character was expressed in the following

fields:• Using administrative boundary data with legal background rather

than the topographical ones of secondary data source• Scientific selection of the generalisation/simplification methods• Providing a full range of scales (resolutions) starting with 1:10 000

large scale AB data • Presenting the possibility of unique position determination of the

points on the border between the states in a Hungarian-Romanian pilot action

• Full range of products of the service, including the product tailoring according to the demands of the users

• Steps towards an on-line real time service.

Conclusion (2)


Besides of the innovation the project has some more positive results:

• Formation of a competent network of specialists able and willing to work together

• Impact on the development on the European GI infrastructure (possible further contribution GSDI

The positive experiences of the pilot project have proven, that we took apromising step towards the implementation of a modern international on-line service of the base data insfrastructure. Our results were highly appreciated by the European Commission. The public report of the results of the project „ABDS for the CEEC”, including the names of representatives of participating countries and organisations, can be visited web site.

Conclusion (3)


ABDS Data Model Administrative Boundary

Data Servicescase of Hungary

ABBREVIATIONS OF HUNGARIAN ORGANISATIONS USED LATER-ON:

CSO – Central Statistal Office of Hungary

DLO – District Land Offices of Hungary (1st level of cadastre)

CLO – County Land Offices of Hungary (2nd level of cadastre)

FÖMI – Institute of Geodesy, Cartography and Remote Sensing, Hungary (3rd level, nation-wide collection of

AB cadastre data)

Case of Hungary


117 DLO 20CLOgeometry and attributes

actual tasks:

new data forbuilt-in areas

update for

settlements

geometry

attributes

future: only updates

ISO - attributes

CSO - attributes

Data flow in ABDScase of Hungary, consolidation level 1:10 000 scale, 2 m resolution

FÖMI

Master

database

F

I

R

E

W

A

L

L

FÖMI

storage

database

Consolidation process

TAKARNETintranet of the land offices network


Case of Hungary

Regulation for data capture and update

Geometry - boundary of the settlement: at ministry decree level (21/1955 FM)

- boundary of the built-up areas: FÖMI internal arrangement– to be changed for

the update into ministry level

Attributes - area volume: FÖMI internal regulation

- population: CSO

- name of ATUs: CSO

- codes of ATUs: CSO

- NUTS: CSO

Case of Hungary


Original data sources (1)boundary points of settlements and of built-in areas

Data available in digital form

· in EOV and other reference systems· in ITR, Microstation, ERTOS etc. software format· content: id of coordinates, x, y, codes – optional Data available in coordinate lists (EOV surveys)

· in EOV and other reference systems· on paper, tipped lists· content: id, x, y, type of marcation – optional

Case of Hungary


Original data sources (2)boundary points of settlements and of built-in areas

Data from traditional map

· EOV other reference systems scales: 1:1.000, 1:2.000, 1:4.000, 1:1440, 1:2.880, with

· different regulation for surveying parameters, content: boundary points of parcels at the settlement and built-in area borders (x, y, type of monument can be digitised)

Case of Hungary


Data content of the files - separately for each settlement (1)

Data format: .text

1. Header: number and order of the rows can be defined for local needs

Content of the rows:

Name of the settlement (as defined by CSO)

Attributes defined by the DLOof boundaries (external, internal, see picture 1)

area volume (in ha)

Case of Hungary


Data content of the files - separately for each settlements (2)

Content of the rows - header (cont.)

Attributes defined by CSO:name od the regioncode of the regionname of the countycode of the countyname of the small regioncode of the small regioncode of the settlementtype of the settlementpopulation (census of 1990)

Case of Hungary



Content of the rows (cont.)

2. Geometry - content of the rows

External boundary 1..n

geocode of the central/label point

area volume (ha)

population

coordinates with y, x, code

1.. w, where 1=w

Case of Hungary



Content of the rows - geometry (cont.)

Internal boundary 1..m

geocode of the central/label point

area volume (ha)

population

coordinates with y, x, code

1.. w, where 1=w

Case of Hungary


Data content of the files - separately for each ssettlement (5)

Content of the rows - (cont.)

3. Metadata*version

format

reference system

date

quality (see codes of coordinates, b+c)

*The metadata should be placed into the first group of rows for processing

Case of Hungary


Types of the basic ATUs, the settlements (1)

One polygon

B) One main polygon and one or more external, separated

polygons, depending from the main polygon

C) One main polygon and a not from this polygon depending

smaller polygon within

D) One polygon with b and c – theoretical, not existing

E) Two type c as one settlement – theoretical, not existing

F) Terra incognita – polygon not depending from any polygons of

any levels

Case of Hungary



A) One polygon (99% - 3159)

·

Case of Hungary



B) One main polygon and one or more external, separated

polygons, depending from the main polygon (0,9 % - 29)

Case of Hungary



C) One main polygon and a not from this polygon depending

smaller polygon within (0.09 % - 6)

Case of Hungary



D One polygon involve the other – theoretical, not existing

Case of Hungary



E) Terra incognita – polygon not depending from any polygons of

any levels (1 case)

Case of Hungary


Built-in areas – polygons below the basic ATU level

Categories

built-in area

external zonesspecial external zones(former “closed garden”)

other legally validated categories detached farmsgroup of detached farms

Number of the built-in areas by settlement: 1… n (maximum: 128, case of Debrecen)


Case of Hungary

Codes of the coordinates (1)

A) level of ATU in the administrative hierarchy

1 = state boundary2= region3= county4 = small region5 = settlement6 = built-in area

(7 = reserved for blocks)

(8 = reserved for parcels) B) monument – only for the storage database

0= no monument

1= marked point

Case of Hungary



C) Origin (quality information)0= not known1= field survey2= photogrammetry3= digitisation4= other (e.g. calculated)

this categories are orientation for accuracy of the data:

1 for 1 ca 10-20 cm2 for 2 ca 50 cm3 for 3 ca 100 cm

Case of Hungary



D) Type of nodes (segmentation points)

0= simple boundary point, not node1= node defined by geometrical segmentation (to avoid self-intersection etc.)2= node defined by thematical segmentation (optional: crossing point of roads, rivers, state borders etc.)3= triple boundary point (common point of 3 or more ATU border segments)4= triple boundary point of built-in areas and other level ATU boundaries (picture 2)

Case of Hungary


The registry data (parts of metadata of the ABD collections for the ATU boundaries (1)

Status: to be completed continuously for the settlements, ready for the built-in

area boundaries

Content:

Cover pageName of the settlementCode of the settlementName of the DLOName of the CLO

Names and codes of the built-in areas of the settlement

Names and codes of the former “closed gardens”

Case of Hungary



Contenrt of the registry data (cont.)

1 page

Date of the execution of the data collection Name of the settlementCode and name of the countyName of the DLOCode of the settlement The neighbouring settlements(in the order as data are contained in the file: code of the settlement, name of the

settlement, competent DLO and CLO if in other county)

Case of Hungary




1 page

Map sheet and reference system used for the settlementScale Date of the implementation of the surveyTechnology used for the implementation of the survey Origin of the data by group of point – coordinates by y, x, detailed description of

the source

Case of Hungary




Last page Executing officer DLODate Controlled by: name, DLO, dateMethod of controlChecking method for the topology: Sent to FÖMI: date

Case of Hungary


Structure of data collection (1)

3 level process

1st level: DLO – locally collected data, local checking

2nd level: CLO – regional checking, and interactive corrections if necessary with DLOs main task: common boundary points between settlements limiting DLO-borders

3. Level: FÖMI – homogenisationmain tasks: common boundary points between countiesstate boundary points – bilateral agreements with neighbouring countries

Case of Hungary


Structure of data collection (2)

Interactive checking process – corrections exclusively by the data ownerat local level

DLO CLO

FÖMI

Unification of districts

By settlements boundaries + corrections

correctionsUnification of

countries

By settlements boundaries + corrections

Case of Hungary


Aspects for checking of the ABD (1)

Completeness• · lack of line segment, lack of part of the map(sheet)• · lack of attributes (codes, centroid, etc.)• · lack of coordinate at triple boundary points• · lack of elements of the codes

Topological correctness• · not continuous line with points jutting out• · common line segment not fully in coverage (number and identity of the

points)• · al points available in the different line segments for triple boundary points• · overlapping - corrections

Case of Hungary


Aspects for checking of the ABD (2) Segmentation points• ·identity at the common segment lines• ·identity of the common lines of settlements and built-in area’s triple

boundary points

Quality• · homogenity on the base of the origin of the data (column c of the code of

the coordinate)

• · maximum error, requirements of the consolidation level resolution

Actuality• · dates of the registry sheet• data concerning updates

Case of Hungary


Software used for checking process

The files contain .text data format - conversion into XML recommended

Software used:• MS Basic

• C

• Mapinfo

• MabBasic

• (ArcView)

• ITR – local programme used for field survey

Case of Hungary


Checking process using software (1)

Checking of the format• number of points, completeness of codes, correctness of coordinates,

separation of attributes and geometry data, first and last point identity by polygons

• test programmes in MS Basic

Checking of the completeness• number of ATUs, • existence of centroid/label point, situation within or not within the polygon • test programme in MS Basic

Case of Hungary



Visual checking• self-intersections caused by wrong coordinates• ordering of polygons• not full coverage of common segment lines between two ATUs• Mapinfo, MS Basic

Checking of the triple boundary points• searching for the triple boundary points defined for different ATUs• identity of the marked triple boundary points• object building by merging coordinates of common line segments • Deleting of line points (virtual nodes) • MS Basic

Case of Hungary



Test generalisation as checking• using Douglas-Peucker with Duda Hart extension• to detect self-intersections and lack of triple boundary points• list of first group of segmentation points with intersection danger in

different scales

Test export into different software formats

Test visualisation – portrayal – using different software • list of coordinates • 0-surface polygons

Case of Hungary


State boundary Key action for ABDS: to merge data of neighbouring countries

along the state boundaries - The main steps (1)

1. Agreement on coordinates of the boundary points in common reference and coordinate system (for ABDS: ETRS 89 and UTM)

2. Definition of triple boundary points: state boundaries and ATUs at different level of the administrative hierarchy

3. Definition of the triple boundary points at built-in area level: common points of state boundary and built-in area boundaries

4. Agreement on the boundary points of the geometrical segmentation – point characteristic for the state boundary line segment between two triple boundary points

Case of Hungary


State boundary Key action for ABDS: to merge data of neighbouring countries along

the state boundaries - The main steps (2)

5. Agreement on the state boundary point of thematical segmentation – points of high interest (cross-border section of roads, railways, buildings, peak of mountain, etc.)

6. Agreement on the coordinates when the rounding off procedure gives different value for the same point – practically at the scale of the surveying of the points

7. Remaining task: definition of the procedures necessary for the conversion of the whole country ABD into ETRS 89 / UTM - in national frame

Case of Hungary


Checking and definition of the segmentation points - controlling for the segmentation

Hierarchical segmentation:definition of the triple boundary points at different levels (in the case of

Hungary ca. 13.000) – see code d/definition of the common points of administrative boundary and built-inarea boundary points – see code d/4

Thematic segmentation roads, railways, buildings, etc crossing administrative boundaries andhaving precisely defined common points important: definition for different resolution standard productsoptional, not used in the case of

Case of Hungary


Conversion

• Commonly used reference and coordinate system at the consolidation level of 2 or 10 m resolution: ETRS 89 and UTM

• Rules conforming the specifications of the national reference systems with the aim to have the whole country in ETRS 89 and UTM resulting from one or more parts of the territory converted

• Parameter of conversion and software tools for Hungary (available from FÖMI – www.fish.fomi.hu

Case of Hungary


http://www.fish.fomi.hu/




Simplification (I.)

• Production of the master database at the consolidation level:

- scale of the original data source: 1.1.000 – 1:4.000

- target scale / resolution as consolidation level: 1:10.000 / 2m

- algorithm used for simplification: Douglas-Peucker; main reason for its

choice: no displacement of points, only deleting

- deleting of the attribute “markation” of the co-ordinates

• Number of points at original scales:

• Number of points at the consolidation level 1:10.000 / 2 m:

• Number of point at the consolidation level 1:50.000 / 10 m:

Case of Hungary


Result: consolidation levels of the ABDS

• Master database at the consolidation level is ready to start the creation, tailoring of the products and services at the resolution of 2 m, scale of 1:10.000 - from the national portal, actually in elaboration

• Simplification of the dataset into the 10 m resolution, 1:50.000 scale: one step of generalisation, first standard product for the ABDS

• Differences: number of points, upgrade period (halfyearly at 1:10.000 scale)

Case of Hungary


Simplification (II-1)

• Creation of the standard products of ABDS for the CEEC following definition in the documents data content and generalisation rules

- AB dataset by countries ar 10, 50, 100, 200, 500 and 1.000 m resolution

- change files

• Gazetteer: showing the searched ATU – search by name in English or local language(s) – situated within the 2-3 higher level ATUs and presenting links

Case of Hungary


Simplification (II-2)

Use of algorithms – software available: Preferred: Douglas-Peucker with Duda-Hart extension – generalisation factor

allows seamless resolution product composition

For tailoring standard product only: Whirlpool

Other could be included into the product line if needed andalgorithm defined

Case of Hungary


Douglas –Peucker algorithm with Duda-Hart modification

•VX1

TBP1 TBP2

d2 d1

d1, d2 ordinate values of vertices

Case of Hungary


The Whirpool algorithm

•


Case of Hungary

Comparison of the algorithms Douglas-Peucker and Whirlpool

Argument for the functionality Douglas-Peucker Whirlpool

Weeding +

Maximum deviation of original line

Higher

Centre of the line maintained +

Area deviation Smaller

Shape maintenance Better

More apt Human created objects Natural objects

Elimination of far away points + -

Self-intersection + +

Overlap + +

Only existing points (reverse engineering)

3 -

Only one step for the generalisation

For each product separated process

Complexity of the algorithm simply complicated

Strongly generalised dataset squaring up fitting to the forms

Cutting big loops with narrow neck

+

Line with high pont density rough averaging

Case of Hungary


Filtering of straight lines

V0V1

V2d1

If d1<3BW v1 eliminated

Case of Hungary


Segmentation by characteristic rectangular nodes

VX1

VX2VX0

>5 x BWBand width (BW)

>5 x BW

α

α = 89º - 91º

Case of Hungary


The parameter of the standard products

The label points for the ATU centres are included into the generalised product with the accuracy needed for the given resolution, always as integer.

Resolution(m)

Scale Bandwith, corridor (m)

Triple boundary point and label point sharpness (m)

:

10 1:50.000 20 10

50 1:250.000 100 10

100 1:500.000 200 100

200 1:1.000.000 400 100

500 1:2.500.000 1.000 100

1.000 1:5.000.000 2.000 1.000

Case of Hungary


The co-ordinates of the points and their attributes delivered in the products

1:50.000 – 1. 500.000 – all polygons, administrative centres of polygons, label points, names, codes, area volume, population and languages data + polygons of built-in areas (below basic ATU level)

1:1.000.000 (proposal) – all polygons, administrative centres of polygons with the exception of the of the built-in area, label points, names,

1:2.500.000 – (n-1)st ATU level (NUTS 4 level) polygons, label points, names

1:5.000.000 – (n-2) th ATU level (NUTS 3 level) polygons, label points, names

Note: The search interfaces of the international portal for ATU names, administrative centre names and codes will run at the 1:1.000.000 or 1.250.000 scale harmonised dataset.

Case of Hungary


Simplification (III–1)

Personalisation of the product and service - preview of the choice

Use of the Douglas-Peucker algorithm with Duda-Hart extension as default

· Delimitation of the area· by countries · by group of different level ATUs

· Definition of the bandwidth of the corridor for simplification

· standard products· individual product

· Definition of the sharpness of the coordinates

· recommendation following resulting of bandwidth

Case of Hungary


Simplification (III-2)

· Definition of the formatXML, text, dxf, dwg, MapInfo, ArcInfo, etc.

· Definition of the creation of long straight – deleting points· parameter for the bandwidth of the corridor · Definition and selection of the typical “rectangulars” –

definition of new segmentation points for the individual product

· parameter for the angle between the sides· parameter for the sides in function of the bandwidth

Case of Hungary


Simplification (III-3)

Composition of the productprice calculation

Document file: description of the ATU structure following inventory

Metadata – full ISO defined contentQuality data – following ISO definition, full

contentAttributes of the ATUsAttributes of the points

Case of Hungary


Topological errors in the generalised dataset:(Douglas-Peucker algorithm)

1. Example

Case of Hungary


Final checking of the personalised products

1. Looking for self-intersection created additionally

2. If created, the original and generalised line segments transferred into a separate file with

• identification of the ATUs

• identification of the triple boundary points

limiting the line segments

Case of Hungary


Data structure in MapInfo format (1)

Base: .text or XML coming from master database

“Header” file

name of the file settlement

reference systemfonttypes of lineattributes – name of the rows and columnsnumber of records

Case of Hungary


Data structure in MapInfo format (2)

Geometry

name and number of the of the regions (1 region = 1 settlement), number of the external and internal boundariesnumber of coordinates

In separate files:

metadata, quality data and hierarchy documentation

Case of Hungary


Documents

ADMINISTRATIVE BOUNDARY DATA SERVICE AS PART OF SPATIAL DATA INFRASTRUCTURES Dr. Mihály Szabolcs Institute of Geodesy, Cartography and Remote Sensing (FÖMI)