Мигрирање на геопросторна платформа 10 години подоцна - Microstation Geographics - Oracle Spatial

Ова е чест предизвик за многу катастарски или картографски проекти, кои во тоа време 2000-2010 интегрираа Microstation Geographics како мотор на просторни податоци, земајќи ги предвид причините како што се:

• Управувањето со архитектонски јазли беше и продолжува да биде исклучително практично, за катастарски проекти.
• На DGN е атрактивна алтернатива, со оглед на последната верзија во истата датотека, која не се промени во 15 години, за разлика од другите формати во кои видовме многу некомпатибилни верзии на секои три години.
• На слободен софтвер 2002 беше сон далеку од она што го имаме денес.
• Стандардите на OGC не беа тешки за комерцијален софтвер.
• SHP датотеки се ограничени на проекти oceangoing и вселенски бази се 'уште се во непосредна близина до не-стандардизирани шеми кои компромитиран вршење на сервери ... и сребро.
• Далечинското поврзување беше почетно во споредба со она што сега го имаме.

Така, спроведувањето на ГИС засновано врз „поврзана CAD“ шема беше остварливо решение, и покрај тоа што се жртвуваше употребливоста за атрактивни цели на презентација. VBA API изобилуваше со рутините за управување со трансакции поврзани со ProjectWise за контрола на физичките датотеки и можноста за користење на GeoWeb Publisher за просторна анализа од серверот, иако објавувањето беше ограничено на ActiveX во Internet Explorer (кој во таа година беше единствен прелистувач).

Проблемот не е еволуиран постепено и наместо да се префрлате на Геопросторниот сервер или повеќе робусни верзии на ProjectWise, сакајќи да направите ГИС да преживее од физички датотеки, имајќи го целиот потенцијал на лиценциран Oracle Spatial и можност за развој. Значи, тоа беше нашиот предизвик.

1. Базата на податоци: Postgres, SQL Server или Oracle?

Особено, би го претпочитал првиот. Но, кога сте пред трансакциски систем кој не е ориентиран кон услуги, но работи добро, во кој дел од логиката и интегритетот е како PL во базата на податоци, промената во базата OpenSoure не е вонредна состојба. Не, освен ако вашата цел не е да развиете нова верзија на системот што не е достапна на непосреден рок.

Ниту станува збор за правење талибанска акција за омаловажување на сè што мириса приватно. Значи, останувањето со Oracle е мудра одлука, ако работи добро, ако е голема и бара, ако е добро дизајнирана, заштитена и ако поддршката се користи. Тема за друга пригода.

Значи она што останало беше да се развијат функционалностите за податоците кои треба да се пренесат во оваа база на податоци, услуги за објавување и трансакциски алатки за управување со векторски податоци.

За да ги контролирате улогите и корисниците кои претходно биле управувани од ProjectWise, беше креирана модуларна алатка која дозволи:

• Управувајте со корисниците и улогите од VBA на BentleyMap.
• Од корисникот назначи административни права, право на одделенија и општини.
• Доделете право на катастарска датотека со проект.
• Право на алатки достапни во модулите за конструкција, издание, публикација, консултации и администрација. На овој начин, само нови апликации се креираат и им се појавуваат на корисниците според нивната улога или специфична задача.
• Оваа најава панел, исто така го поедноставува комплексноста на заеднички проекти BentleyMap, како што ќе влезат само категоријата дрво и атрибути се дефинирани во појавува Администратор на земјена површина.

Панел за ова решава недоразбирања и ризици на корисниците кои се нови за карактеристиките како интероперабилност на податоците. Што е уште еден погрешен, бидејќи Бентли уредува природно во Oracle Spatial, што е прекрасно, но исто така и ризично ако немате трансакциска контрола.

Така, на пример, модулот за изградба ги има следниве алатки:

• Доделете функции
• Волшебник за географски поврзувања
• Миграција на сериски простор
• Избриши објекти
• Уредете полигони
• Експортирај Shp / CAD
• Import Shp / CAD
• Геолошка миграција
• Миграција Геопунто
• Географска миграција
• Регистрирај карта
• Линк Гео-линија
• Врска Гео-точка
• Линк Гео-регион

Комплементарните алатки беа додадени постепено, вклучувајќи ги и некои за директно уредување на геопросторниот администратор.

• Администратор за да ги видите функциите
• Тополошка анализа
• Види SAFT
• Прелистајте ја функцијата
• Конвертирај крива на LineString
• Креирај функции
• Креирај својства
• DBConnect конфигурација
• DBConnect Испраќам барање
• Уреди ја функцијата Xfm
• Уредете го Xfm проектот
• Отстрани карактеристики Xfm
• Идентификација на парцели
• Измени симбологија
• Функции за надпишување
• Класа тематизација
• За тематски
• Тематиката со паѓачката листа
• Xfm комунални услуги

2. Податоците: Миграција од ДГН во просторна база: Oracle Buider или Бентли мапа?

