Przyszłość C-GEO?

[Krzysiek_chriss]

Myśleliście może nad jakąś formą wsparcia dla przepisania kodu? Myślę nad czymś takim jak "zrzutka" np. 1000zł netto na rozwój C-geo. Wpłacający mieliby u Was jakieś profity z tego, np. darmowe aktualizacje przez jakiś czas.
Przepisujecie kod idąc w nakładki do CAD czy na własnej platformie jak dotychczas?

[Aoschin]

Podbijam żeby przypomnieć że czekamy jak ksiądz na kolędę

[dragko19]

My również czekamy, nawet serwer jest przygotowany do działania.

[MarekOtt]

i ja także czekam i trzymam kciuki

[kasprol]

Też kibicuję i trzymam kciuki

[B@rt]

Chciałbym spytać czy coś rusza się w kwestii nowej wersji programu?
Tak jak koledzy wcześniej wymienili, problem z płynnością i stabilnością zwłaszcza w opracowaniach terenów silnie zurbanizowanych nawet na mniejszych powierzchniach jest dosyć irytujący

[Jurek B.]

Chciałbym spytać czy coś rusza się w kwestii nowej wersji programu?
Tak jak koledzy wcześniej wymienili, problem z płynnością i stabilnością zwłaszcza w opracowaniach terenów silnie zurbanizowanych nawet na mniejszych powierzchniach jest dosyć irytujący

Co do nowej wersji programu, to przy braku czasu realizacja się ciągle opóźnia, ale co do problemów, których Pan pisał, może pomoże nasz serwis? Proszę o kontakt.

[grzes]

Chciałbym spytać czy coś rusza się w kwestii nowej wersji programu?
Tak jak koledzy wcześniej wymienili, problem z płynnością i stabilnością zwłaszcza w opracowaniach terenów silnie zurbanizowanych nawet na mniejszych powierzchniach jest dosyć irytujący

Chciałbym napisać coś pozytywnego, ale niestety nie ma dużego postępu. Szczerze mówiąc to optymizm z przełomu 2019/2020 rozbił się o nowy GML.
Wersja 2015 była już w miarę dobrze rozpoznana i wdrożona i na to wszedł nowy format. Dostosowanie do nowej wersji (z czym, biorąc pod uwagę wszystkie kombinacje stosowane w powiatach, borykamy się do dziś) kosztowało mnóstwo pracy.
Obsługa GML to dla nas być albo nie być. A zasoby ludzkie są ograniczone.
Na koniec żeby nie zostawić Pana z niczym, to jeśli ma Pan czas, to proszę podesłać swój projekt i opisać które momenty najbardziej przeszkadzają w pracy. Może na szybko uda się coś zoptymalizować. Ostatnio wprowadziliśmy generalizację, co przyśpieszyło odświeżanie mapy, w aktualnej wersji testowej jest usprawnione powiększanie kółkiem myszki. Na pewno da się jeszcze coś poprawić.

[maciekwu]

Pracuję na C-Geo jeszcze od wersji DOS więc około 30 lat. Zauważam od pewnego czasu istotne zwalnianie pracy programu. Szczególnie w ostatnim okresie. Przez te lata z podziwem obserwuję Państwa pozytywne i bardzo szybkie reakcje na wszelkie pomysły i prośby Użytkowników. Chwała Wam za to, uzyskaliśmy narzędzia przydatne, a w dużej mierze niezbędne do wykonywania różnych koniecznych zadań. Niestety ten fakt oraz ciągłe zmiany w przepisach (przykład rozporządzenie EGiB) oraz przeróżne koncepcje w zakresie modelu przetwarzania danych SWDE, kilka wersji GML, że nie wspomnę wcześniejszych spowodowały, że program już dawno odszedł od swojej pierwotnej struktury i obawiam się niestety, że sytuacja będzie się pogarszać. W moim przekonani jest rzeczą nieuniknioną przebudowanie programu od podstaw. Niestety i tu całkowicie się zgadzam GML wszystkich Nas wykończy. To czym dysponują Starostwa to jest tragedia. Różnorodność taka, że co Starostwo to inny pomysł. Też wydaje mi się, że do czasu ustabilizowania się sprawy GML (doświadczenie nie nastraja tu optymistycznie) raczej nie ma na to szans.

[Jurek B.]

To jednak nie C-GEO zwalnia, ale są dla niego dostarczane wielokrotnie większe pakiety danych. Jeszcze 10 lat temu mapy numeryczne to były mapy wektorowe, z niewielką ilością "kresek" i 2-3 tys. punktów. Teraz są to mapy obiektowe, które mają po 50-100 tys. tysięcy punktów i 10-20 tys. obiektów geometrycznych wraz z atrybutami w bazach danych. Takiego pakietu danych nie można byłoby nawet zaimportować w C-GEO sprzed 10 lat.

[dragko19]

