.:: Ewmapa ::.

Witam, mam taki o to problem:

Występuje problem na linii wykonawca-ośrodek w momencie wsadzania wsadu przez ośrodek, kiedy kartujemy mapę często zachodzi potrzeba przesunięcia istniejącej etykiety (wysokości, wysokości zasuwy, włazu etc.) robimy to poprzez funkcję „modyfikacja pozycji linii lub tekstu” . Nie robimy tego poprzez edycje obiektu i zapisanie go ponownie. I teraz w momencie kiedy ośrodek wgrywa nasz wsad do siebie, do tych ruszanych istniejących elementów mapy przypisuje się nasz operat co oczywiście w ocenie ośrodka jest nieprawidłowe. Ośrodek mówi żebyśmy robili dwa pliki wsadowe jeden dla nich drugi dla klienta tak żeby mapa dla klienta wyglądała poprawnie czytelnie a dla nich nie. Uważam że jednak program powinien działać tak żeby móc robić 1 plik wsadowy, móc ruszać istniejące elementy mapy ale bez przypisywania naszego operatu.
Czy u kogoś występuje podobny problem ?

Jeśli podgik przed zmianą nie zrobi aktywacji swojego operatu i skorzysta z opcji imporuj operaty to dostanie efekt taki jaki chce... Pod warunkiem że ty działasz na operatach.

tylko, że chyba w podgik się boją, że takimi importami ktoś im "namiesza" w operatach. Fajnie by było, gdyby to było programowo rozwiązane...

Czyli generalnie jeżeli ośrodek pracuje w ten sposób jak opisałeś że tworzy i aktywuje swój operat przed wgraniem naszego wsadu to nie masz szans na rozwiązanie problemu ? Zawsze przypisze się nasz operat do tego co "tylko" przesunęliśmy etykietę.
Rzeczywiście mogłoby to być rozwiązane programowo, dzwoniłem do geobidu w tej sprawie ale jakoś na szybko informatyk nie mógł znaleźć rozwiązania

Znalazłem rozwiązanie owego problemu, generalnie program został tak skonstruowany od strony informatycznej i można byłoby to zmienić.
Ośrodek działa tak, że dodaje operat, uaktywnia go następnie importuje plik - wtedy nasz operat przypisuje się do elementów redakcji mapy.
Jeżeli ośrodek najpierw wybierze plik do importu, wtedy program z automatu pyta go na podstawie jakiego operatu i wtedy robi dodaj operat, uaktywnij to elementy redakcji mapy wchodzą na nowe położenie bez przypisania operatu nowo utworzonego, a elementy nowe wchodzą na swoje miejsce z przypisanym nowym operatem.

Ale w tej opisanej sytuacji chyba to nie jest problem

Czym się różni przesunięta etykieta od etykiety ze zmienioną wartością? Moim zdaniem z punktu widzenia programu niczym. Jest zmiana jest nowy operat. Oryginalny operat miał inną redakcję, inne wartości, inne położenie elementów. Twoim operatem następuje zmiana, historia jest zapisana, a nowe elementy i elementy zmienione przez Ciebie mają przypisany Twój operat. W czym problem?

Ale w tej opisanej sytuacji chyba to nie jest problem

Czym się różni przesunięta etykieta od etykiety ze zmienioną wartością? Moim zdaniem z punktu widzenia programu niczym. Jest zmiana jest nowy operat. Oryginalny operat miał inną redakcję, inne wartości, inne położenie elementów. Twoim operatem następuje zmiana, historia jest zapisana, a nowe elementy i elementy zmienione przez Ciebie mają przypisany Twój operat. W czym problem?

W tym że ośrodek nie chce przepuścić mi roboty ponieważ mówi mi że elementom które nie podlegały pomiarze przypisał się mój operat, a tak być nie może. Ja nie wiem czy to jest problem, dla mnie nie ale ośrodek "się czepia". Z drugiej strony dlaczego elementy które przesunąłem mają mieć mój operat, to by świadczyło że ja je pomierzyłem lub coś , może gdyby dodać opis coś w stylu operat dodany z powodu redakcji mapy czy coś nie wiem.

Generalnie powinno być tak że żadna zmiana położenia etykiety nie powinna powodować zmiany operatu.

Generalnie powinno być tak że żadna zmiana położenia etykiety nie powinna powodować zmiany operatu.

może przekornie, ale zapytam: Dlaczego?
Jest to jakaś zmiana na mapie? jest. Historia jest zachowana? jest. Wiemy skąd się wziął dany element i kto go ostatnio ruszał? wiemy. Baza w ośrodku jest zredagowana? jest. Nie ma potrzeby prowadzenia dwóch baz tak jak to opisał Cezary? nie ma, bo przecież wszystko jest OK tak jak to zredagował wykonawca i oddał mapę.
Jedynym problemem jest to, że ostatni przypisany operat do obiektu nie jest faktycznie operatem źródłowym. No i? Można sprawdzić historię i  się dowiedzieć co to jest i skąd pochodzi?
Może faktycznie trzeba by przemodelować cały system przypisywania operatów w Ewmapie. Może to jest wina programu. Może należałoby przerobić tylko sposób importu dla podgik'ów. Może powinni mieć możliwość importu  w taki sposób aby import wchodził z takimi operatami jakie przypisał wykonawca, a nie tylko z jednym najnowszym operatem. Często się nam zdarza, że nie wykonujemy pomiaru jakiegoś elementu tylko wprowadzamy go wykorzystując materiały archiwalne np. mapa była z digitalizacji, mierzę chodniki i budynki, ale kanalizację wprowadzam nie z mojego pomiaru tylko z jej inwentaryzacji sprzed 20 lat. Wtedy ta kanalizacja mogła by mieć przypisany operat archiwalny, a nie mój.  Jednak czy przypisanie mojego operatu powoduje, że mapa jest źle zrobiona? Chyba nie, bo w sprawozdaniu tech. w operacie będzie informacja o tym, że kanalizację opracowałem na podstawie innego pomiaru niż mój. Jak ktoś będzie chciał robić śledztwo skąd się to wzięło to bez problemów dotrze do źródła. Tylko tyle, że po za teoretyczną potrzebą robienia takich poszukiwań, kto? kiedy? i w jakim celu?  miałby je robić.
wg mnie każda zmiana powinna pociągać za sobą aktualizację listy operatów dla elementu/obiektu. 

Sądzę, że Geobid przemyślał temat i nie podjęli takich decyzji bez analizy skutków. Nie jestem pewien czy należy zakładać, że jesteśmy w tym zakresie od nich lepsi i bardziej przewidujący.

Drelson ja rozumiem, że się ośrodek może uprzeć, bo tak, ale w zasadzie tylko to powoduje problem.