Szybka aktualizacja kodowania punktów

[KunziteSan]

Witam.
Szukałem, ale nie znalazłem - czy istnieje możliwość, żeby program zaktualizował kody zgodnie z symboliką warstw bdot500? Mam taką sytuację, że mam paręset pikiet bez kodów - rysując mapę program koduje pikiety ale zauważyłem, że tylko za pierwszym razem. Często zdarza się, że rysując pociągnie się coś źle, ale kasując obiekt kod pikiety pozostaje. Nie ma też hierarchiczności - jak najpierw pociągnę chodnik do narożnika budynku a potem obrys budynku to kod pozostaje chodnika. Czy zatem jest może jakieś narzędzie, które by aktualizowało kodowanie względem aktualnego stanu na mapie?
Kunzite

[FaFaL]

Prosty przykład czemu kodowanie punktów kodami obiektów liniowych jest bez sensu:
- mam punkty graniczne które koduję odpowiednimi kodami właściwymi dla punktów
- wybieram rysowanie granic...
- według Pana propozycji kody punktów z "punktu granicznego" mają się zmienić na "działka ewidencyjna" ?
Coś w tym sposobie myślenia jest nie tak.

[FaFaL]

Co do hierarchiczności, to gdzie jest zdefiniowane co jest ważniejsze od czego (Umm, faktycznie coś gdzieś chyba o tym było, chyba, będę wdzięczny za przypomnienie)? W systemach obiektowych to działa inaczej, weźmy jako przykład latarnie:
- mierzę jedną pikietę jako środek latarni
- to teraz jaki kod jest ważniejszy ? Latarni czy słupa (podpory) ?
- tak naprawdę w systemach obiektowych tworzone są dwa obiekty oparte o ten sam punkt, jeden to podpora, drugi to latarnia.

[KunziteSan]

Akurat z linią graniczą to sprawa jest banalna bo rysując linię między dwoma punktami program powinien punktom nadawać cechy jako punkty a nie jako linie, co obecnie robi bez sensu.
Hierarchiczność - choćby taka jak wyświetlanie mapę. Są jeszcze klasy dokładności punktów. Skoro program wie, że symbolem granicznika przykrywa symbol góry skarpy, to nie widzę problemu, ten punkt był kodowany jako granicznik a nie jako góra skarpy. Jakąś ważność też wskazuje kolejność wymienionych baz w rozporządzeniu.
Słup czy latarnia? Ja tam mierze to co na ziemi czyli podporę, a to czy ona "świeci" czy nie to jest sprawa drugorzędowa. Jest kilka takich elementów mapy które się raczej się nie mierzy w stylu latarni czy bramy

Nie ja wymyśliłem kodowanie więc to proszę nie do mnie mieć żale. A szczerze to dziękuje za dołożenie kolejnych kodów w stylu: punkt narożny budynku, czy punkt załamania ogrodzenia.

Rozumiem z tonu wypowiedzi, że c-geo jednak nie posiada narzędzi, która by wyrzucić kody (choćby jako eksport jeśli nie do tabeli) z aktualnej mapy, czemu z przykrością się dziwię, bo potrafi to zwykły edytor graficzny z przeszło już 10-letnią nakładką bazując tylko na odległości punktu o odpowiedniej cellki - a to że dla jednego punktu mam np dwa rekordy to i tak mniej roboty z ręcznym usuwaniem niż ręcznie przekodowywać i sprawdzać całego syt-wysa, zwłaszcza przy obecnie obowiązujących kodach.

[FaFaL]

Rozumiem z tonu wypowiedzi, że c-geo jednak nie posiada narzędzi, która by wyrzucić kody (choćby jako eksport jeśli nie do tabeli) z aktualnej mapy, czemu z przykrością się dziwię, bo potrafi to zwykły edytor graficzny z przeszło już 10-letnią nakładką bazując tylko na odległości punktu o odpowiedniej cellki - a to że dla jednego punktu mam np dwa rekordy to i tak mniej roboty z ręcznym usuwaniem niż ręcznie przekodowywać i sprawdzać całego syt-wysa, zwłaszcza przy obecnie obowiązujących kodach.

