Migrering af en geospatial platform 10 år senere - Microstation Geographics - Oracle Spatial

Dette er en fælles udfordring for mange matrikel- eller kartografiprojekter, som i perioden 2000-2010 integrerede Microstation Geographics som en rumlig datamotor, i betragtning af årsager som følgende:

• Arc-node management var og er fortsat yderst praktisk til matrikulære projekter.
• DGN er et attraktivt alternativ i betragtning af dens versionering i samme fil, som ikke har ændret sig i 15 år, i modsætning til andre formater, hvor vi har set mange inkompatible versioner hvert tredje år.
• I 2002 var fri software en fjern drøm fra det, vi har i dag.
• OGC-standarderne gjaldt endnu ikke for proprietær software.
• shp-filerne var begrænset til store projekter, og rumbaserne var stadig meget lukkede for ikke-standardiserede ordninger, der kompromitterede servernes ydeevne... og pengene.
• Fjernforbindelse var begyndende i forhold til, hvad vi har nu.

Så implementering af et GIS baseret på et "linked CAD"-skema var en levedygtig løsning, selvom brugervenligheden blev ofret for tiltalende præsentationsformål. VBA API'et var rigeligt til at programmere transaktionsstyringsrutiner forbundet til ProjectWise til kontrol af fysiske filer og muligheden for at bruge GeoWeb Publisher til rumlig analyse fra serveren, selvom udgivelsen var begrænset til ActiveX i Internet Explorer (som i det år var den eneste browser).

Problemet er ikke at have udviklet sig gradvist og i stedet for at flytte til Geospatial Server eller mere robuste versioner af ProjectWise, ønsker at få en GIS til at overleve fra fysiske filer, have det fulde potentiale af licenseret Oracle Spatial og evnen til at udvikle. Så det var vores udfordring.

1. Databasen: Postgres, SQL Server eller Oracle?

Især ville jeg have foretrukket den første. Men når du står over for et transaktionssystem, der ikke er orienteret til tjenester, men som fungerer godt, hvor en del af logikken og integriteten er som PL i databasen, er ændringen til en OpenSoure-base ikke en nødsituation. Nej, medmindre du har et mål om at udvikle en ny version af systemet, som ikke er på kort sigt.

Det handler heller ikke om at gøre en Taliban-handling for at nedgøre alt, hvad der lugter af proprietært. Så det er en klog beslutning at blive hos Oracle, hvis det fungerer godt, hvis størrelsen og efterspørgslen er stor, hvis det er godt designet, godt beskyttet, og hvis supporten bliver udnyttet. emne til en anden lejlighed.

Så det, der var tilbage, var at udvikle funktionaliteter til de data, der skulle migreres til denne base, publiceringstjenester og transaktionsstyringsværktøjer til vektordata.

For at kontrollere rollerne og brugerne, som tidligere blev administreret fra ProjectWise, blev der oprettet et modulært værktøj, der tillod:

• Administrer brugere og roller fra BentleyMap VBA.
• Tildele fra brugeren med administrationsrettigheder, ret til afdelinger og kommuner.
• Tildele ret til matrikel efter projekt.
• Ret til tilgængelige værktøjer i modulerne Byggeri, edition, udgivelse, høring og administration. På denne måde oprettes kun nye applikationer og vises for brugerne i henhold til deres rolle eller specifikke opgave.
• Dette login-panel forenkler også den almindelige kompleksitet af BentleyMap-projekter, således at blot at logge ind får træet af kategorier og attributter, der er defineret i Geospatial Administrator, frem.

Et panel af dette løser problemer med ringe forståelse og risici for brugere, der er nye til funktioner som datainteroperabilitet. Hvilket er et andet problem, da Bentley redigerer indbygget i Oracle Spatial, hvilket er vidunderligt, men også risikabelt, hvis du ikke har transaktionskontrol.

Så for eksempel havde byggemodulet følgende værktøjer:

• Tildel funktioner
• Geografisk sammenkædningsguide
• Batch Spatial Migration
• slette objekter
• redigere polygoner
• Eksporter Shp/CAD
• Importer Shp/CAD
• Geolinmigrering
• Geopoint migration
• Georegion Migration
• registrere kort
• Link Geo-Line
• Link Geo-Point
• Link Geo-Region

Supplerende værktøjer blev gradvist tilføjet, herunder nogle til direkte redigering i Geospatial Administrator.

• Administrator for at se funktioner
• Topologisk Analyse
• SAFT konsultation
• Se funktioner
• Konverter kurve til LineString
• Opret funktioner
• skabe ejendomme
• DBConnect-konfiguration
• DBConnect-forespørgsel
• Rediger funktion Xfm
• Rediger Xfm-projekt
• Fjern Xfm-funktioner
• pakke identifikation
• Ændre symbolologi
• overskrive funktioner
• Temaer efter klasser
• Til tema
• Tema efter rulleliste
• Xfm hjælpeprogrammer

2. Dataene: Rumbaseret DGN-migrering: Oracle Builder eller Bentley Map?

