Testing INSPIRE data specifications Anders Östman Imad Abugessaisa Xin He

Implementation rules Metadata (ready) Information models (data specifications) ◦ According to themes listed in three annexes Network services ◦ Search services ◦ Viewing services ◦ Download services ◦ Transformation services ◦ Invokation services

Why testing? INSPIRE demands that the data specifications shall be balanced with respect to costs and benefits Transformation tests: Can the member states deliver data according to the specifications? At what cost? Applikation tests: Are the data specifications useful? Which benefits do they generate? We have mainly worked with transformation tests related to the data specifications for Annex I themes.

Five themes have been tested Adresses Geographical Names Cadastral Parcels Hydrography Transportation Networks

Method in brief NLS database NLS schema INSPIRE schema NLS shapefiles Transformation rules Source data consistency report Source GML files Target GML files Schema transformation report Schema matching & mapping report Data extraction Schema matching and mapping Shape to GML conversion Source consistency test Schema transformation

Schema translation A schema specify the structure of a dataset Schema matching – to find corresponding elements in the source schema and target schema ◦ Automation may be based on ontologies and semantic matching Schema mapping – to find rules for the transformation ◦ Simple: Datum -> text ◦ Difficult: Point -> polygon, different classification systems Schema translation – to make the translation

Language NamedPlace Ortnamn XKOORD, YKOORD DETALJTYP SPRÅK URSPRUNG ORTNAMN ID-NR typeLocal Identifier sourceOfName Geometry Text INSPIRE Feature & Attributes typesFeasdla;ldk;alk LMV Feature & Attributes typesFeasdla;ldk;alk relatedSpatialObject levelOfDetail referencePointMeaning endLifespanVersion Missing attributes Conversion Rules

Simple mappings Code lists -> Text string 2 numbers -> GML Point Integer -> Text string Datum -> Datum

Complicated mappings Reclassification, Ortnamn -> NamedPlaceType {BEBTX, BEBTÄTTX, KULTURTX, KYRKATX, NATTX, SANKTX VATTDELTX, VATTDRTX, VATTTX} -> {Others} {} -> {Road, BasicRoadLink, RoadNode, RailwayLine} {ANLTX} -> {Airport, Heliport, Others} {TERRTX} -> {MountainRange, Archipelago} {FÖRSAMLTX, KOMMUNTX, SOCKENTX, TRAKTTX} -> {Administrative Unit} {GLACIÄRTX} -> {GlacierSnowfield}

Matching of feature types INSPIRE SchemaINSPIRE # MatchedPct Geographical Names 11100% Addresses66100% Cadastral Parcels33100% Road Transport Network6233% Railway Transport Network8225% Water Transport Network5240% Physical Waters10770% Hydro Facilities4125% Hydro Points Of Interests4250% Hydro Man Made Objects8450% Air Transport Networks Hydrography Networks Hydrography Management & Reporting In Total553055%

Matching of mandatory attributes INSPIRE Schema INSPIRETransformablePct Geographical Names3267% Addresses7686% Cadastral Parcels11982% Road Transport Network3267% Railway Transport Network44100% Water Transport Network44100% Physical Waters12542% Hydro Facilities11100% Hydro Points Of Interests3267% Hydro Man Made Objects44100% In Total523975%

Summary of matching and mapping The Swedish Land Survey is able to deliver data to 11 of 14 schemas (79 %) For these 11 schemas, The Swedish Land Survey can deliver data to 55 % of the feature types (30 / 55) For these 30 feature types, the Swedish Land Survey can deliver 75 % of the mandatory elements (30 / 55) The corresponding value for optional elements is 30 % (102 / 342)

Some expensive problems CadastralParcel.Geometry is to be a simple polygon. About 7,5 % of the Swedish parcels are represented by a point or line. NamedPlace.Type, see previous slide RoadLink.FormOfWay: About 80 % are uncertainly classified RoadLink.RoadWidth: Classes shall be converted to width in meter

Metadata ThemeCompleteness At other place Information missing Addresses28%64%8% Cadastral Parcels75%21%4% Hydrography36%64%0% Geographical Names54%14%32% Transportation network75%25%0%

Summary The GeoTest project is a part of the Swedish geodata strategy Transformation tests of data specifications in INSPIRE Annex I are performed ◦ The responsibility of each agency needs to be reviewed ◦ The cooperation among the agencies needs to be developed further ◦ Some transformations will be costly Current metadata do not comply to any standard

Solutions for GML Schema Transformation

Objective To evaluate existing tools for schema transformation Restricted to tools performing the operations in the XML/GML domain

Tested Tools Safe FME 2008 Desktop Altova MapForce 2009 Snowflake Go-publisher 1.4

FME 2008 Desktop

Altova MapForce 2009

Snowflake Go Publisher 1.4

Overview of tools

Types of transformation (Liljergren et.al 2006) Semantic transformations ◦ Source and target domains may be the same. ◦ Example: Swedish -> English. Domain transformations ◦ Different domains. May also include semantic transformations Coordinate transformation ◦ Geodetic reference systems, linear reference systems, …

Transformations being studied Strings and codelists (semantic + domain) Geometric transformations (domain) Levels of measurement (domain)

Strings and codelists

Geometric transformations

Levels of measurements

What is the best solution? FME can perform almost all transformations in the matrices. However, it lacks the ability to handle XML hierarchical structure. Both MapForce and GoPublisher can do this job. However, GoPublisher is not designed for schema transformation and lacks of developed functions and data interfaces. Luckily, MapForce is on the other side.

Conclusions No single tool can fulfill all requirements of the transformation between GML schemas; The best solution at present is to use FME and MapForce together. However, the efficiency of handling XML/GML files are not so high at this stage. E.g. GML files that only smaller than 50 MB can be handle by MapForce at our computers.