.:: Ewmapa ::.

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

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

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 ?

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.

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.

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

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.

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.