Ewmapa - Forum użytkowników

Cytat: CezaryK w Piątek 05 Lipiec 2019, 07:41:44
Popatrz na bazy globalnie, nie z punktu widzenia wykonawcy. W bazie np. PODGiK'u masz setki tysięcy obiektów. Nadmierne zwiększanie ich ilości wpływa na czas importów, eksportów, analiz, wyszukiwania ...

To geodeci w największym stopniu tworzą i korzystają z tych baz.

Jedna wspólna jezdnia wraz z wjazdami na działki prywatne, z rondami (enklawy) w obrębie miasta wojewódzkiego? Obiekt pewnie z 30mb. No i jaki aktualny - data pomiaru 2019.  Do wyeksportowania do każdej roboty która w obszarze opracowania ma ten obiekt.

Globalna agregacja obiektów o jednym wspólnym atrybucie to przy zachowanej topologii to parę minut dla całej bazy.

Myślę, że właśnie patrzę globalnie i dochodzę do wniosku, że łączenie obiektów z różnych pomiarów w jeden mija się z celem.

Rozumiem jaka idea stała za pomysłem segmentowania obiektów wg rozporządzenia. To jest pomysł, który zakłada, że obiekty, które mają takie same parametry i się ze sobą stykają powinny być jednym obiektem. Niby to logiczne, ale powoduje to paradoksy jak np. asfaltowa droga z roku 1984 i asfalt z 2019 r powinny być jednym obiektem, stary przewód sieci elektrycznej "zwykły trójżyłowy" oraz przewód w izolacji doziemnej to wg gesutu taki sam przewód. Co więcej panuje zasada jeden obiekt to jeden operat i jedna data ostatniego pomiaru.

Ja to widzę inaczej. Obiektem jest element z jednej budowy, z jednej technologii, ... i w końcu z jednej inwentaryzacji. Informacja o tym kto to mierzył, kiedy mierzył, jaką technologią i na jakim odcinku obiektu jest bardzo istotna właśnie do wykonywania analiz i wyszukiwania. Sytuacje kiedy mamy dokładnie tą samą technologię można statystycznie pominąć, ponieważ mamy to tylko kiedy robota jest wykonywana jakimiś etapami i są kolejne domierzane elementy.
Łączenie obiektów w długie ciągi powoduje tylko problemy w imporcie i eksporcie. Począwszy od blokowania zbyt dużych obszarów do zmian, a skończywszy na dłuższym czasie wykonywania importu, bo im dłuższe obiekty tym ewmapa dłużej analizuje ten import.
Dla testu należałoby założyć bazę 10000 obiektów "małych", oraz bazę z tą samą ilością elementów na warstwach ale połączonych w 2000 obiektów.
Wtedy można by było to sprawdzić empirycznie, ale o ile ja znam algorytmy to import-eksport powinien być dosyć prostą procedurą, ale jej koszt zwiększa się w przypadku znacznego skomplikowania analizowanych obiektów.

I jeszcze jedno co mi przyszło do głowy w trakcie pisania tego tekstu.
Na te bazy nie można patrzeć z innej perspektywy niż z perspektywy użytkownika. Na pewno użytkownikiem są wykonawcy prac, bo muszą zasilić, porównać stare-nowe dane, dostosować je do potrzeb zamawiającego, itp.
Użytkownikiem powinni być projektanci, choć zwykle nie są, bo mapy na których pracują zwykle są przetworzone przez geodetów i pozbawione są tych dylematów łączenia lub segmentowania obiektów.
Dalej branże. Teoretycznie też powinny być użytkowniek tych baz, ale są bardzo rzadko, ponieważ prowadzą swoje systemy, rozbieżne pod względem budowy z tym co mamy w PODGiKach.
No i wreszcie PODGIKI. Eksport import jak najbardziej. ALE CO JESZCZE? Wbrew pozorom nie wykonują na tych bazach prawie żadnych analiz. Sprawdzanie poprawności oddanej przez wykonawcę RBD nie jest analizą w rozumieniu istotności i kosztu tego procesu. Ktoś mi powie, że muszą robić sprawozdania. Ale hola, sprawozdania są raz w roku i czy eksport będzie trwał 3 czy 8 minut nie ma żadnego znaczenia praktycznego. Analiza potrzeb aktualizowania bazy, e tam dla każdego obrębu można to spokojnie zrobić raz na 5 lat. I co jeszcze?
[uzupełnienie]
No i oczywiście "obywatele", ale tych możemy olać, ponieważ ich interesuje na razie tylko papierowa wersja mapy, a nie jakieś tam cudactwa.
[/uzupełnienie]

