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

Това е общо предизвикателство за много проекти по кадастър и картография, което от 2000-2010 Microstation Географско положение интегрирани време като двигател за пространствени данни, като се има предвид причини, както следва:

• Управлението на архитектурни възли бе и продължава да бъде изключително практично за кадастралните проекти.
• В DGN е привлекателна алтернатива, за това, което версийте в същия файл, който не се е променило в 15 години, противно на други формати, в които сме виждали много несъвместими версии на всеки три години.
• В 2002, свободният софтуер беше далечна мечта за това, което имаме днес.
• Стандартите на OGC не претеглят дори собствения софтуер.
• ШП файловете бяха ограничени за проекти с висок профил и пространствените бази бяха все още много затворени за нестандартизирани схеми, които компрометират работата на сървърите ... и среброто.
• Отдалеченото свързване беше в начало в сравнение с това, което имаме сега.

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

Проблемът не е в постепенното развитие и вместо в преминаването към Geospatial Server или по-стабилни версии на ProjectWise, които искат да направят ГИС оцеляване от физически файлове, притежаващи целия потенциал на лицензирания Oracle Spatial и способността да се развиват. Така че това беше нашето предизвикателство.

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

По-специално бих предпочел първия. Но когато сте пред транзакционна система, която не е ориентирана към услугите, но работи добре, при която част от логиката и целостта е като PL в базата данни, промяната на базата на OpenSoure не е спешна. Не, освен ако целта ви е да разработите нова версия на системата, която не е налична веднага.

Нито става въпрос за извършване на талибански действия за омаловажаване на всичко, което мирише на частно. Така че да останете с Oracle е мъдро решение, ако работи добре, ако е голямо и взискателно, ако е добре проектирано, защитено и ако подкрепата се използва. Тема за друг повод.

Така останалото беше да се разработят функционалности за прехвърлянето на данните към тази база, услуги за публикуване и инструменти за управление на данни за векторна транзакция.

За да се контролират ролите и потребителите, които преди са били управлявани от ProjectWise, е създаден модулен инструмент, който позволява:

• Управлявайте потребителите и ролите от BBA.
• Задайте на потребителя административни права, право на отдели и общини.
• Задайте право на кадастрално досие по проект.
• Право на инструменти, налични в модулите за конструиране, издание, публикуване, консултация и администрация По този начин се създават само нови приложения, които се показват на потребителите според тяхната роля или конкретно назначение.
• Този панел за влизане също така опростява общата сложност на проектите на BentleyMap, така че само с влизане ще видите дървото на категориите и атрибутите, определени в Geospatial Administrator.

Панел от това решава недоразумения и рискове на потребителите, нови за функции като оперативна съвместимост на данните. Което е поредният сблъсък, защото Bentley редактира първоначално в Oracle Spatial, което е прекрасно, но и рисковано, ако нямате контрол върху транзакциите.

Така например модулът "Строителство" има следните инструменти:

• Присвояване на функции
• Помощник за географско свързване
• Мигриране на партиди в пространството
• Изтриване на обекти
• Редактиране на полигони
• Износ на Shp / CAD
• Импорт на Shp / CAD
• Миграция на Геолин
• Миграция Geopunto
• Георегион на миграцията
• Регистрирайте картата
• Link Geo-Line
• Link Гео-точка
• Link Geo-Region

Допълнителните инструменти бяха добавени постепенно, включително някои, за да редактират директно геопространствения администратор.

• Администратор, за да видите функции
• Топологичен анализ
• Заявка SAFT
• Вижте функцията
• Преобразуване на кривата до линейни
• Създаване на функции
• Създаване на свойства
• Конфигурация на DBConnect
• DBConnect Query
• Редактирайте функцията Xfm
• Редактиране на проекта Xfm
• Премахване на функции Xfm
• Идентификация на парцела
• Промяна на символа
• Презаписване на функциите
• Обучението по класове
• Theming
• Тематизиране по падащ списък
• Xfm Utilities

2. Данните: Миграция от DGN към пространствена база: Oracle Buider или Bentley Map?

Най-интересното предизвикателство в тази епоха, контролирана миграция е необходима и, като се има предвид, че досиетата по DGN като са били актуализирани за над 10 години може да има проблеми с топология-истинска лудост.

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