Dochodzi jeszcze bardzo ważna sprawa, a dotycząca pracy w wersji sieciowej. Praca w CGEO przy 6 stanowiskach bardzo by usprawniło działanie, a obecnie to przecież jest standard.

[kasprol]

GML na pewno sporo zmienił jeżeli chodzi o ilość przetwarzanych danych, ale raczej musimy się do tego dostosować, nie ma szans na powrót do mapy "wektorowej". Niestety też zauważyłem, że przy większych mapach jest problem z płynnością działania C-geo, fajnie, że funkcjonalność programu cały czas się rozwija i dochodzą nowe opcje, ale możliwość wygodnej pracy na dużych opracowaniach też jest ważna, nie jestem informatykiem ale np. Ewmapa nie ma problemu przy imporcie i pracy na dużych obiektach pomimo używania formatu GML.

[B@rt]

Nie jestem pewien czy kontakt z serwisem w kwestii optymalizacji coś może zmienić, wykonywałem konfigurację silnika BDE zgodnie z instrukcją z wiki. W zdecydowanej większości dokonuję opracowań w gęstej zabudowie miejskiej, powierzchniowo przeważnie 1-2ha. Po prostu pliki źródłowe zawierają takie ilości obiektów, że program niedomaga.
CGEO jest kombajnem do obliczeń geodezyjnych, to nie pozostawia żadnych wątpliwości. Zdaję sobie również sprawę, że GML jest priorytetem dla was i dla nas, bo taki jest fakt. Ale konkurencja, która poszła drogą stworzenia nakładek geodezyjnych na programy cadowskie, lub tworzy bezpośrednio w środowisku cad ma przewagę w kwestii płynności działania właśnie uzależnioną od mocy obliczeniowej programu pierwotnego. Wraz ze wszystkimi innymi zaletami cada m.in znakomitym kreśleniem wektorowym.
Spróbujcie uruchomić jakiś program wsparcia, tak jak wcześniej koledzy pisali, na pewno znajdą się chętni do zainwestowania w rozwój a odciąży was to w chociaż minimalny sposób finansowo. Dla nas będzie nadzieja na to, że oczekiwana wersja kiedyś powstanie

[Jurek B.]

wykonywałem konfigurację silnika BDE zgodnie z instrukcją z wiki

Ustawienia BDE nie mają wpływu na szybkość działania programu, zależy ona od tego czy program antywirusowy nie traktuje C-GEO jako programu niezaufanego, skanując i spowalniając program. Dlatego ważne są ustawienia tu opisane:
https://softline.geo.pl/wiki/index.php? ... ciem_pracy
Warto skontaktować się z naszym serwisem, bo możemy doradzić coś co może pomóc w pracy w konkretnym przypadku.
Działając na mapie z GML 60MB, gdzie po imporcie jest ponad 75 tys. punktów, na notebooku z wyświetlaczem 6K, pamięcią 32GB, procesorem i7 11-generacji nie zauważam większych opóźnień niż około 1 sek. przy pracy na mapie:

[omegazull]

Wiadomo że ten temat to niekończąca się opowieść, ale tak zapytam od strony technicznej.

Ile to roboty wymaga by włączyć obsługę wielowątkowości?

Narazie to wykorzystuje tylko 1 wątek, a wiadomo, że procesor ma ich 4+ co najmniej.
Znacząco podskoczyła by wydajność we wszystkim i niebyło by potrzeby grubszego przerabiania wszystkiego.

[Jurek B.]

Wiadomo że ten temat to niekończąca się opowieść, ale tak zapytam od strony technicznej.

Ile to roboty wymaga by włączyć obsługę wielowątkowości?

Narazie to wykorzystuje tylko 1 wątek, a wiadomo, że procesor ma ich 4+ co najmniej.
Znacząco podskoczyła by wydajność we wszystkim i niebyło by potrzeby grubszego przerabiania wszystkiego.

Wielowątkowość nie ma większego wpływu na wydajność, bo niewiele jest czynności wykonywanych na mapie jednocześnie.
Przy okazji, w najbliższej aktualizacji powinno być zauważalne przyspieszenie działania programu.

[Aoschin]

Programista-amator here.
Widzę w tym wątku wielokrotne nawiązania do wprowadzenia wielowątkowości do C-GEO i chciałbym mniej obstukanym w temacie kolegom przybliżyć trochę temat.

Na czym polega wielowątkowość?
A no na tym, że procesor ma wiele niezależnych wątków roboczych w których może wykonywać niezależne czynności. Możecie o tym myśleć jak o kilku równoległych kanałach w których płynie woda. System sobie rozdziela statki (zadania) na poszczególne kanały zwiększając ogólną przepustowość.