Chcesz mi powiedzieć, że poprawiamy i dostosowujemy konstrukcję bazy do potrzeb instytucji, która tylko przechowuje te dane?
To tak jakby wymuszać na wydawnictwach, żeby wszystkie książki o tematyce historycznej miały zielone okładki, a te które są horrorami miały czarną z czerwonym paskiem na boku. Robiąc to tylko po to żeby bibliotekarce łatwiej było układać książki na półkach.

Cytat: CezaryK w Piątek 05 Lipiec 2019, 07:41:44
Na chwilę obecną wartość do wyświetlania etykiety brana jest z jednego obiektu, zapewne pierwszego z listy.

Czyli większą krzywdę robimy tej mapie, bo nie dość, że tylko z jednego obiektu są to informacje to jeszcze nie wiadomo z którego, bo zależy to od tego w jakiej kolejności były zakładane. I to niezależnie od tego czy będzie to obiekt pierwszy założony czy ostatnio aktualizowany.

Cytat: Lupus w Czwartek 04 Lipiec 2019, 15:53:00
Nie mówię tutaj o linii która należy do 2 obiektów, bo takie sytuacje są normalne, linia na połączeniu dwóch obiektów tego samego typu. Bardziej chodzi mi o etykiety.
Szczerze mówiąc nie sprawdzałem tego, ale skąd są brane informacje do wypełnienia treści etykiety
Jeżeli jedną etykietę podłączę do dwóch obiektów, jeden będzie wiązką 3eNN, a drugi eNN to jaki napis pojawi się zamiast etykiety?

Na chwilę obecną wartość do wyświetlania etykiety brana jest z jednego obiektu, zapewne pierwszego z listy.

Cytat: Lupus w Czwartek 04 Lipiec 2019, 15:53:00
Gdzie widzisz problem przy segmentacji wg daty pomiaru i dlaczego nie jest dobre rozwiązanie?

Popatrz na bazy globalnie, nie z punktu widzenia wykonawcy. W bazie np. PODGiK'u masz setki tysięcy obiektów. Nadmierne zwiększanie ich ilości wpływa na czas importów, eksportów, analiz, wyszukiwania ...

Cytat: CezaryK w Czwartek 04 Lipiec 2019, 11:35:11
Nie masz racji. To, co ma się skasować, kasuje się bez problemu. Jeżeli element wchodzi w skład innego obiektu, nie zostanie skasowany.

Nie mówię tutaj o linii która należy do 2 obiektów, bo takie sytuacje są normalne, linia na połączeniu dwóch obiektów tego samego typu. Bardziej chodzi mi o etykiety.
Szczerze mówiąc nie sprawdzałem tego, ale skąd są brane informacje do wypełnienia treści etykiety
Jeżeli jedną etykietę podłączę do dwóch obiektów, jeden będzie wiązką 3eNN, a drugi eNN to jaki napis pojawi się zamiast etykiety?

Cytat: CezaryK w Czwartek 04 Lipiec 2019, 11:35:11
A jakie jest inne rozwiązanie? Fragmentacja obiektu ze względu na datę pomiaru? To też nie jest dobrym rozwiązaniem.

Gdzie widzisz problem przy segmentacji wg daty pomiaru i dlaczego nie jest dobre rozwiązanie?

Cytat: wfor w Czwartek 04 Lipiec 2019, 09:44:53
I to jest największa herezja tego rozporządzenia. Ocena przydatności w dużym stopniu powinna wynikać z daty pomiaru. A tak zmodyfikowany jeden wierzchołek obiektu i data aktualna - czasami przeskok o 30 lat. I później wychodzi że wszystkie jezdnie z miasta o jednakowej nawierzchni i pomiarze na osnowe to jeden ogromny obiekt który jest "aktualny" przynajmniej o tym świadczy data pomiaru

A jakie jest inne rozwiązanie? Fragmentacja obiektu ze względu na datę pomiaru? To też nie jest dobrym rozwiązaniem.

Cytat: Lupus w Czwartek 04 Lipiec 2019, 09:48:29
To nie jest takie proste.
Podłączenie jednej etykiety do wielu obiektów uniemożliwia np. kasowanie obiektu w całości. Bo skasujesz etykietę należącą do innego obiektu, a tak oczywiście nie może się stać.

Nie masz racji. To, co ma się skasować, kasuje się bez problemu. Jeżeli element wchodzi w skład innego obiektu, nie zostanie skasowany.

