Problem z importem bazy z pliku SWDE nasunął mi wiele pytań.
Jak to się dzieje że wyeksportowanej z Ewmapy bazy nie można normalnie bez problemu zaimportować także w Ewmapie?
Wychodzi na to że albo moduł eksportu albo moduł importu jest skopany.
A może można napisać jakiś plik konfiguracyjny który po wczytaniu wszystko ładnie automatycznie poustawia wraz z konfiguracją obiektowości budynków.
Rozumiem że jeżeli błędna jest baza -> program który nie pozwala na błędny import powinien nie pozwolić na eksport! czy dobrze rozumuję ?
A jeżeli już pozwala na eksport powinien moim zdaniem pozwolić na import z wykazem błędów.
Wiadomo że programy do prowadzenia ewidencji różnie sobie radzą z eksportem dlatego moim zdaniem Ewmapa powinna pozwolić na import błędnej bazy na tyle ile to jest możliwe wraz z raportem błędów.
Prosiłbym także o możliwość (już wcześniej pisałem) importu danych EGB na warstwy ! -> kładąc nacisk na import budynków - chodzi o obrys budynku. Pozwoliło by to ominąć przymusową konfigurację obiektów /budynków/.

Marcin jaki masz problem z importem pliku swde do ewmapy?

Problem jest taki:
- budynki powinny się importować na warstwy  - taka sama możliwość była by przydatna (import budynków jako obiektów zmusza nas do tego że musimy mieć dobrze skonfigurowaną obiektowość budynków),
- eksportując złą bazę masz taką możliwość - importować już nie za bardzo - wywala błędy,
- problem jak zwykle z numeracją użytków (wiem wiem o wpisaniu i przypisaniu wszystkich możliwości w kody.ini),
I taki mój apel - żeby była możliwość zrobienia importu na warstwy - o ile prostsze by było życie
Albo inaczej niech program pozwoli zrobić import z błędami a później jak sobie użytkownik będzie miał chęć poprawi dane (wykaz błędów wraz z zaimportowaną bazą - załatwia sprawę - oprócz budynków).

- problem jak zwykle z numeracją użytków (wiem wiem o wpisaniu i przypisaniu wszystkich możliwości w kody.ini),

To jest akurat denerwujące.
Możesz to rozwiązać w ten sposób że wywalasz plik kody_u.ini robisz import a potem przywracasz plik kody_u.ini.
Ale to rozwiązanie tymczasowe.
Trzeba napisać posta w dziale propozycje.

A co z resztą ?

- budynki powinny się importować na warstwy  - taka sama możliwość była by przydatna (import budynków jako obiektów zmusza nas do tego że musimy mieć dobrze skonfigurowaną obiektowość budynków),
- eksportując złą bazę masz taką możliwość - importować już nie za bardzo - wywala błędy,
I taki mój apel - żeby była możliwość zrobienia importu na warstwy - o ile prostsze by było życie
Albo inaczej niech program pozwoli zrobić import z błędami a później jak sobie użytkownik będzie miał chęć poprawi dane (wykaz błędów wraz z zaimportowaną bazą - załatwia sprawę - oprócz budynków).

Może jest na to rozwiązanie którego nie znam ?

Odświeżam wątek - może ktoś coś znalazł jakieś rewelacyjne rozwiązanie ?

Import - działek jakoś udzie w tłoku.
Ale import klaso - użytków - masakra ;] czy wszystkie głupoty trzeba wpisywać do pliku kody_u.ini ? czy jest jakieś rozwiązanie na wczytanie danych ?
Chyba lepiej wczytać bazę i bawić się już na bazie/warstwwach niż nie wczytać bo trzeba zmieniać kody i dodawać np.: dr-LsIV i inne głupstwa.