Најинтересен предизвик во ова беше дека е потребна контролирана миграција и имајќи предвид дека DGN датотеките кои се ажурирани повеќе од 10 години може да имаат проблеми со топологијата - вистинско лудило.

Навистина беше. Главните проблеми на мапите се тука:

• Модификацијата на парцелата во границата на датотеката (сектор или зона) подразбира дека мора да има модификација на двете, вклучувајќи ја и совпаѓањето на јазли во случаи како кога во еден сектор е една линија, но во соседот таа линија е сегментирана.
• Постојат датотеки кои по трансакциите за одржување на 300 складирани во историјата на DGN можат да бидат оштетени.
• Постојат повеќе комплексни проблеми кои не можат да се контролираат во кабинетот, како на пример кога имотот се преклопува со друг сосед во друга датотека, за износи што не можат да се решат на картата, бидејќи тоа би вклучувало и теренска инспекција за да се избегне да влијае на трето лице.
• Лошите практики, како што е вклучувањето на мапи во различни проекции, во овој случај имаа сектори во NAD27, иако стандардот беше WGS84. Во екстремни случаи беа направени прилагодувања помеѓу податоците од различни проекции, до перверзни.

Решението беше алатка за тип на Wizzard за масовна миграција, која може да мигрира индивидуална мапа, неколку или дури и цела општина (градска сала) или оддел.

Во суштина она што алатката ги зема податоците од проектот Geographics и ги промовира до карактеристиките на Benltey Map, потоа прави серија валидации, како што се:

• Еден-на-еден врска помеѓу геометријата и база на податоци,
• Валидација на недостаток на дупликати,
• Проверка на конзистентноста на површина-центрио,
• Проверка на објекти на картата во однос на неактивни објекти во базата на податоци,
• Валидација на топологијата во однос на постоечките топологии во просторна основа

По валидациите, панелот овозможува масовно собирање на информациите, како што се методот на мерење и стандардот за контрола на квалитетот на тие податоци.

Конечно, објавете во базата на податоци, конечно генерирајте извештај. Од речено до факт, има огромна истегнување, но конечно се прилагоди на каприците на Oracle Spatial кои сè уште се далечни како оние на Бентли и нивниот начин на гледање на комплексни својства или многу темиња.

3. Публикацијата: Geoserver или MapServer? Отворени слоеви или летоци?

Прегледувач е изграден со користење на OpenLayers и некои додатоци. За прв пат по 10 години занемарување на развојот на просторниот дел, можеше да се види нов прегледувач што го замени ActiveX на GeoWeb Publisher. Кодот MapFish беше искористен за печатење, geojson за контрола на страничното дрво, од Geoserver се сервираа слоевите опслужени од OracleSpatial.

Конечно, замена на технологии беше направена според следниот графикон. Како што можете да видите, комбинација на слободен код, одржување на базата на податоци и управување со земјиштето користејќи комерцијален софтвер.

4. Изградба и уредување, директно во Oracle Spatial. Мапа на Бентли или QGIS?

Ова е друга приказна. Мапа на Бентли се уредува природно на просторна основа, што предизвикува конфликти доколку не работи со услугата за трансакциски веб-карактеристики (WFS). Конфликтот е:

Како да се реши правилото за да не се дозволи преклопување на топологијата, ако се уредува и кога сака да објавува извештаи дека објектот влијае на себе?

Ова е решено со верзионирање пред, уредување директно и потврдување дека при објавување, ако нешто не успее, верзијата се обновува, оставајќи ја трансакцијата целосна, но во неуспешна состојба.

Друг проблем што мораше да се надминат за внесувањето на масивни податоци, со оглед дека корисниците треба да се престане со користење geographics и имаше неколку проекти до масовни земјиште.

Ова беше лесно бидејќи беше направена само алатка слична на онаа што се користеше за интегрирање на податоците во Microstation Geographics, олеснување со потенцијалите на BentleyMap и со повеќе контролиран асистент.

Сликата покажува како оваа алатка е развиена, со некои особености, како што се создавање и регистрација на темиња и вклучување на Puntoparcela, како листа на функционалности во случај методот на мерење на некои темиња не одговара на одреден стандард за квалитет.

Дефинитивно овој проток беше многу добар, бидејќи корисниците знаеја кои алатки ги користат најчесто. Беше потребно да се натераат да го променат својот менталитет помеѓу преселување од повеќе одлики до управување по нивоа, промовирање на нови придобивки за да заборават на архаичната Microstation V8 2004, како што се услугата WMS, транспарентите и природното препознавање на DWG-датотеките од неодамнешните верзии; Што да не кажам за интероперабилноста со kml, shp и gml за повеќето астрални.

Слично на тоа стана катастарски одржување алатки, кои имаат можност да ги менуваат директно во форми или намалување на Arc-јазол за комплексни случаи.

5. Клиент за општини преку ГМЛ. QGIS или gvSIG?

QGIS. Но, тоа е друга приказна што треба да се раскаже подоцна.