CODER

Znalazłem niedociągnięcie przy tworzeniu punktu o określonej wysokości dla GESUT. Przy wpisaniu rzędnej góry 116.70 opis jest obcinany i wyświetla się 116.7. Dla włazu i zasuwy ma znaczenie dokładność zapisu do cm.
Pozdrawiam

> Znalazłem niedociągnięcie przy tworzeniu punktu o określonej wysokości dla
> GESUT. Przy wpisaniu rzędnej góry 116.70 opis jest obcinany i wyświetla się
> 116.7. Dla włazu i zasuwy ma znaczenie dokładność zapisu do cm.
> Pozdrawiam

GML ma taką przykrą właściwość, że rzędne, które maja byc do 1 miejsca, i tak podaje do 2 miejsc, z zerem na końcu. Dlatego te zera usuwamy.

---
Admin

A propos wysokości w GML.
Skoro obiektujemy skarpy, rowy, drogi itd., przypisując im pikiety wysokościowe jako podobiekty, to może jest to wreszcie jakaś ścieżka do tworzenia przestrzennego modelu DTM w MM do generowania warstwic (wiem, nie są elementem BDOT, ale dla projektanta czasem są przydatne) uwzgledniających linie nieciągłości? Może da się z tego robić jakieś eksporty do programów CAD?
Czy jednak robimy to zupełnie po nic?

> A propos wysokości w GML.
> Skoro obiektujemy skarpy, rowy, drogi itd., przypisując im pikiety
> wysokościowe jako podobiekty, to może jest to wreszcie jakaś ścieżka do
> tworzenia przestrzennego modelu DTM w MM do generowania warstwic (wiem, nie
> są elementem BDOT, ale dla projektanta czasem są przydatne)
> uwzgledniających linie nieciągłości? Może da się z tego robić jakieś
> eksporty do programów CAD?
> Czy jednak robimy to zupełnie po nic?


Nie rozumiem, a co jest nie tak z obecnym generowaniem warstwic?

---
Admin

> Nie rozumiem, a co jest nie tak z obecnym generowaniem warstwic?

Nie da się edytować siatki trójkątów z poziomu mapy tak, aby dokładnie uwzględniać wymuszone linie interpolacji. Program sam wykrywa część krawędzi, ale nigdy w 100%. Skoro już mamy "obiekty" powierzchniowe z przypisanymi rzędnymi, a dotyczy to skarp, rowów, dróg, to może da się je jakoś uwzględnić przy tworzeniu siaki trójkątów? Druga sprawa, to obiekty mogłyby przesłaniać warstwice, ale niekoniecznie, bo faktycznie nie chodzi tu o wydruk mapy, tylko obliczenia DTM i ewentualnie wizualizację tych obliczeń.
Przykładowo w Surferze do takich linii nieciągłości trzeba dość żmudnie robić pliki tzt z wykazami współrzędnych linii, tutaj niby mam już obiekty w bazie.
W obliczeniach mas często chodzi o bilans robót, w sensie: mamy zobiektowany teren z mapy lub pomiaru stanu zerowego budowy i mamy jakiś stan z inwentaryzacji też jako mapę obiektową. Czyli niby linie szkieletowe szkielety i pikiety są zdefiniowane.
Nie da się tego łatwo wykorzystać do modułu obliczeń DTM?

> > Nie rozumiem, a co jest nie tak z obecnym generowaniem warstwic?
>
> Nie da się edytować siatki trójkątów z poziomu mapy tak, aby dokładnie
> uwzględniać wymuszone linie interpolacji. Program sam wykrywa część
> krawędzi, ale nigdy w 100%. Skoro już mamy "obiekty" powierzchniowe z
> przypisanymi rzędnymi, a dotyczy to skarp, rowów, dróg, to może da się je
> jakoś uwzględnić przy tworzeniu siaki trójkątów? Druga sprawa, to obiekty
> mogłyby przesłaniać warstwice, ale niekoniecznie, bo faktycznie nie chodzi
> tu o wydruk mapy, tylko obliczenia DTM i ewentualnie wizualizację tych
> obliczeń.
> Przykładowo w Surferze do takich linii nieciągłości trzeba dość żmudnie
> robić pliki tzt z wykazami współrzędnych linii, tutaj niby mam już obiekty
> w bazie.
> W obliczeniach mas często chodzi o bilans robót, w sensie: mamy
> zobiektowany teren z mapy lub pomiaru stanu zerowego budowy i mamy jakiś
> stan z inwentaryzacji też jako mapę obiektową. Czyli niby linie szkieletowe
> szkielety i pikiety są zdefiniowane.
> Nie da się tego łatwo wykorzystać do modułu obliczeń DTM?
Popatrz ile kosztują te programy...nie możemy wymagać/prosić aby MM i WK je zastępował.

> Popatrz ile kosztują te programy...nie możemy wymagać/prosić aby MM i WK je
> zastępował.

Też o tym kiedyś wspominałem przy innej liście życzeń.
W każdej z tych dużych aplikacji większość ceny generuje platforma CAD, reszta to różnego rodzaju moduły do projektowania i analiz, moduł DTM to tylko jedna z funkcji. Płaci się za moduł wpasowujący projekt drogi w teren, analizujący spadki i przepływy instalacji czy choćby za bazy kwiatków w programie dla architektów krajobrazu.
Kiedyś klimatyzacja i nawigacja też była tylko w ekskluzywnych limuzynach, dziś to standard w samochodach do rozwożenia pizzy, telefon był na kablu i służył tylko do rozmowy.
Dlatego o tym teraz piszę, bo teraz mamy GML-a i zamknięte obiekty powierzchniowe, już nie jakieś bezładne kreski i wykaz punktów.
Naprawdę psu na budę to nasze mozolne obiektowanie bazy BDOT, nawet nasza branża nie jest w stanie tego łatwo wykorzystać, skoro już to zaimplementowano "gratis"? Bo o tym, ze jeszcze żaden projektant nie chciał ode mnie GML-a, to chyba oczywiste?

