Conversie sondeerdata :
GEF-CPT <--> BRO-XML (IMBRO of IMBRO/A)
GEF-CPT <--> BRO-XML (IMBRO of IMBRO/A)
Techniek
1 - Cone Penetration Test (CPT)
Bij een CPT test wordt een conus met sensoren met een constante snelheid (2 cm/s) de grond ingedrukt. Gedurende de beweging naar beneden word de data afkomstig van sensoren uiteindelijk geregistreerd in een "parent" GEF-CPT bestand. Voorbeelden van te meten grootheden zijn : temperatuur, waterdruk, puntweerstand, trilling, wrijvingsweerstand, geleidbaarheid, korrelstructuur en helling.
2 - Dissipatietest
De beweging van de sondeerstreng naar beneden kan worden gestopt i.v.m het uitvoeren van een dissipatietest. Hierbij word op een bepaalde diepte gedurende een bepaalde tijd waterdruk en conusweerstand geregistreerd. Per sondering zijn meerdere dissipatietesten mogelijk. Elke afzonderlijke dissipatietest word opgeslagen in een apart "child" GEF-CPT bestand. Tijdens het conversieproces worden "parent" en één of meerdere "child" bestanden automatisch verwerkt tot één BRO-XML bestand.
3 - Data acquisitie en besturing
Voor het uitvoeren van een Cone Penetration Test (mogelijk inclusief dissipatietest) word gebruik gemaakt van een microcontroller gebaseerd data-acquisitiesysteem. Een dergelijk systeem bestaat uit de volgende componenten :
| Onderdeel | Functie |
|---|---|
| Conus | Conussen voor sondering zijn uitgerust
met sensoren en elektronika. Bij analoge conussen is er sprake van conditioneringselektronika welke het mogelijk maakt relatief "kleine" signalen over langere afstanden door te geven. Digitalisering van die analoge data gebeurt bovengronds (datakoppelaar) door middel van een microcontroller gebaseerd systeem. Digitale conussen zijn uitgerust met een microcontroller in de conus zelf. De microprocessor is verantwoordelijk voor digitalisering van sensordata alsmede communicatie met de "bovenliggende" besturing. Analoge of digitale conussen zijn beide uitgerust met sensoren voor punt- en wijvingsweerstand (rekstrookjes), waterdruk (druksensor) en helling (capacitief of mechanisch). De analoge sensorsignalen worden "typical" met 24-bit resolutie en een sampling frequentie van 10 Hz gedigitaliseerd. Op basis van ingestelde calibratiegegevens bewerkt de microcontroller de ruwe data en stuurt deze in geval van een digitale conus naar "boven". |
| Communicatie | Voor de communicatie naar boven (hardware) zijn er in geval van een digitale conus meerdere mogelijkheden : CAN, RS485, optisch en audio. Elke methode heeft zijn eigen voor- en nadelen. In geval van bedrading word een kabel door de diverse sondeerbuizen getrokken. De "handling" van de buizen wordt hierdoor wel gecompliceerder. Het robuuste Controller Area Network (CAN) heeft o.a als voordeel t.o.v. RS485 dat transmissie fouten worden herkend en hersteld. Ook kan het multimaster CAN netwerk worden gekoppeld aan het reeds bestaande netwerk in vrachtauto's. De draadloze varianten (optisch en audio) hebben als nadeel dat er beperkingen zijn in connectiviteit, data-snelheid en data-betrouwbaarheid. Ook zijn beide laatstgenoemden nogal onderhoudsgevoelig. In verband hiermee is het maar zeer de vraag of de trend naar "draadloos" doorzet. Wanneer er sprake is van geautomatiseerde buizentoevoer dan moet toch de voorkeur worden gegeven aan een "bedraadde" realisatie. |
| Datakoppelaar | Deze eveneens microcontroller gebaseerde hardware ontvangt digitale meetgegevens van de digitale conus. In geval van een analoge conus vindt hier ook de digitalisering van analoge meetdata plaats. Deze gegevens worden gekoppeld aan de positie van de conus (diepte). De diepte word verkregen door een roterende encoder mechanisch te koppelen aan de sondeerstreng. De gekoppelde datastroom (meetwaarden en diepte) word via USB of RS232 doorgestuurd naar een desktop computer. Voor nauwkeurige vastlegging van de geografische positie is de datakoppelaar mogelijk uitgerust met een GPS ontvanger. |
| Desktop computer | Een desktop computer (bij voorkeur Linux) is met de datakoppelaar verbonden via een USB of RS232 poort. Het sondeerproces kan vanaf deze plaats worden gestart, gestopt of gepauzeerd. Ook kunnen diverse configuratie waarden voor conus en koppelaar hier worden ingesteld. Op de desktop wordt de ruwe meetdata verder verwerkt en "realtime" gevisualiseerd. De meetdata en aanvullende informatie worden ingekapselt in standaard formaten zoals GEF-CPT en BRO-XML. Voor externe toegankelijkheid is mogelijk web- of fileserver functionaliteit geinstalleerd. In dat geval kan na een sondering de data direkt worden aangeboden aan de BasisRegistratie Ondergrond (BRO). |
4 - Applicatie
De conversie software is ontwikkeld in C/C++. Vergeleken met geinterpreteerde talen als C#, Java of Python heeft een C/C++ gebaseerde oplossing een snelheidsvoordeel. Zoveel mogelijk is er gebruik gemaakt van open source software en tools. De uiteindelijke applicatie draait native op een Linux webserver (Ubuntu 24.04.1 LTS). De keuze voor Linux is gemaakt in verband met snelheid, stabiliteit en "realtime" eigenschappen.
5 - Conversie GEF-CPT naar BRO-XML
Alle benodigde gegevens worden door de gebruiker middels een HTML formulier aangeboden aan de Apache webserver. Na verzending zorgt CGI functionaliteit ervoor dat genoemde gegevens op de juiste plaats worden opgeslagen. Hierbij wordt ook een eerste controle uitgevoerd m.b.t. de juistheid van de aangeboden data.
Bij de verdere verwerking is gebruik gemaakt van technieken welke worden toegepast in de compilerbouw (compilatie, interpretatie, translatie). Een aangeboden GEF bestand word onderworpen aan een systematisch onderzoek. Na herkenning van woorden en structuren vind een semantische analyse plaats. Er wordt o.a gecontroleerd op volledigheid, tegenstrijdigheid en samenhang. Vervolgens vindt de eigenlijke vertaling plaats. Hierbij wordt een datamodel gevuld met data en metadata.
De informatie welke nu aanwezig is in het datamodel kan worden geexporteerd als een BRO-XML bestand. Dit bestand wordt tenslotte voor controle en validatie aangeboden aan een RESTfull API server van de BRO.
6 - Graphische representatie
Een GEF-CPT of BRO-XML bestand bevat alle noodzakelijke data (grootheden, eenheden, metadata en data) om een correcte grafische weergave te genereren. Al deze gegevens worden als vectoren weggeschreven naar één of meer pdf bestanden. Het Portable Document Formaat (pdf) is de defacto standaard voor uitwisseling van meetdata in grafiekvorm.
7 - Foutrapportage
Fouten of tekortkomingen in aangeleverde bestanden kunnen ertoe leiden dat een voltooien van de conversie niet mogelijk is. In een later gestuurde email word vermeld welke fouten zijn opgetreden en waarom de conversie niet is gelukt.
8 - Conversietijd
Het algehele conversieproces per sondering kan oplopen tot naar schatting 10 seconden. Bepaling van bijvoorbeeld het "soil behaviour type" is rekenintensief en kan een fors deel van de totale conversietijd in beslag nemen. De verwerkingstijd is naast de bestandsgrootte mede afhankelijk van factoren zoals webserver, RESTful API server, mailserver en internetsnelheid.
9 - Aanpassen conversie software
Het GEF-CPT formaat kan worden omschreven als "loosely typed". Tekst kan voorkomen op niet voor de hand liggende plaatsen. De volgorde van sommige "keywords" is belangrijk maar voor andere geldt dit niet. In sommige delen van het bronbestand mogen spaties worden genegeerd. Maar in andere delen juist weer niet. De verwerkingssoftware moet alle mogelijke combinaties herkennen en op de juiste manier verwerken. Het kan voorkomen dat in de testfase een bepaalde combinatie of structuur nog niet wordt herkend. Team www.cptdata.nl zal in dat geval de conversiesoftware aanpassen zodat een dergelijk geval in de toekomst wel op de juiste manier automatisch wordt verwerkt.
10 - Opmerkingen GEF-CPT versus BRO-XML
- In een GEF-CPT document mogen kolommen met data in elke volgorde voorkomen. De #COLUMNINFO nummers geven aan welke kolom correspondeert met welke meetwaarde. Voor iedere kolom wordt ook het meetkanaal gespecificeerd. In het BRO-XML formaat hebben kolommen een vaste volgorde. Het meetkanaal is niet aanwezig.
- In #SPECIMENVAR worden enkel de bovengrens van de verschillende verwijderde lagen gespecificeerd. In de BRO-XML wordt voor iedere verwijderde laag ook de ondergrens toegevoegd.
- De #FIRSTSCAN waarde is niet overgenomen.
- De #LASTSCAN waarde is niet overgenomen maar wel impliciet aanwezig in de meetdata.
- De #COLUMNMINMAX waarden zijn niet overgenomen maar wel impliciet aanwezig in de meetdata.
- Het totaal aantal aanwezige kolommen in #COLUMN is niet overgenomen maar wel impliciet aanwezig in de meetdata.
- Meetdata in bestaande BRO-XML bestanden bestaat uit een lange rij van numerieke waarden. Dit is niet erg overzichtelijk en daarom is in gegenereerde bestanden de data op een meer ordelijke manier gerangschikt. De originele kolomstructuur in het GEF-CPT formaat is overgenomen.
11 - Opmerkingen bestanden van de BasisRegistratie Ondergrond
- Sommige BRO-XML bestanden bestaan uit 1 lange regel. Dat geld ook voor de meetdata. Een gevolg hiervan is een moeilijke leesbaarheid.
- Datarijen BRO-XML bestanden zouden altijd in de juiste volgorde moeten staan. Dit is lang niet altijd het geval. Kolommen penetratielengte en verlopen tijd zijn niet altijd eenduidig oplopend. De BRO bevestigt dit probleem en heeft toegezegd daaraan te zullen werken.
- Soms is het element "zeroLoadMeasurement" wel aanwezig maar heeft geen child elementen. De validatiesoftware van het BRO-loket accepteert dit.
- Root element "dispatchDataResponse" heeft als childelement "dispatchDocument". Dit laatste element kan in aangeboden documenten element "CPT_O_DP" als child hebben. De validatiesoftware van het BRO-loket accepteert dit.
- SVG bestanden van de BRO zijn onjuist of onvolledig. Een "schaakbord" achtergrond zorgt ervoor dat grafiek en text niet duidelijk leesbaar zijn.
- Een gegenereerd pdf bestand bevat voor iedere meetparameter een grafische presentatie. Van iedere kolom wordt de resolutie berekend en gevisualiseerd. Bij hellingmetingen valt vaak op dat de resolutie niet in verhouding staat tot het meetbereik. Voorbeeld : een resolutie van 1 graad op een bereik van -1 tot +1 graad. Een dergelijke hellingmeting is niet zinvol. De BRO zegt zelf dat zij niet verantwoordelijk is voor dataintegriteit.
12 - Validatie
Bij een GEF-CPT naar BRO-XML conversie wordt het gegenereerde XML bestand (automatisch) aangeboden aan de validatieservice van de BRO. De BRO retourneert een testrapport met daarin informatie of het XML bestand voldoet aan de standaard. Met dit testrapport weet de aanvrager van de conversie of het gegenereerde XML bestand geschikt is voor inname door de BRO.
13 - Doorsturen gegevens naar de BRO
Bij voldoende belangstelling wil team www.cptdata.nl volautomatisch sondeerdata kunnen aanleveren aan de BRO. De keuze om een gegenereerd BRO-XML bestand direkt te deponeren bij de BRO kan dan door de gebruiker worden aangevinkt in het websiteformulier. Op deze manier wordt het gehele proces van conversie, validatie en levering in 1 transactie afgerond.
14 - Zelf gegevens aanleveren aan de BRO
Een sondeerbedrijf kan ook zelf data aanleveren bij de BRO. Hierbij word het bedrijf voor een bepaald project gemachtigd door de betreffende bronhouder (b.v. gemeente) en fungeert daarmee als dataleverancier. Er zijn twee mogelijkheden :
1 - Handmatig aanleveren via het bronhouder portaal. Na inloggen kunnen via deze website BRO-XML bestanden worden geupload naar de BRO.
2 - Volautomatisch aanleveren van BRO-XML bestanden door vanaf een client computer te communiceren met een RESTful API server van de BRO. Voor deze manier van communiceren is authentificatie vereist. Het instellen van een username en password is reeds eerder gebeurd via het bronhouderportaal. In alle communicatie met de RESTful API server worden beide "sleutels" gebruikt.
Samenvatting :
1 - Sondeerbedrijf maakt een account aan in het bronhouderportaal
2 - Sondeerbedrijf maakt onder genoemd account een username en password aan. Dit is noodzakelijk wanneer data word geleverd aan een RESTful API server
3 - Voor een project kan het sondeerbedrijf nu gemachtigd worden door een bronhouder. De bronhouder machtigt het sondeerbedrijf via zijn eigen account in het bronhouderportaal. Het sondeerbedrijf is nu dataleverancier.
4 - Het nu gemachtigde sondeerbedrijf kan sondeerdata leveren aan de BRO via zijn account of de RESTful API server
15 - Bronvermelding en links
Voor de totstandkoming van de conversie software zijn meerdere bronnen geraadpleegd. Hierbij de meest relevante :
