Migreer kenmerken van geografische gegevens naar Bentley Map

Een tijd geleden hebben we gepraat over wat het betekent om de sprong van Microstation Geographics te maken Bentley Map, we hebben gepraat over hoe beide werken schema's en enkele belangrijke voordelen van Bentley Map. Al in een post vertelde ik hoe het mogelijk is migreer de structuur van het project, in dit geval wil ik kauwen hoe ik kaarten met migreren van geografische attributen naar classificaties van xfm kunnen migreren.

Hoewel een projectstructuur die is gebouwd met Geography Legacy, kan worden geïmporteerd vanuit de Bentley Map, betekent dit niet dat de eigenschappen die de objecten hebben, door het nieuwe project herkend worden, zij moeten worden toegewezen.

Hoe geografie werkte

In de stijl van Geographics hadden de objecten via een MSLINK een associatie met een database, dat was alles wat het object had, een OLE-type link. Deze MSLINK koppelde het grafische object uit het dgn-bestand via de MAPNAME van de MAPS-tabel en via de MSCATALOG om te bepalen waar de gegevens vandaan konden worden gehaald Entitynum. Bovendien waren er dubbele tafels voor Intergraph-compatibele projecten die voorheen meestal een RUG droegen.

Bovendien had het object een FEATURE, hoewel dit niet dynamisch was, bij het toewijzen ervan kreeg het de eigenschappen die voor dat attribuut waren gedefinieerd (inclusief opdrachten) en werd het geassocieerd met de CATEGORY-tabel. Een object kan meer dan één attribuut hebben en de prioriteit was degene die werd toegewezen door de definitieve stijl, dat FEATURE en andere objecten die aan de basis waren gekoppeld, waren gekoppeld aan de MSCATALOG-tabel waar ze het dergelijke toegewezen kregen entitynum dat was de navel van alles.

Dan het bestand index.dgn het handhaven van de vorm van kaarten verbonden zijn, hier de kaarten kreeg een mapId, dus elke tafel gekoppeld aan Geographics had minstens twee velden: MSLINK (aantal grafische entiteit, is uniek op elke kaart), die is altijd de primaire sleutel en mapId ( welke kaart is opgeslagen, het is uniek in de kaartcatalogus), die een vreemde sleutel is in de MAPS-tabel.

Dus de enige manier om met de gegevens te communiceren was door verbonden te zijn met de basis, en de operaties daarbij werden gemaakt naar het beest  zoals het bijwerken van de tabellen met informatie over het object, zoals oppervlakte, omtrek en coördinaten, zodat Publisher wist hoe het moest worden weergegeven. Je zou ook kunnen extraheren labels Dat viel als voorwerpen uit de database met dezelfde link van het gekoppelde object.

Het lijkt me simpel, maar het kost me een wereld om het van MGE te begrijpen, en het pijnlijke is dat alles wat rook doet, niet veel bijdraagt ​​aan een project met Bentley Map.

Hoe Bentley Map werkt

Een Bentley Map project behoudt dezelfde logica van categorie, attribuut, kaart, object; maar in dit geval verandert het formulier van de OLE-gegevensverbinding door XML veel van het proces.

In dit geval kan het object op de kaart gegevens hebben die zijn opgeslagen (in dezelfde dgn), wat wordt begrepen als xml of zoals Bentley wfm het noemt. Dan verandert het ook dat objecten nu maar één attribuut kunnen hebben, en ruimtelijk geassocieerd kunnen worden door topologische regels; Voordat de limiet van de appelboom dezelfde lijn kon zijn en ook de limiet van de eigenschap, moeten het nu afzonderlijke objecten zijn, maar met een topologische associatie zodat bij het wijzigen van de ene de andere ook zo is.

Dus interactie met gegevens is slechts één klik verwijderd, of u nu wel of niet bent verbonden met het project, u kunt alles lezen dat is achtergelaten als gegevens xfm. En dan de afhandeling van labels en attributen eigenschappen, gewoon door wijzigingen aan te brengen vanuit de Geospatial Administrator. Voorheen was het aanbrengen van wijzigingen alleen dynamisch in de weergave via Publisher, maar voor objecten moest het kenmerk worden verwijderd en opnieuw worden toegewezen.

