TomKam Napisał(a):
...
> Doskonale zdaję sobie sprawę z tego, że plik GML
> zwracany przez geodetę do ośrodka powinien
> zawierać wszelkie niezbędne dane, aby w sposób
> zautomatyzowany przeprowadzić aktualizację zasobu.
> Problem w tym, że nie zostało sprecyzowane, co
> taki plik powinien zawierać. Producenci
> oprogramowania, w tym Softline, próbują sobie
> oczywiście jakoś radzić. W tej jak i w innych
> kwestiach na zasadzie dedukcji i bardzo
> subiektywnej interpretacji
> Nie jestem do końca przekonany, że różnicówka w
> wydaniu Softline to dobry pomysł (nie gniewaj się
> Jurek - rozmawialiśmy), dlatego że konieczne jest
> przechowanie historii obiektu. Dla programistów
> Softline nie ma z tym problemu, bo mogą sobie
> oprogramować wszystko jak chcą, problem jest
> natomiast w przypadku programów takich jak MapaSG
> i GoKart, gdzie przechowanie pełnej historii
> obiektu w pliku DWG/DGN bez użycia dodatkowych baz
> to spory problem. Można to zrobić dużo prościej.
> Wystarczy przyjąć następujące zasady:
> - obiekty niezmodyfikowane są zwracane w takiej
> samej formie
> - obiekty gdzie zmodyfikowano atrybuty i/lub
> geometrię są przekazywane w formie zmodyfikowanej
> z tym samym IdIIP,
> - obiekty usunięte nie są przekazywane.
> Oprogramowanie w ośrodku powinno porównać plik
> wydany i zwrócony i na tej podstawie wygenerować
> listę zmian do wprowadzenia w zasobie.
> Operator powinien zatwierdzić zmiany i dopiero w
> tym momencie powinna w zasobie pojawić się nowa
> wersja obiektu. Zarządzanie cyklem życia obiektu
> powinno się odbywać po stronie Ośrodka a nie
> Wykonawcy.
> Korzyści:
> - zmniejszamy wymagania co do oprogramowania
> używanego przez geodetę. co z pewnością przełoży
> się na ogólną wydajność pracy,
> - wynikowy plik GML stworzony przez geodetę
> zawiera tylko aktualne atrybuty i aktualną
> geometrię. W wariancie C-GEO otrzymujemy w pliku
> GML zbitkę oryginalnych, zmodyfikowanych i
> usuniętych obiektów - w programach GISowych taki
> GML jest bezużyteczny.
>
> Pozdrawiam

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

Pozdrawiam
Jurek B.



Zmieniany 1 raz/y. Ostatnio 2014-08-26 16:23 przez Jurek B..