Ewmapa - Forum użytkowników

Tam gdzieś jest check, żeby nie sprawdzał obwodnicy, ale to też nie będzie elegancko.
Jeśli masz kilka działek "poprawionych" to ręcznie je popraw w swojej bazie i wtedy rób eksport.
Samo faktycznie się nie domyśli, która wersja jest lepsza.

Cytat: Lupus w Poniedziałek 12 Styczeń 2026, 15:06:56Eksport poprawnych działek "po" do pliku edz
Pełny import do nowej bazy i prób importu plików "przed" i "po" jako pliki pierwotny i wtórny

nie bardzo mi to wychodzi, może źle to robię:
1. baza z moim podziałem zrobionym na pliku pierwotnym sprzed czyichś zmian- tu eksportuję do edz działki, kontury i użytki
2. baza nowy import do modyfikacji ze świeżego pliku z ośrodka- czyli z czyimiś zmianami
3. do bazy nr 2 importuję przez działki--> import-w pliku pierwotnym wstawiam działki wyeksportowane z bazy 2, a w pliku wtórnym moje działki "po" z bazy nr 1- program poprawia mi moją działkę ok, ale te które ktoś już modyfikował też poprawia na mój stan. Jak wyeksportuje mój podział tylko z markera wokół- to usuwa te dalsze działki.

Eksport poprawnych działek "po" do pliku edz
Pełny import do nowej bazy i prób importu plików "przed" i "po" jako pliki pierwotny i wtórny

zrobiłam bardzo skomplikowany podział- dużo przesunięć, modyfikacja konturów i użytków, działka drogowa zmieniła całkiem miejsce, częściowo wręcz wypadła. Protokół z PODGiK- w międzyczasie ktoś zmodyfikował działki sąsiednie gdzieś dalej i jest konflikt obiektów. Próbuję zrobić import uzupełniający, ale pojawia się błąd że importowana działka występuje w nowszej wersji. Jak zaimportuję mimo konfliktu to szlag trafi moją robotę... Da się jakoś wybrać co ma być poprawione, a co nie? Albo jakoś obszarem zrobić eksport, żeby w PODGiK przeszło?

Możesz mieć w pliku do cm.
Importując rzędne naturalne ewmapa ogarnie temat w locie.

Wybierać rzędne mozesz poprzez dodawanie ich do bloku a potem eksport/import obiektów z bloku.

czy macie jakiś "patent" na hurtowy import rzędnych. Wiem, że można to zrobić przez import rzędnych do baz GESUT i BDOT, ale chodzi mi bardziej o wybranie poszczególnych rzędnych. Mam ich kilkadziesiąt tysięcy i nie chcę importować wszystkich jak leci, bo usuwanie niepotrzebnych zajmie cały dzień. Może w jakiejś drugiej roboczej bazie zaimportować wszystko jak leci i stamtąd powybierać (jak)? Drugi temat to czy jeśli w pliku txt będę miała rzędne do 2 miejsc, a przy imporcie zaznaczę, że to rzędna naturalna- to będzie OK, czy muszę utworzyć plik wyjściowy txt od razu do 1 miejsca po przecinku.

Ośrodki wydają też w formacie tekstowym, dxf i kilku innych, to nie znaczy, że można oddać im to poprawnie.

Plik emu ma tę przewagę, że oddaje nie tylko dane gml'owe, ale też poprawia np. warstwy, oddaje cechy punktów itp.

Zastanawiam się, co by się stało jeśli byś mając bazę (A), czyli tą którą już poprawnie zrobiłeś z plików emu:

1. zaimportował nowy plik gml do czystej bazy (B)
2. z (B) wydał plik emu do modyfikacji
3. z (A) wydał plik emu modyfikujący
4. emu mod z (A) zaimportował do bazy (B) udając, że to zwykła zmiana
5. wydał bazę (B) do modyfikacji w gml...

Ciekawe czy by zadziałało?

ChatGpt odpowiedział mi tak:
Aby prawidłowo skonfigurować połączenie z komputera B do bazy danych Firebird (FB) znajdującej się na komputerze A, należy zastosować odpowiedni format ścieżki dostępu oraz upewnić się, że infrastruktura sieciowa nie blokuje połączenia.
Oto kroki niezbędne do poprawnej konfiguracji:
1. Prawidłowy format ścieżki dostępu
W systemie EWMAPA ścieżka do bazy Firebird musi mieć postać: fb:<adres serwera>:<baza na serwerze>.
Dla Twojej konfiguracji, gdzie komputer A ma IP 192.168.2.20, a serwer FB nasłuchuje na porcie 3052, prawidłowa ścieżka wprowadzana na komputerze B to: fb:192.168.2.20/3052:D:\baza\egib.fdb.
Ważne uwagi dotyczące ścieżki:
• Ścieżka lokalna serwera: Ścieżka po drugim dwukropku (D:\baza\egib.fdb) musi być ścieżką widzianą z punktu widzenia serwera (komputera A). Nie wolno używać liter dysków zmapowanych na komputerze B ani ścieżek sieciowych typu UNC (np. \\192.168.2.20\...).
• Separator portu: Adres IP i port oddziela się znakiem ukośnika (/).
2. Konfiguracja zapory sieciowej (Firewall)
Jeśli na komputerze A (serwerze) zainstalowana jest zapora sieciowa (Windows Firewall lub inny program antywirusowy), należy bezwzględnie odblokować port 3052 dla ruchu przychodzącego. Brak odblokowania tego portu jest najczęstszą przyczyną komunikatu o niedostępności bazy danych.
3. Klient Firebird na komputerze B
Komunikat o braku klienta FB sugeruje problem z bibliotekami dostępowymi na komputerze B:
• Aby program EWMAPA mógł połączyć się z serwerem, w jego katalogu głównym (lub w ścieżce systemowej) musi znajdować się biblioteka klienta Firebird (np. gds32.dll lub fbclient.dll).
• Upewnij się, że wersja klienta na komputerze B jest kompatybilna z wersją serwera Firebird na komputerze A, która obsługuje bazę na porcie 3052.
4. Logowanie i uprawnienia
• Przy połączeniu zdalnym program może wymagać ponownego podania loginu i hasła (domyślnie SYSDBA i masterkey), chyba że na obu komputerach oraz w samej bazie danych użytkownicy i hasła są identyczni (tzw. logowanie kaskadowe).
• Możesz wymusić okno logowania do bazy Firebird przy otwieraniu projektu, korzystając z opcji "Wymuś logowanie do baz Firebird" lub przytrzymując klawisz Shift podczas łączenia.

Na komputerze A w katalogu D:\baza jest założona baza FB. Na tym komputerze zainstalowane są trzy wersje Firebirda więc lokalnie mam do niej taką ścieżkę dostępu:
fb:127.0.0.1/3052:D:\baza\egib.fdb
ten komputer ma lokalne IP 192.168.2.20
Na komputerze B również mam zainstalowane trzy wersje Firebirda. Chcę podłączyć się do bazy na komputerze A. Próbowałem różnych wersji ścieżki dostępu ale zawsze dostaję komunikat, że albo na danym serwerze nie ma klienta FB albo, że baza jest niedostępna.
Jak prawidłowo skonfigurować takie połączenie?