Bovendien biedt Bentley Map opties om gegevensformulieren, opeenvolgende processen, bijbehorende opdrachten (methoden / bewerkingen / domeinen / criteria / rapporten) en andere pirouettes te maken die de gegevensconstructie vergemakkelijken.

Iets wat niet veel veranderen, en dat de gebruikers van ESRI zoals ze zeggen, dat zich bezighoudt met de groene rook te kauwen te bereiken en te verteren.

Het probleem

Nu, migreren de projectstructuur mogelijk is, voeg dan de functionaliteit met behulp van de Geospatial Administrator, die klaar zijn om voeden cijfers blijven zou zijn, maar het dilemma is:

En de kaarten die zijn gebouwd met Geografie?

Bentley heeft hiervoor geen artefact ontworpen waarmee het omzetten van objecten van een Legacy-project naar een xfm ... Wat een fuck!

Het voorstel zal voorstellen is wat ik zie levensvatbaar nadat ze chatten met een vriend uit Chili contact met me na een aantal e-mails van een verouderd, maar functioneel Geofumada hebben bereikt.

Stap 1. Exporteren om bestanden te vormen

Vanuit een open geografisch project wordt gekozen voor het exporteren van attributen om bestanden te formatteren (bestand / export / SHP). Dit moet voor elk worden gedaan kenmerken bestaand op de kaart.

Het zou nodig zijn om een ​​beetje te vechten als de objecten centraal / grens zijn, aangezien het nodig zou zijn om ze door te geven aan de vormen door de link naar hen over te brengen.

Ook kan de export naar Mapinfo, volgens uw voorkeur, worden uitgevoerd.

Stap 2. Vanuit Bentley Map importeren

En nu, uit het Bentley Map Project, kozen we voor de importoptie (Bestand / import / GIS Data types), hiermee verschijnt het venster Interoperabiliteit, de rechter muisknop is klaar in invoer en het is geselecteerd nieuwe invoer.

Met de rechtermuisknop op Imoport1 selecteert u een bestand of een hele directory. Het is mogelijk om bestanden vormeneen Mapinfo-bestanden typen mif en tabblad.

Door het aan te raken functie klasse We kunnen zien dat het mogelijk is om niveau, kleur, transparantie en andere eigenschappen te selecteren.

Om het toe te wijzen kenmerken waar we in geïnteresseerd zijn, geef het gewoon de laag (niveau) toe.

De pijnlijke

Zoals Memín in die oude Mexicaanse paquin zei:

"Diantres !!!"

Dit zou voor elke functie op elke kaart in elke categorie in elk project moeten worden gedaan.

Hiervoor is het mogelijk om de importeren, dus het wordt alleen bestand voor bestand of map genoemd. De waarheid is dat er hard wordt gewerkt om gegevens te transformeren, vooral als deze zich in afzonderlijke bestanden bevinden. Het zou geen kwaad, werk een vba in .NET voor aut
Sla het proces over in plaats van deze taak te voet aan te pakken, wat kan leiden tot meer dan één zelfmoord per dag. Het grootste probleem is dat om de sprong te maken, we afhankelijk blijven van een gespecialiseerd (en zeer gerookt) adviesbureau om de ins en outs van Bentley Map en Geographics te begrijpen, het is mogelijk, maar de toepassingen zouden niet zo astraal moeten zijn (laten we toegeven, beide zijn) voor gewone gebruikers.

Nog meer pijnlijke, als informatie in het originele DNA werd opgeslagen in de geschiedenis... het nieuwe bestand heeft geen geschiedenis.

Concluderend

De oplossing die ik presenteer is haalbaar als je weinig gegevens hebt, of als deze is opgeslagen in een ruimtelijke cartridge, dus de trieste conclusie is dat de migratie van Geographics naar Bentley Map niet zo eenvoudig is vanwege gegevenstransformatie. Als de Geospatial Administrator, zoals hij eerder zei, is een tandpijn, data migratie kan nog pijnlijker zijn, tenzij Bentley denkt oplossingen voor zijn gebruikers die niet van de ene dag naar de andere willen gaan.

Om met geofumed vrienden te praten, maakten ze me een onverstandige analogie, maar sinds vandaag is een saaie dag in een zacht hotel en de vergelijking is zo waar, met uw toestemming zal ik het gebruiken:

"Het is niet zoals het veranderen van partners ...

... het zou kunnen zijn als je je maagd nogmaals verliezen "