Aktualności:

tyle zostało zrobione
75%

Menu główne

Brak obiektów przy imporcie GMLa

Zaczęty przez Wyszyn03, Sobota 02 Grudzień 2023, 13:43:17

Poprzedni wątek - Następny wątek

0 użytkowników i 1 Gość przegląda ten wątek.

Lupus

Źle mnie zrozumiałeś.
Jeśli mówimy o ponownym pomiarze, to ja jestem zdecydowanie przeciwny robieniu tego rękami wykonawców.
Jeśli mówimy o poprawianiu baz przez podgik w zakresie elementów niezgodnych z dzisiejszym standardem to nie liczę też na to, że to zrobią, tak jak napisałeś skala takiej akcji jest całkowicie absurdalna.
Uważam, że sens miałoby wydawanie wcześniejszych pomiarów wniesionych na mapę jako elementy wprawdzie niezgodny ze standardem GML, ale możliwym do zmiany na prawidłowy przez aktualizującego mapę, w ramach czynności całkowicie kameralnych. Koszt po stronie wykonawcy wbrew pozorom nie jest taki wysoki, a skuteczność przekształcania bazy dosyć wysoka.
__________
Pozdrawiam
Lupus

Wszystko da się zrobić, tylko czy jest to uzasadnione ekonomicznie?

Cezary.K

Cytat: Lupus w Wtorek 05 Grudzień 2023, 21:18:27ale dało by się znaleźć pomiar oryginalny i tylko wnieść to na właściwe warstwy i obiekty?

Pewnie dla wielu by się dało, ale to jest praca do wykonania. W skali powiatu ogrom pracy. Liczenie na to, że geodeci uzupełnią całą bazę podczas prac geodezyjnych, jest w mojej ocenie naiwne.
Z drugiej strony, co ja tam mogę wiedzieć o pracy ośrodka ;)

staw

Cytat: Cezary.K w Wtorek 05 Grudzień 2023, 20:04:23To też jest jakieś rozwiązanie. Trochę słabo, że cały ciężar zrzucono na geodetę.

No właśnie. Tak jak pisałem wcześniej.

Lupus

ale dało by się znaleźć pomiar oryginalny i tylko wnieść to na właściwe warstwy i obiekty?
__________
Pozdrawiam
Lupus

Wszystko da się zrobić, tylko czy jest to uzasadnione ekonomicznie?

Cezary.K

To też jest jakieś rozwiązanie. Trochę słabo, że cały ciężar zrzucono na geodetę.

Wyszyn03Autor w?tku

Temat rozwiązany w ten sposób, że wszystkie obiekty, które oni mają na Geoportalu, a ja nie mam w gmlu muszę pomierzyć od nowa.

Cezary.K

Cytat: Lupus w Wtorek 05 Grudzień 2023, 10:55:23A po za tym, że się wydadzą w GML, to jaki jest plus zastosowania tego skryptu?

Nie, nie ma innych plusów. Ośrodek zobligowany jest rozporządzeniem do wydawania danych w formacie GML i musi takie działania podjąć, żeby eksport był wykonalny. Rzetelna naprawa problemu to w skali powiatu miesiące. Skrypt to takie pudrowanie syfilisu ;)

Wyszyn03Autor w?tku

Dzisiaj będę w Ośrodku, to im to zgłoszę i zobaczymy co powiedzą.

Lupus

A po za tym, że się wydadzą w GML, to jaki jest plus zastosowania tego skryptu?
__________
Pozdrawiam
Lupus

Wszystko da się zrobić, tylko czy jest to uzasadnione ekonomicznie?

Cezary.K

#10
Tak, tak to działa. Różnica między istniejącymi obiektami a przeniesionymi jest taka, że te dodane skryptem nie mają informacji dodatkowej przy obiekcie.

Można tą operację robić w ewmapie, ale problem może wyniknąć z zachowaniem operatu a tym bardziej daty powstania elementu. Czy te elementy są na tyle ważne, żeby o te dane dbać, musi zadecydować organ prowadzący tą bazę.

staw

Dobrze rozumiem?
Pierwszy UPDATE zamienia kod EGBI17 "Inny obiekt trwale związany z budynkiem" na EGBI06 "Inny blok budynku"?
A drugi "przerzuca" elementy na odpowiednią warstwę?

Cezary.K

#8
Ja nie mówię o burzy, bo to ostatnia rzecz, którą należałoby zrobić. Domierzenie może powodować dublowanie elementów, i to też nie jest dobre rozwiązanie. Mówiąc o kontakcie z ośrodkiem dokumentacji chodziło mi o zgłoszenie, że jest problem. Przy ogromie pracy związanej z wdrażaniem funkcjonalności czy przystosowaniem baz coś może umknąć, i tu najwyraźniej taka sytuacja się zadziała. Jak nikt nie zgłosi, PODGiK będzie na nieświadomce wydawał niekompletne dane ;)

Jak masz z nimi dobry kontakt, podeślij rozwiązanie - skrypt (operaty i dane autoryzacyjne przy obiektach i na warstwach zostają nieruszone)
Nie jest to naprawa z prawdziwego zdarzenia, bo przy takiej każdy element trzeba przeanalizować i zamienić na właściwy obiekt. Jest to proteza umożliwiająca wymianę danych plikami GML

update EW_obiekty
set
    KOD = 'EGBI06'
where
    KOD = 'EGBI17' and STATUS = 0 and IDKATALOG = (select ID from EW_KATALOGI where NAZWA = 'BUDYNKI');

update EW_POLYLINE
set
    TYP_LINII=1, 
    ID_WARSTWY = (select ID from EW_WARSTWA_LINIOWA where NAZWA = 'EGBI06' and ID_KATALOGU = (select ID from EW_KATALOGI where NAZWA = 'BUDYNKI') )
where
    ID_WARSTWY = (select ID from EW_WARSTWA_LINIOWA where NAZWA = 'EGBI17' and ID_KATALOGU = (select ID from EW_KATALOGI where NAZWA = 'BUDYNKI') )
    and STAN_ZMIANY = 0

staw

#7
Może rozpętam burzę, ale nie to jest moim zamiarem.
Mapę i tak aktualizuje się w terenie, więc podczas wywiadu terenowego wykonawca jak zauważy, że na wydruku mapy z GMLa nie ma "innego elementu trwale związanego z budynkiem", to go domierzy lub upewni się w PODGiK co jest grane.

PS. Wiem, że (jak to się zdarza na innych forach, grupach, gdzieś tam) może rozpocząć się szum, że "jak to tak, ośrodki wydają złe dane, a wykonawcy mają poprawiać... bla bla bla". Nie to mam na celu tym wpisem. Z każdej sytuacji (o ile dwie strony wykonawca i podgik wyrażą odrobinę dobrej woli) jest pokojowe wyjście.

Cezary.K

Nie o tolerancję chodzi, tylko o to, że nie masz kompletu danych, czyli nie zrobisz kompletnej mapy dla zleceniodawcy. W tym przypadku PODGiK udostępnia multieksporty, więc poza GML dopuszcza też wymianę danych plikami ewmapowymi. Nie zmienia to faktu, że PODGiK musi dostosować swoje bazy do zaistniałych realiów. Nie ma na to innej rady.

staw

W miarę myślący PODGiK, w którym zdają sobie sprawę z problemu powinien tolerancyjnie podejść do sprawy.