Jest taki mały myk.
Wykasuj plik Kody_U.ini z folderu Kontury (lub użytki w zależności jak masz bazę zrobioną)
Otwórz Ewmapę, wybierz odpowiednią bazę i wykonaj import.
Program nie będzie się czepiał oznaczeń typu RV-Bp - łyka wszystko jak leci.
Potem przywróć wykasowany wcześniej plik Kody_U.ini i restart ewmapy.
Działą w przypadku importu użytków z ewmapy.
Nie testowałem na swde ale powinno być tak samo.

Hmm teraz tak patrzę, że gdy wykasujesz plik Kody_U.ini to nie masz dostępu do konturów podczas importu swde.
Trza kombinować dalej - może czyszczenie pliku Kody_U.ini pomoże.

Ani to ani to ;/
Nic z tych rzeczy.

Moim zdaniem powinno zaimportować i napisać że wystąpiły następujące błędy ! jaki błąd i współrzędne lub też zaznaczenie markerem - zawsze można sobie taki marker zapisać na warstwę.

to może rozwiązanie znane z EwOpisu

lista występujących wpisów zestawiona z propozycją zmiany.

wtedy mamy możliwość poprawienia literówek, niestandardowych zapisów itp.

Można i tak - ale lepiej by była taka opcja już w bazie - wtedy wsadowo można by było poprawić całą bazę (już w czytaną).

nie "wczytaną" bazę ale "wczytywaną", w trakcie importu wtedy w bazie masz już tylko poprawne dane.

Nie Darku nie przejęzyczyłem się: wczytaną  :wizard:- różnica polega na tym że to jest tylko import z swde a taka funkcja byłaby w zakładce - działki/kont/uż
Dawało by to możliwość poprawy i istniejących baz i tych które są importowane z różnych formatów, danych itd...  :party:

Nie łapię Cię za słówka ale wyrażam swoje zdanie.

Pozwolenie na import błędnych danych, zawsze jest niepożądane.

Każdy program narobi "swoich" błędów i do tego mają służyć narzędzia kontroli wewnętrznych.
Natomiast zezwolenie na import danych z definicji błędnych jest mało sensowne.
Importowanie z każdego formatu może zostać poprzedzone procedurą kontroli danych, ale błędnych danych nie należy wpuszczać.
Można zapisywać pliki z "parami" do zmian, można próbować tworzyć automaty do wykrywania podobnych i dawania podpowiedzi.

Jedynym dopuszczalnym moim zdaniem przykładem możliwości importu pomimo błędu jest niepokrywanie się granic importowanych i tych już będących w bazie.
Bez tego nie da się uzgodnić styków, ale nazwy użytków/konturów powinny być ujednolicane przed zaimportowaniem.

Kiedyś wysłaliśmy do geobidu propozycję aby użytkownik miał możliwość wyłączenia sprawdzanie użytków podczas importu.
Ale jak dotąd cicho sza  :hmm:

Darku wiem że mnie nie łapiesz za słówka -że chciałeś przedstawić swoje zdanie.
Moje jest odmienne.
Czasem trzeba na szybko coś podejrzeć - a przejść przez ścieżkę "zdrowia" zmiany nazw użytków wymaga trochę czasu.
No dobrze importować  błędnych danych nie można a eksportować można ?
Ktoś Ci bubel wydaje a ty masz to wszystko poprawiać ?
OK jeżeli nie można importować błędnych danych to może i zrobić takie ograniczenie z eksportem ?
- wymuszenie poprawienia danych w bazach ośrodkowych przydało by się i to bardzo! Tylko co wtedy z danymi w ewidencji,  z rozbieżnościami grafiki z opisem?
No i teraz tak: ośrodek wydaje dane - ja nie mogę wczytać bez poprawienia - ok poprawiam  -> następnie aby oddać dane muszę z powrotem   zmieniać dane bo nie będzie się wtedy zgadzało z danymi opisowymi. Podwójna głupiego robota. :uglystupid2: :knuppel2:
Oczywiście to tylko przykład.