Co do tonu, to napisałem co myślę o takim kodowaniu, ponieważ żaden przepis nie nakazuje takiego kodowania. To moje prywatne zdanie. Co do reszty, to proszę mi wskazać gdzie powyżej dyskutowaliśmy akurat o takiej funkcjonalności?

[KunziteSan]

Oczywiście, że kodowanie nigdzie nie jest wymagane i w założeniu nie potrzebne przy pełnej wymianie danych cyfrowych, tylko że póki co takie wymiany nie ma i nadal ośrodki mniej lub bardziej ręcznie kartują a wówczas takie kody mają sens by nie tłumaczyć się z każdej pikiety. Ale jeśli czemuś ma służyć w tabeli pozycja KOD to chciałbym, żeby albo działała dobrze albo wcale, a chwilowo powstają śmieci z procesu edycji mapy.
To co wspomniałem o eksporcie to tylko przykład, bo może być problematyczne operowanie czymś takim na tabeli, stąd też pomysł z eksportem zewnętrznym. C Geo poznaje od roku, ale przecież program istnieje już lata, stąd może moje zdziwienie że brak takiego kodera, fundamentalnego od czasów numerycznej K1

[FaFaL]

Ja myślę, że to o czym Pan pisze wynika z przyzwyczajeń pracy w innych narzędziach, a filozofia pracy w C-GEO jest czasem inna (albo Pan jej nie poznał, albo nie przywykł, albo po prostu Panu ona nie odpowiada). No nic, w sprawach możliwości programu C-GEO to już muszą wypowiadać się autorzy. W sprawach po co jest kolumna kod to już nie będę się wypowiadał, tak samo co da osobie kartującej wiedza, że dana pikieta to krawężnik, skoro i tak nie wie z czym ją połączyć. Co innego kod typu kratka ściekowa - ale z tym to w C-GEO nie ma problemu.

[KunziteSan]

Ok. filozofia programu polega na tym, że muszę bezbłędnie skartować pomiar, bo jeśli się pomylę to muszę błędne kody usuwać ręcznie z tabeli. Na pewno praktyka czyni mistrza, choć nie wiem, czy udało mi się wykonać taki pomiar, żeby na 1000 pikiet się gdzieś na szkicu nie pomylić w numeracji - a wówczas biada, jeśli kartujący to nie ja.

tak samo co da osobie kartującej wiedza, że dana pikieta to krawężnik, skoro i tak nie wie z czym ją połączyć

Nie wiem czy Pan wie, ale do kartowania służy poza wykazem współrzędnych także szkic gdzie bardzo dobrze widać z czym połączyć krawężnik. Natomiast chwała temu, kto potrafił na szkicu (takim z terenu) tak narysować linię przerywaną, że kartująca osoba miała pewność że to użytek/chodnik/jezdnia itd. Dlatego kody się przydawały.

[grzes]

W zastepstwie (pewnie jak Jurek wroci z urlopu to napisze cos wiecej):
Z tego co zrozumialem to nadaje Pan kody punktom rysujac obiekty na mapie korzystajac z niedawno wprowadzonej takiej mozliwosci. Ta opcja została dodana na zyczenie uzytkownika, ale nie jest wspierana przez zadne inne machanizmy w programie - stad tez takiej funkcjonalności o jakiej Pan pisze w pierwszym poście nie ma. Kod nadawany jest obiektowi niezaleznie od tego o jakie punkty jest zaczepiony. Rozumiem problem przy przekazywaniu danych w postaci wykazu punktow i szkicow/wydrukow z mapy. Kody faktycznie byłyby wtedy pomocne, ale na szybko nic tu nie damy rady zmienic.

[MarekOtt]

Ja natomiast z kodowaniem mam inny problem. Nie wiem za bardzo kiedy się pojawił, ale jest już od jakiegoś czasu.

