Jurek B. Napisał(a):
-------------------------------------------------------
> rodi Napisał(a):
> --------------------------------------------------
> -----
> > Jurek B. Napisał(a):
> >
> --------------------------------------------------
>
> > -----
> > > rodi Napisał(a):
> > >
> >
> --------------------------------------------------
>
> >
> > > -----
> > > > jimny Napisał(a):
> > > >
> > >
> >
> --------------------------------------------------
>
> >
> > >
> > > > -----
> > > > > czym otworzyć pliki gml - materiał zasobu
> > bo
> > > > > próbuję róznymi programami i nic
> > > >
> > > > Ewmapa, C-geo (rozp. 2013 i 2015), Geokart
> > > (rozp.
> > > > 2015), Mikromapa, MapaSG v15 (rozp. 2015)
> > > MapaSG
> > > > 14 (rozp. 2013), jest już tego sporo.
> > Zrobiłem
> > > > kilka testów import eksport (C-geo - MapaSG
> -
> > > > GeoKart) i generalnie działa to poprawnie,
> > nie
> > > > licząc 2 obiektów, które program nie
> > rozpoznał
> > > ale
> > > > zakładam, że są to problemy, które zostaną
> > > > dopracowane. Cały czas ciekawi mnie jednak
> > jak
> > > > będzie wyglądała wymiana między wykonawcą i
> > > > ośrodkiem, tzn. plik różnicowy czy cała
> > robocza
> > > > baza danych. Nowe rozporządzenia o tym nie
> > > > wspominają, czytając rozp. w sprawie
> > standardów
> > > > wychodziłoby, że musimy oddać plik z całą
> > > roboczą
> > > > bazą danych (PZGiK+pomiar), więc to
> > > oprogramowanie
> > > > w ośrodku będzie musiało rozpoznać zmiany.
> > >
> > > Nowe rozporządzenia mają dobrze dopracowane
> > zapisy
> > > dotyczące zasad wymiany danych BDOT, GESUT,
> > > EGiB... w GML.
> > > W praktyce działa to w jednym z programów do
> > > prowadzenia PZGiK - tym z Krakowa. Producent
> z
> > > Katowic ogłasza, że niedługo będzie
> importować
> > > GML, a producent aplikacji z Poznania nie
> > > deklaruje wprowadzenia obsługi GML.
> > > Także nie wszystkie programy dla geodetów są
> > tak
> > > naprawdę gotowe do GML.
> > > Np. program z Warszawy nie zachowuje rygorów
> w
> > > zakresie IdIIP, wersji obiektu, odwzorowania.
> > To
> > > skutecznie uniemożliwi wymianę danych z
> PODGiK.
> > > Problemy są też w ośrodkach, bo nie wszystkie
> > mają
> > > zaktualizowane aplikacje i także same bazy
> > zgodne
> > > z aktualnymi przepisami.
> >
> >
> > Więc czy wiadomo jak to będzie wyglądało, tzn.
> czy
> > to wykonawca będzie musiał wykonać plik
> różnicowy,
> > czy oprogramowanie ośrodka będzie porównywało
> > zmiany?
> > Pozdrawiam
>
>
> Tak, to oprogramowanie w PODGiK wykrywa zmiany w
> obiektach porównując to co jest w zasobie z tym co
> przychodzi w GML po aktualizacji obiektów mapy
> zasadniczej od wykonawcy.
> W GML od wykonawcy, zapisywany jest stan
> archiwalny obiektów, które podlegały zmianom i
> oczywiście ich stan aktualny.

Oprogramowanie w PODGiK nie musi nic wykrywać, bo otrzymuje plik różnicowy, gdzie nowe, zmienione i usunięte obiekty są zapisane w GML z odpowiednimi atrybutami cyklu życia. I wcale nie jest to nigdzie umocowane w przepisach, po prostu GUGiK się wypowiedział że tak to ma wyglądać.
Było by prościej - tak jak postulowałem - żeby przekazywać w GML tylko aktualny stan, a oprogramowanie w ODGiK wykrywało by zmiany w geometrii/atrybutach i tworzyło w razie potrzeby nowe wersje obiektów i usuwało stare.
Odpowiadając na pytanie Rodiego: to Wykonawca musi wykonać plik różnicowy. Oprogramowanie w Ośrodku sprawdza tylko identyfikatory obiektów i na tej podstawie wprowadza zmiany w bazach.