[OSM-talk-nl] NLExtract project

Just van den Broecke just at justobjects.nl
Mon Jan 23 21:24:24 UTC 2012


Frank,

Schakel net pas in: dank voor de heldere antwoorden hieronder.

groet,

Just

On 23-01-12 22:06, Frank Steggink wrote:
> 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
>
> _______________________________________________
> Talk-nl mailing list
> Talk-nl at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-nl
>
>




More information about the Talk-nl mailing list