Mam pikietę na kodzie np. UPK, kod ten jest przypisany do warstwa kanalizacja. Wchodzę w edycje punktu na mapie, kasuję oznaczenie kodu, czyli pozostawiam puste okno. Punkt ten jest bez kodu i chyba powinien przeskoczyć na warstwę zerową (tak przynajmniej kiedyś było), on jednak dalej pozostaje na warstwie kanalizacja.

[FaFaL]

a jest włączone przypisanie kodów do warstw ? Bo jeśli tak to faktycznie coś nie tak, jeśli nie to zachowanie jest ok... bo wtedy punkty mogą być na dowolnych warstwach niezależnie od kodów.

[MarekOtt]

a jest włączone przypisanie kodów do warstw ? Bo jeśli tak to faktycznie coś nie tak, jeśli nie to zachowanie jest ok... bo wtedy punkty mogą być na dowolnych warstwach niezależnie od kodów.

Faktycznie, przypisanie kodów do warstw jest wyłączone. Wiec sprawa wyjaśniona, jednak analogicznie w/g takiego działania, w przypadku gdy pikieta jest z kodem UPK na warwie kanalizacja i zmieniam ją na ZAS (który to kod jest na warstwie woda), to punkt powinien zostać na warstwie kanalizacja z kodem ZAS. A tak nie jest, bo automatycznie przeskakuje na warstwę woda.

Chodzi mi o to, że chyba to powinno działać tak że gdy kod na który zmieniamy jest w domyśle na innej warstwie, to powinien go zmienić na ta warstwę. I chyba tak powinno to też działać przy kasowaniu kodu danej pikiety, z automatu powinien on przeskoczyć na pikietę na warstwie zerowej, bo w domyśle pikiety bez kodu są na warstwie zerowej.

Oczywiście być może coś kiedyś zostało ustalone i przedyskutowane że tak jak jest będzie lepiej, zrozumiem. Jednak nie wiem czy takie wyjątki dla danej operacji są potrzebne, raz działa tak, a dla pozostałych przypadków działa inaczej . Ciężko jest to ogarnąć, dlatego myślałem że to błąd .

[Jurek B.]

czy istnieje możliwość, żeby program zaktualizował kody zgodnie z symboliką warstw bdot500? Mam taką sytuację, że mam paręset pikiet bez kodów - rysując mapę program koduje pikiety ale zauważyłem, że tylko za pierwszym razem. Często zdarza się, że rysując pociągnie się coś źle, ale kasując obiekt kod pikiety pozostaje. Nie ma też hierarchiczności - jak najpierw pociągnę chodnik do narożnika budynku a potem obrys budynku to kod pozostaje chodnika.

Pisze Pan o kodowaniu pikiet zgodnie z rozporządzeniem, proszę więc podać jaki kod z rozporządzenia powinien być nadany dla punktu załamania chodnika, a jaki dla punktu załamania ściany budynku?

Akurat z linią graniczą to sprawa jest banalna bo rysując linię między dwoma punktami program powinien punktom nadawać cechy jako punkty a nie jako linie, co obecnie robi bez sensu.

Chyba przykład z linią graniczną nie jest najszczęśliwszy. Jakie dokładnie miałyby być nadane cechy dla punktów załamania linii granicy działki? Punktu granicznego: niestabilizowanego, stabilizowanego, granicy państwa?

Skoro program wie, że symbolem granicznika przykrywa symbol góry skarpy, to nie widzę problemu, ten punkt był kodowany jako granicznik a nie jako góra skarpy.

Niestety rozporządzenie nie zawiera w swoim katalogu obiektów - obiektu punktowego - punkt załamania skarpy i odpowiedniego dla niego kodu.

