Podbijam temat ale też dodaje do tematu.

Przy imporcie danych nie ma raportu (informacji) ile i jakie elementy zostały zaimportowane.
Przydała by się taka informacja: z czego został przeprowadzony import i jakie dane zostały zaimportowane.

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.
Oczywiście to tylko przykład.

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 

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.

Nie Darku nie przejęzyczyłem się: wczytaną  - 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... 

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

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ą).

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.

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ę.

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.

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.

A co z resztą ?

Cytat: Nyzczsel w Środa 06 Lipiec 2011, 10:34:07
- 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 ?

Cytat: Nyzczsel w Środa 06 Lipiec 2011, 10:34:07
- 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.

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).

Marcin jaki masz problem z importem pliku swde do ewmapy?