[OSM-talk-nl] NLExtract project
Frank Steggink
steggink at steggink.org
Mon Jan 23 21:06:33 UTC 2012
On 23-1-2012 21:58, Frank Steggink wrote:
> Michiel,
>
> De meeste gotcha's zijn inherent aan het datamodel van Top10NL, dus ze
> zijn "bewust" ingebracht. Dit is gebaseerd op GML (geography markup
> language). Op basis hiervan is door Geonovum NEN3610 ontwikkeld en
> geïmplementeerd in GML (via een XML Schema-definitie). Dit heeft als
> doel uitwisseling van ruimtelijke data in Nederland. Dit model is
> behoorlijk complex. Top10NL is weer op basis van NEN3610 ontwikkeld.
> Volgens mij is dit alleen door het Kadaster gedaan. NEN3610 biedt al
> de mogelijkheid om meerdere geometrieën aan een object te koppelen
> (bijv. oppervlakte en hartlijn van een weg), of om meerdere attributen
> met dezelfde naam toe te voegen (bijv. wegnummers: een weg kan
> meerdere wegnummers hebben). Het doel is om de informatie zo compleet
> mogelijk op te slaan en uit te wisselen. Het is aan de gebruikers
> hiervan om te bepalen welke data wel of niet getoond wordt.
>
> Dit heeft als consequentie dat de tooling aan behoorlijke eisen moet
> voldoen. ogr2ogr komt een heel eind, maar niet overal is een oplossing
> voor. Bijv. de meerdere geometrieen per object: hiervoor is dus de
> splitsings-stap nodig. Uitlevering in een ander formaat lost het
> probleem niet 1-2-3 op. Bijv. Shape is te beperkt om alle informatie
> ongeschonden door te laten. De data zoals die door het Kadaster wordt
> uitgeleverd is ook geen eindproduct waar een willekeurige gebruiker
> iets mee kan. Daarvoor moet er nog een bewerkingsslag overheen. De
> reden dat het NLExtract project is opgestart is juist om deze
> bewerkingsslag te maken en afgeleide producten te genereren, bijv.
> database-dumps voor PostgreSQL/PostGIS en Oracle. Dit is geen
> verantwoordelijkheid van het Kadaster. De "markt" kan het prima
> oplossen. (Het Kadaster levert wel de data in FGDB uit, maar
> waarschijnlijk komt dat omdat dit een tussenproduct van hun eigen
> werkproces is.) O.a. op LinkedIn in de NL OpenData groep is hierover
> discussie gevoerd.
>
> Andere gotcha's zijn niet bewust:
> * Afkappen van velden: dit is iets wat ogr2ogr blijkt te doen. Hier is
> omheen te werken, door bijv. de GFS-bestanden te editen.
> * Niet-validerende GML: ik heb begrepen dat het Kadaster hier
> ondertussen van op de hoogte is. In april zou een goede versie moeten
> komen. (Kan geen linkje vinden.)
> * Sommige objecten zijn dubbel als je alles importeert. Dit komt omdat
> ze over de bladgrenzen heen liggen. Dat zullen we met de hand moeten
> oplossen, tenzij het Kadaster een set landsdekkende GML's gaat maken
> waar geen dubbelingen in voorkomen.
> Voor de rest moeten we zien waar het schip strandt ;)
>
>
Een andere gotcha waar ik bang voor was, nl. meertaligheid, zit ook in
Top10NL. Zie bestand 06west.gml.
<top10nl:GeografischGebied gml:id="nl.top10nl.103078931" >
<nen3610:identificatie>NL.TOP10NL.103078931</nen3610:identificatie>
<nen3610:objectBeginTijd>2008-11-24T00:00:00</nen3610:objectBeginTijd><nen3610:versieBeginTijd>2008-11-24T00:00:00</nen3610:versieBeginTijd>
<top10nl:naam xml:lang="nl">Leeuwarden</top10nl:naam>
<top10nl:naam xml:lang="fy">Ljouwert</top10nl:naam>
<top10nl:typeGeografischGebied >plaats, bewoond
oord</top10nl:typeGeografischGebied>
<top10nl:labelPunt><gml:Point
srsName='urn:opengis:def:crs:EPSG::28992'><gml:pos
srsDimension="2">182596.785
579147.489</gml:pos></gml:Point></top10nl:labelPunt>
<top10nl:brontype>top10vector</top10nl:brontype>
<top10nl:bronbeschrijving>TOP10vector 2004</top10nl:bronbeschrijving>
<top10nl:bronactualiteit>2004-01-01</top10nl:bronactualiteit>
<top10nl:bronnauwkeurigheid>2</top10nl:bronnauwkeurigheid>
<top10nl:dimensie>2D</top10nl:dimensie>
</top10nl:GeografischGebied>
De naam "Leeuwarden" komt ook in het Fries voor, Ljouwert (met
xml:lang="fy").
Frank
More information about the Talk-nl
mailing list