Den mest interessante udfordring i dette var, at en kontrolleret migrering var påkrævet, og under hensyntagen til, at DGN-filerne, efter at have modtaget opdateringer i mere end 10 år, kunne have topologiproblemer - ægte galskab-.

Det var det faktisk. Kortenes hovedproblemer er her:

• Ændringen af ​​en pakke på grænsen af ​​filen (sektor eller zone) indebærer, at der skal være ændring af begge, inklusive sammenfaldet af knudepunkter i tilfælde som når en sektor er en enkelt linje, men i naboen er denne linje segmenteret.
• Der er filer, som efter 300 vedligeholdelsestransaktioner gemt i DGN-historikken kan blive beskadiget.
• Der er mere komplekse problemer, der ikke kan kontrolleres på kontoret, såsom når en ejendom overlapper en anden nabo i en anden fil, for mængder, der ikke kan løses på kortet, da det ville indebære at lave en markinspektion for at undgå at påvirke en tredjepart.
• Dårlig praksis, såsom inkludering af kort i forskellige projektioner, i dette tilfælde var der sektorer i NAD27, selvom standarden var WGS84. I ekstreme tilfælde blev der foretaget justeringer mellem data fra forskellige fremskrivninger, omvendt.

Løsningen var et Wizzard-type værktøj til massiv migration, som individuelt kan migrere et kort, flere eller endda alle dem fra en kommune (rådhus) eller afdeling.

Grundlæggende er det, værktøjet gør, at tage data fra Geographics-projektet og promovere dem til Benltey Map-funktioner, hvorefter det udfører en række valideringer, såsom:

• Et-til-en forhold mellem geometri og database,
• Validering af mangel på dubletter,
• Areal-centroid-konsistensvalidering,
• Validering af kortobjekter mod inaktive objekter i databasen,
• Topologivalidering mod eksisterende topologier i rumbasen

Efter valideringerne giver panelet dig mulighed for at tilføje information på en massiv måde, såsom målemetoden og kvalitetskontrolstandarden for disse data.

Til sidst sender den til databasen og genererer til sidst en rapport. Fra sagt til kendsgerning er der en enorm strækning, men til sidst tilpassede den sig til Oracle Spatials luner, der stadig er lige så skøre som Bentleys og dens måde at se komplekse egenskaber eller plot med mange hjørner på.

3. Indlægget: Geoserver eller MapServer? OpenLayers eller folder?

En fremviser blev bygget ved hjælp af OpenLayers og nogle plugins. For første gang efter 10 års opgivelse af udviklingen af ​​den rumlige del, var en ny fremviser synlig, der erstattede ActiveX fra GeoWeb Publisher. MapFish kode blev brugt til udskrivning, geojson til at styre sidetræet, OracleSpatial serverede lag blev serveret fra Geoserver.

Endelig blev udskiftningen af ​​teknologier foretaget i henhold til følgende graf. Som du kan se, en kombination af open source, vedligeholdelse af databasen og arealforvaltning ved hjælp af proprietær software.

4. Konstruktion og udgave, direkte til Oracle Spatial. Bentley Map eller QGIS?

Dette er en anden historie. Bentley Map redigerer native på det rumlige grundlag, hvilket skaber konflikter, hvis du ikke vil arbejde med en Transactional Web Feature Service (WFS). Konflikten er:

Hvordan løser man en regel om ikke at tillade topologi-overlapning, hvis den redigeres, og når man forsøger at sende den, rapporterer man, at objektet påvirker sig selv?

Dette løses ved at versionere før, redigere direkte og validere, at når der bogføres, hvis noget fejler, genoprettes versioneringen, hvilket efterlader transaktionen gennemført, men i en mislykket tilstand.

Et andet problem, der skulle løses, er den massive indtastning af data, i betragtning af at brugerne var nødt til at stoppe med at bruge Geographics, og der var flere projekter, der rejste massiv matrikel.

Dette var nemt, fordi der kun blev lavet et værktøj, der ligner det, der eksisterede til at integrere dataene i Microstation Geographics, hvilket letter BentleyMaps potentiale og med en mere kontrolleret assistent.

Billedet viser, hvordan dette værktøj blev udviklet, med nogle særlige forhold, såsom oprettelse og registrering af hjørner og inkludering af Puntoparcela, som klar funktionalitet i tilfælde af, at målemetoden for nogle hjørner ikke opfyldte en vis kvalitetsstandard.

Dette flow var bestemt meget godt, fordi brugerne vidste, hvilke værktøjer de brugte oftest. Det var nødvendigt at få dem til at ændre deres mentalitet mellem overgangen fra flere funktioner til styring efter niveauer, og fremme nye fordele, så de ville glemme den arkaiske Microstation V8 2004, såsom WMS-tjenesten, gennemsigtigheden og indbygget genkendelse af DWG-filer af nyere versioner; Hvad skal man ikke sige om interoperabiliteten med kml, shp og gml for de mest astrale.

På samme måde blev der lavet værktøjer til matrikelvedligeholdelse, med mulighed for at redigere direkte i former eller downloade dem til arc-node for komplekse sager.

5. Bygherre for kommuner via GML. QGIS eller gvSIG?

QGIS. Men det er en anden historie at fortælle senere.