c-geo jednak nie posiada narzędzi, która by wyrzucić kody (choćby jako eksport jeśli nie do tabeli) z aktualnej mapy, czemu z przykrością się dziwię, bo potrafi to zwykły edytor graficzny z przeszło już 10-letnią nakładką bazując tylko na odległości punktu o odpowiedniej cellki - a to że dla jednego punktu mam np dwa rekordy to i tak mniej roboty z ręcznym usuwaniem niż ręcznie przekodowywać i sprawdzać całego syt-wysa, zwłaszcza przy obecnie obowiązujących kodach.

Niestety to zdanie jest niezrozumiałe - czy chce Pan usunąć kody jakiejś grupy punktów?, czy wyeksportować punkty z kodami?

A szczerze to dziękuje za dołożenie kolejnych kodów w stylu: punkt narożny budynku, czy punkt załamania ogrodzenia.

Hmm, gdzie są takie kody? W C-GEO w zestawie kodów MapaZasadnicza, takich kodów punktów nie ma.

[KunziteSan]

Pisze Pan o kodowaniu pikiet zgodnie z rozporządzeniem, proszę więc podać jaki kod z rozporządzenia powinien być nadany dla punktu załamania chodnika, a jaki dla punktu załamania ściany budynku?

Z jednej strony ma Pan racje na brak logiki na punktowanie kodem punktów obiektów liniowych ale przecież to samo było od czasów K1 1995 - jakoś przez 20 lat nikomu nie przeszkadzało by kodować jako BUD narożnik budynku, choć "obiektowo" była to linia łamana a nie punkt. Więc temat dość stary tylko teraz weszła nowa semantyka i obiekty powierzchniowe. Z mojego punktu widzenia nic się nie zmieniło i dlatego nie rozumiem problemu, choć zgadzam się że gdyby wszystko działało zgodnie z przepisami to problemu nie powinno być i żadne kodowanie nie byłoby potrzebne. Ale człowiek musi sobie jakoś radzić, bo nie zanosi się na zmiany.

Chyba przykład z linią graniczną nie jest najszczęśliwszy. Jakie dokładnie miałyby być nadane cechy dla punktów załamania linii granicy działki? Punktu granicznego: niestabilizowanego, stabilizowanego, granicy państwa?

Przecież c-geo graficznie już teraz jak rysuję granice działki to rysuje ją jakby punkty były niestabilizowane więc obecne działanie programu jest najlepszą odpowiedzią na Pańskie pytania. Granicę państwa proszę nie mieszać w to przecież to całkiem inny symbol i ma własne symbole swojej stabilizacji lub nie. A stabilizacja? - ręczne wstawianie graniczników jako symbole załatwia sprawę. A przynajmniej powinno - bo obecnie jak narysuję linię to punkty zakoduje mi jako granica działki i wstawiając granicznik kodu już mi program nie zmieni.

Niestety rozporządzenie nie zawiera w swoim katalogu obiektów - obiektu punktowego - punkt załamania skarpy i odpowiedniego dla niego kodu.

To już było wyżej.

Niestety to zdanie jest niezrozumiałe - czy chce Pan usunąć kody jakiejś grupy punktów?, czy wyeksportować punkty z kodami?

Na samym początku zapytywałem czy jest jakieś dodatkowe usprawnienia dotyczące automatycznego kodowania które by działało bezpośrednio w relacji mapa-tabela. Dowiedziałem się że nie ma, stąd też zapytanie o narzędzie które by pozwalało choćby wyeksportować kody pikiet z mapy i tu podałem przykład paragramu granicznego który wyrzuca kody punktów na podstawie bliskości pikiety do obiektu (nieważne czy punktowego czy liniowego) - ale wtedy np jednemu punktowi przypisywane są np dwa kody w osobnych wierszach - wówczas już ręcznie można by usunąć wiersz jeśli by coś się nie zgadzało.

Hmm, gdzie są takie kody? W C-GEO w zestawie kodów MapaZasadnicza, takich kodów punktów nie ma.

Trochę wyrwał Pan moją wypowiedź z kontekstu wymiany zdań i nie zrozumiał ironii. To także obawa, że skoro nie ma takich kodów, znajdzie się ktoś, kto takie zrobi, skoro jest problem z kodowaniem punktów stanowiących "obiekt".