> Dlatego o tym teraz piszę, bo teraz mamy GML-a i zamknięte obiekty
> powierzchniowe, już nie jakieś bezładne kreski i wykaz punktów.
> Naprawdę psu na budę to nasze mozolne obiektowanie bazy BDOT, nawet nasza
> branża nie jest w stanie tego łatwo wykorzystać, skoro już to
> zaimplementowano "gratis"? Bo o tym, ze jeszcze żaden projektant nie chciał
> ode mnie GML-a, to chyba oczywiste?

Po części się zgadzam, ale przecież projektantowi można przekazać wykaz punktów z rzędnymi oraz wyeksportować z gotowej mapy osobny plik DXF z samymi liniami nieciągłości. Wczyta sobie jedno i drugie i stworzy powierzchnię, niezależnie od tego czy pracuje na Civilu czy jakimkolwiek innym programie.

---
Pozdrawiam,
Michał Niemczyk
geodeta
GeoMensus
ul. Witosa 3e
38-400 Krosno

> Po części się zgadzam, ale przecież projektantowi można przekazać wykaz
> punktów z rzędnymi oraz wyeksportować z gotowej mapy osobny plik DXF z
> samymi liniami nieciągłości. Wczyta sobie jedno i drugie i stworzy
> powierzchnię, niezależnie od tego czy pracuje na Civilu czy jakimkolwiek
> innym programie.

I tak robię od dawna, ale to nie wyjaśnia, po co GML, który w tej operacji nie bierze udziału razem z obiektami? A żaden PDGiK w swoich wydrukach do wniosku o warunki zabudowy nie korzysta z polilinii 3D ani z tego, że skarpy to obiekty z pikietami.
A poza tym to ja często muszę zrobić te bilanse podczas obsługi, nie projektant.

> > Nie rozumiem, a co jest nie tak z obecnym generowaniem warstwic?
>
> Nie da się edytować siatki trójkątów z poziomu mapy tak, aby dokładnie
> uwzględniać wymuszone linie interpolacji. Program sam wykrywa część
> krawędzi, ale nigdy w 100%. Skoro już mamy "obiekty" powierzchniowe z
> przypisanymi rzędnymi, a dotyczy to skarp, rowów, dróg, to może da się je
> jakoś uwzględnić przy tworzeniu siaki trójkątów? Druga sprawa, to obiekty
> mogłyby przesłaniać warstwice, ale niekoniecznie, bo faktycznie nie chodzi
> tu o wydruk mapy, tylko obliczenia DTM i ewentualnie wizualizację tych
> obliczeń.
> Przykładowo w Surferze do takich linii nieciągłości trzeba dość żmudnie
> robić pliki tzt z wykazami współrzędnych linii, tutaj niby mam już obiekty
> w bazie.
> W obliczeniach mas często chodzi o bilans robót, w sensie: mamy
> zobiektowany teren z mapy lub pomiaru stanu zerowego budowy i mamy jakiś
> stan z inwentaryzacji też jako mapę obiektową. Czyli niby linie szkieletowe
> szkielety i pikiety są zdefiniowane.
> Nie da się tego łatwo wykorzystać do modułu obliczeń DTM?


Nasz algorytm triangulacji nie ma mozliwości uwzględniania linii wymuszonej interpolacji. Ale można wykorzystać siatkę trójkątów przygotowaną w WinKalk w module Oliczenia mas ziemi - graficzne

---
Admin

> Nasz algorytm triangulacji nie ma mozliwości uwzględniania linii wymuszonej
> interpolacji. Ale można wykorzystać siatkę trójkątów przygotowaną w WinKalk
> w module Oliczenia mas ziemi - graficzne

Tak robię, na dwa monitory, na jednym mam Mikromap z mapą, na drugim Winkalk z trójkątami. Nauczyłęm się już nawet mierzyć "trójkątami" w terenie i tak dobieram pikiety, żeby powierzchnie brył dzieliły się na trójkąty.
Czyli to tylko utwierdza mnie w przekonaniu, że jedyny zysk z wprowadzania tych GML-i to pretekst dla pozyskania pieniędzy przez powiaty na zakup i wdrożenie obsługujących to aplikacji oraz wydania pieniędzy na dostosowywanie baz.
Ale praktycznego wykorzystania chyba nie ma, przynajmniej nie dla bazy BDOT i nie da się tego przerobić łatwo i tanio na nic pożytecznego.

> Czyli to tylko utwierdza mnie w przekonaniu, że jedyny zysk z wprowadzania
> tych GML-i to pretekst dla pozyskania pieniędzy przez powiaty na zakup i
> wdrożenie obsługujących to aplikacji oraz wydania pieniędzy na
> dostosowywanie baz.

Powiat, w którym pracuję, dostał kilka milionów dofinansowania i nie jestem przekonany czy w ogóle ktoś z GML-a korzysta, gdyż wdrożyli system GeoInfo i pracujemy na tzw. givach. Tak więc wiesz. Gdybym im oddał GML to by mnie pogonili w diabły.

Ja oddaje gmle z ewmapy do powiatow pracujacych na geoinfo i jakos dają rade

---
Korepetycje z ewmapy / pliki gml / operaty -> ewmapa@o2.pl