W takiej sytuacji najrozsądniej jest chyba (moim zdaniem) trzymanie odpowiednio skonfigurowanych pustych baz  łącznie z plikiem baza.ini w jakimś katalogu roboczym i w zależności od potrzeb kopiowanie tego w odpowiednie miejsce docelowe połączone z ręcznym modyfikowaniem w notatniku "produkcyjnego baza.ini" (wkopiowujesz wpis zmieniając ścieżkę dojścia do plików).

Nie do końca zgadzam się z tym pomysłem. Wybór rodzaju eksportu/importu wymusza na użytkowniku świadome działanie i jest pierwszą kontrolą, czy wykonawca roboty geodezyjnej dostał właściwy plik z ośrodka dokumentacji oraz czy wykonawca przekazuje odpowiedni plik z eksportem dla ośrodka dokumentacji.
O ile w przypadku ośrodków część ma wdrożony mechanizm automatycznych eksportów danych i tu o pomyłce nie ma mowy, o tyle geodetom czasem zdarza się zrobić nie ten typ eksportu, który by chcieli. Podczas zasilania bazy ośrodkowej, gdyby ewmapa automatycznie  przełączała się na import zgodny z typem pliku, generowałoby to w najlepszym razie komunikaty o braku możliwości wgrania pliku z uwagi na występowanie w bazie docelowej obiektów, a w najgorszym scenariuszu powielałoby to elementy w bazie docelowej tam, gdzie baza nie jest zobiektowana.

Różnice potrafią występować w ramach różnych baz jednego PODGik'u 

Nie ma w tym wielkiej filozofii, ale pamiętaj, że sama konwersja nie utworzy baz obiektowych, tylko zamienia rozwarstwienie, symbole i typy linii do zgodności z rozporządzeniem.
Do konwersji używasz dołączonego z ewmapą programu "E11konw.exe" oraz pliku ze schematem konwersji "BDOT500.sch" lub "GESUT.sch".
I z tymi plikami jest największy problem, bo prawda wygląda tak, że do każdego ośrodka dokumentacji potrzebowałbyś innego schematu konwersji, gdyż każdy ośrodek prowadziła bazy na swój własny sposób, tj lekko modyfikowane warstwy, różne menu aktywności ...
Wygląda to tak, że śledzisz podwarstwa po podwarstwie otrzymaną bazę, i na jej podstawie tworzysz/modyfikujesz plik *.sch.
Zwróć uwagę jeszcze na to, że te pliki nie są aktualizowane z kolejnymi wersjami ewmapy, a w międzyczasie, tj od 2013 roku (pliki ze schematami są z listopada 2013) trochę się pozmieniało z rozwarstwieniem ewmapy FB.
Ach, jeszcze jedno, ważne. Plik wejściowy i wynikowy przy konwersji to eksporty wielu warstw do formatu tekstowego.

Musisz też pamiętać, że na każdym kompie musi być zainstalowany klient firebird w tej samej wersji co na serwerze z bazami.

Używaj menu dostarczanego z ewmapą. Masz to w tej lokalizacji  ...\ewmapa\gesut\gesut.mnu. Jeżeli ktoś w tym menu nagmerał, zrób upgrade ewmapy i odzyskasz niemodyfikowane menu (przy aktualizacji aktualizują się także pliki menu).
Łykiem yerby uczczę mój setny wpis

Rozumiem, że tworzysz obiekty z istniejących elementów. Musisz zamienić teksty na zmienne, i zmienić wartość dla opisu eN na ${u.Etykieta} a dla rzędnej na ${u.Etykieta2}, lub usunąć co jest i wykorzystać menu ewmapy. Po odpowiednim uzupełnieniu atrybutów obiektu pojawią się na mapie pożądane wartości.
Musisz pamiętać jeszcze o tym, że rzędna musi być podobiektem przewodu.

Z tego co wiem, Ewmapa nie eksportuje obiektów ole. Pocieszeniem może być fakt, że ole możesz wczytywać w programach CAD'owskich, np darmowy (nie do celów komercyjnych) DraftSight.

Trochę mało informacji. w Ewmapie baza obiektowa czy nie?
Powinnaś zacząć od pobrania danych do modyfikacji z ośrodka dokumentacji geodezyjnej, wgrać to do siebie tworząc bazę roboczą, wnieść pomiar używając do tego menu aktywności takiego, jaki obowiązuje w ośrodku dokumentacji, wyeksprotować pliki modyfikujące i przekazać je do ośrodka. Myślę, że najrozsądniejszym rozwiązaniem jest kontakt z pracownikiem ośrodka, ustalenie wymogów, zasad, wersji oprogramowania. My tu możemy coś radzić, ale to trochę wróżenie z fusów

Jeśli masz ewmapę, tą instrukcję masz na dysku 
...\Ewmapa\Instr\mapa_zasadnicza.pdf

@Kassovitz, masz rację. Występuje problem z eksportem GESUT'u do dxf. Dotyczy przewodów rurowych i rur osłonowych. To tak na szybko stwierdzone. Zgłosiłem problem do GEOBID'u.

Cytat: kassovitz w Czwartek 07 Marzec 2019, 21:17:32
nawet geoportal generuje plik dxf w którym są zdublowane linie ...

Dane generowane przez geoportal to nic innego jak kopia ewmapy uruchamiana w trybie wsadowym z uprzednio przygotowanym scenariuszem eksportu. Żadne czary mary. Skoro eksportując ręcznie wychodzą błędy, Geoportal nie naprawi nic w tej materii. 

Jeśli eksportują się dwie linie, jedna na drugiej, to zapewne tak jest to wrysowane w bazie. Sprawdź to w ewmapie klikając na info z paska "operacje na warstwach". Sam fakt, że baza jest prowadzona w FDB, nie powinien powodować dublowania linii na tej samej warstwie. Ja się z takim czymś nie spotkałem.

Spróbuj coś takiego:
update EW_OBIEKTY set NUMER=replace (NUMER, '060507_2.000', '') where NUMER like '060507_2.000%'

Ale zwróćcie uwagę, że jeżeli po skomplikowanej obwodnicy pociągnie się marker polilinii i odłoży go równolegle o 0.5 metra, wygląda to ok.

Moim zdaniem chodzi o eksport z podanego obszaru, ale to tylko mój domysł, bo pytanie jest bardzo nieprecyzyjne.