To nie jest takie proste.
Podłączenie jednej etykiety do wielu obiektów uniemożliwia np. kasowanie obiektu w całości. Bo skasujesz etykietę należącą do innego obiektu, a tak oczywiście nie może się stać.

Zgodnie z rozporządzeniem każdy kabel powinien być oddzielnym obiektem. Skoro kabel robi pętle -można było by to narysować zgodnie z przebiegiem w terenie - z tym że to będzie błąd w topologi. Takiego zapętlonego kabla nie narysujemy też w rurze ochronnej. Krótko mówiąc niektórych sytuacji nie da się w rzeczywisty sposób wykazać na mapie.

Cytat: CezaryK w Czwartek 04 Lipiec 2019, 07:38:51
Datę pomiaru obiekt przyjmuje z daty pomiaru ostatniego modyfikowanego/dołączanego elementu. Przynajmniej tak w teorii powinno to wyglądać.

I to jest największa herezja tego rozporządzenia. Ocena przydatności w dużym stopniu powinna wynikać z daty pomiaru. A tak zmodyfikowany jeden wierzchołek obiektu i data aktualna - czasami przeskok o 30 lat. I później wychodzi że wszystkie jezdnie z miasta o jednakowej nawierzchni i pomiarze na osnowe to jeden ogromny obiekt który jest "aktualny" przynajmniej o tym świadczy data pomiaru

Datę pomiaru obiekt przyjmuje z daty pomiaru ostatniego modyfikowanego/dołączanego elementu. Przynajmniej tak w teorii powinno to wyglądać. Co do mufy, wykazuje się je tylko na światłowodach.
Co do obiektowania, jestem zwolennikiem prowadzenia obiektu od początku do końca jako jeden obiekt. W niektórych miejscach będzie się on pokrywał z innym obiektem, wtedy jeden wektor lub etykieta wchodzi w skład dwóch lub więcej obiektów.
Na dzień dzisiejszy w ewmapie obiektuje się tak, żeby albo prawidłowo wyświetlała się liczba przewodów na danym odcinku, i wtedy następuje fragmentacja obiektu w miejscach, gdzie faktycznie się on nie dzieli, albo obiektuje się w sposób zgodny z jego rzeczywistym przebiegiem, ale wówczas nie wyświetla się prawidłowo liczba przewodów na poszczególnych odcinkach. Zgłaszałem do Geobidu pomysł, żeby przed wizualizacją wartości etykiety program sprawdzał, w skład ilu obiektów wchodzi etykieta (bo etykietę można podpiąc do dowolnej liczby obiektów) i sumował ilość przewodów ze wszystkich obiektów i tą wartość wyświetlał. Pomysł do tej pory nie został zrealizowany, ale jestem dobrej myśli.

no też tak mi się wydaje, chociaż czasem jak jest główna nitka i odbicie 0,5 m do ZK i z powrotem- to aż mnie kusi żeby zrobić 2 obiekty zamiast 3 ( w tym jeden 0,5m). A jak robicie w sytuacji, gdy na starym przewodzie (z pomiaru) wykonawca przecina kabel- tą końcówkę starego kabla wprowadza do nowej szafki+ w miejscu przecięcia wstawia mufę i łączy ją kablem również z nową szafką. Ja robię podział obiektu liniowego w miejscu mufy i jeden z tych "starych" odcinków wprowadzam do szafki (bez zmiany daty pomiaru w atrybutach), a potem rysuję nowy fragment od mufy do szafki już z nową datą i nowym obiektem, ale to mija się z wcześniejszą zasadą rysowania wiązki 2eN osobnym obiektem. Takie moje dywagacje, pewnie nikt się tym nie przejmuje... w istniejącej bazie też jest porobione różnie, pewnie w zależności kto robił.

Nie wgryzałem się w rozporządzenie gesut ale na logike to chyba po to jest wiązka aby kreślić kilka kabli jedną linią. Ja przynajmniej tak robię

hej,
mam dylemat jak powinno się kreślić sieci, gdy np. jest główny 1 przewód i co kawałek odchodzi kabel do złącza i wraca do rozgałęzienia- czyli na tym odcinku są 2 przewody. Czy kreślić ten fragment jako 1 obiekt wiązką 2eN, czy nałożyć na siebie na tym odcinku 2 pojedyncze obiekty- tylko co wtedy np. z rurami osłonowymi lu rzędnymi- przypisać je losowo do jednego z obiektów? Czy przepisy coś mówią na ten temat? Często jest też tak, że idzie wiele przewodów razem i potem po drodze się rozchodzą po kilka sztuk.