ONDERSTEUNEND
CENTRUM
Grootschalig Referentie Bestand
Testproject Herenthout-Bouwel Werkverslag
7 januari 2000 finale versie
werkverslag testproject
Inhoud Inhoud ___________________________________________________________________ 1 Inleiding __________________________________________________________________ 4 Hoofdstuk 1: fotogrammetrie _________________________________________________ 5 1. Inleiding ____________________________________________________________________ 5 2. Methode_____________________________________________________________________ 5 2.1. VOORBEREIDENDE TAKEN ________________________________________________________ 6 2.1.1. Bekendmaking van het project _____________________________________________________ 6 2.1.2. Opstellen van een vliegplan op schaal 1/4000 __________________________________________ 6 2.1.3. Signalisatie van paspunten ________________________________________________________ 6 2.1.4. Luchtopname __________________________________________________________________ 7 2.1.4.1. De vlucht __________________________________________________________________ 8 2.1.4.2. Kwaliteit van de fotoÕs ______________________________________________________ 8 2.1.4.3. Camera en objectief ________________________________________________________ 8 2.1.4.4. Films____________________________________________________________________ 8 2.1.4.5. De uitvoering _____________________________________________________________ 8 2.1.5. Controle van de luchtopname ______________________________________________________ 9 2.1.6. Scanning van diapositieven ________________________________________________________ 9 2.1.7. Opmeten van paspunten __________________________________________________________ 9 2.2. Ori‘ntatieprocedure ________________________________________________________________ 10 2.2.1. Inwendige ori‘ntaties ___________________________________________________________ 10 2.2.2. Relatieve ori‘ntaties ____________________________________________________________ 10 2.2.3. Blokvereffening _______________________________________________________________ 10 2.2.4. Absolute ori‘ntatie _____________________________________________________________ 11 2.3. Fotogrammetrische dataproductie _____________________________________________________ 11 2.3.1. De ondersteunende bestanden _____________________________________________________ 11 2.3.1.1. Hoogtegegevens ____________________________________________________________ 11 2.3.1.2. Orthofotoplans _____________________________________________________________ 11 2.3.2. Restitutie van het GRB-bestand ___________________________________________________ 12 2.3.2.1. Algemeen _________________________________________________________________ 12 2.3.2.2. Methodologie en conventies in GRB-verband _____________________________________ 12
3. Integratie van externe bestanden________________________________________________ 16 3.1. Cardib-data ______________________________________________________________________ 16 3.1.1. Overdracht van CARDIB-data ____________________________________________________ 16 3.1.2. Integratie van CARDIB-data______________________________________________________ 17 3.2. Middenschalige data _______________________________________________________________ 17
Hoofdstuk 2: topografie_____________________________________________________ 20 1. Inleiding ___________________________________________________________________ 20 2. Methode____________________________________________________________________ 20 2.1. Directorystructuur _________________________________________________________________ 21 2.2. Voorbereiding van de naverkenning____________________________________________________ 22 2.2.1. Bekendmaking van het project ____________________________________________________ 22 2.2.2. Data-input ____________________________________________________________________ 22 2.2.3. Normalisatie van bestanden_______________________________________________________ 22 2.2.4. Selecteren en opslaan van grondslagpunten __________________________________________ 23 2.2.5. Plotten van het fotokoppel________________________________________________________ 24 2.3. Eerste naverkenningsronde: inventarisatie _______________________________________________ 24 2.3.1. Terreinverkenning______________________________________________________________ 24 2.3.2. Conventies ___________________________________________________________________ 25 2.3.3. Informatiseren van alfanumerieke attribuutinformatie___________________________________ 27 2.3.3.1. Huisnummers ______________________________________________________________ 27 2.3.3.2. Type- en relatiecoderingen ____________________________________________________ 27
rsc000107av0.doc
1
werkverslag testproject 2.3.3.3. Straatnamen _______________________________________________________________ 30 2.3.4. Opstellen van een meetplan voor de tweede naverkenningsronde __________________________ 30 2.4. Tweede naverkenningsronde: opmetingen en verwerking ___________________________________ 31 2.4.1. Eigenlijke opmetingen __________________________________________________________ 31 2.4.2. Verwerking van de ruwe velddata __________________________________________________ 31 2.4.2.1. Gegevensuitwisseling tussen totaalstation en netwerk _______________________________ 31 2.4.2.2. Controle en gericht uitvoeren van correcties in meetbestand __________________________ 31 2.4.2.3. Verwerking in het topografisch pakket___________________________________________ 32 2.4.3. Normalisatie van opmetingsbestand ________________________________________________ 35 2.4.4. Integratie van opmetingen met overige tussentijdse bestanden ____________________________ 35 2.4.5. Oplevering van fotokoppel aan dataverwerking (gegevensuitwisseling) _____________________ 36 2.5. Opbouw grafische bestanden ______________________________________________________ 37 2.5.1. Gestandaarsiseerd restitutiebestand _________________________________________________ 37 2.5.2. Tussentijdse bestanden __________________________________________________________ 38 2.5.2.1. Huisnummers , straatnamen en type- en relatiecodering ____________________________ 38 2.5.2.2. Terrestrische opmetingen verwerkt in dg Dialog__________________________________ 38 2.5.3. Gestandaardiseerd naverkend bestand _______________________________________________ 38
Hoofdstuk 3: conversie van externe databanken _________________________________ 39 1. Inleiding ___________________________________________________________________ 39 2. Conversie van Cardib-bestanden voor de fotogrammetrie ___________________________ 39 2.1. Het conversieproces ________________________________________________________________ 39 2.1.1. Geometrie ____________________________________________________________________ 39 2.1.1.1. Beschrijving _______________________________________________________________ 39 2.1.1.2. Geautomatiseerde verwerking _________________________________________________ 40 2.1.1.3. Illustratie _________________________________________________________________ 43 2.1.2. De geregistreerde elementen ______________________________________________________ 44 2.1.2.1.Beschrijving _______________________________________________________________ 44 2.1.2.2. Geautomatiseerde verwerking _________________________________________________ 45 2.1.2.3. Illustratie _________________________________________________________________ 46 2.2. Werkomgeving____________________________________________________________________ 48 2.2.1. Directorystructuur ______________________________________________________________ 48 2.2.1.1. Plaats van de scripts _________________________________________________________ 48 2.2.1.2. Plaats van de input data ______________________________________________________ 48 2.2.1.3. Plaats van de output data _____________________________________________________ 48 2.2.2.Logicals ______________________________________________________________________ 48
3. Conversie van Cardib-bestanden voor de naverkenning _____________________________ 50 3.1. Het conversieproces ________________________________________________________________ 50 3.1.1. Beschrijving __________________________________________________________________ 50 3.1.2. Geautomatiseerde verwerking _____________________________________________________ 50 3.1.3. Illustratie _____________________________________________________________________ 51 3.2. Werkomgeving____________________________________________________________________ 52 3.2.1. Directorystructuur ______________________________________________________________ 52 3.2.1.1. Plaats van het script _________________________________________________________ 52 3.2.1.2. Plaats van de input data ______________________________________________________ 52 3.2.1.3. Plaats van de output data _____________________________________________________ 52 3.2.2. Logicals _____________________________________________________________________ 52
4. Vlaamse Hydrografische Atlas en Tele Atlas Streetnet ______________________________ 53 4.1. Het conversieproces ________________________________________________________________ 53 4.1.1. Beschrijving __________________________________________________________________ 53 4.1.2. Geautomatiseerde verwerking _____________________________________________________ 53 4.1.3. Illustratie _____________________________________________________________________ 54 4.2. Werkomgeving____________________________________________________________________ 55 4.2.1. Directorystructuur ______________________________________________________________ 55 4.2.1.1. Plaats van de scripts _________________________________________________________ 55 4.2.1.2. Plaats van de input data ______________________________________________________ 55 4.2.1.3. Plaats van de output data _____________________________________________________ 55 4.2.2. Logicals _____________________________________________________________________ 56
rsc000107av0.doc
2
werkverslag testproject Hoofdstuk 4: dataverwerking ________________________________________________ 57 1. Inleiding ___________________________________________________________________ 57 2. Werkomgeving ______________________________________________________________ 57 2.1 Directorystructuur __________________________________________________________________ 57 2.2 Naamgevingsconventie voor de softwaremodules__________________________________________ 59 2.3 Programmeeromgeving ______________________________________________________________ 59 2.4 Gebruiksomgeving _________________________________________________________________ 60
3. Verwerking van de gegevens van de fotogrammetrie________________________________ 60 3.1 Inleiding _________________________________________________________________________ 60 3.2 Input ____________________________________________________________________________ 60 3.3 Output ___________________________________________________________________________ 63 3.3.1. Gegevensbestanden voor de naverkenning ___________________________________________ 63 3.3.2. Coverages ____________________________________________________________________ 63 3.3.3. Statistieken ___________________________________________________________________ 63 3.4 Verwerking _______________________________________________________________________ 64 3.4.1. Conversie naar DXF-formaat _____________________________________________________ 64 3.4.2. Utilities ______________________________________________________________________ 71
4. Verwerking van de gegevens van de naverkenning _________________________________ 74 4.1 Inleiding _________________________________________________________________________ 74 4.2 Input ____________________________________________________________________________ 74 4.3 Output ___________________________________________________________________________ 75 4.3.1. Coverages ____________________________________________________________________ 75 4.3.2. Statistieken ___________________________________________________________________ 75 4.4 Verwerking _______________________________________________________________________ 75
5. Interactie met de databank ____________________________________________________ 78 5.1 Inleiding _________________________________________________________________________ 78 5.2 Input ____________________________________________________________________________ 78 5.3 Output ___________________________________________________________________________ 78 5.4 Verwerking _______________________________________________________________________ 78
Kritische beschouwingen____________________________________________________ 79 1. Inleiding ___________________________________________________________________ 79 2. Fotogrammetrie _____________________________________________________________ 79 3. Topografie __________________________________________________________________ 79 4. Wisselwerking fotogrammetrie-topografie ________________________________________ 80
rsc000107av0.doc
3
werkverslag testproject
Inleiding Om het GRB-concept te toetsen en verder uit te werken, is het Ondersteunend Centrum GIS Vlaanderen in mei 1998 gestart met een eigen testproject. Onderhavig document bevat een neerslag van de gehanteerde methodes en is een mogelijke leidraad bij de uitvoering van de pilootprojecten. Er zijn drie modules te onderscheiden voor de invoer van data: fotogrammetrie, topografie en conversie van externe databanken. Ze worden achtereenvolgens besproken in de hoofdstukken 1, 2 en 3. Een vierde hoofdstuk bevat de module dataverwerking. Deze module staat in voor de uitwisseling van data tussen de eerder genoemde modules onderling en voor de interactie met de databank. Schematisch kan men dit voorstellen als volgt:
Fotogrammetrie
Topografie
Externe databanken
Dataverwerking
GRB BESTEK DATABANK
rsc000107av0.doc
4
werkverslag testproject
Hoofdstuk 1: fotogrammetrie 1. Inleiding De fotografische luchtopname van het testproject Herenthout-Bouwel werd uitgevoerd op 8 mei 1998. De te fotograferen oppervlakte bestaat uit 10 vliegassen en 197 diapositieven en bedraagt 4989 ha. De initi‘le uitvoeringstermijn voor luchtopnamen begrepen tussen 15/02/1998 en 30/04/1998 werd in het kader van dit testproject bij wijze van uitzondering en omwille van niet geschikte weersomstandigheden verlengd tot 15/05/1998. Na controle is gebleken dat, ondanks de dichtere begroeiing, de diapositieven van goede kwaliteit en dus bruikbaar zijn. Ten behoeve van de implementatie van het GRB Conceptueel Datamodel werden er binnen het testproject slechts 9 fotokoppels voor restitutie geselecteerd. Hierbij werd er een onderscheid gemaakt tussen stedelijk, voorstedelijk en landelijk gebied. De ondersteunende bestanden, met name het hoogtemodel en het orthofotobestand, werden gebiedsdekkend aangemaakt.
2. Methode In de gevolgde methode zijn drie delen te onderscheiden, nl. de voorbereidende taken, het ori‘ntatieproces en de dataproductie. In onderstaande figuur wordt het fotogrammetrische productieproces schematisch voorgesteld.
rsc000107av0.doc
5
werkverslag testproject 2.1. VOORBEREIDENDE TAKEN 2.1.1. Bekendmaking van het project Voor de uitvoering van meerdere projectfasen waaronder signalisatie van punten, opmeten van basispunten, naverkenning, e.a. is terreinverkenning van het projectgebied vereist. Bij de aanvang van het te realiseren GRB-project wordt schriftelijk aan de gemeente gemeld wanneer en welke terreinwerkzaamheden er zullen plaatsgrijpen. 2.1.2. Opstellen van een vliegplan op schaal 1/4000 Het projectgebied wordt digitaal of analoog afgebakend op basis van een NGI-kaart met een schaal van maximaal 1/25000. Vliegassen en fotocentra worden erop aangeduid, rekening houdend met het feit dat het gebied volledig in stereoscopie moet kunnen worden behandeld. De overlapping tussen fotoÕs bedraagt 60 % en tussen de vliegstroken 30 %. De vliegassen zijn gelegen volgens een OostWest of Noord-Zuid richting. Op de onderstaande foto wordt bij wijze van voorbeeld een vluchtplan ge•llustreerd. De gesignaliseerde punten (zie verder) werden tevens erop aangeduid.
2.1.3. Signalisatie van paspunten Het signalisatieplan (al dan niet hetzelfde als het vliegplan) wordt voorafgaandelijk aan de vlucht opgesteld. Het bevat een overzicht van de locaties waar een paspunt zal worden gesignaliseerd. Er wordt een terreinbezoek gebracht aan het projectgebied met als doel paspunten te: ·
Signaliseren: bestaande wegmarkeringen worden weerhouden, nieuwe markeringen worden aangebracht;
·
Materialiseren: zo mogelijk wordt de ligging van het punt met een klinknagel of vastgelegd;
·
Illustreren: de ligging van het punt in zijn omgeving wordt op foto of schets vastgelegd. Later bij de fotogrammetrische verwerking zijn ze aldus makkelijker terug te vinden.
schroef
Voor de lokalisatie van deze punten wordt rekening gehouden met: ·
Een homogene verspreiding over het gebied;
·
Een goede omsluiting van het blok. Net buiten de begrenzing van het blok worden tevens punten opgemeten;
rsc000107av0.doc
6
werkverslag testproject ·
Een dichtheid van +/- 1 punt per 3 fotoÕs;
·
De toegankelijkheid met GPS-apparatuur.
Toegankelijkheid met GPS-apparatuur betekent dat de geselecteerde punten: ·
Een vrije horizont hebben boven de 12;
·
Stationeerbaar zijn voor GPS-apparatuur;
·
Uit de omgeving van reflecterende objecten zijn gelegen;
·
Op een verkeersveilige plaats voorkomen.
Op de twee onderstaande fotoÕs wordt de signalisatieopdracht ge•llustreerd.
2.1.4. Luchtopname De volgende technische specificaties zijn voor de uitvoering van een luchtopname tijdens de voorjaarsperiode en op schaal 1/4000 van toepassing.
rsc000107av0.doc
7
werkverslag testproject 2.1.4.1. De vlucht ·
De luchtopnamen worden uitgevoerd tussen 15/02/99 en 30/04/99;
·
De luchtopname gebeurt op de uitgekozen dag steeds tussen 10u in de voormiddag en 15u in de namiddag;
·
Een vliegplan wordt opgemaakt door de aannemer;
·
De dwarsoverlapping tussen de opeenvolgende evenwijdige banden bedraagt 30% met een tolerantie van 5%;
·
De langsoverlapping tussen de opeenvolgende fotoÕs van een zelfde band bedraagt 60% met een tolerantie van 3 ˆ 4%;
·
De schaal van de opnamen bedraagt 1/4000;
·
De absolute vlieghoogte bedraagt 1200m. De werkelijke absolute vlieghoogte zal niet meer dan 10% afwijken van de theoretische 1200m;
·
Er wordt een overzichtsplan van de luchtopname opgemaakt;
·
De fotoÕs worden verticaal genomen met een tolerantie van 4¡ t.o.v. de verticale as. Het verschil in afwijking t.o.v. de verticale as tussen twee opeenvolgende fotoÕs zal steeds kleiner zijn dan 4¡;
·
De drifthoek van de fotoÕs moet kleiner zijn dan 5¡ (krabeffect).
2.1.4.2.
Kwaliteit van de fotoÕs
·
De fotoÕs dienen overal scherp te zijn, zowel in het midden als in de hoeken en de merktekens. Ze zijn nergens overbelicht noch onderbelicht;
·
De fotoÕs moeten vrij zijn van wolken en schaduwen van wolken. De fotoÕs mogen niet genomen worden onder een homogeen wolkendek;
·
De beelden zijn vrij van laag frequente ruis te wijten aan nevel of haze;
·
Op de rand van de fotoÕs zijn minstens de volgende gegevens duidelijk af te lezen: uur, vlieghoogte, volgnummer van de foto, objectiefnummer en brandpuntsafstand.
2.1.4.3.
Camera en objectief
·
Er wordt een volledig calibratierapport gemaakt dat naast de datum ook de volgende elementen bevat: cameratype, type en nummer van het objectief, opening, filters, brandpuntsafstand, radiale distortietabel, fotografische resolutie, positie van het autocollimatiehoofdpunt, het symmetriehoofdpunt en de merktekens;
·
De brandpuntafstand is +/- 300 mm. Het formaat is 23 cm bij 23 cm;
·
De camera is uitgerust met een Forward Motion Compensation (FMC) systeem of een vergelijkbaar systeem.
2.1.4.4.
Films
·
De luchtopnames worden uitgevoerd met een kleurdiapositief film;
·
De film wordt zo snel mogelijk na de vlucht ontwikkeld (max. 72 uur);
·
De films mogen geen onregelmatige uitrekking of inkrimping vertonen van meer dan 10 micron noch ontwikkelingsfouten vertonen;
·
De films worden verknipt. De diapositieven worden in hoezen geleverd.
2.1.4.5.
De uitvoering
·
Een project wordt bedekt door ŽŽn enkele luchtopname. Combinatie van luchtopnames voor de bedekking van het grondgebied van ŽŽn project worden niet aanvaard;
·
In geval een vlucht door het OC wordt afgekeurd, verplicht de aannemer zich ertoe om de vlucht op eigen kosten over te doen tijdens de vastgestelde uitvoeringstermijn;
·
De uitvoering van luchtopnamen door de inschrijver voor zichzelf of derden mag geenszins gebeuren ten koste van de uitvoering van deze voor het OC binnen de gevraagde uitvoeringstermijn;
rsc000107av0.doc
8
werkverslag testproject ·
Indien, wegens een of andere reden, in voorkomend geval grondig door de inschrijver te verantwoorden en te staven, ŽŽn of meerdere vluchten niet in de opgegeven uitvoeringstermijn kunnen worden gefotografeerd, beschikt het OC over de vrije keuze om ofwel het betreffende deel van de bestelling te annuleren en in evenredigheid minder te betalen, ofwel de uitvoeringstermijn te verlengen of de uitvoering naar dezelfde periode van het volgende jaar te verwijzen. De verbintenis, aangegaan door de inschrijver onder F2, blijft geldig in de verlengde of nieuwe termijn. In geen van de drie gevallen kan de inschrijver bijkomende kosten aanrekenen aan het OC.
2.1.5. Controle van de luchtopname De vlucht wordt door het OC GIS-Vlaanderen gecontroleerd. De originele diapositieven en het vluchtplan worden aan het OC overgemaakt en binnen een termijn van 15 werkdagen wordt door het OC nazicht verricht inzake: ·
Geometrie van de vlucht;
·
Kwaliteit van de diapositieven;
·
Schaal van de luchtopname;
·
Te fotograferen oppervlakte.
Het advies over de luchtopname, goedkeuring of afkeuring, wordt schriftelijk aan de aannemer overgemaakt. Wat betreft de eigendomsrechten van de oorspronkelijke diapositieven, is het OC GIS-Vlaanderen de exclusieve eigenaar van dit bronmateriaal. 2.1.6. Scanning van diapositieven In het geval van digitale fotogrammetrie wordt uitgegaan van digitale luchtfotoÕs. Afgezien van de tussenstap scanning van luchtfotoÕs, blijft het productieproces met de analytische fotogrammetrie verder ongewijzigd. Er wordt gebruik gemaakt van een hoge precisiescanner geschikt voor het inscannen van diapositieven, waarbij de geometrische vervorming in de x- en y Ðrichting minimaal is, d.w.z. de RMS error < 2 micrometer. Voor het scannen van de originele diapositieven zijn de volgende specificaties van toepassing: ·
Alle merkpunten op de randen van het diapositief worden mee ingescand;
·
De resolutie bedraagt 850 dpi ( 30 micron);
·
Het uitvoerbestand is een 24-bit RGB beeld.
De gescande diaÕs worden geplaatst op CD-ROM in MrSid-formaat samen met de freeware viewer van het pakket MrSid, Lizard Tech Company. Zie ook GRB Conceptueel Datamodel versie 3.1. hoofdstuk 5 Ôcatalogus van ondersteunende bestandenÕ. 2.1.7. Opmeten van paspunten De basispunten worden met het Global Positioning System (GPS) opgemeten via de Rapid Static meetmethode. Deze methode is perfect geschikt voor het opmeten van individuele, ver uit elkaar gelegen paspunten, zonder rekening te moeten houden met hun onderlinge zichtbaarheid. Door het gebruik van differenti‘le GPS zullen de paspunten tot op centimeter-niveau nauwkeurig zijn. In eerste instantie worden de ligging en cošrdinaten van de nabijgelegen NGI-punten (een fiche per punt) geselecteerd en opgevraagd bij het Nationaal Geografisch Instituut (NGI), Dienst Geodesie. De opmeting van de paspunten en de NGI-punten gebeurt in het WGS-84 cošrdinatensysteem. De opmeting wordt getransformeerd naar een lokaal assenstelsel (cartesische cošrdinaten), dat dan op haar beurt wordt getransformeerd naar het Lambert 72/50 assenstelsel, aan de hand van de gekende NGI-punten. Finaal wordt een puntenlijst verkregen met X, Y en Z-cošrdinaten in de Belgische Lambert 72/50 projectie en op basis van de TAW voor de hoogte.
rsc000107av0.doc
9
werkverslag testproject 2.2. ORIèNTATIEPROCEDURE Voor het genereren van fotogrammetrische uitvoerbestanden (zie verder), dienen er relaties te worden gelegd tussen de afzonderlijke fotoÕs (een set van diapositieven is het eindresultaat van de luchtopname) enerzijds en het terreinstelsel anderzijds. Het fotogrammetrisch blok dient zoals dat tijdens de opname bestond, rekenkundig te worden gereconstrueerd. De ori‘ntatiestappen (aerotriangulatie) en de blokvereffening, hierna beschreven, zijn voor de reconstructie verantwoordelijk. 2.2.1. Inwendige ori‘ntaties De inwendige ori‘ntatieprocedure bestaat uit het opmeten van randmerken (fiducials) en deze te laten corresponderen met de fotocošrdinaten van de randmerken opgenomen in het cameracalibratierapport. De aannemer die de luchtopname heeft uitgevoerd, stelt het betreffende camera calibratierapport ter beschikking. Bij de uitvoering van de inwendige ori‘ntatie per foto worden de volgende regels in acht genomen: ·
Alle randmerken worden opgemeten;
·
De waarde van de kwadratisch middelbare fout (sigma) bedraagt maximaal 5;
·
De maximale afwijking (residual) per individueel randmerk bedraagt 10 micron.
2.2.2. Relatieve ori‘ntaties Deze stap en de hierop volgende in de ori‘ntatieprocedure kunnen sinds kort ook automatisch worden uitgevoerd. Onafhankelijk van de wijze van uitvoering is het tijdens de relatieve ori‘ntatie de bedoeling om in de overlappende zone tussen fotoÕs, verbindingspunten op te meten. De parallax die voorkomt tussen de punten gelegen op twee verschillende fotoÕs wordt uitgeschakeld. Er ontstaat stereoscopie binnen het fotopaar. Bij de uitvoering van de relatieve ori‘ntatie per fotopaar moeten de volgende regels in acht worden genomen: ·
In de gemeenschappelijke zone tussen fotoÕs van 60 %, worden minimaal 12 verbindingspunten opgemeten;
·
In de overlappende zone tussen stroken van 30 %, worden minimaal 8 punten opgemeten;
·
De verbindingspunten liggen volgens onderstaand patroon over de fotoÕs verspreid;
·
De standaardafwijking per opgemeten verbindingspunt bedraagt maximaal 10 micron;
·
Per fotokoppel ligt de waarde van de kwadratisch middelbare fout (sigma) niet hoger dan 5.
Tijdens de fase van aerotriangulatie is het interessant te beschikken over kleurenkopies van de originele diapositieven. Zij kunnen immers als hulpmiddel gebruikt worden bij de voorbereiding van de blokvereffening. Op de kleurenkopies worden de overlappende zones tussen aangrenzende fotoÕs aangeduid, evenals de verbindingspunten en de paspunten. 2.2.3. Blokvereffening Doel: verdichting van de grondslag ten behoeve van de realisatie van fotogrammetrische uitvoerbestanden. Na de relatieve ori‘ntatie volgt een berekening, de blokvereffening genoemd, die ervoor zorgt dat het volledige blok bij het terreinstelsel aansluit ( Lambert 72/50 en TAW-stelsel).
rsc000107av0.doc
10
werkverslag testproject Bedoeling is om het fotogrammetrisch blok te kunnen ori‘nteren aan de hand van enkele gekende punten, met name de paspunten opgemeten op het terrein met GPS. Van alle punten, zowel de pasals de verbindingspunten, werden fotocošrdinaten bepaald. De transformatie om van fotocošrdinaten naar terreincošrdinaten over te gaan, berekend voor de paspunten, wordt finaal toegepast op alle punten. Na blokvereffening bekomt men naast de terreincošrdinaten van de paspunten ook deze van de verbindingspunten. Met de volgende instellingen wordt de blokvereffening opgestart: ·
De standaardafwijking voor de individuele verbindingspunten bedraagt maximaal 10 micron;
·
De standaardafwijking op de paspunten bedraagt 12 cm in de x- en y-richting en 18 cm in de zrichting;
·
De sigma waarde is afhankelijk van de inwinningsmethode en de gekozen verbindingspunten. Voor analytische toestellen geldt dat sigma begrepen is tussen 4 en 12 micron. In het geval van digitale toestellen is de waarde begrepen tussen 3 en 10 micron;
·
Een rapport met de resultaten van de berekening wordt opgesteld. De volgende gegevens worden erin opgenomen: ·
Een lijst van de verbindingspunten gegroepeerd per foto met fotocošrdinaten en residuele waarden;
·
Een lijst van de paspunten per foto met fotocošrdinaten en residuele waarden;
·
Statistieken over de berekeningsprocedure zelf (iteratiestappen, sigma per iteratie, É);
·
Een lijst per foto met de berekende cošrdinaten en residuele waarden van de opgemeten punten;
·
Een lijst per foto met de resultaten (omega, phi, kappa) en de x-, y-, z-cošrdinaten van de fotomiddens van de uitwendige ori‘ntaties;
·
Een ASCII-lijst met de berekende cošrdinaten in Lambert 72/50 van alle punten.
2.2.4. Absolute ori‘ntatie Van het volledige stereomodel worden de fotocošrdinaten in terreincošrdinaten omgezet. Aan de volgende voorwaarden wordt voldaan: ·
Per stereokoppel bedraagt de RMS-fout in de x- en y-richting 12 cm en in de z-richting 18 cm;
·
De maximale afwijking per punt mag 15 cm bedragen in de x- en y-richting en 20 cm in de zrichting.
2.3. FOTOGRAMMETRISCHE DATAPRODUCTIE In het kader van het GRB-pilootproject worden 2 typen van uitvoerbestanden gegenereerd, met name: ·
De ondersteunende bestanden, zijnde de hoogtegevens en de orthofotoplans;
·
Een vectorbestand per stereokoppel met de gerestitueerde topografie conform het GRB Conceptueel Datamodel versie 3.1.
2.3.1. De ondersteunende bestanden
2.3.1.1. Hoogtegegevens Er wordt een digitaal hoogtemodel (DHM) aangemaakt waarvan de puntendichtheid 50*50m bedraagt. Het gaat om een onregelmatig raster van punten gelegen ter hoogte van het maaiveld. Terreinobstructies zoals water, gebouwen, bomenrijen, e.a. worden uitgesloten. Het originele DHM wordt onderworpen aan een kwaliteitscontrole (zie inspectieprocedure). Wat betreft het bestandstype (TIN), het formaat en de naamgeving wordt verwezen naar het GRB Conceptueel Datamodel versie 3.1., hoofdstuk 5, paragraaf 5.4. ÔhoogtegegevensÕ.
2.3.1.2. Orthofotoplans OrthofotoÕs worden aangemaakt op basis van het hierboven vermelde DHM. Er wordt een TIN-model en daaruit een rastermodel (regelmatig puntenraster) van 15*15m uit afgeleid.
rsc000107av0.doc
11
werkverslag testproject Er wordt 1 orthofoto per foto gemaakt. De resolutie wordt hierbij teruggebracht van 12cm naar 20cm. Vervolgens worden de orthofotoÕs gemoza•ekeerd en versneden op basis van een vierkantennet van 500m * 500m. Specificaties omtrent de beeldparameters, de bestandsorganisatie en de naamgeving zijn terug te vinden in het bestek versie 3.1, hoofdstuk 5, paragraaf 5.3. ÔorthofotoplansÕ. 2.3.2. Restitutie van het GRB-bestand
2.3.2.1. Algemeen Bij deze vorm van kartering wordt stereoscopisch gemeten waardoor in vergelijking met een ŽŽnbeeldkartering, de zichtbaarheid beter is en de interpretatie van objecten in het terrein eenvoudiger wordt. Het resultaat is een bestand met x-, y- en z-cošrdinaten voor de gekarteerde punten. Het doel bestaat erin om het terrein in landelijk en stedelijk gebied te karteren. In deze context kan fotogrammetrische kartering aanzien worden als een alternatief voor terrestrische opmetingen. Net zoals bij de terrestrische opmetingen, resulteert de fotogrammetrie niet in een volledig bestand. Bepaalde elementen van het terrein zijn op de fotoÕs immers niet zichtbaar (fotografische schaduw, zonneschaduw, nevel, É). De fotogrammetrische resultaten worden daarom doorgegeven aan de module topografie. Door middel van naverkenning wordt het digitaal bestand bijgewerkt met de gegevens die op het terrein verzameld worden. Vooral in bebost en verstedelijkt gebied zal de inspanning, vereist voor naverkenning, aanzienlijk oplopen. Randvoorwaarden voor een goede kartering zijn: een succesvolle voltooiing van de fotovlucht, de triangulatie en de blokvereffening. De precisie van de meting is in feite afhankelijk van volgende factoren: ·
De interpreteerbaarheid van een object op foto;
·
De fotoschaal;
·
De kwaliteit van de fotografie;
·
De kwaliteit van scanning;
·
De precisie van de opgemeten paspunten;
·
De resultaten van de blokvereffening.
2.3.2.2. Methodologie en conventies in GRB-verband Op basis van het GRB Conceptueel Datamodel versie 3.1, wordt binnen de fotogrammetrische werkomgeving een aangepaste datastructuur opgebouwd. Zowel bij de analytische als de digitale fotogrammetrie wordt de restitutie in een CAD-omgeving, met aangepaste softwarepakketten zoals ÒMicrostationÒ, ge•ntegreerd. De data worden doorgaans in een lagenstructuur opgeslagen. Elke GRBentiteit (zie bestek versie 3.1, hoofdstuk 3 ÔgegevensspecificatiesÕ) komt dan overŽŽn met ŽŽn laag. Verder kunnen de objecten grafisch van elkaar worden onderscheiden op basis van hun kleur, lijnstijl en lijndikte. Bij wijze van voorbeeld is hier de ÒelemententabelÓ toegevoegd die aangewend werd voor de realisatie van het testproject Herenthout-Bouwel. level
code
inhoud
color
style
weight
Inbreng CARDIB (niet in output) 1
Cardib
gevel-nodes
2
0
5
groen
2
Cardib
riooldeksels
3
0
5
rood
3
Cardib
huisnummer
0
text
0
wit
4
Cardib
electriciteitspaal (verlichting)
0
0
5
wit
10
gbw
dakrand
3
0
0
rood
rsc000107av0.doc
12
werkverslag testproject 11
gbn
dakoversteek
3
1
3
rood
12
gbb
constructiegevel
51
0
0
donker rood
13
gbbn
Cardib BB01
51
1
3
donker rood
14
ogb
Cardib BB05, IGAO, BB10
3
3
0
rood
15
*
Cardib terugplaatsing
3
0
0
rood
16
gba
gebouw aanhorigheid
101
0
0
donker purper
17
knw
kunstwerk
2
0
0
groen
18
knwn
kunstwerk met naverkenning
2
1
3
groen
20
wbn
wegsectie
47
0
0
licht blauw
21
wbnn
wegsectie met naverkenning
47
1
3
licht blauw
22
wbnk
kruispuntzone
95
0
0
grijs blauw
23
wbnkn
kruispuntzone met naverkenning
95
1
3
grijs blauw
25
wvb
wegverbinding
4
0
0
geel
27
wkn
wegknoop
4
pointcel
0
geel
28
spb
spoorbaan
13
0
0
purper
29
spbn
spoorbaan met naverkenning
13
1
3
purper
30
woz
weg onverharde zone
50
0
0
donker groen
31
wozn
weg onverharde zone met naverkenning
50
1
3
donker groen
32
wcz
zwakke weggebruikerszone
5
0
0
purper
33
wczn
zwakke weggebruikerszone met naverkenning
5
1
3
purper
37
wli4
longitudinale weginrichting > 1meter in wcz
6
4
0
oranje
38
wli3
longitudinale weginrichting vangrail
6
3
0
oranje
39
wli2
longitudinale weginrichting vangmuur
6
2
0
oranje
40
wli
longitudinale weginrichting
6
0
0
oranje
41
wlin
longitudinale weginrichting met naverkenning
6
1
3
oranje
42
wti
transversale weginrichting
70
0
0
bruin
43
wtin
transversale weginrichting met naverkenning
70
1
3
bruin
45
trn
terrein
125
0
0
donker purper
46
trnn
terrein met naverkenning
125
1
3
donker purper
47
wrl
spoorrails
9
0
0
grijs
48
wrln
spoorrails met naverkenning
9
1
3
grijs
49
wga
wegaanhorigheid
11
0
0
vuil groen
rsc000107av0.doc
13
werkverslag testproject 50
rio
riooldeksel
4
pointcel
0
geel
51
paal1
elec-tele-licht-verkeerslicht
0
pointcel
0
wit
57
kraan
brandkraan
3
pointcel
0
rood
58
txt
kenmerken terrein
t
0
text
0
wit
01
verhard
01 verkeer
0
t##-##
0
wit
02
onverhard/onbegroeid 02 ingericht groen
0
t##-##
0
wit
03
begroeid gras
0
t##-##
0
wit
04
begroeid kruidachtig
04
militair
0
t##-##
0
wit
05
begroeid houtig
05
braakliggend
0
t##-##
0
wit
06
begroeid gemengd
burgerlijk
0
t##-##
0
wit
exploitatie
0
t##-##
0
wit
0
text
0
wit
03
natuur
06 07
txt
kenmerken wegaanhorigheden
w
01
bushokje
0
w##
0
wit
02
telefoonhokje
0
w##
0
wit
03
overdekte fietsstalling
0
w##
0
wit
04
verkeerscabine
0
w##
0
wit
05
bergplaats
0
w##
0
wit
txt
actor a, b, I, s, w
entiteit
0
text
0
wit
I
ingericht kunstwerk
01 gedragen
0
#0#
0
wit
a
wegas
02 overbrugde
0
#0#
0
wit
b
wegbaan
03 doorgelaten
0
#0#
0
wit
s
spoorbaan
04 opgehouden
0
#0#
0
wit
r
wateras
0
#0#
0
wit
0
text
0
wit
txt
kunstwerk
05 ingerichte k
1
overbrugging
0
text
0
wit
2
waterstaatkundig werk (sluis)
0
text
0
wit
3
waterkerende constructies
0
text
0
wit
4
cultuurhistorisch monument
0
text
0
wit
5
hoogspanningsmast
0
text
0
wit
6
pijler
0
text
0
wit
7
rooster
0
text
0
wit
8
schoorsteen
0
text
0
wit
9
koeltoren
0
text
0
wit
10
silo /c conglomeraat
0
text
0
wit
rsc000107av0.doc
14
werkverslag testproject 11
elektriciteitscabine
0
text
0
wit
12
watertoren
0
text
0
wit
garagetoegang
standaardlabel
g0
binnenkoer
0
text
0
wit
g1
trap
0
text
0
wit
g2
loopbrug
0
text
0
wit
g3
onderkeldering
0
text
0
wit
g4
afdak
0
text
0
wit
52
wtg
watergang onverharde oevers
1
0
0
blauw
53
wtg2
watergang afwisselend verharde oevers
1
0
1
blauw
54
wtg3
watergang verharde oevers
1
0
2
blauw
60
prbl
probleemgebied
120
1
3
grijs
61
wtgn
watergang met naverkenning
1
1
3
blauw
62
was
as van geregistreerde waterloop
57
4
3
blauw
63
spl
splitsing per koppel
14
0
0
grijs
Teneinde de restitutie vlot te laten verlopen, kunnen de dataspecificaties, d.w.z. een object per laag met zijn specifieke grafische kenmerken en grafische vorm (lijn, punt, shape, É) worden opgeslagen in ÒpulldownÓ menu's. Een klik op de gepaste menuknop volstaat om met de restitutie van een bepaald terreinelement van start te gaan. Het stereokoppel is de basiseenheid voor de module fotogrammetrie. Een afgewerkt stereokoppel wordt nadien verwerkt tot een topologisch opgekuist GIS-bestand (module dataverwerking) en vervolgens door de module topografie naverkend. Bij de restitutie van een stereokoppel worden de volgende deeltaken doorlopen: ·
Afbakeningen, grenslijnen (gesloten omtrek waarbinnen gerestitueerd werd) uit vorige stereokoppels overnemen;
·
Eventueel integratie van externe data (CARDIB, e.a.);
·
Restitutie van het wegennet (assen en knooppunten);
·
Restitutie van de wegbanen (kruispuntzones en wegsecties);
·
Restitutie van de grenzen van de wegopdeling;
·
Restitutie van weginrichtingselementen;
·
Restitutie van inrichtingselementen;
·
Restitutie van andere themaÕs;
·
Afbakening van het stereokoppel.
Met uitzondering van de lijn- en puntobjecten, worden de objecten onder de vorm van gesloten veelhoeken opgeslagen. Dit gebeurt d.m.v. snappen op het dichtstbijzijnde punt. Vooraf worden de parameters voor snapping, waaronder de afstand, ingesteld. Waar snapping niet mogelijk is, worden er overshoots tot 1 meter, gecre‘erd. Deze worden nadien, in de fase van dataverwerking, automatisch verwijderd. Het restitutiebestand wordt in feite opgekuist. Bij de restitutie van een volgend stereokoppel worden de grenslijnen, afbakeningen van de gerestitueerde zones, van de vorige koppels overgenomen. Om de objecten uit naburige stereokoppels te herkennen worden deze stereokoppels op de achtergrond opgeroepen (referencefiles). Voor de restitutie van elementen gelegen in de rand van het nieuwe koppel zal, waar nodig,
rsc000107av0.doc
15
werkverslag testproject gezorgd worden voor een perfecte aansluiting op deze grenslijn. Als dusdanig wordt een naadloze aanŽŽnsluiting van de restitutiebestanden verkregen. Wat betreft de naamgeving van het restitutiebestand wordt een voorstel geformuleerd waarbij de naam is samengesteld uit de volgende codes: ·
Projectnummer;
·
Nummer van het stereokoppel zoals gespecificeerd in de ori‘ntatieprocedure.
Vb : 1_342_341.dgn. Dit restitutiebestand heeft betrekking op het stereokoppel 342_341, dat deel uitmaakt van het project met nummer 1. De restitutie werd gerealiseerd met behulp van het pakket ÓMicrostationÒ vandaar de extensie Ó.dgnÓ.
3. Integratie van externe bestanden 3.1. CARDIB-DATA Indien er van de betreffende gemeente CARDIB-gegevens werden opgebouwd, worden deze door het OC GIS-Vlaanderen ter beschikking gesteld van de aannemer. In feite wordt een uitgefilterde dataset overgemaakt. Tijdens de fotogrammetrische verwerking, worden de CARDIB-gegevens in het GRBbestand ge•ntegreerd. Dit impliceert onder meer het controleren en editeren van de gegevens in functie van de specificaties opgenomen in het GRB Conceptueel Datamodel versie 3.1. 3.1.1. Overdracht van CARDIB-data De volgende Òlayers en blocksÓ worden uit CARDIB geselecteerd: ·
Snappunten, aansluitingspunten op gevels (B999);
·
Riooldeksels (BR06 of B998);
·
Huisnummers (B997);
·
Palen (BR12 of B996);
·
Voorgevels (BB01);
·
Dakrand fotogrammetrisch gemeten (BB05);
·
Fotogrammetrische achtergevel (BB10);
·
Rand van de rijbaan (BR01);
·
Rand onverharde weg (BR02);
·
Bruggen (BR03);
·
As van de weg (BR05);
·
Verharde oever (BR07);
·
Masten (BR10);
·
Sporen (trein, tram, kraan) (BT01);
·
Rand van water (BW01);
·
As van gracht (BW02).
rsc000107av0.doc
16
werkverslag testproject De gegevens worden verwerkt tot een bruikbare lagenstructuur en als volgt ter beschikking gesteld aan de fotogrammetrische aannemer: Cardib-object
Datalaag fotogrammetrie
GRB-entiteit
B999 B998 B997 B996 BW01 BW02 BR07 BT01 BB01 BB05, BB10 Restitutie van BB01 BR03 BR10 BR05 BR02 BR01
1 2 3 4 5 6 7 8 13 14 15 17 17 25 30 32
gbv wri adr wpi wtg wtl wtg wrl gbg gbg gbg knw knw wvb woz wcz
Op te merken valt dat de lagen van 1 tot en met 9, voorbehouden worden om externe gegevens tijdelijk in op te slaan. Deze elementen worden in het GRB eindbestand van de fotogrammetrie niet weerhouden. De data op de eerste 9 levels hebben een louter indicatieve waarde. De elementen geplaatst op levels > 9, zijn in het finale GRB-bestand terug te vinden. Wat betreft de voorgevels geldt een specifieke regeling: ·
BB01 die verkeerd gepositioneerd is, wordt verwijderd en opnieuw gerestitueerd;
·
BB01 die goed gepositioneerd is, wordt behouden en niet opnieuw gerestitueerd rekening houdend met de regels in volgende paragraaf;
·
BB01 die twijfelachtig is of niet kan worden beoordeeld door de fotogrammeter wordt behouden en tevens gerestitueerd. In dit geval komen de voorgevels 2 maal voor in het bestand d.w.z. ŽŽnmaal op level 10, 11 of 12 (opnieuw gerestitueerd) en ŽŽnmaal op level 15 (opslag van twijfelachtige CARDIB-gevel). De naverkenning zal bepalen welke gevel definitief moet worden bewaard.
De fotogrammetrische gevels van CARDIB, BB05 en BB10, worden verwijderd indien ze slecht zijn gepositioneerd of gekopieerd naar de lagen 10 en 11 indien ze voor de fotogrammeter goed bruikbaar zijn. Verder geldt ook dat onafhankelijk van het bestaan van geconverteerde gevellijnen er gevellijnen worden gerestitueerd: ·
Ter hoogte van kruispunten;
·
Langs onbebouwde percelen;
·
En als de rand van de wegbaan met de gevel samenvalt.
Snappunten of aansluitingspunten op gevels zijn tijdelijke elementen. Zij zijn een hulpmiddel om de omtrek van het gebouw in zijn geheel fotogrammetrisch te restitueren. In het finale restitutiebestand worden deze punten, gelegen op de hoek van een gebouw of ter hoogte van de gemene gevel, niet als een afzonderlijke entiteit weerhouden. 3.1.2. Integratie van CARDIB-data De CARDIB-gegevens worden verknipt in kilometerhokken overgedragen. Bij de fotogrammetrie dienen de kilometerhokken samengevoegd te worden tot 1 bestand voor het volledige project. Er wordt vervolgens per stereokoppel een uitsnede van de data gemaakt.
3.2. MIDDENSCHALIGE DATA Aan de module fotogrammetrie worden eveneens de geregistreerde wegassen en waterassen doorgegeven.
rsc000107av0.doc
17
werkverslag testproject Het OC GIS-Vlaanderen maakt voor de betreffende gemeente twee bestanden over aan de opdrachtnemer zijnde: 1. De assen van de wegen; 2. De hydrografie. Het eerste bestand bevat de geregistreerde assen der wegen en is een afgeleide van het Streetnetbestand van Tele Atlas. In het tweede bestand worden de assen van de geregistreerde waterlopen, afkomstig uit de Vlaamse Hydrografische Atlas, en de randen van brede waterlopen, afkomstig uit Streetnet, verzameld. Beide bestanden worden in DXF-formaat en in 2D aan de aannemer te beschikking gesteld. De aannemer dient er rekening mee te houden dat beide bestanden oorspronkelijk bestemd voor gebruik op middenschalig niveau. De elementen die er in voorkomen moeten bijgevolg zowel in de x-, de yals de z-richting worden verplaatst en ge•ntegreerd in het GRB-restitutiebestand. Assen die ontbreken in de aangeleverde bestanden worden gerestitueerd. Elementen die niet thuishoren in de huidige topografische toestand van het terrein worden niet in het GRB-bestand opgenomen.
rsc000107av0.doc
18
werkverslag testproject
rsc000107av0.doc
19
werkverslag testproject
Hoofdstuk 2: topografie 1. Inleiding Ondanks de grootschalige fotovlucht, zijn terrestrische opmetingen essentieel in functie van de applicaties van het GRB. Dit omvat een controle en aanvulling van de gerestitueerde gegevens vanop het terrein. Aanvankelijk werd de module topografie dan ook voornamelijk beperkt tot het aspect naverkenning, zoals beschreven in dit hoofdstuk. Als opmerking dient hierbij gegeven te worden dat, omwille van kostprijsreducerende redenen en omwille van een verbeterde kwaliteit van de digitale bestanden vanuit digitaal standpunt bekeken, het aan te raden is om over te schakelen naar een uitgebreide skeletmeting met aanvullingen vanuit de fotogrammetrie. Op deze manier kan de daaropvolgende naverkenning sterk beperkt worden (zie ÒKritische beschouwingenÓ). Een tweede element binnen de module topografie is de geodetische grondslag, die de basis moet vormen voor de bijhouding van het GRB. Onder geodetische grondslag wordt een betrouwbaar puntennet begrepen, waarvan de dichtheid varieert naargelang het type gebied.
2. Methode In de gevolgde methode zijn drie delen te onderscheiden, nl. de voorbereidende taken, de eerste naverkenningsronde (inventarisatie) en de tweede naverkenningsronde (opmetingen en verwerking). In onderstaande figuur wordt het topografisch productieproces schematisch voorgesteld.
MODULE DATAVERWERKING
Voorbereiding
Fotokoppel
Selectie en bewerking van grondslagpunten
Plot van restitutiebestand met genummerde grondslagpunten
rsc000107av0.doc
20
werkverslag testproject
Inventarisatie
Verificatie en aanvulling van de plot op het terrein
Opstellen van een meetplan
Opmeting en verwerking
Terrestrische opmeting
Verwerking
Integratie met het restitutiebestand
MODULE DATAVERWERKING
2.1. DIRECTORYSTRUCTUUR De gevolgde methode is ook terug te vinden in de directorystructuur: Top directory Onderverdeling naverkenning/
Bestanden
fotogramm in/
v_xxx_yyy_c
topografie 1 template/
v_xxx_yyy_ct
grondslagbestanden
v_xxx_yyy_g
topografie 2 alfanum/
v_xxx_yyy_cth gemeente_1 gemeente_2 gemeente_3 gemeente_1t gemeente_2t gemeente_3t
topografie 3 opmetingen/dg dialog/v_xxx_yyy/
convert/ dgdb/ field/ input/ rapport/
move projecten/
v_xxx_yyy.prj v_xxx_yyy.tco v_xxx_yyy.tob v_xxx_yyy.cor
topografie 4 conversie/
v_xxx_yyy_d
rsc000107av0.doc
Functie
21
werkverslag testproject
topografie 5 template/
v_xxx_yyy_dt
topografie 6 resultaat
v_xxx_yyy_t
topografie 7 conversie
v_xxx_yyy_t
2.2. VOORBEREIDING VAN DE NAVERKENNING 2.2.1. Bekendmaking van het project De naverkenning van een gerestitueerd grootschalig bestand, betekent dat in sommige gevallen het privaat domein door de landmeter zal moeten betreden worden. In enkele gevallen zal de signalisatie van grondslagpunten op het openbaar domein noodzakelijk zijn. Om eventuele misverstanden te voorkomen, worden de politiediensten van de desbetreffende gemeente van deze naverkenningsactiviteiten op de hoogte gesteld. Deze brief wordt gericht aan de politiecommissaris van de gemeente. Meteen wordt deze vriendelijk verzocht zijn collegaÕs van de rijkswacht eveneens op de hoogte te brengen. 2.2.2. Data-input Aangezien de naverkenning erop gericht is de restitutie aan te vullen en te corrigeren teneinde de GRB-specificaties te kunnen halen, is het restitutiebestand het uitgangspunt. De eenheid van karteren bij de fotogrammetrie is het fotokoppel, wat zich weerspiegelt in de bestanden die de naverkenning krijgt van de dataverwerking. Er wordt ŽŽn bestand per fotokoppel afgeleverd door de module fotogrammetrie en verder is de naamgeving van het bestand afgeleid van de volgende kenmerken van het fotokoppel: v_xxx_yyy_c v: projectnummer x: numerieke variabele, nl. het nummer van de eerste foto van het fotokoppel. y: numerieke variabele, nl. het nummer van de tweede foto van het fotokoppel. Tussen de eerste en tweede foto bestaat er een overlappingszone van minstens 60%. Deze overlappingszone, fotokoppel genoemd, is de eenheid van verwerking binnen de fotogrammetrie en laat restitutie toe. c: letterteken dat ÔcorrectedÕ voorstelt, m.a.w. het fotokoppel met suffix ÔcÕ werd door de dataverwerking geometrisch gecorrigeerd (overshoots, gaps, É).
Dit bestand wordt niet opgeleverd aan de module topografie aangezien de normalisatie (zie volgende paragraaf) uitgevoerd wordt door de module dataverwerking. 2.2.3. Normalisatie van bestanden De bestanden uit de fotogrammetrie hebben een laagopbouw die varieert naargelang de entiteiten die zich voordoen op het terrein. Voorts zijn de eigenschappen gedefinieerd per entiteit en niet per laag waarop deze entiteiten zich bevinden. De bestanden uit de fotogrammetrie worden genormaliseerd door de module dataverwerking. dit betekent dat de afgeleverde bestanden aan de naverkenning uniform zijn voor wat betreft: ·
Laagopbouw: alle gedefinieerde lagen komen voor;
·
De CAD-eigenschappen (kleur, lijndikte, lijntype, É) zijn ge‘nt op de laag en niet op het individueel object;
·
De kleuren van de gerestitueerde entiteiten zijn dermate aangepast dat het afdrukken op wit blanco papier goed leesbaar is op het terrein.
Het resulterende bestand krijgt de naam v_xxx_yyy_ct t:
template file
en wordt opgeleverd aan de module topografie. Het wordt opgeslagen in de directory \\naverkenning\topografie 1 template\. Hieronder staat een voorbeeld van een dergelijk genormaliseerd restitutiebestand. Het bestand bevat, op enkele type- en relatiecoderingen na, geen enkele alfanumerieke informatie.
rsc000107av0.doc
22
werkverslag testproject
2.2.4. Selecteren en opslaan van grondslagpunten Alvorens de eigenlijk naverkenning van start kan gaan, dient de puntnummering van de aanwezige stations- en ori‘nteringspunten in het fotokoppel gekend te zijn. Het gaat om de volgende entiteiten (in afnemende graad van positionele nauwkeurigheid): ·
Zichtbare riooldeksels en meetkundige verdichtingspunten;
·
Hoekpunten van de dakrand;
·
Straatverlichting.
Deze punten worden uit v_xxx_yyy_ct geselecteerd en opgeslagen. Dit resulteert in een nieuw grafisch bestand dat enkel objecten met puntgeometrie bevat. Dit bestand bevindt zich in de directory \\naverkenning\grondslagbestanden\ en draagt de volgende bestandsnaam: v_xxx_yyy_g g: grondslag
Dit bestand wordt vervolgens ge•mporteerd in de topografische verwerkingssoftware (in dit geval dg Dialog Topografie). Na conversie wordt er een grondslagbestand gecre‘erd. Bij het converteren naar een ASCII grondslagpuntenbestand kent het programma automatisch aan elk punt een (voor dat fotokoppel) uniek puntnummer toe. Het is belangrijk dat op het terrein dit puntnummer gekend is,
rsc000107av0.doc
23
werkverslag testproject zodat onmiddellijk de juiste grondslagpunten kunnen aangesproken worden door het totaalstation. De opmetingen zullen door het pakket berekend worden op basis van de gebruikte grondslagpunten. 2.2.5. Plotten van het fotokoppel De laatste voorbereidende taak alvorens de landmeetploeg op het terrein kan gaan, bestaat uit het plotten van het fotokoppel, met inbegrip van de puntnummers van de aanwezige grondslagpunten. De schaal van de plot verandert naargelang het type gebied: ·
Landelijk, voorstedelijk, industrie en natuur: 1/1.000;
·
Stedelijk: 1/500.
De reden hiervoor ligt in het feit dat de densiteit van informatie enorm toeneemt in het stedelijk koppel, zowel voor de attributen (straatnamen, huisnummers, É) als de geometrie (aantal voorgevels, riooldeksels, É). Indien het stedelijk koppel zou worden afgedrukt op 1/1000 is de kans re‘el dat achteraf verwarring ontstaat rond notities en relatieve opmetingen. De volgende informatie moet eveneens afgedrukt worden: ·
Noordpijl;
·
Schaal;
·
Bestandsnaam en path;
·
GBK huisnummers (Cardib, É) (optioneel);
·
GBK straatnamen (Cardib, NGI, StreetNet, É).
2.3. EERSTE NAVERKENNINGSRONDE:
INVENTARISATIE
2.3.1. Terreinverkenning Tijdens de eerste naverkenningsronde gaat de landmeetploeg op het terrein zonder totaalstation en bijhorende uitrusting. Enkel de plot, een balpen en een meetband worden meegenomen zodat relatieve controlematen reeds tijdens de eerste ronde kunnen opgemeten worden. Systematisch worden alle straten afgestapt, gelet op de grenzen van het fotokoppel. Indien men reeds op het terrein over plots van naburige fotokoppels kan beschikken, worden straten die door verschillende fotokoppels heen lopen, afgewerkt los van de grenzen van het fotokoppel. Notities worden genomen op de plot met de balpen in de volgende gevallen: ·
Overbodige objecten;
·
Ontbrekende objecten;
·
Opgenomen relatieve controlematen (regelmatige opgemeten dwarsprofielen van de wegbaan (tussen twee voorgevels van recht tegenover elkaar staande gebouwen indien mogelijk om interpretatiefouten gedurende de restitutie te kunnen ontdekken);
·
Huisnummers (indien een GBK-inventaris van de huisnummers bestaat, worden de huisnummers eveneens afgeplot en wordt deze inventaris gecontroleerd op fouten en onvolledigheden);
·
Straatnamen;
·
Aanduiding van stationpunten, ori‘nteringspunten en detailpunten (en hun aard) voor de tweede ronde;
·
Correctie van typecodering en codering van relatie tussen kunstwerken en andere entiteiten vanuit de fotogrammetrie.
Een fotokoppel is slechts afgewerkt voor wat betreft de eerste naverkenningsronde wanneer de restitutie, samen met de notities (incl. de nog uit te voeren opmeting en verwerking) conform de specificaties van het GRB Conceptueel Datamodel versie 3.1 bevonden wordt.
rsc000107av0.doc
24
werkverslag testproject 2.3.2. Conventies De eerste naverkenningsronde is een inventarisatie die grotendeels steunt op analoge inwinning van bijkomende informatie (geometrische en inhoudelijke). Bijgevolg zijn er weinig concrete afspraken die voor automatisatie van belang kunnen zijn. Er gebeurt enkel een veldnotatie voor het: ·
Aanduiden van te gebruiken grondslagpunten (reeds genummerd of niet);
Opstelpunt Ori‘ntatierichting In te meten detailpunt
·
Inwinnen van huisnummers of het verifi‘ren van een bestaande inventaris (Cardib) met de terreinwerkelijkheid; De veldnotatie gebeurt volgens onderstaande conventie: uitleg
notatie
Enkelvoudig huisnummer u Huisnummer met bisnummer x_y Huisnummer met bereik van bisnummers x_p-s Huisnummer met busnummer z/A Huisnummer met bereik van busnummers z/A-Z Huisnummerbereik (steeds even = -, u-v steeds oneven = +) u+v Huisnummerbereik (gemengd, aan ŽŽn zijde van de u*v straat) Niet genummerd hoofdgebouw $
Voorbeeld 203 12_2 (=12BIS) 12_a-b of 12_1-2 12/B 12/A-D 6-10 (d.i. 6,8 en10) 5+9 (d.i. 5,7 en 9) 5*10 (d.i. 5,6,7,8,9 en 10) $
Hierbij zijn de volgende componenten aanwezig: - u, v, w, x, y, z: huisnummer, steeds gehele getallen; - p, q, É, s: bisnummer, steeds gehele getallen of alfanumerieke karakters; - A, B, C, É, Z: busnummers (alfanumerieke karakters of gehele getallen); - $: speciale waarde voor niet genummerd hoofdgebouw; - + en -: specifieke notatie voor huisnummerbereiken (- voor de notatie van een bereik van even huisnummers en + voor de notatie van een bereik van oneven huisnummers); - *: specifieke notatie voor een bereik van gemengde huisnummers (even en oneven langs ŽŽn zijde van de straat). De inwinning van deze informatie op het terrein moet getoetst worden aan de ontwikkelingen rond het Centraal Referentie Adressen Bestand (CRAB). Dit CRAB definieert een adres als een gerefereerde plaats in de straat. Een adres bestaat dus uit een gemeente, een straat en een geregistreerd (huis)nummer. In dit kader dient de inwinning van huisnummer geschetst te worden. Volgende gevallen kunnen vaak voorkomen: 1. ge•soleerd huisnummer
12
rsc000107av0.doc
.12
25
werkverslag testproject 2. huisnummer met bisnummer
12a
.12_a
3. huisnummer met busnummer
12a
.12/a
4. huisnummer met bereik van bisnummers .12_a-b 12a tot 12b
5. huisnummer met bereik van busnummers
12a tot 12b OF .12a
.12/a-b . 12b
6. huisnummer met bereik van bisnummers en busnummers
12a
12b/1-2
.12_a-b/1-2
7. Bereik van huisnummers a. steeds even
12,14,16,18,20
.12-20
b. steeds oneven
11,13,15,17,19
.11+19
c. gemengd (aan ŽŽn zijde van de straat)
11,12,13,14,15,16,17
rsc000107av0.doc
.11*19
26
werkverslag testproject
8. Niet genummerd hoofdgebouw
.$
Enkel in de stad Gent worden appartementen geregistreerd met een apart huisnummer. Hiervoor wordt gewerkt met een bereik van huisnummers. Dit wordt beschreven in de bovenstaande tabel (laatste drie records). Deze veldnotatie is heel belangrijk aangezien de landmeter enkel tijdens de terreinconfrontatie het verschil kan zien tussen individuele huisnummers met bisnummer (ŽŽn insertiepunt per huisnummer in ŽŽn of meerdere gebouw) enerzijds en ŽŽn huisnummer met een bereik van (niet geregistreerde) busnummers (ŽŽn insertiepunt met huisnummer voor alle busnummers). De veldnotatie maakt het dus mogelijk de informatisering in een postprocessing omgeving uit te voeren. ·
Verifi‘ren van bestaande gebiedsdekkende inventaris van straatnamen (zowel geometrisch als inhoudelijk);
·
Verificatie van door fotogrammetrie toegekende tekstuele attributen (typecodes) van vlakvormige entiteiten en relatiecodes tussen bepaalde entiteiten. Deze conventie geldt ook voor de inwinning van attributen van entiteiten die opgemeten worden tijdens de tweede naverkenningsronde;
·
Opstellen van een meetplan voor de tweede naverkenningsronde.
2.3.3. Informatiseren van alfanumerieke attribuutinformatie
2.3.3.1. Huisnummers Indien de Cardib-huisnummers kunnen worden overgenomen, worden wijzigingen en onvolledigheden zoals ervaren op het terrein gecorrigeerd. De manier van voorstellen is echter niet meer belangrijk zoals dat bij Cardib wel het geval was, in tegenstelling tot de conventie over de inhoudelijke voorstelling van huisnummers. Deze dient nageleefd te worden teneinde de conformiteit met CRAB te waarborgen. Aangezien de notities op de plot reeds deze conventie respecteren, is een verdere interpretatie bij het informatiseren niet aan de orde. ·
Insertiepunt: gelegen binnen de contouren van het gebouw waaraan het huisnummer vast hangt. Het insertiepunt wordt dermate geplaatst binnen de contouren van het hoofdgebouw zodat de afstand tot de wegas waartoe het huisnummer behoort steeds kleiner is dan de afstand naar eender welke andere wegas (afstandsregel). Wanneer dit niet ŽŽnduidig kan, wordt aan het huisnummer de volgende notatie toegevoegd:
HUISNUMMER__STRAATNAAM [veldnotatie][2x underscore][straatnaam waaraan het huisnummer toebehoort)
Op die manier kan de dataverwerking op een ŽŽnduidige manier het huisnummer toekennen aan de juiste straatnaam; ·
Code: deze wordt overgenomen van de veldnotatie.
2.3.3.2. Type- en relatiecoderingen Voor wat betreft de informatisatie van type- en relatiecoderingen, wordt dezelfde methodologie vooropgesteld zoals beschreven bij de informatisatie van de huisnummers. In het GRB zijn de domeinen van de attributen strikt gedefinieerd. Dit betekent dat voor bepaalde entiteiten (ongeacht de geometrie) een aantal mogelijke typecodes beschikbaar zijn die voor elke
rsc000107av0.doc
27
werkverslag testproject entiteit dienen vastgelegd. De module fotogrammetrie heeft hiervoor reeds een ŽŽnduidige conventie uitgewerkt: ·
Onderscheid op basis van lagen: punt- en lijnvormige entiteiten;
·
Onderscheid door toekennen van tekstuele attributen: vlakvormige entiteiten.
Het onderscheid naar lagen houdt in dat bvb. elk type watergang (onverhard/afwisselend verhard en onverhard/verhard) gegroepeerd wordt in een aparte laag. De entiteiten die op die manier gecodeerd worden zijn: ·
gvl;
·
wli;
·
wti;
·
wri;
·
wpi;
·
wtg;
·
wbn.
Bij vlakvormige entiteiten is het echter mogelijk om op een ŽŽnduidige manier een tekstcode toe te kennen aan elk vlak. De algemene regel stelt dat het insertiepunt van het tekstueel attribuut binnen de grenslijnen van het desbetreffende vlak moet liggen. De entiteiten die op die manier gecodeerd worden zijn: ·
trn;
·
wga;
·
knw;
·
gba.
De typecodering gaat als volgt: terrein 01 verhard 02 onverhard/onbegroeid 03 begroeid gras 04 begroeid kruidachtig 05 begroeid houtig 06 begroeid gemengd
01 verkeer 02 ingericht groen 03 natuur 04 militair 05 braakliggende 06 burgerlijk 07 exploitatie
wegaanhorigheden 01 bushokje 02 telefoonhokje 03 overdekte fietsstalling 04 verkeerscabine 05 bergplaats kunstwerken 1 overbrugging 2 waterbouwkundig werk 3 cultuurhistorisch monument 4 hoogspanningsmast 5 pijler 6 rooster 7 schoorsteen 8 koeltoren 9 silo / conglomeraat 10 elektriciteitscabine 11 watertoren 12 tunnelmond gebouwaanhorigheid g0 binnenkoer g1 trap g2 loopbrug g3 onderkeldering
rsc000107av0.doc
28
werkverslag testproject g4 afdak g5 uitbreiding van gebouw g6 verdieping
De relatiecodering zorgt ervoor dat verbanden tussen (verschillende) entiteiten kunnen opgenomen worden in het GRB. Deze relatiecodering bestaat uit een actor (gedragen, overbrugde, doorgelaten, opgehouden of ingerichte) en een entiteit (ingericht kunstwerk, wegas, wegbaan, spoorbaan of wateras). De relatiecodering wordt hier eveneens beschreven: relatie
entiteit l ingericht kunstwerk a wegas b wegbaan s spoorbaan r wateras
probleemzone
actor 01 gedragen 02 overbrugde 03 doorgelaten 04 opgehouden 05 ingerichte
type 1 tijdelijke en sterk veranderende toestand 2 niet interpreteerbare terreinsituatie 3 manifest fout gekarteerd gebied de 4 3 ommegang
de
De 3 ommegang bestaat erin dat de terreinploeg kan genoodzaakt worden om GPS-metingen uit te voeren wanneer grondslag uit de fotogrammetrie niet aanwezig of van twijfelachtige kwaliteit blijkt te zijn. Deze GPS-metingen kunnen gegroepeerd uitgevoerd worden voor een aantal probleemgevallen per fotokoppel, ook al zijn de detailmetingen met het totaalstation reeds uitgevoerd vanuit twee goed gekozen grondslagpunten die ook voldoen aan de eisen voor GPS-ontvangst. Voor de verschillende entiteiten die tekstueel gecodeerd worden, gelden naast de algemene regel toch enkele specifieke richtlijnen voor het plaatsen van de code. ·
Gebouwaanhorigheden: typecodering: ·
Insertiepunt: zo dicht mogelijk bij de grenslijn die eveneens een grenslijn is van de polygoon van het gebouw waarbij de desbetreffende gebouwaanhorigheid aansluit. Op die manier wordt het mogelijk te specificeren bij welk gebouw aan de grond de aanhorigheid aansluit bij meerdere mogelijkheden (zoals bvb uitbreiding van een gebouw boven een centraal gelegen doorgang door een gebouw);
·
Code: zie hierboven;
·
Symbool: tekst:
· ·
·
Hoogte: 0.50 m.;
·
Kleur: 0 (white);
·
Stijl: standard;
·
Laag: 185;
·
Ori‘ntatie: 0 gon;
Drager van informatie: veelhoek;
Kunstwerken: typecodering: ·
Insertiepunt: zo dicht mogelijk tegen de grenslijn van het desbetreffende kunstwerk. Op die manier wordt het mogelijk vlakken die elkaar overlappen toch een verschillende code te kunnen toekennen. Voorwaarde hierbij is wel dat de grenslijn van het kunstwerk een gesloten polyline is en geen knooppunten heeft wanneer ze de grenslijn van het andere overlappende kunstwerk kruist;
·
Code: zie hierboven;
·
Symbool: tekst: ·
Hoogte: 0.50 m;
·
Kleur: 0 (white);
rsc000107av0.doc
29
werkverslag testproject ·
Stijl: standard;
·
Laag: 185;
·
Ori‘ntatie: 0 gon;
·
Drager van informatie: veelhoek;
·
Geometrie van grenslijn: onafgebroken en bestaande uit ŽŽn gesloten.
Beide operaties resulteren in een nieuw bestand: v_xxx_yyy_cth. h: huisnummerbestand
Dit bestand wordt opgeslagen in een nieuwe directory zijnde: \\naverkenning\topografie 2 alfanum\
2.3.3.3. Straatnamen Hier is steeds hetzelfde uitgangspunt van kracht: er bestaat voor elke gemeente in Vlaanderen een (digitale) ruimtelijk gerefereerde inventaris van het stratenbestand. De datasets waarin deze informatie zich bevindt (in afnemende volgorde van positionele nauwkeurigheid), worden hieronder opgesomd: ·
Cardib;
·
NGI;
·
Tele Atlas (StreetNet).
In alle gevallen wordt door de dataverwerking een GIS-dataset aangemaakt die de geometrie en attributen opslaat zoals aangeleverd door het bronbestand. Het bestand wordt geleverd vanuit de dataverwerking en wordt versneden per project (gemeente). De bestanden die de dataverwerking ter beschikking stelt, nl. gemeente_x (Met x = 1 (Cardib, GBK, É), 2 (NGI) of 3 (Tele Atlas)), worden opgeslagen in de directory \\naverkenning\topografie 2 alfanum\ Na het corrigeren en vervolledigen van inhoud en geometrie van de ganse gemeente worden de bestanden gemeente_xt opgeleverd en in dezelfde directory opgeslagen. 2.3.4. Opstellen van een meetplan voor de tweede naverkenningsronde Een meetplan opmaken, houdt in dat een prognose gemaakt wordt van de duur van opmetingen op basis van een aantal parameters. Er dient rekening gehouden te worden met een aantal randvoorwaarden. ·
Aantal opstelpunten: ·
Bekende standplaatsen;
·
Vrije standplaatsen;
·
Aantal in te meten detailpunten (classificatie aard terrein volgens CORINE LANDCOVER generalisatie);
·
Complexiteit van detailpunten (aard van codering bvb. lijnnummers, segmenten versus een ge•soleerd punt).
Een aantal randvoorwaarden die niet op voorhand kunnen ingecalculeerd worden zijn: ·
Weersomstandigheden (regen, wind, mist, É);
·
Zichtbaarheid (obstructie door autoÕs, É);
·
Voortdurende evolutie van het terrein (wegenwerken, É).
Het effect van dit laatst aangehaalde probleem kan op voorhand geminimaliseerd worden door de tweede naverkenningsronde zo dicht mogelijk op de eerste te laten volgen. De uitrusting dient steeds in uitstekende staat van onderhoud aangetroffen voor het vlot en nauwkeurig uitvoeren van de opmetingen. De uitrusting bestaat uit: ·
Wagen;
·
Signalisatie en veiligheidskledij;
·
Totaalstation;
·
Driepoot;
·
Basis;
rsc000107av0.doc
30
werkverslag testproject ·
Reflector(houder) en verlengbare prismastok;
·
2 jalons en drievoet met nijptang;
·
Klinknagels, fenopalen en hamer;
·
2 opgeladen batterijen (elk met autonomie van 3 uur);
·
Geheugenkaart van minimum 0.5Mb (pcmcia);
·
Plot van het restitutiebestand uit de eerste naverkenningsronde.
Het resultaat is een ruwe schatting van de duur van opmetingen en verwerking. Het meetplan wordt belangrijk bij de planning van de tweede naverkenningsronde. Het meetplan zal immers gebruikt worden om de duur van de tweede naverkenningsronde in te schatten. De waarde van dit meetplan daalt naarmate het tijdsverschil tussen de eerste en tweede naverkenningsronde toeneemt.
2.4. TWEEDE NAVERKENNINGSRONDE:
OPMETINGEN EN VERWERKING
2.4.1. Eigenlijke opmetingen Tijdens de tweede naverkenningsronde, worden na te verkennen objecten op het terrein ingemeten met een totaalstation. Hierbij zij het opgemerkt dat relatieve controlematen ook met behulp van het totaalstation kunnen opgemeten worden. De afstand tussen gerestitueerde riooldeksels, stoepranden, etc. kan bijvoorbeeld op die manier nauwkeuriger nagezien worden dan met behulp van de meetband. Deze objecten voldoen in de regel allemaal aan ŽŽn van de volgende kenmerken: ·
Het zijn klasse A-elementen (geodetische grondslag) en vereisen dus een nauwkeurige absolute inmeting;
·
Het zijn klasse B/C-elementen, die eveneens zichtbaar zijn vanuit hetzelfde opstelpunt dat gebruikt werd voor het inmeten van de klasse A-elementen.
De metingen worden opgeslagen met de volgende bestandnaam: v_xxx_yyy_t . Hierbij stelt ÔtÕ een autonummering voor in het geval meerdere files nodig zijn voor een zelfde fotokoppel. Er wordt immers ŽŽn bestand per meetdag aangemaakt. Het document met de beschrijving van het dataformaat van de ruwe velddata, wordt apart opgesteld. Een fotokoppel is afgewerkt voor wat betreft de tweede naverkenningsronde, indien alle in te meten detailpunten werden ingemeten en dit volgens de specificaties van datamodel GRB versie 3.1. Meteen kan de accuraatheid van het meetplan getoetst worden aan de werkelijke duur van de opmetingen (terreingedeelte van de tweede naverkenningsronde). 2.4.2. Verwerking van de ruwe velddata
2.4.2.1. Gegevensuitwisseling tussen totaalstation en netwerk De file van het totaalstation wordt uitgelezen op PC. Een kopie van de originele meetfile wordt opgeslagen in \\naverkenning\topografie 3 opmetingen\dg dialog\v_xxx_yyy\. Het project \v_xxx_yyy\ is op directory-niveau eveneens een aparte directory met een aantal subdirectoryÕs: \convert\ \dgdb\ \field\ \input\ \rapport De kopie wordt opgeslagen in de subdirectory \field\. In deze subdirectory van het project zoekt het topografisch pakket immers automatisch naar meetbestanden van het totaalstation.
2.4.2.2. Controle en gericht uitvoeren van correcties in meetbestand
rsc000107av0.doc
31
werkverslag testproject Intern werd op het OC een applicatie ontwikkeld die het veldgeheugen van het totaalstation converteert naar een meer gebruiksvriendelijk en leesbaar bestand. De meet- en codeblokken worden duidelijk door opmaak en aangevingen van elkaar gescheiden en de op het terrein ingegeven en geregistreerde werkelijke waarden worden hier weergegeven zonder de overbodige en verwarrende codes en in de juiste eenheid. Aan de hand van het meetnummer kan dan een eventueel foutieve regel in het origineel meetbestand worden teruggevonden en gecorrigeerd. Uiteindelijk gebeuren alle correcties in de ruwe meetfile, aangezien dit nog steeds het vertrekpunt is voor de verwerking in het topografisch pakket. De applicatie zal de geconverteerde versie ook opslaan in een ascii-formaat zodat dit steeds raadpleegbaar is door notepad bij elke stap binnen het topografisch pakket. De geconverteerde versie wordt in dezelfde directory opgeslagen in het fileformaat van het totaalstation; maar krijgt het suffix _NL. Hieronder een voorbeeld van de output van de applicatie. MEETN¼ 1 2 3 4
CODE 90 91 81 83
INFO1 4 1 96 8
INFO2
INFO3
20 1551 1500
100
MEETN¼ 5
PUNTN¼ 3003
Hz 0.0005
V 99.71
D 100.652
MEETN¼ 6
CODE 83
INFO1 8
INFO2 1500
INFO3
MEETN¼ 7
PUNTN¼ 3004
Hz 200.005
V 300.289
D 100.653
MEETN¼ 8
CODE 83
INFO1 13
INFO2 1500
INFO3
É
2.4.2.3. Verwerking in het topografisch pakket 2.4.2.3.1. CONVERSIE NAAR STANDAARD MEETBESTAND Deze conversie naar dit ascii-bestand zorgt ervoor dat elke inputfile voor dg Dialog dezelfde opbouw heeft ongeacht het type totaalstation waarmee werd gewerkt. De beschrijving van het dataformaat van dit standaard meetbestand is aangevraagd bij de Grontmij Geogroep. De inputfile wordt opgeslagen in de subdirectory-structuur van het project: \\naverkenning\topografie 3 opmetingen\dg dialog\v_xxx_yyy\ \convert\ \dgdb\ \field\ \input\ \rapport Dit bestand draagt dezelfde bestandsnaam, maar krijgt het suffix 01, 02, naargelang het aantal meetfiles dat reeds werd verwerkt in dat project. v_xxx_yyy01 Er wordt afgesproken om ŽŽn meetbestand per dag aan te maken. Duurt de opmeting van hetzelfde fotokoppel meerdere dagen, dan zullen verschillende bestanden gegenereerd worden. 2.4.2.3.2. AANMAAK VAN EEN INPUTFILESET Om de verwerking als ŽŽn meetbestand te laten gebeuren per fotokoppel, worden de verschillende bestanden ge•ntegreerd door een inputfileset aan te maken. Hierbij moeten de achtereenvolgende
rsc000107av0.doc
32
werkverslag testproject bestanden in de juiste volgorde toegekend worden aan de inputfileset. Zo worden de opmetingen in de juiste volgorde doorlopen en worden er geen onbekende punten aangesproken. De inputfileset genereert geen nieuw meetbestand op directory-niveau, maar een ascii-bestand geeft wel de koppelingen aan naar de specifieke inputfiles. Dit bestand bevindt zich in dezelfde directory als de inputfiles. 2.4.2.3.3. CHECKEN VAN INPUTFILESET Vooreerst wordt er een semantische en inhoudelijke controle uitgevoerd op de verschillende inputfiles. Deze actie verifieert de volgende zaken: ·
Foutieve codes;
·
Foutieve parameters van juiste codes;
·
Waarnemingen (opbouw en indexcorrectie).
Op het einde van deze controle wordt het dialoogvenster voor de volgende stap (vereffening van de grondslag) weergegeven. Er worden een aantal rapportbestanden gegenereerd die de waarschuwingen en fouten aangeven in de inputbestanden. Fouten onderscheiden zich van waarschuwingen doordat ze de verdere verwerking onmogelijk maken. De rapportbestanden kunnen opgeslagen worden onder de volgende directory: \\naverkenning\topografie 3 opmetingen\dg dialog\v_xxx_yyy\ \convert\ \dgdb\ \field\ \input\ \rapport 2.4.2.3.4. VEREFFENEN VAN GRONDSLAG Hierbij worden de grondslagwaarnemingen vereffend op basis van de methode van de kleinste kwadraten. Dg Dialog Topografie maakt hierbij gebruik van de rekenmethode van Move 3 volgens de theorie van de Universiteit van Delft, doch heeft niet dezelfde interactiemogelijkheden als het aparte pakket Move 3 om het geheel van bekende punten en waarnemingen afzonderlijk te toetsen aan het kansmodel. De toetsing van de waarnemingen is mogelijk door een vrije netwerkvereffening wanneer er overtallige waarnemingen aanwezig zijn. In het andere geval leidt deze vereffening in Move 3 tot fouten aangezien het singulariteitscriterium van toepassing is. Eens verdachte overtallige waarnemingen met een overschreden W-toets uitgeschakeld worden tijdens de vereffening, kan de pseudo kleinste kwadraten vereffening het ganse netwerk vereffenen waarbij de bekende punten vast gehouden worden. Deze aangesloten vereffening geeft vooral een idee van de kwaliteit van de bekende punten. In eerste instantie wordt in het hierboven vermeld dialoogvenster de optie rekenen aangekruist, indien de weergegeven grondslagpunten met unieke puntnummers de juiste zijn. Het is geen probleem wanneer er meer grondslagpunten dan nodig aanwezig zijn, maar gebruikte grondslagpunten (bvb verlichtingspalen) die niet in deze grondslagfile aanwezig zijn, moeten eerst hieraan toegevoegd worden door de actie Bewerken grondslagpunten. Ook de standaardafwijking dient ingegeven. Hierbij moet opgemerkt worden dat een grondslagpunt in dg Dialog Topografie niet van kwaliteit kan verminderen. Eens bvb. een standaardafwijking (dx) werd ingegeven van 2cm kan nadien voor datzelfde punt geen dx van 4cm worden ingegeven, ook niet wanneer het punt verwijderd en opnieuw ingevoerd wordt. Het komt er dus op neer onmiddellijk de juiste standaardafwijking in te geven. Voor riooldeksels uit de fotogrammetrie betekent dit ongeveer 7cm in x en y en 15cm in z. Voor andere (klasse B) elementen zoals verlichtingspalen wordt 15cm in x en y gebruikt. Hier wordt geen z-waarde gebruikt.
rsc000107av0.doc
33
werkverslag testproject
Figuur 5: Grondslagwaarnemingen en bekende stations in Move 3
Indien de F-toets in dg Dialog-berekening verworpen wordt, wordt de stap Ôchecken inputfilesetÕ opnieuw doorlopen en wordt in het dialoogvenster de optie gekozen ÔMaak Move 3 projectÕ. Op die manier kunnen we gebruik maken van uitgebreide analyse-tools van Move3. In dit dialoogvenster dienen de parameters van het kansmodel en de toestelparameters gecheckt aangezien deze worden doorgegeven aan het Move project. Dit move project wordt opgeslagen in \\naverkenning\move projecten\. Voor een volledige en grondige beschrijving van de methode van de kleinste kwadraten toegepast volgens Move 3, verwijzen we hier naar de handleiding van Grontmij Geogroep. Het project bestaat uit drie bestanden: v_xxx_yyy.prj v_xxx_yyy.tco v_xxx_yyy.tob Na de vereffening komt er een vierde bestand v_xxx_yyy.cor bij dat de vereffende cošrdinaten bevat. Dg Dialog kan dit bestand inlezen en op die manier de vereffende cošrdinaten gebruiken voor de volgende stap. De enige grondslagpunten die vereffend kunnen worden, zijn vrije standplaatsen aangezien gekozen wordt om de gerestitueerde punten vast te houden tijdens de vereffening. Een opstelling vanuit een bekende standplaats wordt eveneens ÔvereffendÕ doch dit houdt enkel een controle van de waarnemingen in. Wanneer de F-toets geaccepteerd wordt, worden de grondslagpunten uit de databank van dg Dialog automatisch overschreven met vereffende waarden en Move 3 als oorsprong. Nu pas kan worden overgegaan naar de volgende stap: de verwerking van de detailmeting. Wanneer de F-toets verworpen wordt en de landmeter kan geen verdachte overtollige waarnemingen meer uitschakelen en alle bekende punten zijn nodig voor verdere verwerking, dan zijn volgende oplossingen mogelijk:
rsc000107av0.doc
34
werkverslag testproject ·
Opnieuw uitvoeren van meting indien de verdachte waarneming van het totaalstation niet aanvaard wordt tijdens de vrije netwerkvereffening;
·
Opnieuw bepalen van gebruikt grondslagpunt door restitutie of GPS-meting wanneer de inpassing van in eerste fase aanvaarde waarnemingen in het stelsel van de bekende punten geweigerd wordt in functie van het gedefinieerde kansmodel.
2.4.2.3.5. VERWERKING VAN INPUTFILESET De verwerking van de waarnemingen kan pas van start gaan wanneer de grondslagpunten vereffend zijn. Het dialoogvenster toont alle inputfilesets die door de controle gegaan zijn. De inputfileset dient geselecteerd, de standaard objectcode op 95 gezet en we passen geen correctie toe op de aardkromming, aangezien het steeds om kleine afstanden gaat. Wanneer de inputfileset verwerkt is (m.a.w. er zitten geen fouten meer in de inputfileset en de grondslagpunten zijn vereffend) kan men het resultaat bekijken door de detaillaag aan te zetten. Visuele fouten (zoals verkeerde excentriciteitscode) kunnen in dit stadium nog rechtstreeks in de inputfile gecorrigeerd worden, op voorwaarde dat deze opnieuw gecheckt wordt. De grondslagpunten dienen vanzelfsprekend niet opnieuw verwerkt te worden. Wanneer alle fouten uit de inputfile(s) verwijderd, kan de detaillaag doorgeboekt worden naar de Topografie. Nu pas kunnen de opgemeten objecten bevraagd, ge‘diteerd en ge‘xporteerd worden. De link met de inputfile blijft echter nog steeds bestaan doch aangezien het resultaat reeds werd doorgeboekt, kan dit niet automatisch worden bijgewerkt na het corrigeren van de inputfile. 2.4.2.3.6. EXPORTEREN VAN NAVERKENNINGSOPMETINGEN NAAR CAD-PAKKET Niettegenstaande dg Dialog een eigen tekenomgeving en een aantal tools heeft voor interactief tekenen, werd er gekozen om de verdere afwerking en integratie met vorige tussentijdse bestanden in een professioneel CAD-pakket uit te voeren. Het exporteren naar het CAD-pakket gebeurt aan de hand van de door de gebruiker aangemaakte conversietabel in dg Dialog. Het resulterend CAD-bestand krijgt de volgende bestandsnaam: v_xxx_yyy_d (d staat voor export uit dialog) en wordt opgeslagen in de directory \\naverkenning\topografie 4 conversie\. 2.4.3. Normalisatie van opmetingsbestand Het in de vorige stap gegenereerde grafische bestand bevat de terrestrisch ingemeten objecten, met een aantal CAD-eigenschappen. Deze eigenschappen komen na conversie niet overeen met de wijze van voorstellen in dg Dialog (GRB Dialog template) of de overeengekomen wijze van voorstellen in het CAD-pakket volgens de aangemaakte sjabloontekeningen. Om dit te standaardiseren is het inlezen van dit grafisch bestand in deze laatste sjabloontekening (terr dialog) noodzakelijk. Het zij opgemerkt dat alle CAD-eigenschappen reeds ge‘nt zijn op de laag na conversie door dg Dialog. De standaardisatie kan dus, afhankelijk van het gebruikte CAD-pakket, uitgevoerd worden door het grafisch bestand in te voegen in een nieuwe tekening die werd aangemaakt aan de hand van de sjabloontekening terr dialog. De parameters van het invoegen zijn als volgt: insertiepunt: 0,0,0; rotatie 0 en verschaling 1,1,1. Het ingevoegd bestand moet na het invoegen editeerbaar zijn. De resulterende tekening met het genormaliseerde grafisch bestand wordt opgeslagen als v_xxx_yyy_dt in de volgende directory \\naverkenning\topografie 5 template\. De integratie met de restitutie en de eerste naverkenningsronde kan nu doorgaan in de volgende stap. 2.4.4. Integratie van opmetingen met overige tussentijdse bestanden Deze integratie gebeurt in de gekozen CAD-omgeving. De keuze hiervoor berust op de uitgebreide tekenfunctionaliteiten van het pakket en de gestandaardiseerde output-mogelijkheden. De overige tussentijdse bestanden waarvan sprake zijn de volgende: ·
\\naverkenning\topografie 2 alfanum\v_xxx_yyy_cth Dit bestand bevat het restitutiebestand samen met o.a. de huisnummers en de gecorrigeerde type- en relatiecoderingen.
·
\\naverkenning\topografie 5 template\v_xxx_yyy_dt Dit genormaliseerd bestand bevat de terrestrisch ingemeten entiteiten tijdens de tweede naverkenningsronde.
De integratie met de notities op de plot (relatieve maten met meetband) gebeurt in dezelfde fase.
rsc000107av0.doc
35
werkverslag testproject In het CAD-pakket wordt het bestand v_xxx_yyy_cth geopend. Afhankelijk van het gebruikte pakket kan het genormaliseerde grafische bestand v_xxx_yyy_dt met de terrestrische opmetingen (verwerkt in dg Dialog) ingevoegd worden. Ook hier worden dezelfde opties gekozen als beschreven in de voorgaande paragraaf. Op dit moment is de integratie van de restitutie, de eerste en tweede naverkenningsronde een feit op enkele acties na: ·
Informatiseren van relatieve maten op plot (met meetband);
·
Verband leggen tussen dakoversteek en terrestrisch ingemeten of naverkende voorgevel.
Het is de tijdsduur van deze laatste acties die de opmerking in het begin van dit hoofdstuk rechtvaardigt. De integratie van een gerestitueerde, van GBK overgenomen en terrestrisch opgemeten voorgevel zorgt er immers voor dat ·
De kost van de voorgevel stijgt aangezien deze verschillende keren beoordeeld en meestal gekarteerd wordt;
·
De kwaliteit van het bestand, bekeken vanuit digitaal standpunt, achteruitgaat.
Door de werkwijze om te draaien en de voorgevels eerst terrestrisch op te meten in gebieden waar veel gebouwen voorkomen en dus zichtbaar zijn vanuit hetzelfde opstelpunt, wordt de kost van de voorgevel verminderd op voorwaarde dat de fotogrammetrie de terrestrisch opgemeten voorgevel zonder bijkomende beoordeling kan integreren in de restitutie. Bijkomend kan de aansluiting tussen de gerestitueerde zij- en achtergevels en de terrestrisch opgemeten voorgevels sterk geautomatiseerd worden zodat de kwaliteit van het digitaal bestand niet negatief be•nvloed wordt. Aangezien de uitgebreide skeletmeting en de restitutie gebruik maken van een grondslag die onafhankelijk van elkaar werd bekomen, is een absolute controle mogelijk tussen beide modules. Het informatiseren van relatieve maten houdt in dat aan de hand van het desbetreffende commando in het CAD-pakket de gemeten afstanden ingebracht worden. Op die manier worden de teruggezette dakoversteken ingebracht en in de juiste laag (111) geplaatst. De afspraak met de module dataverwerking bestaat erin dat de naverkenning de aansluiting van de teruggezette of terrestrisch ingemeten voorgevels overlaat aan de dataverwerking die dit automatiseert. De terrestrisch ingemeten voorgevel is steeds afkomstig uit de verwerkte opmetingen van dg Dialog, dus uit v_xxx_yyy_dt. De terrestrisch naverkende voorgevel kan echter afkomstig zijn van de volgende bronnen: ·
·
v_xxx_yyy_ct: restitutiebestand: ·
Cardib BB01: laag13;
·
Cardib terugplaatsing tijdelijk: laag15;
Notities op de plot tijdens de eerste naverkenningsronde en informatisering in v_xxx_yyy_t.
De integratie in het CAD-pakket beslaat verder de volgende acties: ·
Visuele controle op juistheid van opmetingen;
·
Controle van ingebrachte type- en relatiecodering via Ôlosse tekstÕ;
·
Controle van insertiepunt van huisnummers van gebouwen met terrestrisch ingemeten of naverkende voorgevel (moet gelegen zijn binnen de contouren van gebouw).
Het resulterende bestand wordt opgeslagen als v_xxx_yyy_t in de directory \\naverkenning\topografie 6 resultaat\. 2.4.5. Oplevering van fotokoppel aan dataverwerking (gegevensuitwisseling) Dit gebeurt in de vorm van een grafisch bestand. Het bestandsformaat is afhankelijk van het gekozen CAD-pakket en de mogelijkheden voor wat betreft data-input van de module dataverwerking. In dit geval werd gekozen voor een DXF-bestand versie 13. Het resulterende bestand wordt opgeslagen als v_xxx_yyy_t in de directory \\naverkenning\topografie 7 conversie\. Via FTP (File Transfer Protocol) werd geopteerd om via de UNIX-server de data uit te wisselen met de module dataverwerking zodat er dagelijks een backup werd gemaakt van het resulterend bestand.
rsc000107av0.doc
36
werkverslag testproject Wat betreft de oplevering van het shape-bestand aan de dataverwerking, moet opgemerkt dat de eenheid van verwerking hier niet het fotokoppel is, maar het project (gemeente). Deze bestanden worden dus pas opgeleverd via FTP indien de naverkenning van het project achter de rug is.
2.5.
OPBOUW GRAFISCHE BESTANDEN
2.5.1. Gestandaarsiseerd restitutiebestand
laag 10 11 12 13 14 15 16 17 18 20 21 22 23 25 27 28 29 30 31 32 33 38 39 40 41 42 43 45 46 47 48 49 50 51 52 53 54 55 57 58 59 60 61 62 63
rsc000107av0.doc
entiteit / object dakrand dakoversteek constructiegevel Cardib BB01 Cardib BB05, BB10, IGAO Cardib terugplaatsing (tijdelijk) gebouwaanhorigheid kunstwerk kunstwerk met naverkenning wegsectie wegsectie met naverkenning kruispuntzone kruispuntzone met naverkenning wegverbinding wegknoop spoorbaan spoorbaan met naverkenning rand van onverharde zone rand van onverharde zone met naverkenning circulatiezone z.w. circulatiezone z.w. met naverkenning vangrail wli3 vangmuur wli2 verhoogde drempel wli1 longitudinale weginrichting met nvk transversale weginrichting transversale weginrichting met nvk terrein terrein met naverkenning spoorrails spoorrails met naverkenning wegaanhorigheid zichtbaar riooldeksel elec-tele-licht-verkeerslicht watergang onverharde oevers watergang afwisselend verharde oevers watergang verharde oevers gracht brandkraan type- en relatiecodering gracht met naverkenning probleemzone watergang met naverkenning as van geregistreerde waterloop splitsing per koppel
37
werkverslag testproject 2.5.2. Tussentijdse bestanden
2.5.2.1.
Huisnummers , straatnamen en type- en relatiecodering
attribuut huisnummer straatnaam typecodering relatiecodering
2.5.2.2.
entiteit
laag/thema
adr adr trn, wga, knw, gba, grz knw, wvb, wbn, sbn, was
201, 202, 203 Streetnet 185 185
Terrestrische opmetingen verwerkt in dg Dialog
type Verdichtingspunt Terrestrisch ingemeten voorgevel Terrestrisch naverkende voorgevel Gebouwaanhorigheid Kunstwerk Wegbaan Kruispuntzone Terrein Gracht Verharde watergang Afwisselende verharde-/onverharde watergang Onverharde watergang Onverharde zone Circulatiezone zwakke weggebruikers ste Riooldeksels (1 orde) de Riooldeksels (2 orde) Vangrail Vangmuur Verhoogde drempel Elec-tele-licht-verkeerslicht Brandkraan Meerpaal Grenspaal Praatpaal Paal van de bovenleiding Verhoging Verlaging Overgang nr inrichting van dwarsende weg Spoorrails Wegaanhorigheid Spoorbaan Type- en relatiecodering (ingegeven in totaalstation) Verbindingslijn tss gbv
entiteit
laag
mkv gbv gbv gba knw wbn wbn trn wtl wtg wtg wtg woz wcz wri1 wri2 wli3 wli2 wli wpi1 wpi2 wpi3 wpi4 wpi5 wpi6 wti1 wti2 wti3 wrl wga sbn
101 110 111 115 116 120 121 130 135 140 141 142 150 151 160 161 162 163 164 166 167 168 169 170 171 172 173 174 175 180 181
txt
185
vbl
199
2.5.3. Gestandaardiseerd naverkend bestand De opbouw van dit grafisch bestand wordt bekomen door de integratie van de drie voorgaande bestanden, weergegeven in de voorgaande tabellen. Het GIS-bestand met de straatnamen wordt niet ge•ntegreerd met het naverkend bestand in deze module.
rsc000107av0.doc
38
werkverslag testproject
Hoofdstuk 3: conversie van externe databanken 1. Inleiding In het testproject werd gebruik gemaakt van Cardib, de Vlaamse Hydrografische Atlas (VHA) en het Tele Atlas Streetnet bestand (TASN). Dit hoofdstuk beschrijft hoe de data worden ge‘xtraheerd en klaargemaakt voor verdere bewerking. Er wordt geen uitspraak gedaan over de gebruikservaringen van deze data.
2. Conversie van Cardib-bestanden voor de fotogrammetrie 2.1. HET CONVERSIEPROCES De te recupereren informatie wordt opgedeeld in twee groepen: 1. De geometrische elementen (gevels, rand van de rijbaan, riooldeksels, É); 2. De geregistreerde elementen (wegassen, huisnummers, straatnamen). De conversiemethodiek voor deze twee groepen is verschillend en zal bijgevolg apart besproken worden. 2.1.1. Geometrie De geometrische elementen worden verwerkt per vierkantshok. De originele uitsnijding wordt hierbij 1 behouden; het bestand Ô176203.dxfÕ leidt tot een bestand Ô176203.dgnÕ.
2.1.1.1. Beschrijving De gegevens doorlopen de volgende stappen: ·
Relevante dxf-layers worden geselecteerd (zie tabel 1);
·
Sommige elementen ondergaan een bijzondere bewerking, bvb. gemene gevels worden in het GRB niet voorgesteld als een lijn maar als een aanzetpunt in de voorgevel;
·
De resulterende lagen worden samengebracht;
·
Aan deze elementen wordt een hoogte gekoppeld via het DHM à overgang van 2D naar 3D;
·
De gevellijnen worden voorzien van snappunten waarop zijgevels of gemene gevels moeten aansluiten;
·
De gegevens worden omgezet naar dgn-formaat.
2
1
De Cardib gegevens zijn versneden in vierkanthokken (1km op 1km). De cošrdinaten van de linkerbenedenhoek (Lambert 72 in km) zijn opgenomen in de naamgeving van het bestand. Vb. 176203 à x: 176000m; y: 203000m 2 DHM: Digitaal Hoogte Model: hoogtelijnenmodel dat aangeleverd werd door de fotogrammetrie
rsc000107av0.doc
39
werkverslag testproject
Cardib DXF-layer
Beschrijving Cardib-layer
GRB-entiteit
BB01 BB02 BB05 BB10 BR01 BR02 BR03 BR06 BR07 BR10 BR12 BW01 BW02 BT01
Gevel Gemene gevel Dakrand Fotogram. achtergevel Rand van de rijbaan Rand onverharde weg Brug Riooldeksel Verharde oever Mast Paal Waterrand As van een gracht Trein-, tram-, kraanspoor
GBV-GBG
WCZ WOZ KNW WRI WTG KNW WPI WTG WTL WRL
Tabel 1: Weerhouden Cardib-lagen voor het GRB
Opmerkingen 1. Indien er binnen een bepaald vierkantshok geen nuttige Cardib-elementen aanwezig zijn, wordt er geen dgn-bestand aangemaakt voor dit vierkanthok. Per project zal een lijst worden meegeleverd aan de fotogrammetrie die een overzicht geeft van de verwerkte bestanden binnen het projectgebied. Vb. 2 vierkantshokken van het project Herenthout Bestandsnaam
Resultaat
178205.dgn
OK
174203.dgn
NODATA
Tabel 2: OK = verwerkt; NODATA = geen nuttige informatie voor het GRB
2. Indien de elementen niet binnen het gebied vallen bedekt door het DHM worden ze niet verwerkt. Er wordt geen dgn-bestand aangemaakt (Resultaat in verwerk.log = NO).
2.1.1.2. Geautomatiseerde verwerking De verwerking gebeurt in ARC/INFO. De technische specificaties (structuur van directories en beschrijving van environment) worden weergegeven in 2.2. Opstarten De te behandelen Cardib dxf-bestanden voor een project worden in de directory $GRBDATA/proj<projectnr>/cardib geplaatst (input Cardib voor fotogrammetrie voor een bepaald project vb. proj1 voor Herenthout). Voor de verwerking worden volgende handelingen uitgevoerd : 1. De Cardib-bestanden worden verzameld in een ASCII lijst via: ll *.dxf >> cardib.lst (list alle dxf-bestanden en plaats ze in de ASCII-lijst cardib.lst) 2. De bestanden voor een bepaald project vb. Herenthout (nr = 1) worden verwerkt via: &r $CB/foto/verwerkkaarten cardib.lst 1 Scripts Het script verwerkkaarten.aml is het stuurprogramma. Van hieruit worden per vierkantshok volgende deelprogrammaÕs aangeroepen: ·
maakgevel.aml (combinatie van BB01, BB02, BB05, BB10) omvat verkortlijn.aml (verwerking van BB01: de hangende uiteinden van BB01 worden ingekort);
rsc000107av0.doc
40
werkverslag testproject ·
maakstraat.aml (nuttige elementen voor de wegbaan worden weerhouden zoals riooldeksels , verlichtingspalen, rand van de weg, É); omvat maakriool.aml (hoogte opgemeten door Cardib wordt aan riooldeksels gekoppeld)
·
maakhydro.aml (de begrenzing van de waterlopen en assen van de grachten worden geselecteerd); Opmerking: De hydrografie van Cardib is niet gebiedsdekkend, maar is opgenomen voor een zone van 20m aan de wegbaan. Toch is dit interessant voor het GRB o.w.v. de baangrachten. De restitutie ontvangt daarnaast ter aanvulling een extract uit de VHA en Streetnet om over een vollediger hydrografisch net van het projectgebied te beschikken.
·
maakspoor.aml (spoorrails worden weerhouden); Opmerking: De spoorbanen van Cardib zijn, zoals de hydrografie, slechts opgenomen voor een zone van 20m aan de wegbaan. Dit betekent dat de tramsporen binnen de wegbaan en de overwegen gerecupereerd kunnen worden voor het GRB.
·
mergecb.aml (alle weerhouden elementen van ŽŽn vierkantshok worden samengebracht in 1 coverage);
·
haalhoogte.aml (aan alle elementen wordt een hoogte gekoppeld via een grid GRBDHM; de gegevens worden 3D); Opmerking: Het DHM is ons aangeleverd door de fotogrammetrie als dxf-bestand $SUP/grbdhm.dxf. Dit dxfbestand wordt omgezet naar een grid $SUP/grbdhm via &r $GRB/maakdhm.aml.
·
maaksnap.aml (waar zijgevels of gemene gevels aansluiten aan de voorgevel wordt een snappunt geplaatst; dit vereenvoudigt de toevoeging van de nieuwe gevels op de restitutie; dxf-layer van snappunt = B999);
·
maakigds.aml (aanmaak van het design-bestand per vh). Opmerking: 1. De dgn-bestanden worden verzameld per project (aangeduid met een nummer) onder de directory $GRBDATA/proj<projectnr>/restitutie 2. Voor de omzetting van dxf- naar dgn-formaat wordt gebruik gemaakt van 2 tabellen: $SUP/cb2grb.txt (vertaling van Cardib-layer naar een link die samengesteld is uit DGN-level en DGN-color) $SUP/cbacode.txt (symbologie voor elke DGN-level) Indien deze tabellen niet bestaan kunnen zij gecre‘erd worden via: &r $CB/support/maakcb2grb &r $CB/support/maakcbacode Aanpassingen aan deze vertaling of deze symbologie kunnen via ÔviÕ gebeuren. De wijzigingen nemen effect na het opnieuw uitvoeren van het script. De inhoud van deze tabellen is: DXF-LAYER B999 B997 BB01 BB05 BB10 BR01 BR02 BR03 BR05
rsc000107av0.doc
LINK 12 30 1351 143 143 95 950 172 254
41
werkverslag testproject BR06 BR07 BR10 BR12 BT01 BW01 BW02
23 71 172 40 813 51 61
Tabel cb2grb: vertaling DXF-layer naar DGN-level Link 12 23 30 40 51 61 71 813 950 95 1351 143 172 254
Level 1 2 3 4 5 6 7 8 9 9 13 14 17 25
Color 2 3 0 0 1 1 1 13 50 5 51 3 2 4
style 0 0 0 0 0 0 0 0 0 0 1 3 0 0
Weight 5 5 0 5 0 1 2 0 0 0 3 0 0 0
Type 2 2 17 2 4 4 4 4 4 4 4 4 4 4
Tabel cbacode: symbologie (DGN-items)
rsc000107av0.doc
42
werkverslag testproject 2.1.1.3. Illustratie Figuur 1: Input voor conversie (bebouwing, wegranden, palen, É) Figuur 2: Output na conversie (gemene gevels = snappunten, É)
rsc000107av0.doc
43
werkverslag testproject 2.1.2. De geregistreerde elementen Onder de geregistreerde elementen worden het stratennet en het adressenbestand verstaan. Deze elementen worden projectmatig verwerkt. Het resultaat wordt weggeschreven in een bestand Ôwgn.dgnÕ voor elk project.
2.1.2.1.Beschrijving Tabel 3 geeft de geselecteerde Cardib-elementen weer en de naam van de GRB-entiteiten waarvoor zij bruikbaar zijn. Cardib-gegevens
Beschrijving
GRB-entiteit
BR05
Wegassen (dxf-layer)
WGN
.bb
Geg. bebouwing (ASCII)
GBG-ADR
.br1
Geg. straatnet (ASCII)
GBG-ADR
De gegevens doorlopen de volgende stappen: Voorbereiding De Cardib-gegevens worden eerst samengebracht voor gans het projectgebied alvorens de eigenlijke verwerking plaatsvindt: ·
De wegassen van gans het projectgebied worden uit de dxf-bestanden gefilterd en samengevoegd in ŽŽn ARC/INFO coverage ÔCBWGNÕ. De schijnknopen en gaten ter hoogte van de kaartbladgrenzen worden manueel verwijderd;
·
De .bb-bestanden (gegevens i.v.m. de bebouwing zoals huisnummers) en br1-bestanden (gegevens i.v.m. het stratennet zoals straatnummers en -namen) worden ingelezen in INFO en resulteren in de tabellen ÔBB.INFÕ en BR.INFÕ;
·
ÔCBWGNÕ en de twee INFO-tabellen vormen de input voor de eigenlijke verwerking.
Integratie van huisnummers in het wegenbestand ·
Vanuit ÔBB.INFÕ wordt er een puntencoverage ÔCBADRÕ aangemaakt. Deze punten staan binnen de omtrek van het gebouw met als attribuut het huisnummer;
·
ÔCBWGNÕ neemt deze huisnummers van ÔCBADRÕ op als annotatie;
·
Hoogte koppelen aan de elementen van ÔCBWGNÕ; Opmerking De wegassen en de huisnummers worden gebruikt tijdens de fotogrammetrische verwerking en dienen hiervoor gekoppeld te worden aan een hoogte (3D). De straatnamen daarentegen leveren geen bijdrage tijdens de restitutie. Zij worden nadien wel ge•ntegreerd met de restitutiegegevens om de naverkenning te vereenvoudigen (niet alle straatnamen dienen te worden genoteerd en de ori‘ntatie op terrein wordt gemakkelijker).
·
De gegevens worden omgezet naar dgn-formaat: wgn.dgn.
Opmerkingen 1. De elementen die niet binnen het gebied vallen, bedekt door het DHM, worden niet overgenomen; 2. Op dit ogenblik bestaat het wegennet uit ÔruweÕ wegverbindingen. De juiste topologie (plaatsing van de knopen volgens GRB-criteria), is nog niet ge•mplementeerd. Via overlays met gemeentegrenzen en overdracht van de nodige attributen kan deze topologie grotendeels automatisch gecre‘erd worden.
rsc000107av0.doc
44
werkverslag testproject 2.1.2.2. Geautomatiseerde verwerking De verwerking gebeurt in ARC/INFO. De technische specificaties (structuur van directories en beschrijving van environment) worden weergegeven in 2.2. Opstarten De .BB bestanden en .BR bestanden van de vierkanthokken voor een project worden toegevoegd in de directory $GRBDATA/proj
/cardib (input Cardib voor fotogrammetrie voor een bepaald project) naast de dxf-bestanden. Alle namen van de dxf-bestanden van het projectgebied worden verzameld in een ASCII-bestand via het commando: ll *.dxf >> anno.lst De verwerking van de geregistreerde elementen kan niet uitgevoerd worden via ŽŽn stuurprogramma vermits er een manuele tussenstap nodig is. In de voorbereidingsfase worden alle elementen voor gans het projectgebied vb. Herenthout (nr = 1) samengebracht via: &r $CB/foto/prepanno anno.lst 1 De eigenlijke verwerking nl. de integratie van de annotaties in de wegencoverage wordt opgestart door: &r $CB/foto/verwerkanno 1 Scripts DeelprogrammaÕs van prepanno.aml: ·
maakstraatnet.aml (script om het wegennet te extraheren uit Cardib-bestanden; aanmaak van CBWGN);
·
haalstraatcode.aml (de informatie uit de Cardib .BB en .BR1 bestanden wordt geconverteerd naar INFO-tabellen).
DeelprogrammaÕs van verwerkanno.aml: ·
maakadres.aml (aanmaak van de puntencoverage CBADR);
·
maaktekst.aml (het attribuut huisnummer van CBADR wordt als annotatie toegevoegd aan het wegennetwerk CBWGN);
·
omvat haalhoogte.aml (aan alle elementen wordt een hoogte gekoppeld via de grid GRBDHM; de gegevens worden 3D);
·
maakdgn.aml (aanmaak van het design-bestand).
Opmerking De specificaties voor de aanmaak van de grid GRBDHM en de gebruikte vertalingstabellen van Cardib- naar DGN-structuur kan je terugvinden bij de scripts voor de verwerking van de geometrie.
rsc000107av0.doc
45
werkverslag testproject 2.1.2.3. Illustratie
Figuur 3: Input voor conversie (BR05: wegassen)
x-cošrd
y-cošrd
richting
NIS
postcode
staatnr
Huisnr
178481.2
204782.93
6.19
13012
2270
1040
50
178559.07
204910.43
34.61
13012
2270
1040
37
178963.8
204434.38
273.62
13012
2270
1030
9A
Tabel 4: ASCII input BB-bestand
x-cošrd
y-cošrd
richting
NIS
postcode
straatnr
Straatnaam
Pos. snm
178034.6
204459.81
46.17
13012
2270
1040
Bergense stwg
G
178065.18
204433.82
46.17
13012
2270
1040
Bergense stwg
A
rsc000107av0.doc
46
werkverslag testproject 178617.18
204796.12
34.82
13012
2270
1040
Bergense stwg
G
Tabel 5: ASCII input BR-bestand
Figuur 4: Output van conversie: huisnummers ge•ntegreerd in wegenbestand
rsc000107av0.doc
47
werkverslag testproject 2.2. WERKOMGEVING 2.2.1. Directorystructuur
2.2.1.1. Plaats van de scripts ·
ConversieprogrammaÕs Cardib à fotogrammetrie: $GRBPROG/cardib/foto/verwerkkaarten.aml enz. Opmerking: Bij de conversie van Cardib-data wordt er ook gebruik gemaakt van scripts die niet specifiek geschreven zijn voor Cardib: $GRBPROG/grb/verkortlijn.aml /haalhoogte.aml
·
Aanmaak codetabellen (cb2grb en cbacode): $GRBPROG/support/maakcbacode.aml /maakcb2grb.aml
·
Aanmaak grbdhm (grid) uit dxf-bestand van de fotogrammetrie: $GRBPROG/dhm/maakdhm.aml
2.2.1.2. Plaats van de input data ·
Inputbestanden van Cardib $GRBDATA/proj/cardib/176205.dxf /176205.br1 /178204.dxf /178204.br1 /178204.bb enz.
·
ASCII-bestanden cbacode.txt en cb2grb.txt: $GRBPROG/support/cbacode.txt /cb2grb.txt
·
dxf-bestand van de fotogrammetrie voor de aanmaak van grbdhm: $GRBPROG/dhm/grbdhm.dxf
2.2.1.3. Plaats van de output data ·
Voor de fotogrammetrie:
- .dgn-bestanden geometrie per vierkantshok - wegassen en annotaties voor gans project (cbwgn.dgn)
$GRBDATA/proj/restitutie/176205.dgn /178204.dgn enz /cbwgn.dgn ·
INFO-tabellen (vertaling naar fotogrammetrie en symbologie): in de workspace $GRBPROG/support
·
grbdhm (grid): $GRBPROG/support/grbdhm
2.2.2.Logicals
rsc000107av0.doc
48
werkverslag testproject De werkomgeving wordt opgebouwd in de loginscript van deze gebruiker door definitite van de environment variabelen: $GRBPROG : /export/home/grb/prog (AML programmaÕs) $GRBDATA: /ocproj/alg/grb/data (verschillende data voor grb geordend per project) $CB : /export/home/grb/prog/cardib (verwerking van Cardib data) $GRB : /export/home/grb/prog/grb (generische programmaÕs) $SUP : /export/home/grb/prog/support (codetabellen, verwerkingsparameters) $ADM: /export/home/grb/prog/adm (extractie van de administratieve grenzen) $DHM: /export/home/grb/prog/dhm (aanmaak digitaal hoogtemodel)
rsc000107av0.doc
49
werkverslag testproject
3. Conversie van Cardib-bestanden voor de naverkenning 3.1. HET CONVERSIEPROCES De conversie van deze alfanumerieke informatie wordt pas uitgevoerd na het opkuisen van de restitutiegegevens. We maken gebruik van de coverage adm, resulterend uit de opkuisfase, die de limiet van het fotokoppel bevat. 3.1.1. Beschrijving De gegevens doorlopen de volgende stappen: ·
Vanuit BB.INF wordt een puntencoverage ÔHNRPTÕ aangemaakt. Deze punten staan binnen de omtrek van het gebouw met als attribuut het huisnummer (DXF-TEXT). Bijkomende kenmerken i.v.m. de grootte en de richting worden toegevoegd;
·
In BR.INF selecteren we de straatnamen die langs de as van de weg liggen. Er wordt een puntencoverage aangemaakt ÔSNMPTÕ. Deze punten liggen op de wegassen met als attribuut de straatnaam (DXF-TEXT);
·
We voegen de gegevens samen in de coverage ÔADRÕ (straatnamen en huisnummers voor gans het projectgebied); Opmerking: Deze coverage wordt aangemaakt tijdens de eerste keer dat het programma loopt voor een bepaald project. Voor alle volgende fotokoppels gelegen binnen dit projectgebied is de verwerking beperkt tot de selectie van de nodige huisnummers en straatnamen.
·
ÔADRÕ wordt ÔgecliptÕ met de limiet van het gerestitueerde fotokoppel à ÔADR_CLÕ;
·
Aanmaak van een dxf-bestand: Ôprojectnummer_foto1_foto2_t.dxfÕ vb. 1_194_193_t.dxf.
3.1.2. Geautomatiseerde verwerking De verwerking gebeurt in ARC/INFO. De technische specificaties (structuur van directories en beschrijving van environment) worden weergegeven in 3.2. Script Het programma wordt gestart met het commando: &r $CB/trn/maakadr_dxf <projectnummer_foto1_foto2> x-cošrd
y-cošrd
richting
NIS
postcode
staatnr
Huisnr
178481.2
204782.93
6.19
13012
2270
1040
50
178559.07
204910.43
34.61
13012
2270
1040
37
178963.8
204434.38
273.62
13012
2270
1030
9A
Tabel 1: ASCII input BB-bestand
x-cošrd
y-cošrd
richting
NIS
postcode
straatnr
Straatnaam
Pos. snm
178034.6
204459.81
46.17
13012
2270
1040
Bergense stwg
G
178065.18
204433.82
46.17
13012
2270
1040
Bergense stwg
A
178617.18
204796.12
34.82
13012
2270
1040
Bergense stwg
G
Tabel 2: ASCII input BR-bestand
rsc000107av0.doc
50
werkverslag testproject 3.1.3. Illustratie
Figuur 1: De huisnummers en straatnamen kunnen gecombineerd worden met de restitutiegegevens.
rsc000107av0.doc
51
werkverslag testproject 3.2. WERKOMGEVING 3.2.1. Directorystructuur
3.2.1.1. Plaats van het script $GRBPROG/cardib/trn/maakadr_dxf.aml
3.2.1.2. Plaats van de input data ·
Infobestanden (BB.INF en BR.INF) aangemaakt tijdens de conversie van de Cardib-data naar de fotogrammetrie (zie rapport rpm990726av0_cb.doc) $GRBPROG/cardib/foto/proj/info
·
De coverage die de limiet van het fotokoppel omvat: $GRBDATA/proj%pj%/foto1_foto2/restitutie/adm
3.2.1.3. Plaats van de output data $GRBDATA/proj/naverkenning/proj_foto1_foto2_t.dxf 3.2.2. Logicals Het conversieprogramma kan uitgevoerd worden door iedere gebruiker met een login op de SUN ocho1. De werkomgeving wordt opgebouwd in de loginscript van deze gebruiker door definitie van de environment variabelen: $GRBPROG : /export/home/grb/prog (AML programma«s) $GRBDATA : /ocproj/alg/grb/data (verschillende data voor grb geordend per project) $GRBTEXT: /ocproj/alg/grb/text (informatie per project) $CB: /export/home/grb/prog/cardib (verwerking van Cardib data) $GRB: /export/home/grb/prog/grb (generische programma«s) $SUP: /export/home/grb/prog/support (codetabellen, verwerkingsparameters) $ADM: /export/home/grb/prog/adm (extractie van de administratieve grenzen) $DHM: /export/home/grb/prog/dhm (aanmaak digitaal hoogtemodel)
rsc000107av0.doc
52
werkverslag testproject
4. Vlaamse Hydrografische Atlas en Tele Atlas Streetnet 4.1. HET CONVERSIEPROCES De hydrografische elementen worden verwerkt per project (gemeente). Het proces verloopt volledig automatisch en leidt tot een bestand Ôwtr.dgnÕ. 4.1.1. Beschrijving De gegevens doorlopen de volgende stappen: ·
Selectie van de gemeentegrens uit de coverage adm van TASN;
·
Deze grens gebruiken we om de juiste hydrografische elementen te extraheren uit de middenschalige databanken;
·
Assen van de waterlopen zijn afkomstig uit de VHA; boorden van brede waterlopen, vijvers en meren worden uit TASN gehaald;
·
De informatie wordt samengebracht en er wordt aan deze elementen een hoogte gekoppeld via het DHM à overgang van 2D naar 3D;
·
De gegevens worden omgezet naar dgn-formaat.
4.1.2. Geautomatiseerde verwerking De verwerking gebeurt in ARC/INFO. De technische specificaties (structuur van directories en beschrijving van environment) worden weergegeven in 4.2. Opstarten De hydrografie voor een bepaald project vb. Herenthout (nr = 1) wordt behandeld via: &r $GRBPROG/hydro/foto/verwerkhyd 1 Scripts Het script verwerkhyd.aml is het stuurprogramma. Van hieruit worden de volgende deelprogrammaÕs aangeroepen: ·
haalgemeente.aml (de gemeentegrens wordt geselecteerd uit TASN); Opmerking Onder $GRBTEXT staat per project de nodige informatie (bron inputdata, projectgebied, datum,). Op deze manier kan het ingegeven projectnummer gekoppeld worden aan de juiste gemeente.
·
haalwater.aml (clip maken in de VHA en TASN met de gemeentegrens);
·
haalhoogte.aml (aan alle elementen wordt een hoogte gekoppeld via een grid GRBDHM; de gegevens worden 3D); Opmerking: Het DHM is ons aangeleverd door de fotogrammetrie als dxf-bestand $SUP/grbdhm.dxf. Dit dxfbestand wordt omgezet naar een grid $SUP/grbdhm via: &r $GRB/maakdhm.aml
·
maakigds.aml (aanmaak van het design-bestand per project: Ôwtr.dgnÕ). Opmerking 1. De volledige pathname : $GRBDATA/proj<projectnr>/restitutie/wtr.dgn; 2. Voor de omzetting van naar dgn-formaat wordt gebruik gemaakt van 2 tabellen: $SUP/hyd2grb.txt (vertaling van layer naar een link die samengesteld is uit DGN-level en DGN-color) $SUP/hydacode.txt (symbologie voor elke DGN-level)
rsc000107av0.doc
53
werkverslag testproject Indien deze tabellen niet bestaan kunnen zij gecre‘erd worden via: &r $SUP/maakhyd2grb &r $SUP/maakhydacode Aanpassingen aan deze vertaling of deze symbologie kunnen via ÔviÕ gebeuren. De wijzigingen nemen effect na het opnieuw uitvoeren van het script. De inhoud van deze tabellen is: LAYER
LINK
SK
51
VHA
61
Tabel hyd2grb: vertaling layer naar DGN-level
Link
Level
Color
style
Weight
Type
51
5
1
0
0
4
61
6
1
0
1
4
Tabel hydacode: symbologie (DGN-items)
4.1.3. Illustratie
Figuur 1: Extractie hydrografie (assen van VHA; polygonen van TASN)
rsc000107av0.doc
54
werkverslag testproject 4.2. WERKOMGEVING 4.2.1. Directorystructuur
4.2.1.1. Plaats van de scripts ·
ConversieprogrammaÕs hydrografie à fotogrammetrie: $GRBPROG/hydro/foto/verwerkhyd.aml haalwater.aml Opmerking: Bij de conversie van de hydrografie wordt er ook gebruik gemaakt van scripts die niet specifiek geschreven zijn voor deze conversie: $GRBPROG/adm/haalgemeente.aml /grb/haalhoogte.aml /maakigds.aml
·
Aanmaak codetabellen (hyd2grb en hydacode): $GRBPROG/support/maakhydacode.aml /maakhyd2grb.aml
·
Aanmaak grbdhm (grid) uit dxf-bestand van de fotogrammetrie: $GRBPROG/dhm/maakdhm.aml
4.2.1.2. Plaats van de input data ·
Inputbestanden van VHA en TASN: /ocproj/geodb/skelet/skel98/adm (TASN coverage met de gemeentegrenzen van Vlaanderen) /ocproj/geodb/hydro/vha991 (assen van waterlopen uit VHA) $GRBPROG/hydro/foto/hydro-sk (coverage die enkel de polygonen van de hydrografie van TASN bevat)
·
ASCII-bestanden hydacode.txt en hyd2grb.txt: $GRBPROG/support/hydacode.txt /hyd2grb.txt
·
Dxf-bestand van de fotogrammetrie voor de aanmaak van grbdhm: $GRBPROG/dhm/grbdhm.dxf
4.2.1.3. Plaats van de output data ·
Voor de fotogrammetrie: dgn-bestand Ôwtr.dgnÕ per project $GRBDATA/proj<projectnr>/restitutie/wtr.dgn
·
INFO-tabellen (vertaling naar fotogrammetrie en symbologie): in de workspace $GRBPROG/support
·
grbdhm (grid): $GRBPROG/dhm/grbdhm
rsc000107av0.doc
55
werkverslag testproject 4.2.2. Logicals De werkomgeving wordt opgebouwd in de loginscript van deze gebruiker door definitie van de environment variabelen: $GRBPROG : /export/home/grb/prog (AML programma«s) $GRBDATA : /ocproj/alg/grb/data (verschillende data voor grb geordend per project) $GRBTEXT: /ocproj/alg/grb/text (informatie per project) $CB: /export/home/grb/prog/cardib (verwerking van Cardib data) $GRB: /export/home/grb/prog/grb (generische programma«s) $SUP: /export/home/grb/prog/support (codetabellen, verwerkingsparameters) $ADM: /export/home/grb/prog/adm (extractie van de administratieve grenzen) $DHM: /export/home/grb/prog/dhm (aanmaak digitaal hoogtemodel)
rsc000107av0.doc
56
werkverslag testproject
Hoofdstuk 4: dataverwerking 1. Inleiding De dataverwerkingsmodule werd ontwikkeld in het kader van het GRB-testproject Herenthout-Bouwel. Deze module is een verzameling van softwarecomponenten die instaan voor de verwerking van GRBgegevens (zowel input als output) op volgende niveaus: ·
Verwerken van de data afkomstig van de fotogrammetrie, de resulterende gegevens worden doorgegeven aan de naverkenning;
·
Verwerken van de gegevens afkomstig van de naverkenning. Het resultaat van deze verwerkingsstap zijn aan aantal datasets die klaar zijn om in de GRB databank ingevoerd te worden;
·
Interactie met de databank.
Het gros van de gebruikte softwarecomponenten zijn ge•mplementeerd als ARC/INFO 7.2.1 amlscripts. De dataverwerking verloopt automatisch als batch-procedure op een SUN SPARC-server 1000, tenzij anders vermeld.
2. Werkomgeving De werkomgeving bevat de volgende componenten: 1. De directorystructuur; 2. De naamgevingsconventie; 3. De programmeeromgeving; 4. De gebruiksomgeving.
2.1 DIRECTORYSTRUCTUUR Er zijn twee directory bomen aanwezig: De eerste directory boom bevat alle broncodes, scripts, stuurtabellen e.d. die in de dataverwerkingsmodule gebruikt worden: ·
De topdirectory wordt gerefereerd via de environment variabele $GRBPROG, deze wordt in de login script van de gebruiker opgegeven;
·
Omdat de meeste verwerkingen niet omgevingsspecifiek zijn, wordt dit niet in de &atool zoeklijst opgenomen en moet dus steeds gedefinieerd worden;
·
Onder de topdirectory is verdere onderverdeling im mappen voorzien op basis van entiteit (gbg, kad, knw, mkr, trn, wbn, wgn en wtr), algemene structuren (grb, kwc en support) en externe bestanden (adm, cardib en hydro).
Schematisch: Top Directory $GRBPROG/
rsc000107av0.doc
Onderverdeling gbg/ kad/ knw/ mkr/ trn/ wbn/ wgn/ wtr/ grb/ kwc/ support/ adm/ cardib/
Functie verwerking gbg-data verwerking kad-data verwerking knw-data verwerking mkr-data verwerking trn-data verwerking wbn-data verwerking wgn-data verwerking wtr-data generische programmaÕs automatisering kwaliteitscontrole codetabellen, verwerkingsparameters extractie van adminstratieve grenzen verwerking van cardib-data
Voorbeeld maakgbg.aml leeskad.aml maakknw.aml maakmkv.aml maaktrn.aml maakwga.aml maakwgn.aml maakwta.aml leesdxf.aml maaksteekproef.aml acode.txt, grb_params.tag haalgemeente.aml maakkaart.aml
57
werkverslag testproject dhm/ hydro/
aanmaak van DHM verwerking VHA(*)-data
maakdhm.aml haalwater.aml
De tweede directory boom bevat alle bestanden die bij de gegevensverwerking worden aangemaakt; de data: ·
De topdirectory wordt gerefereerd via de environment variabele $GRBDATA, deze wordt in de login script van de gebruiker opgegeven;
·
Een eerste onderverdeling gebeurt op basis van een project. Ieder project ontvangt een uniek volgnummer (zo: proj);
·
Naast de project directories is er een directory ÒtextÓ voorzien. Die bevat project gebonden documentatiebestanden;
·
Elke projectmap is op zijn beurt onderverdeeld in de volgende submappen: ·
Een ÒsupportÓ directory bevat de projectmatige bestanden en coverages;
·
Een ÒrestitutieÓ directory fungeert als uitwisselingsmap voor data van/naar de restitutie;
·
Een ÒnaverkenningÓ directory fungeert als uitwisselingsmap voor data van/naar de naverkenning;
·
Een ÒorthosÓ directory bevat de orthofoto bestanden;
·
Een ÒcardibÓ directory bevat de cardib data (als die voorhanden zijn);
·
Een ÒhydroÓ directory bevat data afgeleid van de Vlaamse Hydrologische Atlas (VHA);
·
Een ÒkaartÓ directory bevat basiskaarten afgeleid van de cardib bestanden;
·
De verdere onderverdeling gebeurt op basis van dossier-toeleveringseenheden. Bij de hier gevolgde werkwijze is het stereopaar de toeleveringseenheid. Deze mappen krijgen dan ook de naam _ , naar de nummers van de fotoÕs die het stereopaar samenstellen. De stereopaar directories worden op hun beurt onderverdeeld in een map ÒrestitutieÓ en ÒnaverkenningÓ.
Schematisch: Top directory $GRBDATA/proj/
Onderverdeling support/
restitutie/
grbadm/ tasn/ grbzid/ É 1_192_191.dgn
naverkenning/
1_193_192.dgn wtr.dgn wgn.dgn É 1_192_191_c.dgn
orthos/
cardib/
hydro/ kaart/ 192_191/restitutie
rsc000107av0.doc
Bestanden
1_192_191_t.dxf 1_192_191_t.sta É 1770_2030.sid 1770_2030.sdw 1770_2035.sid 1770_2035.sdw É 174202.bb 174202.br1 174202.dxf É krt174202.dxf krt174202.dgn É gbg/ knw/
Functie administratieve grenzen Teleatlas Streetnet overzicht verwerkte zones gegevens fotogrammetrie
van
de
gegevens fotogrammetrie
voor
de
gegevens voor de naverkenning gegevens van de naverkenning statistieken orthofoto's ÒworldÓ Ð bestanden
cardib gegevens
VHA data (coverage) basiskaarten (dxf-formaat) basiskaarten (dgn-formaat) entiteiten na fotogrammetrie (coverages)
58
werkverslag testproject
192_191/naverkenning
$GRBDATA/text/
wri/ wta/ É gbg/ knw/ wri/ wta/ É
entiteiten na naverkenning (coverages)
proj<1> proj<2> É
2.2 NAAMGEVINGSCONVENTIE VOOR DE SOFTWAREMODULES ·
De naamgeving maakt zoveel mogelijk gebruik van codes en geen beschrijvingen;
·
De naamgeving voor databestanden wordt in het conceptueel model ontwikkeld;
·
Scriptnamen weerspiegelen de operaties die ze uitvoeren: ·
Het eindresultaat ligt vast in de directory plaats en dient niet vermeld;
·
De algemene syntax wordt <werkwoord>{conditie};
·
Bijvoorbeeld: $GRBPROG/grb/verlenglijn.aml, $GRBPROG/gbg/maakpoly.aml.
2.3 PROGRAMMEEROMGEVING Algemeen hebben alle programmaÕs of scripts de volgende onderdelen header &args driver &return &routine ctrl &routine init &routine exec &routine stop
commentaar en beschrijving ontvangt externe argumenten roept de verschillende deelroutines aan controleert of alles aanwezig is en stopt indien niet bereidt de omgeving voor voert de eigenlijke processing uit (meerdere mogelijk) ruimt alles op
Bovendien : ·
Meerdere exec routines kunnen uiteraard in een enkel bestand voorkomen;
·
Tijdelijke tussenstappen worden bij voorkeur net voor gebruik gecontroleerd/aangemaakt en direct na gebruik verwijderd (dus in de exec routine);
·
Complexe exec routines kunnen op hun beurt aanleiding geven tot opslag in een nieuw script. In principe geldt dat ieder stuk software dat meer dan 3 maal gebruikt / aangepast wordt in een aparte routine of generisch script wordt gebracht (zie verder: ÒutilitiesÓ);
·
Ieder verwerkend script maakt een testmelding of log van de uitgevoerde activiteiten / aangemaakte elementen, deze log wordt bij de data geplaatst;
·
Versiebeheer: In de ÒheaderÓ van elk script is er een mechanisme voor versiebeheer voorzien. Elke verandering aan de code heeft een verandering van het versienummer tot gevolg. Dit wordt door middel van een commentaarlijn in het script als volgt gedocumenteerd: ·
Het versienummer is opgebouwd uit drie cijfers, gescheiden door een punt (X.Y.Z);
·
De initi‘le versie krijgt als versienummer 0.0.0;
·
Het derde cijfer (Z) is het Òmaintenance releaseÓ nummer. Dit cijfer wordt met 1 verhoogd voor wijzigingen die geen verandering aan de functionaliteit van het programma tot gevolg hebben (commentaar, afhandeling van foutmeldingenÉ);
·
Het tweede cijfer (Y) is het Òminor releaseÓ nummer. Dit wordt verhoogd bij kleine wijzigingen (naamgevingconventie, aanpassingen van externe argumenten, wijzigingen aan de gebruikersinterfaceÉ);
·
Het eerste cijfer (X) is het Òmajor releaseÓ nummer. Dit wordt verhoogd bij fundamentele wijzigingen aan de functionaliteit;
rsc000107av0.doc
59
werkverslag testproject
·
·
Naast het nieuwe versienummer bevat de commentaarlijn de initialen van de programmeur die de wijziging aanbrengt, dat datum van de wijziging en een korte beschrijving van de wijziging;
·
Bijvoorbeeld: 0.2.0 LVA
140999 $GRB[user] vervangen door $GRBDATA;
Parameterbestand: Om ÒhardÓ-codering van verwerkingparameters in de AML-scripts te vermijden, wordt gebruik gemaakt van een zgn. parameterbestand. Dit is een tekstbestand: $GRBPROG/support/grb_params.tag Elke tekstlijn is van de vorm: parameter_naam: parameter_waarde; Voorbeeld:
gbg_intersectieafstand: 0.1; gbg_verlengingafstand: 0.2; gbg_smeltsnapafstand: 0.5; gbg_voorgevelverlengafstand: 1.0; grb_maakadm_fuzzy: 1.0;
Met behulp van de opdracht: &run $GRBPROG/grb/haal_parameter_waarde <parameternaam> kan de waarde van de desbetreffende parameter opgevraagd worden: haal_parameter_waarde definieert een globale variabele: Ò.parmvalueÓ die de waarde van de parameter bevat. Voorbeeld: na het uitvoeren van Ò&run $GRBPROG/grb/haal_parameter_waarde gbg_intersectieafstandÓ is de waarde van Ò.parmvalueÓ gelijk aan Ò0.1Ó.
2.4 GEBRUIKSOMGEVING · · · · ·
De gebruiksomgeving wordt opgebouwd in de loginscript van de gebruiker door definitie van de environment variabelen $GRBPROG en $GRBDATA; Iedere handeling die routinematig uitgevoerd wordt dient in een script gegoten. Wat niet automatisch verwerkt wordt, dient interactief behandeld; Tussen verschillende verwerkingsstappen kan een visuele evaluatie ingelast worden (Arcplot routines). De aangemaakte gegevens dienen minstens met het originele materiaal vergeleken; Daar ieder dossier overeenkomt met een directory, moeten op het einde van de procedures de logs de verwerking van alle elementen aantonen; Coverages zijn te beschouwen als tijdelijke groeperingen van gelijkaardige elementen. De kern van de verwerking gebeurt via individuele elementen of exemplaren.
3. Verwerking van de gegevens van de fotogrammetrie 3.1 INLEIDING Op dit niveau worden de gegevens, afkomstig van de fotogrammetrie, opgekuist en geconverteerd naar een formaat dat direct door de naverkenning kan gebruikt worden. De uitwisselingseenheid is het stereokoppel. De restitutiegegevens worden aangeleverd als een microstation design-bestand (dgn) bestand. Tijdens de opkuisoperatie worden de gegevens opgesplitst in entiteiten en als ARC/INFO coverages bewaard. Deze coverages zijn te beschouwen als tijdelijke groeperingen van gelijkaardige elementen. De kern van de verwerking gebeurt via individuele elementen of exemplaren. Het uiteindelijke resultaat van deze operatie wordt aan de module topografie doorgegeven onder de vorm van een aantal autocad-dxf bestanden, en een zgn. ÒstatistiekenÓ-bestand (zie verder).
3.2 INPUT ·
Formaat: Microstation Designfile (dgn);
·
Teneinde gegevensverlies te vermijden worden 3D-bestanden aangeleverd;
·
Naamgeving: het input-bestand wordt door de fotogrammetrie operator in de map $GRBDATA/proj /restitutie geplaatsts en heeft als naam __.dgn
rsc000107av0.doc
60
werkverslag testproject Hierbij staat voor het projectnummer (1 voor Herenthout-Bouwel). De nummers en zijn de nummers van de fotoÕs die het stereokoppel samenstellen; vb: $GRBDATA/proj1/restitutie/1_192_192.dgn ·
Codering: de data in een DGN-bestand is georganiseerd in ÒlevelsÓ die elk een aantal tekenobjecten of entiteiten kunnen bevatten. Daarnaast bevat het bestand nog een aantal grafische attributen en eventueel nog verwijzingen naar databank attributen in externe databanken. Het verband tussen de GBR-entiteiten en de gebruikte DGN-levels en de grafische attributen worden opgesomd in onderstaande tabel: DGN-level
GRBentiteit
Inhoud
Color
Style
Weight
10 11 12 13 14 15 16 17 18 20 21 22 23 25 27 28 29 30 31 32 33
GBG GBG GBG GBG GBG GBG GBA KNW KNW WBN WBN WBN WBN WGN WGN SBN SBN WOZ WOZ WCZ WCZ
3 3 51 51 3 51 101 2 2 47 47 95 95 4 4 13 13 50 50 5 5
0 1 0 1 3 3 0 0 1 0 1 0 1 0 pointcel 0 1 0 1 0 1
0 3 0 3 0 0 0 0 3 0 3 0 3 0 0 0 3 0 3 0 3
38 39 40 41
WLI WLI WLI WLI
6 6 6 6
3 2 0 1
0 0 0 3
42 43
WTI WTI
70 70
0 1
0 3
45 46 47 48 49 50 52 53 54 61 55 59 51 57 60
TRN TRN WRL WRL WGA WRI WTG WTG WTG WTG WTL WTL WPI WPI GRP
Dakrand Dakoversteek Constructiegevel Terrestrische recup gevel (BB01) Fotogrammetrische recup gevel Cardib gevel na te verkennen Gebouwaanhorigheid Kunstwerk Kunstwerk met naverkenning Wegsectie Wegsectie met naverkenning Kruispuntzone Kruispuntzone met naverkenning Wegverbinding Wegknoop Spoorbaan Spoorbaan met naverkenning Onverharde zone Onverharde zone met naverkenning Zwakke weggebruikerzone Zwakke weggebruikerzone met naverkenning Longitudinale weginrichting Ð vangrail Longitudinale weginrichting Ð vangmuur Longitudinale weginrichting Longitudinale weginrichting met naverkenning Transversale weginrichting T r a ns v e r s al e we g in rich t in g me t naverkenning Terrein Terrein met naverkenning Spoorrails Spoorrails met naverkenning Wegaanhorigheid Riooldeksel Watergang onverharde oevers Watergang afwisselend verharde oevers Watergang verharde oevers Watergang met naverkenning Gracht Gracht met naverkenning Elec-tele-licht-verkeerslicht Brandkraan Probleemzone
125 125 9 9 11 4 1 1 1 1 1 1 0 3 120
0 1 0 1 0 pointcel 0 0 0 1 0 1 pointcel pointcel 1
0 3 0 3 0 0 0 1 2 3 0 3 0 0 3
62 63 58
WTA GRZ
57 14
4 0
3 0
rsc000107av0.doc
As van geregistreerde waterloop Grens karteringszone Tekstelementen
61
werkverslag testproject TRN
XX 01: Verhard 02: Onverhard en onbegroeid 03: Begroeid, gras 04: Begroeid, kruidachtig 05: Begroeid, houtig 06: Begroeid, gemengd WGA
0
t##-##
0
YY 01: Verkeer 02: Ingericht groen
0 0
t##-## t##-##
0 0
03: Natuur 04: Militair
0 0
t##-## t##-##
0 0
05: Braakliggend
0
t##-##
0
06: Burgerlijk
0
t##-##
0
07: Exploitatie
0 0
t##-## w##
0 0
0 0 0 0 0 0
w## w## w## w## w## #0#
0 0 0 0 0 0
0
#0#
0
0 0 0 0 0
#0# #0# #0# #0# k##
0 0 0 0 0
k## k## k## k## k## k## k## k## k## k## k## k## k## g#
0 0 0 0 0 0 0 0 0 0 0 0 0 0
g# g# g# g# g0
0 0 0 0 0
tXX-YY
wXX XX 01: Bushokje 02: Telefoonhokje 03: Overdekte fietsstalling 04: Verkeerscabine 05: Bergplaats
KNW
x0Y x (ACT) l: Ingericht kunstwerk a: Wegas b: Wegbaan s: Spoorbaan r: Wateras
KNW
Y (FNC) 1: Gedragen 2: Overbrugd 3: Doorgelaten 4: Opgehouden 5: Ingericht
kXX XX (TPC) 01: Overbrugging 02: Waterstaatkundig werk (sluis) 03: Waterkerende constructie 04: Cultuurhistorisch monument 05: Hoogspanningmast 06: Pijler 07: Rooster 08: Schoorsteen 09: Koeltoren 10: Opslagtank/silo 11: Elektriciteitscabine 12: Watertoren 13: Tunnelmond
GBA
gX
0 0 0 0 0 0 0 0 0 0 0 0 0 0
GBG
X 1: Trap 2: Loopbrug 3: Onderkeldering 4: Afdak g0: Binnenkoer
0 0 0 0 0
Tabel 1: IGDS-codes gebruikt in het DGN-bestand van de restitutie.
·
Merk op dat de tekstelementen zich allen in laag 58 bevinden. Deze tekstelementen worden gebruikt om bepaalde database attributen, zoals bvb. Òtype wegaanhorigheidÓ, aan elementen te koppelen. De conventie voor het formaat van de gebruikte tekstelementen is strikt vastgelegd in de kolom ÒstyleÓ. De domeinen van deze attributen vindt u in de kolom ÒinhoudÓ.
·
grb_igdscodes.txt is een ASCII-bestand dat door de verschillende verwerkingsmodules gebruikt wordt om de gegevens input gegevens in GRB-entiteiten te scheiden. Dit bestand is een weergave van bovenstaande tabel. Het exacte formaat wordt verder beschreven.
rsc000107av0.doc
62
werkverslag testproject 3.3 OUTPUT 3.3.1. Gegevensbestanden voor de naverkenning ·
Formaat: Autocad DXF voor de gegevens (.dxf);
·
De cošrdinaten zijn 3D voor de puntobjecten, 2D voor lijn en annotatieobjecten;
·
Naamgeving: het outputbestand wordt door de dataverwerkingsmodule in de map $GRBDATA/proj /naverkenning geplaatst en heeft als naam ___c.dgn Hierbij staat voor het projectnummer (1 voor Herenthout-Bouwel). De nummers en zijn de nummers van de fotoÕs die het stereokoppel samenstellen. vb: $GRBDATA/proj1/restitutie/1_192_192_c.dgn Het kan daar door de naverkenning opgehaald worden voor verdere verwerking;
·
Codering: de data in een DXF-bestand is georganiseerd in een ÒlayersÓ die elk een aantal tekenobjecten of entiteiten kunnen bevatten. Daarnaast bevat het bestand nog een aantal grafische attributen. Elk layer wordt aangeduid met een naam. De namen die hier gebuikt worden komen overeen met de DGN-levels uit bovenstaande Tabel 1. Zo worden de tekstelementen opgeslagen in een layer met naam Ò58Ó. Voor de grafische attributen verwijzen wij naar de module naverkenning.
3.3.2. Coverages ·
Formaat: ARC/INFO 7.2 coverages;
·
Naamgeving: zoals eerder vermeld zijn de coverages een tijdelijke verzameling van objecten, gegroepeerd volgend de specificaties van de GRB-entiteiten. De respectieve coverages krijgen de drieletter-acronymen als naam. De workspace waar de coverages zich bevinden is: $GRBDATA/proj/_/restitutie;
·
Codering: elk type object krijgt andere attributen. Dit wordt in paragraaf 3.4 in detail besproken;
·
Voorbeeld: $GRBDATA/proj1/216_217/gbg;
3.3.3. Statistieken ·
Formaat: ASCII-bestand. Elke tekstlijn bevat drie of vier elementen: ·
Het layernummer in het corresponderende DXF-bestand;
·
Het corresponderende GRB-entiteitsacronym;
·
Een getal (aantal, lengte of oppervlakte);
·
Eventueel een ÒmÓ (voor lengtes in meter) of een ÒsqmÓ (voor oppervlaktes in vierkante meter);
·
Naamgeving: ___c.sta in de map $GRBDATA/proj /naverkenning;
·
Inhoud:
·
·
Aantal GBG-gegevens in de verschillende layers (dus opgedeeld volgens geveltype);
·
Aantal kunstwerken, gebouwaanhorigheden, wegaanhorigheden en terreinen;
·
Aantal meter wegbaan, wegverbinding, wegopdeling en weginrichting;
·
Aantal riooldeksels en puntvormige weginrichtingen;
·
Aantal meter watergang, wateras en gracht;
·
Aantal probleemzones;
·
Oppervlakte van de gekarteerde zone;
Voorbeeld: $GRBDATA/proj1/naverkenning/1_216_217_c.sta 10 gbg 67 11 gbg 205 12 gbg 178 13 gbg 61
rsc000107av0.doc
63
werkverslag testproject 15 gbg 87 20 wbn 3140 m 21 wbn 1566 m 22 wbn 400 m 23 wbn 459 m 25 wgn 2664 m 30 woz 2811 m 31 woz 763 m 32 wcz 1529 m 33 wcz 198 m 40 wli 17 m 41 wli 82 m 50 wri 28 51 wpi 50 52 wtg 2487 m 61 wtg 864 m 55 wtl 1039 m 59 wtl 365 m 63 adm 367162 sqm
3.4 VERWERKING De driver ·
De verwerking gebeurt volautomatisch door opstarten van ŽŽn enkel ARC/INFO aml-script:
·
Versie:
·
Gebruik (in een ARC shell):
$GRBPROG/grb/kuisdgn.aml; 1.1.0
26-okt-1999;
&run $GRBPROG/grb/kuisdgn.aml ·
is het DGN-bestand (voldoet aan de naamgevingsconventie uit paragraaf 3.2);
·
bepaalt het type outputbestand: DGN: output is een DGN-bestand. Deze aanpak heeft een extra conversiestap binnen de naverkenning tot gevolg en wordt bijgevolg niet meer gebruikt. SHAPE: output is een set shape-bestanden (nvk_lin.shp, nvk_pts.shp en nvk_ann.shp) in de map $GRBDATA/proj/_/restitutie/ Deze bestanden worden nadien dmv. een FME (Feature Manipulation Engine) script geconverteerd naar het output DXF-bestand (zie verder);
·
De aanmaak van de entiteiten-coverages en het statistiek-bestand vergt geen bijkomende handelingen;
·
Voorbeeld: &run $GRBPROG/grb/kuisdgn.aml $GRBDATA/proj1/restitutie/1_216_217 SHAPE.
3.4.1. Conversie naar DXF-formaat · FME is een programma ontwikkeld door SAFE-software (http:\\www.safe.com). Het laat toe om de conversie van features tussen verschillende gangbare dataformaten op een heel gecontroleerde manier te laten verlopen. Om die reden werd de voorkeur gegeven aan FME boven de standaard ARC/INFO-dataconverters zoals ARCDXF of ARCIGDS; · Opmerking: FME is enkel beschikbaar in een DOS/Windows omgeving. Dit betekent dat de shape-bestanden eerst naar een PC moeten getransfereerd worden. Na conversie zal het resultaat terug op de SUN-machine geplaatst worden. Op dit moment gebeurt de datatransfer van/naar de
rsc000107av0.doc
64
werkverslag testproject Windows machine manueel (via een FTP-sessie). geautomatiseerd worden via FTP-scripting;
Eventueel kan de ganse procedure
· Bestanden nodig in de windows omgeving: · shp2sfx.bat: DOS-batch file die de FME-conversie opstart; · grb_shp2dxf.fme: FME-ÒmappingÓ bestand die de conversie definieert; · dxfMACROs.fmi: ÒincludeÓ-bestand met voorgedefinieerde macroÕs; · dataverwerking_in.dxf: ÒtemplateÓ-dxf bestand, bevat de definitie van de grafische symbologie voor de naverkenning; · Versie:
0.0.0
20-okt-1999;
· Gebruik (in een MS-DOS venster): shp2dxf Dit commando converteert nvk_lin.shp, nvk_pts.shp en nvk_ann.shp naar naverkenning.dxf. Dit is een Autocad R14 compatibel bestand dat via een FTP-commando naar de SUN-machine wordt teruggestuurd. Tenslotte wordt de naam aangepast aan de conventies. DeelprogrammaÕs · De driver (kuisdgn.aml) roept verschillende deelprogrammaÕs op. Deze worden in deze paragraaf uitvoerig toegelicht; · Naast de deelprogrammaÕs worden er nog een aantal generische programmaÕs gebruikt. Een lijst van deze ÒutilitiesÓ vindt u in de volgende paragraaf; · $GRBPROG/grb/leesdgn · Gebruik: &run $GRBPROG/grb/leesdgn <projectnr> ; · Defaults: geen; · Voorbeeld: &run $GRBPROG/grb/leesdgn 1_216_217.dgn 1 216_217; · Versie:
0.2.0
4-okt-1999;
· Functie: - Conversie van het DGN bestand naar 1 enkele coverage (IGDS); · Builden van de coverage voor lijnen, punten en een annotatieklasse (ANNO.IGDS); · Toevoegen van een extra attribuut (LICD Ð het DGN-level) aan de lijn, punt en annotatie attributentabellen. Dit attribuut zal instaan voor de verdere opsplitsing in GRB-entiteiten; · $GRBPROG/grb/maakzone · Gebruik: &run $GRBPROG/grb/maakzone <projectnr>; · Defaults: geen; · Voorbeeld: &run $GRBPROG/grb/maakzone 1; · Versie:
0.3.0
4-okt-1999;
· Functie: - Aanmaken van de polygoon-coverage ADM. Deze gesloten polygoon definieert de grens van de karteringszone. · Opmerking: in de laatste versie van het GRB-concept wordt de grens van de karteringszone aangeduid met GRZ. Dit zou een betere naam zijn voor ADM. Door de impact van deze naamverandering op de totale dataverwerkingsmodule is dit (nog) niet ge•mplementeerd; · Toevoegen van de aldus bekomen polygoon aan de polygooncoverage: $GRBDATA/proj/support/GRBZID. Deze bevat op die manier een inventaris van de reeds verwerkte zones binnen een project; Werkwijze: Selectie van de lijnelementen met LICD=63 uit de coverage IGDS en builden van de polygonen. De Òfuzzy_toleranceÓ bij het ÒbuildÓ- commando wordt bepaald door de GRB-parameter Òadm_maakadm_fuzzyÓ (standaard op 1 meter) Dit gebeurt in de utility: $GRBPROG/grb/maakadm.aml Als de resulterende omtrek niet gesloten is, wordt de verwerking hier afgesloten! · Toevoegen van een GRBZID Ð attribuut. Dit tekstattribuut bevat de koppelcode van de desbetreffende zone;
rsc000107av0.doc
65
werkverslag testproject · Update van $GRBDATA/proj/support/GRBZID; · $GRBPROG/gbg/maakgbg.aml · Gebruik: &run $GRBPROG/gbg/maakgbg {} {}; · Defaults: = IGDS = GBG; · Voorbeeld: &run $GRBPROG/gbg/maakgbg IGDS GBG; · Versie:
1.0.1
6-okt-1999;
· Functie: - Aanmaken van de polygoon-coverage GBG (gebouwen) · Opkuisen van de gebouwpolygonen; · De LICD-code van elke gevel wordt in de AAT-tabel opgeslagen; · Toevoegen van polygoonattributen GBGTPC (gelijk aan 0 voor de binnenkoeren) en GBGGBC (gelijk aan 1 voor na te verkennen gebouwen.); · Werkwijze: - Selecteren van alle GBG-lijnelementen uit coverage IGDS (zie tabel 1) · Clean om polygonen te maken; · Verlengen van de ge•soleerde lijnen tot aan eventueel snijpunt met een andere lijn. De maximum afstand wordt gedefinieerd door de GRB-parameter gbg_intersectieafstand; · Nieuwe clean; · Verlengen van de overgebleven ge•soleerde lijnen over een afstand grb_verlengingsafstand met behulp van het (generische script): $GRBPROG/grb/verlenglijn.aml (versie 0.0.1 van 24mar-1999); · Nieuwe clean; · Verwijderen van overgebleven ge•soleerde lijnen; · Alle voorgaande acties worden uitgevoerd door het script: $GRBPROG/gbg/maakpoly.aml (versie 0.1.2 van 6-okt-1999) Coderen van de polygonen: GBG-polygonen met een annotatie-element Òg0Ó binnen hun omtrek zijn binnenkoeren en krijgen GBGTPC=0. De andere hebben GBGTPC=1. GBGpolygonen met na te verkennen gevels (LICD=11, LICD=13, LICD=14) krijgen GBGGBC=1, andere hebben GBGGBC=0. Het coderen wordt uitgevoerd door het script: $GRBPROG/gbg/codeerpoly.aml (versie 0.2.0 van 6-jul-1999); ·
$GRBPROG/gbg/maakgba ·
Gebruik:
&run $GRBPROG/gbg/maakgba {};
·
Defaults:
= IGDS;
·
Voorbeeld: &run $GRBPROG/gbg/maakgba IGDS;
·
Versie: 0.1.1
·
Functie: Aanmaken van de polygoon-coverage GBA.
6-okt-1999;
Toevoegen van het polygoonattribuut GBATPC:
·
GBGTPC = 2
afdak;
GBGTPC = 3
loopbrug;
GBGTPC = 4
trap;
GBGTPC = 5
onderkeldering;
GBGTPC = 6
verzonken garagetoegang;
Werkwijze ·
Selecteren van alle GBA-lijnelementen uit coverage IGDS (LICD=16);
·
Selectie van de GBA-tekstelementen ÒGBATATÓ;
rsc000107av0.doc
(zie tabel 1) en opslag in een punten-coverage
66
werkverslag testproject
·
·
Toevoegen van de lijnelementen uit de GBG-coverage: GBA elementen worden steeds gerestitueerd in combinatie met het bijhorende gebouw;
·
Clean van de polygoon-coverage (dangle_length = 5 meter);
·
Coderen op basis van GBATAT;
·
Opmerking: niet gecodeerde polygonen krijgen de Òdefault waardeÓ: GBGTPC = 6. Dit betekent dat de fotogrammetrie de garagetoegangen niet expliciet hoeft te coderen;
$GRBPROG/gbg/maakknw ·
Gebruik: &run $GRBPROG/gbg/maakknw {};
·
Defaults: = IGDS;
·
Voorbeeld:
&run $GRBPROG/gbg/maakknw IGDS;
·
Versie:
6-okt-1999;
·
Functie:
0.0.1
·
Aanmaken van de polygoon-coverage KNW;
·
Toevoegen van polygoonattributen KNWTPC, KNWFNC en KNWACT: KNWTPC = 1: Overbrugging; KNWTPC= 2:
Waterstaatkundig werk (sluis);
É (zie tabel 1) KNWFNC = 1: Gedragen entiteit (ligt op het brugdek); KNWFNC = 2: Overbrugde entiteit (de genomen hindernis); É (zie tabel 1) KNWACT = a: Wegas; KNWACT = b: Wegbaan; É (zie tabel 1) ·
·
Werkwijze ·
Selecteren van alle KNW-lijnelementen uit coverage IGDS (zie tabel 1);
·
Selectie van de KNW-tekstelementen (zie tabel 1) en opslag in een punten-coverage ÒKNWTATÓ;
·
Toevoegen van de lijnelementen uit de GBG-coverage: de omtrek van sommige elementen (vb: silo) wordt gerestitueerd in combinatie met een bijhorende gebouw;
·
Clean van de polygoon-coverage;
·
Coderen op basis van KNWTAT;
·
Verwijderen van niet gecodeerde polygonen;
$GRBPROG/wgn/maakwgn ·
Gebruik: &run $GRBPROG/gbg/maakwgn {} {};
·
Defaults: = IGDS = WGN;
·
Voorbeeld: &run $GRBPROG/gbg/maakwgn IGDS WGN;
·
Versie:0.0.1
·
Functie:
6-mar-1999;
· Aanmaken van de lijnen-coverage WGN (wegverbindingen); · Aanmaken van de punten-coverage WGNPT (wegknopen); ·
Werkwijze: · Selecteren van alle WGN-lijnelementen uit coverage IGDS (LICD=25); · Selecteren van alle WGN-puntelementen uit coverage IGDS (LICD=27), opslaan in coverage WGNPT en toevoegen van de cošrdinaat-informatie als X-COORD en Y-COORD attributen;
rsc000107av0.doc
67
werkverslag testproject ·
$GRBPROG/wgn/kuiswgn ·
Gebruik: &run $GRBPROG/gbg/kuiswgn {} {};
·
Defaults: = WGN = WGNPT;
·
Voorbeeld:
&run $GRBPROG/gbg/kuiswgn WGN WGNPT;
·
Versie:0.2.0
6-oct-1999;
·
Functie:
·
Werkwijze:
- Topologisch opkuisen van de lijnen-coverage WGN (wegverbindingen);
· Dissolve van WGN op basis van LICD (verwijderen pseudo-knopen); · Toevoegen van originele knopen uit WGNPT; ·
$GRBPROG/wbn/scheidthema.aml ·
Gebruik: &run $GRBPROG/wbn/scheidthema {};
·
Defaults: = IGDS;
·
Voorbeeld:
&run $GRBPROG/wbn/scheidthema IGDS;
·
Versie:0.3.1
6-oct-1999;
·
Functie: ·
Aanmaak van de polygoon coverage WBN (wegbaan);
·
Toevoegen van polygoon attributen WBN (WBN=0 voor de ÒgatenÓ (vb. vluchtheuvels) in de coverage, WBN=1 voor de andere polygonen) en WBNTPC (1 voor de kruispuntsecties, 2 voor de wegsecties);
·
Aanmaak van de lijnen coverage WGO (wegopdeling: bevat zowel de WOZ -grens onverharde zone- als de WCZ Ðgrens circulatiezone zwakke weggebruikersobjecten);
·
Aanmaak van de lijnen coverages WLI en WTI (longitudinale en transversale weginrichtingen);
·
Aanmaak van de punten coverages WPI en WRI (puntvormige weginrichting en riooldeksels);
·
Aanmaak van de lijnen coverage WRL (spoorrails binnen de wegbaan);
·
Aanmaak van de polygoon coverage WGA (wegaanhorigheden);
·
Toevoegen van het polygoon attribuut WGATPC: WGATPC = 1: Bushokje; WGATPC = 2: Telefoonhokje; É (zie tabel 1)
·
Werkwijze: · Selectie van alle WBN-lijnelementen uit coverage IGDS; · Sluiten met de grens van de karteringszone ADM; · Clean van de aldus ontstane polygonen; · De gebouwvoorgevels in rekening brengen (GBG); · Clean van de aldus ontstane polygonen; · Wegwerken van ge•soleerde lijnen met behulp van het script $GRBPROG/wbn/kuispoly.aml (versie 0.0.0 14-oct-1998). Dit script verlengt hangende lijnen tot aan een intersectie met een andere lijn over een afstand van maximum 10 centimeter. Na een nieuwe clean worden de overgebleven lijnen onvoorwaardelijk verlengd over een afstand van 2 meter ($GRBPROG/grb/verlenglijn.aml). Een laatste clean bepaalt uiteindelijk de resulterende dataset; ·
rsc000107av0.doc
Coderen van de WBN-polygonen mbv.: (versie 0.1.0 8-apr-1999);
$GRBPROG/wbn/codeerpoly.aml
68
werkverslag testproject
·
·
Selectie van alle WGO-lijnelementen uit coverage IGDS;
·
Dissolve op LICD;
·
Enkel de WGO-elementen binnen de WBN-coverage behouden;
·
Selectie van alle WLI-lijnelementen uit coverage IGDS;
·
Dissolve op LICD;
·
Enkel de WLI-elementen binnen de WBN-coverage behouden;
·
Selectie van alle WTI-lijnelementen uit coverage IGDS;
·
Dissolve op LICD;
·
Enkel de WTI-elementen binnen de WBN-coverage behouden;
·
Selectie van alle WRI-puntelementen uit coverage IGDS;
·
Enkel de WRI-elementen binnen de WBN-coverage behouden;
·
Selectie van alle WPI-puntelementen uit coverage IGDS;
·
Enkel de WPI-elementen binnen de WBN-coverage behouden;
·
Selectie van alle WRL-lijnelementen uit coverage IGDS;
·
Aanmaak van coverage WGA m.b.v. het script $GRBPROG/wbn/maakwga.aml (versie 0.0.0 26-may-1999). Dit script selecteert alle WGA-lijnelementen uit coverage IGDS, selecteert de WGA-tekstelementen (zie tabel 1) en slaat die op in een punten-coverage ÒWGATATÓ. De WGA-polygonen worden tenslotte gecodeerd op basis van ÒWGATATÓ;
$GRBPROG/trn/maaktrn.aml ·
Gebruik: &run $GRBPROG/trn/maaktrn {} {};
·
Defaults: = IGDS = TRN;
·
Voorbeeld:
&run $GRBPROG/trn/maaktrn IGDS TRN;
·
Versie:0.1.1
6-okt-1999;
·
Functie: ·
Aanmaken van de polygoon-coverage TRN (terreinen);
·
Toevoegen van de polygoonattributen TRNMTC en TRNFNC: TRNMTC = 1
verhard;
TRNMTC = 2
onverhard en onbegroeid;
É (zie tabel 1) TRNFNC = 1
verkeer;
TRNFNC = 5
ingericht groen;
É (zie tabel 1) ·
Werkwijze ·
Selecteren van alle TRN-lijnelementen uit coverage IGDS (LICD=45, 46);
·
Selectie van de TRN-tekstelementen puntencoverage ÒTRNTATÓ;
·
Coderen van de TRN-polygonen m.b.v.: $GRBPROG/trn/maakpoly.aml (versie 0.2.0 11-okt-1999).
(zie tabel 1) en opslag in een
Dit script sluit eerst de terreingrenzen aan op de wegbaan. Daarna worden de codepunten van ÒTRNTATÓ ingebracht en de polygonen overeenkomstig gecodeerd; Opmerking: door de interactie met de wegbaan gegevens is het van belang dat de coverage WBN bestaat vooraleer ÒmaaktrnÓ uitgevoerd wordt. ·
$GRBPROG/wtr/maakwtg.aml ·
Gebruik: &run $GRBPROG/wtr/maakwtg {} {<wtgcover>} {<wtlcover>};
rsc000107av0.doc
69
werkverslag testproject ·
Defaults: = IGDS <wtgcover> = WTG <wtlcover> = WTL;
·
Voorbeeld:
&run $GRBPROG/wtr/maakwtg IGDS WTG WTL;
·
Versie:0.0.1
6-okt-1999;
·
Functie: · Aanmaken van de polygoon-coverage WTG (watergang); · Aanmaken van de lijnen-coverage WTL (baangrachten);
·
·
Werkwijze: ·
Selecteren van alle WTG-lijnelementen uit coverage IGDS;
·
Sluiten met de grens van de karteringszone ADM;
·
Builden van de polygoon coverage WTG;
·
Selecteren van alle WTL-lijnelementen uit coverage IGDS;
·
Builden van de lijnencoverage WTL;
$GRBPROG/wtr/maakwta.aml ·
Gebruik: &run $GRBPROG/wtr/maakwta {} {<wtacover>};
·
Defaults: = IGDS <wtacover> = WTA;
·
Voorbeeld:
&run $GRBPROG/wtr/maakwta IGDS WTA;
·
Versie:0.0.1
6-okt-1999;
·
Functie: ·
·
·
Aanmaken van de lijnen-coverage WTA (waterassen);
Werkwijze: ·
Selecteren van alle WTA-lijnelementen uit coverage IGDS (LICD=62);
·
Builden van de lijnencoverage WTA;
$GRBPROG/grb/maakgrp.aml ·
Gebruik: &run $GRBPROG/grb/maakgrp {} {};
·
Defaults: = IGDS = GRP;
·
Voorbeeld:
&run $GRBPROG/grb/maakgrp IGDS GRP;
·
Versie:0.0.1
6-okt-1999;
·
Functie: ·
·
·
Aanmaken van de polygoon coverage GRP (probleemzones);
Werkwijze: ·
Selecteren van alle GRP-lijnelementen uit coverage IGDS (LICD=60);
·
Builden van de polygoon coverage GRP;
$GRBPROG/grb/maakshape.aml ·
Gebruik: &run $GRBPROG/grb/maakshape {};
·
Defaults: = IGDS;
·
Voorbeeld:
&run $GRBPROG/grb/maakshape IGDS;
·
Versie:0.1.0
9-nov-1999;
·
Functie: ·
rsc000107av0.doc
Aanmaken van de drie shape bestanden (nvk_lin.shp, nvk_pts.shp en nvk_ann.shp) die respectievelijk de lijn, de punten en de annotatie elementen bevatten;
70
werkverslag testproject ·
·
Werkwijze: ·
Verwijderen van de elementen uit de oorspronkelijke dataset en vervangen;
·
Door de opgekuiste elementen uit de coverages die door de verschillende maak*scripts zijn aangemaakt;
·
Het resultaat van deze operatie wordt opgeslagen in een nieuwe coverage ÒXXIGDSÓ;
·
Conversie van de lijnelementen uit ÒXXIGDSÓ naar nvk_lin.shp (shape-type polyline);
·
Conversie van de puntenelementen uit ÒXXIGDSÓ naar nvk_pts.shp (shapetype point);
·
Conversie van nvk_pts.shp naar een 3D-shapebestand (shapetype pointZ) m.b.v. de utility shape_convertto3D (toevoegen van de hoogte-informatie uit het attribuut ÒIGDS_HEIGHÓ als Z-cošrdinaat voor de puntvormige elementen zoal riooldeksels);
·
Conversie van de annotatie-elementen uit ÒXXIGDSÓ naar nvk_ann.shp. (shapetype point). Daartoe moet de informatie uit de annotatiesubclasse ÒIGDSÓ eerst omgezet worden naar een puntencoverage. Dit gebeurt m.b.v. het script $GRBPROG/grb/annonaarpunt.aml (versie 0.0.0 20-okt-1999). De tekstgegevens worden in de attributentabel opgeslagen in een veld ÒTEXTÓ;
$GRBPROG/grb/maakstats.aml ·
Gebruik: &run $GRBPROG/grb/maakstats {};
·
Defaults: = IGDS;
·
Voorbeeld:
&run $GRBPROG/grb/maakstats IGDS;
·
Versie:0.0.0
17-sep-1999;
·
Functie: ·
·
Aanmaken van een ASCII-bestand (igds.sta) met statistieken (aantallen, lengtes en oppervlaktes) over de verwerkte gegevens;
Werkwijze: ·
De gegevens worden uit de opgekuiste coverages afgeleid: (zie paragraaf 3.3 voor meer details);
3.4.2. Utilities Nu volgt een overzicht van de gebruikte hulpprogrammaÕs, samen met hun gebruiksmodaliteiten en een korte functiebeschrijving. Sommige utilities worden eveneens in andere hoofdmodules gebruikt. ·
$GRBPROG/grb/haal_igds_puntcodes.aml ·
Gebruik: &run $GRBPROG/grb/haal_igds_puntcodes <ent> {};
·
Defaults: = RST;
·
Versie:0.0.1
·
Functie: ·
6-okt-1999;
Routine om voor een GRB-entiteit (<ent>) de corresponderende puntcodes uit een ASCII-bestand te halen. Het gebruikte codebestand wordt bepaald door de parameter : ori =RST: $GRBPROG/support/grb_igdscodes.txt (voor de codes gebruikt door de restitutie zie tabel 1) ori = NVK: $GRBPROG/support/grb_naverkenningcodes.txt (voor de codes gebruikt in de naverkenning);
·
De codebestanden: De bestanden bestaan uit twee secties: Sectie 1: de lijncodes. De eerste lijn van deze sectie wordt aangeduid door het woord ÒLINECODESÓ.
rsc000107av0.doc
71
werkverslag testproject Deze sectie eindigt met een lijn ÒEND LINECODESÓ. Elke lijn van Sectie 1 bevat een GBR-entiteit acroniem, gevolgd door een code, beide gescheiden door een komma bvb:
WBN, 20 WBN, 21
Sectie 2: de puntcodes, begint met een lijn aangeduid met het woord ÒPOINTCODESÓ en eindigt bij de EOF. Elke lijn van Sectie 2 bevat een GBR-entiteit acroniem gevolgd door een code, beide gescheiden door een komma bvb.:
KNW, a KNW, b KNW, l KNW, s KNW, k KNW, r
Waar gewenst kan Ò/*Ó gebruikt worden als commentaar delimiter; ·
Werkwijze: Het programma definieert twee globale variabelen: ".igds_numcodes": aantal gevonden codes ".igds_codelijst%i%": lijst van codes (ge•ndexeerde variabele);
·
Voorbeeld: &run $GRBPROG/grb/haal_igds_puntcodes KNW RST definieert de volgende variabelen: .igds_numcodes = 6 .igds_codelijst1 = a .igds_codelijst2 = b .igds_codelijst3 = l .igds_codelijst4 = s .igds_codelijst5 = k .igds_codelijst6 = r
·
$GRBPROG/grb/filter_igds_puntcodes.aml ·
Gebruik: &run $GRBPROG/grb/filter_igds_puntcodes <ent>
·
Defaults: <selc> = 0
{<selc>} {}; = RST; ·
Versie:2.0.1
·
Functie:
20-okt-1999;
Selectie van puntvormige gegevens uit de input coverage (). De selectie gebeurt op basis van tekstinformatie in een annotatie subklasse; ·
Werkwijze: ·
Ophalen van de code lijst voor de gevraagde entiteit (<ent>) m.b.v. haal_igds_puntcodes.aml
·
De selectie gebeurt op basis van een annotatie subklasse (anno.igds voor restitutiegegevens, anno.dxf voor naverkenningsgegevens). Het attribuut ÒTEXTÓ bevat de tekststring waarop de selectie gebeurt. De parameter <selc> bepaalt hoe de selectie gebeurt:
rsc000107av0.doc
72
werkverslag testproject <selc> = 0: ÒTEXTÓ is exact de code (vb: Òg0Ó voor binnenkoer) <selc> = 1: ÒTEXTÓ bevat de code (vb: Òk01Ó bevat de code ÒkÓ ) · De geselecteerde elementen worden als een puntencoverage () opgeslagen, met behoud van het ÒTEXTÓ-attribuut. · $GRBPROG/grb/haal_igds_lijncodes.aml · Gebruik:
&run $GRBPROG/grb/haal_igds_lijncodes <ent> {};
· Defaults:
= RST;
· Versie: 2.0.0
7-okt-1999;
· Functie: · Routine om voor een GRB-entiteit (<ent>) de corresponderende lijncodes uit een ASCII-bestand te halen Het gebruikte codebestand wordt bepaald door de parameter : ori =RST: $GRBPROG/support/grb_igdscodes.txt (voor de codes gebruikt door de restitutie - zie tabel 1) ori = NVK: $GRBPROG/support/grb_naverkenningcodes.txt (voor de codes gebruikt in de naverkenning); · De codebestanden: ·
· Zie $GRBPROG/grb/haal_igds_puntcodes; Werkwijze: · Het programma definieert twee globale variabelen: ".igds_numcodes": aantal gevonden codes ".igds_codelijst%i%" lijst van codes, ge•ndexeerde variabele;
·
Voorbeeld: ·
&run $GRBPROG/grb/haal_igds_lijncodes WBN RST definieert de volgende variabelen: .igds_numcodes = 2 .igds_codelijst1 = 20 .igds_codelijst2 = 21;
·
$GRBPROG/grb/filter_igds_lijncodes.aml ·
Gebruik: &run $GRBPROG/grb/filter_igds_lijncodes <ent> {};
·
Defaults: = RST;
·
Versie:2.0.0
rsc000107av0.doc
7-okt-1999;
73
werkverslag testproject ·
Functie: ·
·
·
Werkwijze: ·
Ophalen van de lijncodes voor de gevraagde entiteit (<ent>) m.b.v. haal_igds_lijncodes.aml;
·
De selectie gebeurt op basis van het numeriek attribuut ÒLICDÓ;
·
De geselecteerde elementen worden als een lijnencoverage () opgeslagen, met behoud van het originele lijnattributen;
$GRBPROG/grb/haal_parameter_waarde.aml ·
Gebruik: &run $GRBPROG/grb/haal_parameter_waarde <param>;
·
Defaults: geen;
·
Versie:
·
Functie:
0.1.0 ·
·
Selectie van lijnvormige gegevens uit de input coverage (). De selectie gebeurt op basis van het numeriek attribuut ÒLICDÓ;
6-okt-1999;
Zie paragraaf 2.3: ÒparameterbestandÓ;
$GRBPROG/grb/ verlenglijn.aml ·
Gebruik: &run $GRBPROG/grb/verlenglijn ;
·
Defaults: geen;
·
Versie:
·
Functie:
0.0.1 ·
24-mar-1999;
Verlenging van de uiteinden van alle lijnen in de lijnencoverage over een afstand van meter, zonder rekening te houden met intersecties met andere lijnen. Het resultaat van de bewerking wordt in weggeschreven.
4. Verwerking van de gegevens van de naverkenning 4.1 INLEIDING Op dit niveau worden de gegevens, afkomstig van de naverkenning, opgekuist en geconverteerd naar een aantal ARC/INFO coverages, opgesplitst per GRB-entiteit. Deze coverages zijn te beschouwen als tijdelijke groeperingen van gelijkaardige elementen. De kern van de verwerking gebeurt via individuele elementen of exemplaren. De uitwisselingseenheid is het stereokoppel.
4.2 INPUT ·
Formaat: Autocad DXF-bestand;
·
Naamgeving: het input-bestand wordt door de naverkenning in de map $GRBDATA/proj /naverkenning geplaatst en heeft als naam ___t.dxf Hierbij staat voor het projectnummer (1 voor Herenthout-Bouwel). De nummers en zijn de nummers van de fotoÕs die het stereokoppel samenstellen. bvb: $GRBDATA/proj1/naverkenning/1_192_192_t.dxf;
·
Codering: de data in een DXF-bestand is georganiseerd in ÒlayersÓ die elk een aantal tekenobjecten of entiteiten kunnen bevatten. Voor een beschrijving van de gebruikte layers verwijzen wij naar de documentatie van de Òmodule topografieÓ;
·
grb_naverkenningscodes.txt is een ASCII-bestand dat door de verschillende verwerkingsmodules gebruikt wordt om de gegevens input gegevens in GRB-entiteiten te scheiden (zie paragraaf 3.4.2.: Utilities);
rsc000107av0.doc
74
werkverslag testproject 4.3 OUTPUT 4.3.1. Coverages ·
Formaat: ARC/INFO 7.2 coverages;
·
Naamgeving: zoals eerder vermeld zijn de coverages een tijdelijke verzameling van objecten, gegroepeerd volgend de specificaties van de GRB-entiteiten. De respectievelijke coverages krijgen de drieletter-acronymen als naam. De workspace waar de coverages zich bevinden is: $GRBDATA/proj/_/naverkenning;
·
Voorbeeld: $GRBDATA/proj1/216_217/naverkenning/gbg.
4.3.2. Statistieken ·
Op het einde van de verwerkingsstap wordt opnieuw een statistiek bestand gegenereerd;
·
Formaat: zie 3.3.;
·
Inhoud: zie 3.3.;
·
Naamgeving: ___t.sta in de map $GRBDATA/proj /naverkenning;
·
Voorbeeld: $GRBDATA/proj1/naverkenning/1_216_217_t.sta.
4.4 VERWERKING De driver ·
De verwerking gebeurt volautomatisch door opstarten van ŽŽn enkel ARC/INFO aml-script: $GRBPROG/grb/kuisdxf.aml;
·
Versie:
·
Gebruik (in een ARC shell):
0.0.0
11-okt-1999;
&run $GRBPROG/grb/kuisdxf ·
is het DXF-bestand (voldoet aan de naamgevingsconventie uit paragraaf 4.2);
·
De aanmaak van de entiteiten-coverages en het statistiek-bestand vergt geen bijkomende handelingen;
·
Voorbeeld: &run $GRBPROG/grb/kuisdxf $GRBDATA/proj1/naverkenning/1_216_217_t.
DeelprogrammaÕs De driver (kuisdxf.aml) roept verschillende deelprogrammaÕs op. Deze worden in deze paragraaf uitvoerig toegelicht. Tenzij expliciet vermeld, verloopt de werkwijze van de verschillende deelprogrammaÕs analoog met deze beschreven in voorgaand hoofdstuk. ·
$GRBPROG/grb/leesdxf.aml ·
Gebruik: &run $GRBPROG/grb/leesdxf <projectnr> ;
·
Defaults: geen;
·
Voorbeeld: &run $GRBPROG/grb/leesxf 1_216_217.dxf 1 216_217;
·
Versie:
·
Functie:
1.0.0
13-okt-1999;
·
Opslaan van de huisnummers in de coverage ÒHUISNRSÓ, een puntencoverage met een annotatieklasse ÒDXFÓ die de huisnummers in het attribuut ÒTEXTÓ bevat;
·
De resterende DXF-layers worden opgeslagen in 1 enkele coverage (ÒNAVERKENDÓ);
·
Builden van de coverage voor lijnen, punten en een annotatieklasse (ANNO.DXF);
·
Toevoegen van een extra attibuut (LICD Ð het DXF layernummen) aan de lijn, punt en annotatie attributentabellen. Dit attribuut zal instaan voor de verdere opsplitsing in GRB-entiteiten;
·
Waar voorhanden wordt de hoogte-informatie opgeslagen in een attribuut ÒHEIGHTÓ.
rsc000107av0.doc
75
werkverslag testproject ·
$GRBPROG/grb/maakadm.aml ·
Gebruik: &run $GRBPROG/grb/maakadm ;
·
Defaults: geen;
·
Voorbeeld: &run $GRBPROG/grb/maakadm NAVERKEND;
·
Versie:
·
Functie:
0.1.1 ·
·
Zie 3.4.1.: (maakzone.aml);
Werkwijze: ·
·
6-okt-1999;
Zie 3.4.1.: (maakzone.aml);
$GRBPROG/gbg/maakgbg_nvk.aml ·
Gebruik: &run $GRBPROG/gbg/maakgbg_nvk {} {};
·
Defaults: = NAVERKEND; = GBG
·
Voorbeeld: &run $GRBPROG/gbg/maakgbg_nvk NAVERKEND;
·
Versie:
·
Functie:
·
Werkwijze:
0.1.1 ·
Zie 3.4.1.: (maakgbg.aml);
· ·
Zie 3.4.1.: (maakgbg.aml);
Opmerking: ·
·
6-okt-1999;
Er wordt eveneens een lijnen coverage Ò_rejectÓ gegenereerd. Deze bevat de niet gesloten lijnstukjes. Meestal gaat het hier om gebouwen die op de rand van het fotokoppel liggen en dus slechts gedeeltelijk in het bestand voorkomen. De vervolledigingen met gegevens uit naburige datasets moeten manueel gebeuren;
$GRBPROG/gbg/maakgba_nvk.aml ·
Gebruik: run $GRBPROG/gbg/maakgba_nvk {} {};
·
Defaults: = NAVERKEND; = GBA
·
Voorbeeld: &run $GRBPROG/gbg/ maakgba_nvk NAVERKEND;
·
Versie:
·
Functie:
0.0.0 ·
·
Zie 3.4.1.: (maakgba.aml);
Werkwijze: ·
·
11-okt-1999;
Zie 3.4.1.: (maakgba.aml);
$GRBPROG/gbg/maakknw_nvk.aml ·
Gebruik: &run $GRBPROG/gbg/maakknw_nvk {} {};
·
Defaults: = NAVERKEND; = KNW
·
Voorbeeld: &run $GRBPROG/gbg/ maakknw_nvk NAVERKEND;
·
Versie:
·
Functie:
0.1.0 ·
·
Zie 3.4.1.: (maakknw.aml);
Werkwijze: ·
·
12-okt-1999;
Zie 3.4.1.: (maakknw.aml);
$GRBPROG/wgn/maakwgn_nvk.aml
rsc000107av0.doc
76
werkverslag testproject ·
Gebruik: &run $GRBPROG/wgn/maakwgn_nvk {};
·
Defaults: = NAVERKEND;
·
Voorbeeld: &run $GRBPROG/wgn/maakwgn_nvk NAVERKEND;
·
Versie:
·
Functie:
0.0.0 ·
·
Zie 3.4.1.: (maakwgn.aml);
Werkwijze: ·
·
Zie 3.4.1.: (maakwgn.aml);
$GRBPROG/wbn/scheidthema_nvk.aml ·
Gebruik: &run $GRBPROG/wbn/scheidthema_nvk {};
·
Defaults: = NAVERKEND;
·
Voorbeeld: &run $GRBPROG/wbn/scheidthema_nvk NAVERKEND;
·
Versie:
·
Functie:
0.0.0 ·
·
Werkwijze: Zie 3.4.1.: (scheidthema.aml);
$GRBPROG/trn/maaktrn_nvk.aml ·
Gebruik: &run $GRBPROG/trn/maaktrn_nvk {};
·
Defaults: = NAVERKEND;
·
Voorbeeld: &run $GRBPROG/trn/maaktrn_nvk NAVERKEND;
·
Versie:
·
Functie:
·
Werkwijze:
0.0.0 ·
Zie 3.4.1.: (maaktrn.aml);
$GRBPROG/wtr/maakwtg_nvk.aml ·
Gebruik: &run $GRBPROG/wtr/maakwtg_nvk {};
·
Defaults: = NAVERKEND;
·
Voorbeeld: &run $GRBPROG/wtr/maakwtg_nvk NAVERKEND;
·
Versie:
·
Functie:
0.0.0 ·
·
Werkwijze: Zie 3.4.1.: (maakwtg.aml);
$GRBPROG/wtr/maakwta.aml ·
·
11-okt-1999;
Zie 3.4.1.: (maakwtg.aml);
· ·
11-okt-1999;
Zie 3.4.1.: (maaktrn.aml);
· ·
11-okt-1999;
Zie 3.4.1.: (scheidthema.aml);
· ·
12-okt-1999;
Zie 3.4.1.: (maakwta.aml);
$GRBPROG/mkr/maakmkv.aml ·
Gebruik: &run $GRBPROG/mkr/maakmkv {};
·
Defaults: = NAVERKEND;
·
Voorbeeld: &run $GRBPROG/wgn/maakwgn_nvk NAVERKEND;
·
Versie:
·
Functie:
0.0.0 ·
·
15-okt-1999;
Aanmaak van de puntencoverage MKV (de meetkundige verdichtingspunten);
Werkwijze:
rsc000107av0.doc
77
werkverslag testproject · ·
$GRBPROG/grb/maakgrp.aml ·
·
Selectie van de MKV-elementen (LICD=101) uit de input coverage;
Zie 3.4.1.: (maakgrp.aml);
$GRBPROG/grb/maakstats_nvk.aml ·
Gebruik: &run $GRBPROG/grb/maakstats_nvk {};
·
Defaults: = NAVERKEND;
·
Voorbeeld: &run $GRBPROG/grb/maakstats_nvk NAVERKEND;
·
Versie:
·
Functie:
0.0.0 ·
·
29-sep-1999
Zie 3.4.1.: (maakstats.aml)
Werkwijze: ·
Zie 3.4.1.: (maakstats.aml)
5. Interactie met de databank 5.1 INLEIDING Deze module staat in voor de vervollediging en conversie van de ARC/INFO coverages, gegenereerd door de module ÒVerwerking van de gegevens van de naverkenningÓ. Men kan de volgende verwerkingsstappen onderscheiden: ·
Invullen van de ontbrekende attributen;
·
Aanmaak van de aanvullende tabellen;
·
Conversie naar ÒshapeÓ-formaat;
·
Input van de shape-bestanden in de databank.
Als databank engine is op dit moment een Oracle 8.0.4 RDBMS voorzien, gecombineerd met een ESRI ArcSDE 8.0.1 voor Oracle. Het systeem zal ge•mplementeerd worden op een Windows NT machine.
5.2 INPUT ARC/INFO coverages, gegenereerd door de module naverkenningÓ.
ÒVerwerking van de gegevens van de
Adresgegevens. Straatnamen É
5.3 OUTPUT Een set ArcSDE-layers en tabellen in de ArcSDE-databank.
5.4 VERWERKING Nog niet ge•mplementeerd.
rsc000107av0.doc
78
werkverslag testproject
Kritische beschouwingen 1. Inleiding Uiteraard zijn de voorgaande methodes voor verbetering vatbaar. Op basis van de eigen ervaringen, worden hieronder per module voorstellen gedaan voor een effici‘ntere werkwijze.
2. Fotogrammetrie 1
Tijdens de uitvoering van het testproject is het GRB-concept ge‘volueerd van versie 2.0 naar een versie 3.1. De fotorestitutie en meer specifiek de voorziene werkwijze, werd tijdens deze evolutie meermaals onderbroken en gewijzigd. Hierdoor nam dit project een langere tijdsduur in beslag dan vooraf aangenomen.
2
De verwachtingen op vlak van geometrische nauwkeurigheid werden initieel voor het fotogrammetrische eindbestand te hoog ingeschat. De opbouw van bestanden via fotogrammetrie wordt onder meer beperkt door de zichtbaarheid van een object op de foto en de re‘le pixelgrootte zijnde 12cm. Objecten met zeer hoge nauwkeurigheidseisen (<10cm), bijvoorbeeld riooldeksels, worden best opgemeten via terrestrische methoden.
3
Het productieproces zoals beschreven voor onderhavig testproject kan sterk ingekort worden in het licht van volgende mogelijkheden: ·
Een luchtopname gestuurd met DGPS waarbij de projectiecentra met hoge precisie bepaald worden;
·
Een hoge precisie scanner die toelaat de diapositieven op filmrol automatisch in te scannen;
·
Het uitvoeren van een automatische aerotriangulatie en blokvereffeningsprocedure. De tijdswinst op dit niveau wordt voor een project van circa 5000 ha teruggebracht van circa 3 weken naar enkele uren.
De eerste en de tweede opmerking staan rechtstreeks met elkaar in verband. Een luchtopname waarbij gebruik gemaakt wordt van DGPS, heeft als doel dat alle fotocentra zeer nauwkeurig, op dm niveau, worden opgemeten. Het gebruik van GPS voor de bepaling van de projectiecentra herleidt het aantal benodigde paspunten die terrestrisch op te meten zijn tot een minimum en maakt het uitvoeren van automatische aerotriangulatie en blokvereffening met hoge precisie mogelijk. Specificaties van de gebruikte GPS-apparatuur zijn voor de voorgestelde methode de volgende: ·
Op de grond worden minimum 2 referentieontvangers opgesteld;
·
In het vliegtuig worden minimum 3 GPS-antennes voorzien;
·
De afstand tussen de 2 GPS-ontvangers op de grond en de GPS-ontvanger in het vliegtuig mag niet groter zijn dan 25km.;
·
De vliegtuig GPS-ontvanger moet voorzien zijn van ÒEvent-registratieÓ voor het vastleggen van het moment van de opname;
·
Het vliegtuig moet beschikken over een Inertieel Navigatie Systeem;
·
Het vliegtuig mag tussen de vliegstroken geen scherpe bochten maken teneinde het contact met de satellieten te bewaren;
·
De GPS-metingen gebeuren volgens de continue kinematische methode (true kinematic method) aan maximum 1 meting per seconde;
·
De GPS-berekeningen gebeuren op basis van fasemetingen;
·
De PDOP van de satellietconstellatie tijdens de opname moet kleiner zijn dan 5;
·
De metingen gebeuren op basis van minimum 6 satellieten;
·
De elevatiehoek tijdens de metingen bedraagt minimaal 12¡.
3. Topografie rsc000107av0.doc
79
werkverslag testproject D.m.v. automatisatie kan de productietijd nog verder ingekort en de kwaliteit verbeterd worden. Dit ook met het oog op controle van fouten zoals: ·
Dubbele punten;
·
Ontbreken van aansluiting (buiten tolerantie van opkuis) van zonebegrenzende elementen op zelfde of andere entiteiten;
·
Lineaire elementen met lengte nul;
·
Hangende lijnen;
·
Elementen in lagen met na te verkennen entiteiten in resulterend dxf-bestand;
·
Juiste type geometrische primitieven in juiste lagen;
Volgende controles kunnen eveneens ingebouwd worden in de gebruikte AutoCAD-omgeving: ·
Toegelaten waarden voor type- en relatiecodering;
·
Toegelaten veldnotatie voor huisnummers;
·
Insertiepunt van tekstveld ÔhuisnummerÕ is gelegen binnen de contouren van het gbg-exemplaar;
·
Dubbele cošrdinaten binnen gesloten polyline behalve begin- en eindpunt;
·
Tekstpositie: lower left of mid mid;
·
Controle op aanwezigheid van blocks;
·
Controle op eventuele rotaties van blocks;
·
Controle op verschaling van blocks;
·
Controle minimum en maximum range van cošrdinaten;
·
Controle van elementen met een z-waarde verschillend van 0;
·
Controle op terugkerende lijnen (met gedeeltelijke bedekking);
·
Bedekking van lijnen (bvb wcz bedekt gedeeltelijk wbn);
De operaties in een grafisch tekenpakket voor de verwerking van de naverkende gegevens zijn zeer arbeidsintensief. Het zou de moeite lonen om een meer geautomatiseerde procedure voor deze manipulaties te ontwikkelen. Bijvoorbeeld substitutie van de gerestitueerde voorgevel door een naverkende gevel met verzekering van de aansluiting op de zijgevels.
4. Wisselwerking fotogrammetrie-topografie Uit de gevolgde werkwijze blijkt dat er in de praktijk dubbel werk plaatsvindt. Een voorgevel bijvoorbeeld, wordt eerst gerestitueerd en in vele gevallen daarna terrestrisch opgemeten bij wijze van naverkenning. Wanneer er recuperatie gebeurt van GBK-gevels (Cardib, Havi-TV, É) dan worden de gevels beoordeeld door zowel de restitutie als door de naverkenning. Door de werkwijze om te draaien en de voorgevels eerst terrestrisch op te meten in gebieden waar veel gebouwen voorkomen en waar ze dus zichtbaar zijn vanuit eenzelfde opstelpunt, wordt de kostprijs van de kartering van een voorgevel gereduceerd op voorwaarde dat de restitutie de terrestrisch opgemeten voorgevel zonder bijkomende beoordeling kan integreren in het gerestitueerde bestand. Aangezien de aangepaste skeletmeting en de restitutie gebruik maken van een grondslag die onafhankelijk van elkaar werd bekomen, is een absolute controle mogelijk tussen beide modules. In stedelijk gebied is het, omwille van tijdsbesparende en kostprijsreducerende redenen zeker te verantwoorden om eerst een aangepaste skeletmeting uit te voeren en vervolgens te restitueren. In landelijk gebied daarentegen, geldt dit niet.
rsc000107av0.doc
80