Myk polega na tym, że jeżeli chcemy aby jedno zamówienie, (w tej analogii jeden program) płynęło na różnych statkach w różnych kanałach (pracował wielowątkowo) to musimy:
a) mieć możliwość podzielenia zamówienia (pracy) na wiele statków (wątków)
b) powinno to mieć sens pod względem logistycznym.
Jeżeli zamówienie to gigantycznie długi szklany wazon(w tej analogii będzie to procedura, która musi być wykonywana po kolei), to nie bardzo jest jak go podzielić na wiele części nie wkładając w to bardzo wiele wysiłku.
Jeżeli zamówienie to 4 gumowe kaczuszki (w tej analogii 4 występujące po sobie krótkie procedury) to zupełnie nieopłacalne jest 4-krotne opłacanie podróży dla każdej kaczuszki z osobna, jeśli można je posłać jedną paczką.

Wyobraźmy sobie taką sytuację. Chcemy przetransportować 4 gumowe kaczuszki z portu A do portu B (będą to nasze 4 obiekty do narysowania na mapie w C-GEO). My też będziemy płynąć tym statkiem, żeby móc obserwować co się dzieje (w tej analogii "my" do interfejs graficzny programu - to co pokazuje nam Windows).
Jeden wątek
Wysyłając kaczuszki jednym statkiem, tym, którym i my płyniemy, cały czas widzimy co dzieje się z kaczuszkami, mamy kontrolę nad tym co się dzieje - tak pracuje program jednowątkowy.
Wiele wątków
Wysyłając kaczuszki wieloma statkami zaczyna się niezła przygoda. Na wstępie musimy każdą kaczuszkę zapakować osobno. Następnie musimy każdą z nich nadać osobną przesyłką. Kaczuszki płyną osobnymi statkami z dala od nas - jeżeli którejś się coś stanie to bez intensywnych poszukiwań nigdy się nie dowiemy co się stało oprócz tego, że kaczuszka nie dopłynęła (kto debbug'ował wiele wątków ten wie o czym mówię). Czy to wszystko? A gdzie!
Wyobraźmy sobie, że kaczuszki to kolekcja i muszą stać obok siebie w określonej kolejności (w tej analogii, poszczególne procedury są od siebie zależne np. kolejność rysowania obiektów). Każdy statek przypływa w innym terminie. Musimy przez cały czas stać w porcie wypatrując naszych kaczuszek (które mogą nie dopłynąć, z miliona powodów), następnie poukładać je w kolejności i dopiero wtedy mamy nasze kaczuszki.
A sąsiad? A sąsiad miał je w zeszłym tygodniu. Jedną paczką. I jeszcze mógł cały czas śledzić w InPoście status dostawy, bo kurier (interfejs graficzny) płynął razem z kaczuszkami.

Podsumowując
Wiele wątków ma sens gdy mamy dużo roboty, którą można podzielić na części i wykonanie podprocedury zajmuje mniej czasu niż sama organizacja pracy wątków. Nie mówiąc już o stopniu skomplikowania programu który pracuje w wielu wątkach.
C GEO to program z jakoś 20 letnią bazą kodu. Program ma kilka tyś. funkcji podoklejanych w trakcie rozwoju programu, robi rzeczy do których jestem przekonany nie był projektowany i te funkcje trzeba było zaimplementować w ramach istniejących możliwości. To uważam jest największym "spowalniaczem".
TL;DR Dodanie wielowątkowości to 2x więcej pracy, 4x więcej czasu na szukaniu błędów i w tym konkretnym przypadku - rysowania mapy w C-GEO - żaden zysk na czasie.
PS
Moja opinia wynika stąd, że napisałem wielowątkowe rysowanie mapy dla swojej apki, a potem je wyrzuciłem - nie dość, że bawiłem się z tym zdecydowanie zbyt długo i nigdy nie udało mi się tego doprowadzić do bezbłędnego działania, to jeszcze wyniki testów przy mniejszej i średniej ilości obiektów wskazywały na GORSZE osiągi niż w pracy jednowątkowej.

PPS
Załoga Softline robi świetną robotę usprawniając tą dżunglę (jeśli dobrze pamiętam, to ktoś pisał o 3 m i l i o n a c h linijek kodu), modernizując i poprawiając naszą ulubioną apkę. Nowe rozporządzenia wywracające wszystko do góry nogami jak tylko się coś uspokoi nie pomagają rozwojowi technologii. Poczekajmy aż przestaną się pojawiać interpretacje przepisów i programiści nadążą doprasowywać program do nowych wytycznych.

[geoproj5]

Tak z ciekawisci...
A gdyby cgeo/cgml na czas importu gml odpalal dwie dodatkowe instancje, wczytywal bazy osobno do tymczasowych cgp a nastepnie je laczył?

[grzes]

(jeśli dobrze pamiętam, to ktoś pisał o 3 m i l i o n a c h linijek kodu),

Stan na dziś:

total.png (479 Bajtów) Przejrzano 120 razy

a to nie koniec bo sporo przenieśliśmy do zewnętrznych aplikacji i bibliotek (np cały moduł EGiB)