Wnioski - zgodnie z rozporządzeniem bdot500 (nieobowiązującym) nie ma czegoś takiego jak kod punktu (pikiety) tylko są zdefiniowane kody kartograficzne dotyczące symboli, zatem w ogóle nie powinno w tabeli punktów takiej kolumny, skoro symbole są częścią mapy i brak jest relacji między punktem a symbolem. Jeśli jednak ta kolumna ma roboczo o czymś mówić i czemuś służyć, to dobrze by było, żeby chociaż działało na jakiś zasadach, choćby praktyki ostatnich 20 lat, odkąd jest coś takiego jak mapa numeryczna. Jakoś nie było nigdy problemu, żeby pikietę, która stanowiła jednocześnie narożnik budynku i krawędź chodnika, kodować zgodnie z zasadami wizualizacji mapy jako BUD.

[Jurek B.]

przecież to samo było od czasów K1 1995 - jakoś przez 20 lat nikomu nie przeszkadzało by kodować jako BUD narożnik budynku

Absolutnie nie było takich standardów - poza lokalnymi przypadkami bezsensownych pomysłów w ośrodkach, wszędzie tam gdzie tworzono przyzwoitą mapę numeryczną (Ewmapa, GeoInfo) nie kodowano w żadnym przypadku punktów załamania budynków, itp.

Przecież c-geo graficznie już teraz jak rysuję granice działki to rysuje ją jakby punkty były niestabilizowane więc obecne działanie programu jest najlepszą odpowiedzią na Pańskie pytania.

Styl linii nie ma nic wspólnego z innym obiektem - punktem granicznym, nieważne czy stabilizowanym czy nie.

Granicę państwa proszę nie mieszać w to przecież to całkiem inny symbol i ma własne symbole swojej stabilizacji lub nie.

Punkt granicy państwa to taki sam punkt graniczny jak każdy inny i jak każdy inny typ punktu granicznego ma swój własny symbol, więc to nie jest żaden wyjątek.

A stabilizacja? - ręczne wstawianie graniczników jako symbole załatwia sprawę. A przynajmniej powinno - bo obecnie jak narysuję linię to punkty zakoduje mi jako granica działki i wstawiając granicznik kodu już mi program nie zmieni.

Czyli sam Pan potwierdza bezsens kodowania punktów załamania obiektu kodem obiektu.

Na samym początku zapytywałem czy jest jakieś dodatkowe usprawnienia dotyczące automatycznego kodowania które by działało bezpośrednio w relacji mapa-tabela. Dowiedziałem się że nie ma, stąd też zapytanie o narzędzie które by pozwalało choćby wyeksportować kody pikiet z mapy i tu podałem przykład paragramu granicznego który wyrzuca kody punktów na podstawie bliskości pikiety do obiektu (nieważne czy punktowego czy liniowego) - ale wtedy np jednemu punktowi przypisywane są np dwa kody w osobnych wierszach - wówczas już ręcznie można by usunąć wiersz jeśli by coś się nie zgadzało.

Czy eksport np. do TXT punktów z numerami, kodami i współrzędnymi z tabeli współrzędnych to nie jest to co o Pan się pytał?

zgodnie z rozporządzeniem bdot500 (nieobowiązującym) nie ma czegoś takiego jak kod punktu (pikiety) tylko są zdefiniowane kody kartograficzne dotyczące symboli, zatem w ogóle nie powinno w tabeli punktów takiej kolumny, skoro symbole są częścią mapy i brak jest relacji między punktem a symbolem.

Przecież w C-GEO jest pełne i jednoznaczne powiązanie między symbolem kartograficznym na mapie a kodem punktu w tabeli.

Jakoś nie było nigdy problemu, żeby pikietę, która stanowiła jednocześnie narożnik budynku i krawędź chodnika, kodować zgodnie z zasadami wizualizacji mapy jako BUD.