• Модификация на заговор на граничния файл (сектор или зона) предполага, че трябва да има промяна и на двете, включително съвпадение възли в случаи като например, когато един сектор е една линия, но в съседна тази линия е сегментиран.
• Има файлове, които след транзакциите за поддръжка на 300, запазени в историята на DGN, могат да бъдат повредени.
• Няма по-сложни проблеми управляеми кабинет, тъй като, когато се припокрива с площ на друг съсед в друг файл, за суми, които не могат да бъдат решени на картата, защото това би означавало да полска инспекция, за да се избегне засягането на трето лице.
• Лошите практики, като включването на карти в различни прогнози, в този случай имаше сектори в NAD27, въпреки че стандартът беше WGS84. В екстремни случаи бяха направени корекции между данните от различни прогнози и изкривяванията.

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

По принцип инструментът използва географските данни за проекта и ги популяризира с функциите на Benltey Map, след което прави поредица от валидации като:

• Едно към едно отношение между геометрията и базата данни,
• Утвърждаване на липсата на дубликати,
• Проверка на консистенцията на площ-центрофуга,
• Валидиране на обекти на картата по отношение на неактивните обекти в базата данни,
• Валидиране на топологията по отношение на съществуващите топологии в пространствената база

След валидирането панелът позволява мащабно добавяне на информация, като например метод за измерване и стандарт за контрол на качеството на тези данни.

И накрая, публикувайте в базата данни, като накрая генерирате отчет. От казаното до фактите има огромно разтягане, но накрая се приспособи към прищявките на Oracle Spatial, които все още са толкова далечни, колкото тези на Bentley, и начина им да виждат сложни свойства или много върхове.

3. Публикацията: Geoserver или MapServer? OpenLayers или брошура?

Изграден е визуализатор с помощта на OpenLayers и някои приставки. За първи път след 10 години пренебрегване на развитието на пространствената част се вижда нов зрител, който замества ActiveX на GeoWeb Publisher. Кодът MapFish е използван за печат, geojson за управление на страничното дърво, от Geoserver са обслужвани слоевете, обслужвани от OracleSpatial.

И накрая, замяната на технологиите е извършена съгласно следната графика. Както можете да видите, комбинация от свободен код, поддържане на базата данни и управление на земята с използване на собствен софтуер.

4. Изграждане и редактиране, директно към Oracle Spatial. Карта на Bentley или QGIS?

Това е друга история. Bentley Map редактира първоначално на пространствена основа, което причинява конфликти, ако не работи с услуга за транзакционни уеб функции (WFS). Конфликтът е:

Как да решим правилото да не позволяваме препокриване на топологията, ако се редактира и когато искаме да публикуваме доклади, че обектът засяга себе си?

Това се разрешава чрез редактиране преди, директно редактиране и потвърждаване, че при публикуване, ако нещо се провали, версирането се възстановява, оставяйки транзакцията завършена, но в неуспешно състояние.

Друг проблем, който трябваше да бъде решен, е масовото вписване на данни, като се има предвид, че потребителите трябваше да спрат да използват Geographics и имаха няколко проекта за набиране на масивен кадастър.

Това беше лесно, защото само инструмент, подобен на този, използван за интегриране на данните в Microstation Geographics, беше направен, улеснявайки с възможностите на BentleyMap и с по-контролиран асистент.

Изображението показва как е разработен този инструмент, с някои особености, като например създаването и регистрацията на върховете и включването на Puntoparcela списък функционалност в случай на метода на измерване на някои върхове не отговарят на определени критерии за качество.

Определено този поток беше много добър, защото потребителите знаеха кои инструменти използват най-често. Беше необходимо да ги накараме да променят манталитета си от преминаване от множество функции към управление по нива, насърчавайки нови предимства, така че да забравят архаичната Microstation V8 2004, като услугата WMS, прозрачно фолио и родното разпознаване на DWG файлове от последните версии; Какво да не кажа за оперативната съвместимост с kml, shp и gml за най-астралните.

По същия начин са създадени инструменти за кадастрална поддръжка, които имат възможност да се редактират директно във форми или да ги спускат на дъга за сложни случаи.

5. Клиент за общини чрез GML. QGIS или gvSIG?

QGIS. Но това е друга история, която ще разкажете по-късно.