Jurek B. Napisał(a):
-------------------------------------------------------
> Witam.
> Tomku, dla Ciebie to na pewno oczywiste:
> gdyby zakładana była najprostsza wymiana
> różnicowa, czyli taka, że brak obiektu w pliku od
> geodety oznacza, że został on usunięty, to nie
> byłoby w schematach standardu wymiany danych GML
> atrybutów KoniecObiekt, koniecWersjiObiektu,
> poczatekWersjiObiektu.
> Warto zadać sobie pytanie - po co wprowadzono te
> atrybuty?
> Przydadzą się tylko wtedy, gdy będą potrzebne - a
> wtedy są potrzebne, gdy o czymś informują - czyli
> np. o tym, że obiekt istniał i został usunięty,
> albo istnieje ale jest zmodyfikowany, czyli
> powstała jego nowa wersja.

Witaj Jurku,
Pełna zgoda, te atrybuty muszą istnieć, aby zapewnić mechanizmy wersjonowania obiektów w zasobie. Podkreślam - w zasobie. Czy te same atrybuty należy wykorzystać w pliku "różnicowym" ? Moim zdaniem niekoniecznie. Próbowałem przez kilka dni sam siebie przekonać do Twojego podejścia, ale jest jedna rzecz która burzy całą koncepcję. Chodzi o redakcję mapy.
Obecnie nie wykorzystujecie obiektów KR_ObiektKarto i KR_Etykieta do przenoszenia chociażby napisów na mapie.
A chyba nie chcesz powiedzieć geodetom, że ustaliłeś z innymi producentami, że będą dostawać z ośrodka mapę bez redakcji - same obiekty bez etykiet, symbole bez obrotów, rowy i skarpy bez wypełnień itp?
Tak, wiem, C-GEO ma opcję automatycznego etykietowania, ale dobrze wiesz, że nie ma takiego algorytmu, który przy mapach wielkoskalowych w pełni zastąpi ręczną redakcję.
Jeśli zatem będziemy chcieli skorzystać z możliwości przenoszenia redakcji, to pojawi się pewien problem natury technicznej.
Wyobraź sobie prostą sytuację - geodeta dostaje mapę z Ośrodka w GMLU (z redakcją). Kartując np. nowy krawężnik przesuwa opis sąsiedniego kanału bo nachodzi. Następnie oddaje plik "różnicowy" do Ośrodka.
Stary obiekt "kanał" według Twojej koncepcji zostanie wyeksportowany z pierwotnymi atrybutami cyklu życia, ponieważ się nie zmienił. Gdzie będzie informacja o tym, że geodeta zmienił położenie opisu?
Załóżmy że zlinkujesz to z Kr_ObiektKarto, tak jak to było wydane w pliku z PODGik, a w KR_etykieta dasz nowe współrzędne opisu. Co będzie musiał zrobić program działający w PODGiKu, aby wychwycić tę zmianę? Ano nic innego, jak porównać geometrię etykiety w obiekcie istniejącym w zasobie (pliku wydanym) z nową geometrią istniejącej etykiety. I w tym momencie i tak wracamy do mojej koncepcji
Zwróć uwagę, że Kr_ObiektKarto nie zawiera atrybutów cyklu życia, więc nie da się tutaj postąpić analogicznie do tego, jak to zrobiliście z obiektami właściwymi.

> W przypadku danych geodezyjnych, to geodeta
> potwierdza stan aktualny: to że czegoś już nie ma,
> to że coś się zmieniło i to że coś nowego się
> pojawiło w terenie. Dlatego to on jest
> odpowiedzialny za przekazanie pełnej informacji do
> zasobu.
> Weryfikacja i ewentualne przyjęcie do zasobu, to
> już zadanie PODGiK.
> Problemem jest realizacja tych zamierzeń.
> Oczywiste jest to, że potrzebne są bazy danych.

Tutaj też pełna zgoda :-) Merytorycznie nie różnimy się w poglądach, kwestia sporna dotyczy tak naprawę sprawy czysto technicznej - dogadania się pomiędzy producentami jak skutecznie wymieniać się danymi, wobec braku ścisłych wytycznych w obowiązujących przepisach.

> Trudniej na pewno łączyć bazy danych z plikami
> aplikacji CAD, ale wydaje się mi, że nie ma przed
> tym ucieczki.
> Z moich informacji wynika, że ten model
> aktualizacji danych jest wprowadzany przez
> producentów ERGO, EWMAPY i TURBOEWID i zapewne też
> GEOINFO.

W sumie to się nie dziwię, bo będą mieli dużo mniej roboty z modułami przyjmującymi GMLa od geodetów
A z moich informacji wynika, że mój sposób zostanie przyjęty przynajmniej w Geomatyce.

> Aplikacje GIS, które są odpowiednio oprogramowane,
> poradzą sobie doskonale z tymi danymi.
> Co do wymagań wobec oprogramowania dla geodety, to
> uważam, że lepsze są wyższe, które sprawią że
> geodeta dostanie lepsze narzędzie.
> Ogólna wydajność pracy w aplikacji to zadanie
> równoległe do tego co jest wymagane prawnie.

Miałem na myśli wymagania systemowe. Konieczność zapisywania dodatkowych danych podczas każdej edycji obiektu z pewnością nie wpłynie pozytywnie na wydajność czy to C-GEO, czy GoKarta, a już na pewno skutecznie wydłuży generowanie pliku GML.
Prostsze rozwiązania z reguły są lepsze, a jeśli można coś zrobić prościej jednocześnie pozostając w zgodzie z przepisami, to po co niepotrzebnie wszystko komplikować?

> Z GML jest jak z książką, nie wszystkie są
> przeznaczone dla każdego - specjaliści czytają
> opracowania naukowe, a typowy czytelnik
> popularnonaukowe.
> Odbiorca GML (czyli specjalistyczna aplikacja)
> powinien być przygotowany na poprawny jego odczyt
> zgodnie z jego zasadami (schematami). Dla innych
> aplikacji wystarczy plik DXF,PDF, itp.
>
> Pozdrawiam.
> Jurek B.

Jeśli plik GML zawiera tylko aktualne obiekty, tak jak postuluję, możemy zawsze otworzyć go w każdym programie GIS. Fakt, że nie zobaczymy symboliki, tylko linie powierzchnie i punkty, ale zawsze może być to przydatne chociażby dla celów ogólnego skontrolowania pliku, przed wydaniem do ośrodka.
Na potwierdzenie, że może to być przydatne:
[www.facebook.com]
Według Twojej koncepcji taka kontrola nie będzie możliwa, bo zobaczymy wszystkie obiekty - stare, skasowane, zmienione i nowe. Oczywiście, będzie się dało jakoś to przefiltrować, żeby wyświetlić tylko aktualne obiekty, ale po co utrudniać życie geodetom?

A na koniec jedna dygresja - przyjdzie nowelizacja i okaże się, że nikt nie miał racji i wszystko trzeba przemyśleć od nowa

pozdrawiam
Tomek K.