Czyli punktowi załamania krawędzi chodnika nadał Pan kod narożnika budynku - co w takim razie z punktem załamania chodnika? Czy w tym miejscu chodnik nie miał już załamania i zmienił się jego przebieg? Czy to nie potwierdza bezsensu takiego kodowania?
Poniżej załączam obraz z definicji obiektu K1 - Budynek - nie wiem kto był w stanie na tej podstawie wywnioskować o kodowaniu narożników budynków kodem BUD:

[grzes]

Mi sie wydaje ze przedmowcy chodzi o sytuację kiedy przekazujemy wykaz zakodowanych punktow do kartowania osobie trzeciej. Wtedy taki kod ma sens bo informuje do jakiego obiektu punkt nalezy. Tyle ze takiego wykorzystania kodowania c-geo nigdy nie wspierało.

[KunziteSan]

Odnośnie zaszłości K1 pisze Pan z pozycji kogoś, kto tworzył mapę numeryczną - większość geodetów jednak, podobnie jak ja znajdowała się po tej drugiej stronie, której zadaniem było dostarczanie danych do tych map. Nigdzie nie twierdzę, że jakiś ośrodek kodował punkty jako BUD, bo szczerze mówiąc, niewiele mnie obchodzi co sobie ośrodek robił z moimi danymi, praktyka jednak była taka, że geodeci, nazwijmy to "roboczo" kodowali sobie punkty nie przejmując się rodzajem "obiektu". Zaczęło to mieć bardzo duże znaczenie zwłaszcza przy kodowaniu pikiet w tachimetrach. Mało który ośrodek nie wymagał (i nadal nie wymaga) kodowania punktów z przyczyn, które podałem parę postów temu.

Skoro tyle Pan, Panie Jurku, mówi o bezsensowności kodowania punktów to czemu dopuszcza jednocześnie, by c geo to robił przy kartowaniu punktów rzeczonym budynkiem, A przecież wystarczy zablokować autokodowanie dla wszystkich obiektów nie-punktowych by nie było takiej sytuacji, że narożnikowi budynku przypisywany jest obiekt powierzchniowy. Nie jest to jakaś niekonsekwencja? Jakby nie przetrzeć, Pan mówi co innego (i jak pisałem, logicznie ma Pan pełną rację), a program robi coś przeciwnego. Jaki zatem jest cel takiego kodera, bo wydawało się że wiem, ale Pan bardzo rzeczowo wyjaśnił, że taka rzecz nie powinna mieć miejsca.

Pozostaje jeszcze kwestia bardzo przydatnego narzędzia w cgeo jakim jest eksport punktów z podziałem na rodzaje baz danych. Jeśli punktu nie zakoduje BUDem to punkt mi się nie wyeksportuje, jako element bazy EGiB, prawda? I tu można wrócić to wcześniejszego mojego przykładu z narożnikiem budynku i chodnikiem. Moja odpowiedź jest prosta - a jaki jest problem, by dana pikieta znalazła się zarówno z kodem BUD w bazie EGiB, jak i z kodem KOD w bazie BDOT500. Wówczas nie mamy do czynienia z utratą informacji. Chyba że pikieta, stanowiąca narożnik budynku nie powinna stanowić element bazy EGiB.

ps.
Pan Grzes ma rację, jak wspomniałem o tym, czemu służyło kartowanie po kodach pisałem wcześniej

[grzes]

Ma to sens - teraz jestem zawalony robotą ale jak bedzie wolniejsza chwila to zobaczę czy nie da sie tego wprowdzic np do eksportu punktów do txt. Tzn w c-geo nie robimy kodowania punktów tworzących obiekty, a przy eksporcie do txt (jesli brak kodu) to program analizuje czy punkt nie jest składową obiektu i wyciaga jego kod z kodu obiektu. Tylko wolalbym tu sie nie bawic w hierarchię kodów i eksportowac dany punkt tyle razy ile razy jest on składową obiektu.