CODER

Witam czy problem został jakoś trwale rozwiązany ? znowu mam taki problem z ośrodkiem , że chcą okrąg jedna linia nie odcinkami . Czy została dodana opcja aby np komory podziemne o zadanym promieniu rysować okręgiem nie odcinkami ? Kiedyś pisaliśmy ,że fajnie było by dodać funkcje w której bedzie wybór czy okra rysujemy okręgiem czy odcinkami

> Witam czy problem został jakoś trwale rozwiązany ? znowu mam taki problem z
> ośrodkiem , że chcą okrąg jedna linia nie odcinkami . Czy została dodana
> opcja aby np komory podziemne o zadanym promieniu rysować okręgiem nie
> odcinkami ? Kiedyś pisaliśmy ,że fajnie było by dodać funkcje w której
> bedzie wybór czy okra rysujemy okręgiem czy odcinkami

W Mikromap od dawna przyjęliśmy, że wszelkie łuki będą rysowane łamanymi, nie mamy obiektów typu okrąg czy łuk, musielibyśmy to dopiero dorobić.
Ale na szczęście nie musimy, gdyż GGK wydał interpretację zabraniającą używania łuków w GML, ośrodek nie ma prawa tego żądać.

Proszę wydrukować to pismo i przedstawić w Ośrodku:
https://geoforum.pl/upload2/files/211223-pismo-ggk-g-rp.pdf

Pytanie 10: Czy obiekty mogą zawierać łuki kołowe?
Nie

---
Admin

> > Witam czy problem został jakoś trwale rozwiązany ? znowu mam taki problem
> z
> > ośrodkiem , że chcą okrąg jedna linia nie odcinkami . Czy została dodana
> > opcja aby np komory podziemne o zadanym promieniu rysować okręgiem nie
> > odcinkami ? Kiedyś pisaliśmy ,że fajnie było by dodać funkcje w której
> > bedzie wybór czy okra rysujemy okręgiem czy odcinkami
>
> W Mikromap od dawna przyjęliśmy, że wszelkie łuki będą rysowane łamanymi,
> nie mamy obiektów typu okrąg czy łuk, musielibyśmy to dopiero dorobić.
> Ale na szczęście nie musimy, gdyż GGK wydał interpretację zabraniającą
> używania łuków w GML, ośrodek nie ma prawa tego żądać.
>
> Proszę wydrukować to pismo i przedstawić w Ośrodku:
> https://geoforum.pl/upload2/files/211223-pismo-ggk-g-rp.pdf
>
> Pytanie 10: Czy obiekty mogą zawierać łuki kołowe?
> Nie

zadzwonie tam jutro do nich i im to powiem, ale te pabianice są nie normalne. Inne ośrodki pracują też w ew mapie i nie mają takiego problemu .
Kiedyś już miałem taki problem i przerabialiście mi mikromape

> > > Witam czy problem został jakoś trwale rozwiązany ? znowu mam taki
> problem
> > z
> > > ośrodkiem , że chcą okrąg jedna linia nie odcinkami . Czy została
> dodana
> > > opcja aby np komory podziemne o zadanym promieniu rysować okręgiem nie
> > > odcinkami ? Kiedyś pisaliśmy ,że fajnie było by dodać funkcje w której
> > > bedzie wybór czy okra rysujemy okręgiem czy odcinkami
> >
> > W Mikromap od dawna przyjęliśmy, że wszelkie łuki będą rysowane
> łamanymi,
> > nie mamy obiektów typu okrąg czy łuk, musielibyśmy to dopiero dorobić.
> > Ale na szczęście nie musimy, gdyż GGK wydał interpretację zabraniającą
> > używania łuków w GML, ośrodek nie ma prawa tego żądać.
> >
> > Proszę wydrukować to pismo i przedstawić w Ośrodku:
> > https://geoforum.pl/upload2/files/211223-pismo-ggk-g-rp.pdf
> >
> > Pytanie 10: Czy obiekty mogą zawierać łuki kołowe?
> > Nie
>
> zadzwonie tam jutro do nich i im to powiem, ale te pabianice są nie
> normalne. Inne ośrodki pracują też w ew mapie i nie mają takiego problemu .
>
> Kiedyś już miałem taki problem i przerabialiście mi mikromape

Mikromapa w którejś poprzedniej wersji generowała faktycznie okręgi a nie linie łamane więc było to już dopracowane. Powoływane już wielokroć pismo GGK odnośnie odpowiedzi na pytania nie zawiera żadnych wyjaśnień a już napewno nie zawiera podstawy prawnej. W zadanym zresztą pytaniu jest mowa o konstruowaniu obiektów z wykorzystaniem łuków a my prosimy o możliwość rysowania okręgów, tak żeby studnia kanalizacyjna była rzeczywiście okręgiem. Cytowane pismo nie jest żadną podstawą prawną do udowadniania racji w PODGiK bo samo w sobie żadnej podstawy prawnej nie zawiera. Geodeta mierząc studnię/ komorę kanalizacyjną pozyskuje o tym obiekcie najczęściej dwie informacje tzn. jej geometryczny środek oraz średnicę i tak też rysuje taki obiekt w programie za pomocą dwóch zmiennych. Nie znam racjonalnych powodów, dla których taki obiekt miałby się generować linią łamaną jako wielobok. Już pomijam fakt, że każdy węzeł(punkt) w obiekcie wnoszonym do bazy bdot/egib/gesut powinien być wynikiem pomiaru geodety w terenie. Sztuczne dzielenie okręgów na linie łamane jest też sprzeczne z par. 18 ust. 1 rozporządzenia w sprawie standardów. Dodatkowo generowanie plików gml z prezentacją okręgów jako zespołu odcinków generuje wiele wartości liczbowych (współrzędnych węzłów), które docelowo zaśmiecają bazę gesut.

> > > > Witam czy problem został jakoś trwale rozwiązany ? znowu mam taki
> > problem
> > > z
> > > > ośrodkiem , że chcą okrąg jedna linia nie odcinkami . Czy została
> > dodana
> > > > opcja aby np komory podziemne o zadanym promieniu rysować okręgiem
> nie
> > > > odcinkami ? Kiedyś pisaliśmy ,że fajnie było by dodać funkcje w
> której
> > > > bedzie wybór czy okra rysujemy okręgiem czy odcinkami
> > >
> > > W Mikromap od dawna przyjęliśmy, że wszelkie łuki będą rysowane
> > łamanymi,
> > > nie mamy obiektów typu okrąg czy łuk, musielibyśmy to dopiero dorobić.
>
> > > Ale na szczęście nie musimy, gdyż GGK wydał interpretację zabraniającą
> > > używania łuków w GML, ośrodek nie ma prawa tego żądać.
> > >
> > > Proszę wydrukować to pismo i przedstawić w Ośrodku:
> > > https://geoforum.pl/upload2/files/211223-pismo-ggk-g-rp.pdf
> > >
> > > Pytanie 10: Czy obiekty mogą zawierać łuki kołowe?
> > > Nie
> >
> > zadzwonie tam jutro do nich i im to powiem, ale te pabianice są nie
> > normalne. Inne ośrodki pracują też w ew mapie i nie mają takiego problemu
> .
> >
> > Kiedyś już miałem taki problem i przerabialiście mi mikromape
>
> Mikromapa w którejś poprzedniej wersji generowała faktycznie okręgi a nie
> linie łamane więc było to już dopracowane. Powoływane już wielokroć pismo
> GGK odnośnie odpowiedzi na pytania nie zawiera żadnych wyjaśnień a już
> napewno nie zawiera podstawy prawnej. W zadanym zresztą pytaniu jest mowa o
> konstruowaniu obiektów z wykorzystaniem łuków a my prosimy o możliwość
> rysowania okręgów, tak żeby studnia kanalizacyjna była rzeczywiście
> okręgiem. Cytowane pismo nie jest żadną podstawą prawną do udowadniania
> racji w PODGiK bo samo w sobie żadnej podstawy prawnej nie zawiera. Geodeta
> mierząc studnię/ komorę kanalizacyjną pozyskuje o tym obiekcie najczęściej
> dwie informacje tzn. jej geometryczny środek oraz średnicę i tak też rysuje
> taki obiekt w programie za pomocą dwóch zmiennych. Nie znam racjonalnych
> powodów, dla których taki obiekt miałby się generować linią łamaną jako
> wielobok. Już pomijam fakt, że każdy węzeł(punkt) w obiekcie wnoszonym do
> bazy bdot/egib/gesut powinien być wynikiem pomiaru geodety w terenie.
> Sztuczne dzielenie okręgów na linie łamane jest też sprzeczne z par. 18
> ust. 1 rozporządzenia w sprawie standardów. Dodatkowo generowanie plików
> gml z prezentacją okręgów jako zespołu odcinków generuje wiele wartości
> liczbowych (współrzędnych węzłów), które docelowo zaśmiecają bazę gesut.




tak więc nie można dodać opcji wyboru rysowania łukami czy odcinkami ?

> > > > > Witam czy problem został jakoś trwale rozwiązany ? znowu mam taki
> > > problem
> > > > z
> > > > > ośrodkiem , że chcą okrąg jedna linia nie odcinkami . Czy została
> > > dodana
> > > > > opcja aby np komory podziemne o zadanym promieniu rysować okręgiem
> > nie
> > > > > odcinkami ? Kiedyś pisaliśmy ,że fajnie było by dodać funkcje w
> > której
> > > > > bedzie wybór czy okra rysujemy okręgiem czy odcinkami
> > > >
> > > > W Mikromap od dawna przyjęliśmy, że wszelkie łuki będą rysowane
> > > łamanymi,
> > > > nie mamy obiektów typu okrąg czy łuk, musielibyśmy to dopiero
> dorobić.
> >
> > > > Ale na szczęście nie musimy, gdyż GGK wydał interpretację
> zabraniającą
> > > > używania łuków w GML, ośrodek nie ma prawa tego żądać.
> > > >
> > > > Proszę wydrukować to pismo i przedstawić w Ośrodku:
> > > > https://geoforum.pl/upload2/files/211223-pismo-ggk-g-rp.pdf
> > > >
> > > > Pytanie 10: Czy obiekty mogą zawierać łuki kołowe?
> > > > Nie
> > >
> > > zadzwonie tam jutro do nich i im to powiem, ale te pabianice są nie
> > > normalne. Inne ośrodki pracują też w ew mapie i nie mają takiego
> problemu
> > .
> > >
> > > Kiedyś już miałem taki problem i przerabialiście mi mikromape
> >
> > Mikromapa w którejś poprzedniej wersji generowała faktycznie okręgi a
> nie
> > linie łamane więc było to już dopracowane. Powoływane już wielokroć
> pismo
> > GGK odnośnie odpowiedzi na pytania nie zawiera żadnych wyjaśnień a już
> > napewno nie zawiera podstawy prawnej. W zadanym zresztą pytaniu jest mowa
> o
> > konstruowaniu obiektów z wykorzystaniem łuków a my prosimy o możliwość
> > rysowania okręgów, tak żeby studnia kanalizacyjna była rzeczywiście
> > okręgiem. Cytowane pismo nie jest żadną podstawą prawną do udowadniania
> > racji w PODGiK bo samo w sobie żadnej podstawy prawnej nie zawiera.
> Geodeta
> > mierząc studnię/ komorę kanalizacyjną pozyskuje o tym obiekcie
> najczęściej
> > dwie informacje tzn. jej geometryczny środek oraz średnicę i tak też
> rysuje
> > taki obiekt w programie za pomocą dwóch zmiennych. Nie znam racjonalnych
> > powodów, dla których taki obiekt miałby się generować linią łamaną jako
> > wielobok. Już pomijam fakt, że każdy węzeł(punkt) w obiekcie wnoszonym
> do
> > bazy bdot/egib/gesut powinien być wynikiem pomiaru geodety w terenie.
> > Sztuczne dzielenie okręgów na linie łamane jest też sprzeczne z par. 18
> > ust. 1 rozporządzenia w sprawie standardów. Dodatkowo generowanie plików
> > gml z prezentacją okręgów jako zespołu odcinków generuje wiele wartości
> > liczbowych (współrzędnych węzłów), które docelowo zaśmiecają bazę gesut.
>
>
>
>
> tak więc nie można dodać opcji wyboru rysowania łukami czy odcinkami ?

Probóje się zagłebić w temat to właśnie głownie programy stosują łuki , ale też w wiekszości jest możliwość wyboru .
Turbo mapa głównie stosuje odcinki .
Niestety ewmapa , na której wiekszość ośrodków działa stosuje łuki .

> Cytowane pismo nie jest żadną podstawą prawną do udowadniania
> racji w PODGiK bo samo w sobie żadnej podstawy prawnej nie zawiera.

Zatem jakiego kalibru akty prawne regulują takie sprawy?
Na przykład jak wygląda podstawa prawna, na której opiera się ośrodek wymagając stosowania łuków.

---
Admin

> > Cytowane pismo nie jest żadną podstawą prawną do udowadniania
> > racji w PODGiK bo samo w sobie żadnej podstawy prawnej nie zawiera.
>
> Zatem jakiego kalibru akty prawne regulują takie sprawy?
> Na przykład jak wygląda podstawa prawna, na której opiera się ośrodek
> wymagając stosowania łuków.

to jest duży problem zrobić możliwość wyboru ? Tak jak w większości to jest . Bo chyba i tak pójście w jedną opcje nie daje sukcesu kiedy jedne urzędy są w turbomapie a drugie w ewmapie .
A walka prawna z nimi to raczej walka z wiatrem, to autorzy programu to ustalają , urzędy są tylko użytkownikami i robią tak jak mają w danym programie. Jakaś wielka analiza tam nie jest , oni mają mieć dobrze wyświetlone w swoim programie bez błędów i nic wiecej ich nie obchodzi. Takie są realia.

> > > Cytowane pismo nie jest żadną podstawą prawną do udowadniania
> > > racji w PODGiK bo samo w sobie żadnej podstawy prawnej nie zawiera.
> >
> > Zatem jakiego kalibru akty prawne regulują takie sprawy?
> > Na przykład jak wygląda podstawa prawna, na której opiera się ośrodek
> > wymagając stosowania łuków.
>
> to jest duży problem zrobić możliwość wyboru ? Tak jak w większości to jest
> . Bo chyba i tak pójście w jedną opcje nie daje sukcesu kiedy jedne urzędy
> są w turbomapie a drugie w ewmapie .
> A walka prawna z nimi to raczej walka z wiatrem, to autorzy programu to
> ustalają , urzędy są tylko użytkownikami i robią tak jak mają w danym
> programie. Jakaś wielka analiza tam nie jest , oni mają mieć dobrze
> wyświetlone w swoim programie bez błędów i nic wiecej ich nie obchodzi.
> Takie są realia.
Odnośnie podstawy prawnej wprost do okręgów to raczej się jej nie znajdzie, ale można by się przy okazji zapytać jaka jest podstawa prawna do prezentacji graficznej odcinka/ linii (linia prosta teoretycznie też mogłaby się składać z n-odcinków, ale póki co nikt nie wpadł na pomysł, żeby takie pytanie zadawać GGK bo kto wie jaka byłaby odpowiedź )Ustawodawcy raczej nie przeszło przez myśl, że można sobie aż tak bardzo życie komplikować i obiekty zamiast okręgów przedstawiać poligonem z n ilością węzłów. Natomiast co do samej podstawy prawnej w protokole weryfikacji to można wskazać na rozbieżność w kształcie pomierzonego obiektu zawartego w pliku w odniesieniu do jego prezentacji graficznej na szkicu polowym i opisującymi taki obiekt współrzędnymi (tzn. środkiem okręgu). No chyba, że w operacie znajdzie się do każdego okręgu n współrzędnych w wykazie współrzędnych, ale wtedy tak skonstruowany obiekt narusza par. 18 ust. 1 gdyż nie jest zachowana generalizacja szczegółów terenowych. Ponadto wprowadzanie do bazy okręgów przekształconych do wieloboków nie pozwoli na odróżnienie w przyszłości obiektów, których obrys jest faktycznie wielobokiem w którym każdy narożnik został pomierzony faktycznie w terenie. Pomijam już fakt, że plik dxf przekazany projektantowi z takimi "okręgami" wygląda co najmniej dziwnie, nie wspominając że przy rozbiciu bloków tworzy się zlepek odcinków. Dlatego przyłączam się do prośby o wprowadzenie funkcjonalności umożliwiającej wybór w jaki sposób okręgi/łuki bę
dą prezentowane.

> > > > Cytowane pismo nie jest żadną podstawą prawną do udowadniania
> > > > racji w PODGiK bo samo w sobie żadnej podstawy prawnej nie zawiera.
> > >
> > > Zatem jakiego kalibru akty prawne regulują takie sprawy?
> > > Na przykład jak wygląda podstawa prawna, na której opiera się ośrodek
> > > wymagając stosowania łuków.
> >
> > to jest duży problem zrobić możliwość wyboru ? Tak jak w większości to
> jest
> > . Bo chyba i tak pójście w jedną opcje nie daje sukcesu kiedy jedne
> urzędy
> > są w turbomapie a drugie w ewmapie .
> > A walka prawna z nimi to raczej walka z wiatrem, to autorzy programu to
> > ustalają , urzędy są tylko użytkownikami i robią tak jak mają w danym
> > programie. Jakaś wielka analiza tam nie jest , oni mają mieć dobrze
> > wyświetlone w swoim programie bez błędów i nic wiecej ich nie obchodzi.
> > Takie są realia.
> Odnośnie podstawy prawnej wprost do okręgów to raczej się jej nie znajdzie,
> ale można by się przy okazji zapytać jaka jest podstawa prawna do
> prezentacji graficznej odcinka/ linii (linia prosta teoretycznie też
> mogłaby się składać z n-odcinków, ale póki co nikt nie wpadł na pomysł,
> żeby takie pytanie zadawać GGK bo kto wie jaka byłaby odpowiedź
> )Ustawodawcy raczej nie przeszło przez myśl, że można sobie aż tak
> bardzo życie komplikować i obiekty zamiast okręgów przedstawiać poligonem z
> n ilością węzłów. Natomiast co do samej podstawy prawnej w protokole
> weryfikacji to można wskazać na rozbieżność w kształcie pomierzonego
> obiektu zawartego w pliku w odniesieniu do jego prezentacji graficznej na
> szkicu polowym i opisującymi taki obiekt współrzędnymi (tzn. środkiem
> okręgu). No chyba, że w operacie znajdzie się do każdego okręgu n
> współrzędnych w wykazie współrzędnych, ale wtedy tak skonstruowany obiekt
> narusza par. 18 ust. 1 gdyż nie jest zachowana generalizacja szczegółów
> terenowych. Ponadto wprowadzanie do bazy okręgów przekształconych do
> wieloboków nie pozwoli na odróżnienie w przyszłości obiektów, których obrys
> jest faktycznie wielobokiem w którym każdy narożnik został pomierzony
> faktycznie w terenie. Pomijam już fakt, że plik dxf przekazany
> projektantowi z takimi "okręgami" wygląda co najmniej dziwnie, nie
> wspominając że przy rozbiciu bloków tworzy się zlepek odcinków. Dlatego
> przyłączam się do prośby o wprowadzenie funkcjonalności umożliwiającej
> wybór w jaki sposób okręgi/łuki bę
> dą prezentowane.


Teraz pytanie do codera czy jest w ogole taka możliwość ?

> Odnośnie podstawy prawnej wprost do okręgów to raczej się jej nie znajdzie,
> ale można by się przy okazji zapytać jaka jest podstawa prawna do
> prezentacji graficznej odcinka/ linii (linia prosta teoretycznie też
> mogłaby się składać z n-odcinków, ale póki co nikt nie wpadł na pomysł,
> żeby takie pytanie zadawać GGK bo kto wie jaka byłaby odpowiedź
> )Ustawodawcy raczej nie przeszło przez myśl, że można sobie aż tak
> bardzo życie komplikować i obiekty zamiast okręgów przedstawiać poligonem z
> n ilością węzłów. Natomiast co do samej podstawy prawnej w protokole
> weryfikacji to można wskazać na rozbieżność w kształcie pomierzonego
> obiektu zawartego w pliku w odniesieniu do jego prezentacji graficznej na
> szkicu polowym i opisującymi taki obiekt współrzędnymi (tzn. środkiem
> okręgu). No chyba, że w operacie znajdzie się do każdego okręgu n
> współrzędnych w wykazie współrzędnych, ale wtedy tak skonstruowany obiekt
> narusza par. 18 ust. 1 gdyż nie jest zachowana generalizacja szczegółów
> terenowych. Ponadto wprowadzanie do bazy okręgów przekształconych do
> wieloboków nie pozwoli na odróżnienie w przyszłości obiektów, których obrys
> jest faktycznie wielobokiem w którym każdy narożnik został pomierzony
> faktycznie w terenie. Pomijam już fakt, że plik dxf przekazany
> projektantowi z takimi "okręgami" wygląda co najmniej dziwnie, nie
> wspominając że przy rozbiciu bloków tworzy się zlepek odcinków. Dlatego

To zgrabny wywód, ale na końcu okazuje się, że po stronie łuków mamy argumenty i emocje, a po drugiej oficjalne pismo z okrągłą pieczęcią, w którym organ odpowiedzialny za standard formatu GML zamieszcza jasną interpretację: łuków ma nie być w GML. Niestety, na polu podstaw prawnych dużo lepiej jest umocowany brak łuków.

---
Admin

> To zgrabny wywód, ale na końcu okazuje się, że po stronie łuków mamy
> argumenty i emocje, a po drugiej oficjalne pismo z okrągłą pieczęcią, w
> którym organ odpowiedzialny za standard formatu GML zamieszcza jasną
> interpretację: łuków ma nie być w GML. Niestety, na polu podstaw prawnych
> dużo lepiej jest umocowany brak łuków.

Zakaz stosowania łuków umocowany jest w przepisach prawa dokładnie tak samo jak nakaz ich stosowania - czyli tak, że przepisy tego nie regulują, natomiast reguluje logika i zdrowy rozsądek. Póki co GGK nie stanowi prawa a z jego interpretacjami przepisów ostatnio nie jest najlepiej mają na uwadze ostatnie zamieszanie z liczeniem terminów weryfikacji. W EwMapie (i kiedyś w Mikromapie) łuki i okręgi są od dawna i nie podejrzewam, aby konkurencja tworzyła oprogramowanie niezgodne z przepisami prawa. Myślę, że najlepszym konsensusem jest możliwość pozostawienia użytkownikowi Mikromapy opcji wyboru w jaki sposób rysować okręgi bez blokowania czegoś na sztywno ze świadomością, że rodzi to problemy. Liczę na przychylność w zrozumieniu problemu.

> > Odnośnie podstawy prawnej wprost do okręgów to raczej się jej nie
> znajdzie,
> > ale można by się przy okazji zapytać jaka jest podstawa prawna do
> > prezentacji graficznej odcinka/ linii (linia prosta teoretycznie też
> > mogłaby się składać z n-odcinków, ale póki co nikt nie wpadł na pomysł,
> > żeby takie pytanie zadawać GGK bo kto wie jaka byłaby odpowiedź
> > )Ustawodawcy raczej nie przeszło przez myśl, że można sobie aż tak
> > bardzo życie komplikować i obiekty zamiast okręgów przedstawiać poligonem
> z
> > n ilością węzłów. Natomiast co do samej podstawy prawnej w protokole
> > weryfikacji to można wskazać na rozbieżność w kształcie pomierzonego
> > obiektu zawartego w pliku w odniesieniu do jego prezentacji graficznej
> na
> > szkicu polowym i opisującymi taki obiekt współrzędnymi (tzn. środkiem
> > okręgu). No chyba, że w operacie znajdzie się do każdego okręgu n
> > współrzędnych w wykazie współrzędnych, ale wtedy tak skonstruowany
> obiekt
> > narusza par. 18 ust. 1 gdyż nie jest zachowana generalizacja szczegółów
> > terenowych. Ponadto wprowadzanie do bazy okręgów przekształconych do
> > wieloboków nie pozwoli na odróżnienie w przyszłości obiektów, których
> obrys
> > jest faktycznie wielobokiem w którym każdy narożnik został pomierzony
> > faktycznie w terenie. Pomijam już fakt, że plik dxf przekazany
> > projektantowi z takimi "okręgami" wygląda co najmniej dziwnie, nie
> > wspominając że przy rozbiciu bloków tworzy się zlepek odcinków. Dlatego
>
> To zgrabny wywód, ale na końcu okazuje się, że po stronie łuków mamy
> argumenty i emocje, a po drugiej oficjalne pismo z okrągłą pieczęcią, w
> którym organ odpowiedzialny za standard formatu GML zamieszcza jasną
> interpretację: łuków ma nie być w GML. Niestety, na polu podstaw prawnych
> dużo lepiej jest umocowany brak łuków.



tak więc będą te okręgi ? akurat mi to na gwałt potrzebne i nie wiem czy komnbinować coś czy czekać ?

> tak więc będą te okręgi ? akurat mi to na gwałt potrzebne i nie wiem czy
> komnbinować coś czy czekać ?

Porządne rozwiązanie wymagałoby dodania łuków do Mikromap, to poważna przeróbka
Na szybko mogę zrobić zrobić analizę wierzchołków linii przy eksporcie i zgadywać, czy tworzą one łuk czy okrąg. Będzie to działać kulawo

---
Admin

> > tak więc będą te okręgi ? akurat mi to na gwałt potrzebne i nie wiem
> czy
> > komnbinować coś czy czekać ?
>
> Porządne rozwiązanie wymagałoby dodania łuków do Mikromap, to poważna
> przeróbka
> Na szybko mogę zrobić zrobić analizę wierzchołków linii przy eksporcie i
> zgadywać, czy tworzą one łuk czy okrąg. Będzie to działać kulawo

zgadywać ?
byle do urzędu to przeszło , ale rozumiem , że to będzie działać losowo lub w ogóle nie da zamierzonego efektu .

> zgadywać ?
> byle do urzędu to przeszło , ale rozumiem , że to będzie działać losowo lub
> w ogóle nie da zamierzonego efektu .

Jak na szybko potrzebuje Pan takiej funkcjonalności, to może trzeba spróbować w innym programie który obsługuje łuki/okręgi, albo napisać tutaj na forum - może ktoś podeśle wersję MM w której okręgi były faktycznie okręgami.

> > Odnośnie podstawy prawnej wprost do okręgów to raczej się jej nie
> znajdzie,
> > ale można by się przy okazji zapytać jaka jest podstawa prawna do
> > prezentacji graficznej odcinka/ linii (linia prosta teoretycznie też
> > mogłaby się składać z n-odcinków, ale póki co nikt nie wpadł na pomysł,
> > żeby takie pytanie zadawać GGK bo kto wie jaka byłaby odpowiedź
> > )Ustawodawcy raczej nie przeszło przez myśl, że można sobie aż tak
> > bardzo życie komplikować i obiekty zamiast okręgów przedstawiać poligonem
> z
> > n ilością węzłów. Natomiast co do samej podstawy prawnej w protokole
> > weryfikacji to można wskazać na rozbieżność w kształcie pomierzonego
> > obiektu zawartego w pliku w odniesieniu do jego prezentacji graficznej
> na
> > szkicu polowym i opisującymi taki obiekt współrzędnymi (tzn. środkiem
> > okręgu). No chyba, że w operacie znajdzie się do każdego okręgu n
> > współrzędnych w wykazie współrzędnych, ale wtedy tak skonstruowany
> obiekt
> > narusza par. 18 ust. 1 gdyż nie jest zachowana generalizacja szczegółów
> > terenowych. Ponadto wprowadzanie do bazy okręgów przekształconych do
> > wieloboków nie pozwoli na odróżnienie w przyszłości obiektów, których
> obrys
> > jest faktycznie wielobokiem w którym każdy narożnik został pomierzony
> > faktycznie w terenie. Pomijam już fakt, że plik dxf przekazany
> > projektantowi z takimi "okręgami" wygląda co najmniej dziwnie, nie
> > wspominając że przy rozbiciu bloków tworzy się zlepek odcinków. Dlatego
>
> To zgrabny wywód, ale na końcu okazuje się, że po stronie łuków mamy
> argumenty i emocje, a po drugiej oficjalne pismo z okrągłą pieczęcią, w
> którym organ odpowiedzialny za standard formatu GML zamieszcza jasną
> interpretację: łuków ma nie być w GML. Niestety, na polu podstaw prawnych
> dużo lepiej jest umocowany brak łuków.

Podstawa prawna znajduje się w rozporządzeniu i schematach. Obiekty nazwijmy to 'liniowe' są poliliniami i poligonami. W schematach znajdziemy
GM_SURFACE - dla powierzchni oraz
GM_CURVE - dla linii łamanych
+ odpowiedniki dla wariantów 'multi'.
Teraz co to jest? Typy zdefiniowane przez specyfikacje OGC ISO 19107 / ISO 19136.
Warto zerknąć do środka ale np GM_CURVE może zawierać:
GM_ARC - łuki
GM_Circle - okręgi
GM_SplineCurve - krzywe beziera
GM_Clothoid - klotoidy
GM_LineString - linie

Podobnie przy powierzchniach.

Gugik wydał zalecenia, które są niezgodne z zapisami obowiązujących przepisów prawnych. Dlaczego je wydał? Ponieważ odpowiedź była wydawana jeszcze za naszego geodezyjnego celebryty Izdebskiego, którego oprogramowanie nie ma łuków... (ale okręgi chyba ma?) prawie na pewno chodziło mu wyłącznie o łuki. Konkludując warto by ich zapytać teraz czy ciągle 'zalecają' tak samo

> Teraz co to jest? Typy zdefiniowane przez specyfikacje OGC ISO 19107 / ISO
> 19136.
> Warto zerknąć do środka ale np GM_CURVE może zawierać:
> GM_ARC - łuki
> GM_Circle - okręgi
> GM_SplineCurve - krzywe beziera
> GM_Clothoid - klotoidy
> GM_LineString - linie

I sam Pan widzi, że nie da się stosować dosłownie tej specyfikacji, jest zbyt szeroka. Biorąc ją dosłownie mógłbym podefiniowac łuki krzywymi Bezie'ra i powodzenia z odczytem w ośrodku.

---
Admin

> może ktoś podeśle wersję MM w której okręgi były faktycznie
> okręgami.

Sam chętnie taką wersję bym obejrzał

---
Admin

> > może ktoś podeśle wersję MM w której okręgi były faktycznie
> > okręgami.
>
> Sam chętnie taką wersję bym obejrzał

Postaram się odnaleźć i przesłać.

> > Teraz co to jest? Typy zdefiniowane przez specyfikacje OGC ISO 19107 /
> ISO
> > 19136.
> > Warto zerknąć do środka ale np GM_CURVE może zawierać:
> > GM_ARC - łuki
> > GM_Circle - okręgi
> > GM_SplineCurve - krzywe beziera
> > GM_Clothoid - klotoidy
> > GM_LineString - linie
>
> I sam Pan widzi, że nie da się stosować dosłownie tej specyfikacji, jest
> zbyt szeroka. Biorąc ją dosłownie mógłbym podefiniowac łuki krzywymi
> Bezie'ra i powodzenia z odczytem w ośrodku.

Nie sądziłem, że będzie bardziej politycznie "uważaj co powiesz bo je przekręcą".
W teorii gdyby ktoś się uparł to owszem otwieramy puszkę pandory. Bo dlaczego nie? Schemat mówi wyraźnie to to i to. No i tu wchodzi logika podstawowymi stosowanymi typami geometrii są punkty, linie, łuki i okręgi. Większość producentów je stosuje i tak zapisuje dane w bazach. ALE prędzej należałoby wprowadzić klotoidy (bo np Turbomapa się na nei uparła) niż likwidować łuki bo Izdebski nie umie ich robić w programie.

Załącznik nr 1 do rozporządzenia BDOT i MZ określa:
"WYKAZ OBIEKTÓW BAZY BDOT500 WRAZ Z DOZWOLONYMI TYPAMI GEOMETRII:
- punkt, multipunkt, linia łamana, multilinia, poligon i multipoligon.
Dla krawężników jest dopuszczalna tylko linia łamana, dla pozostałych, oprócz rowu, tylko poligony.

Podobnie jest dla bazy GESUT.

Nie ma tam informacji "obiekty liniowe", tylko dopuszczalnym typem geometrii jest "linia łamana".

Teraz możemy się spierać czy linia łamana może być , okręgiem, łukiem itd.
Dla mnie okrąg i łuk to NIE jest linia łamana.

Pozdrawiam

> Załącznik nr 1 do rozporządzenia BDOT i MZ określa:
> "WYKAZ OBIEKTÓW BAZY BDOT500 WRAZ Z DOZWOLONYMI TYPAMI GEOMETRII:
> - punkt, multipunkt, linia łamana, multilinia, poligon i multipoligon.
> Dla krawężników jest dopuszczalna tylko linia łamana, dla pozostałych,
> oprócz rowu, tylko poligony.
>
> Podobnie jest dla bazy GESUT.
>
> Nie ma tam informacji "obiekty liniowe", tylko dopuszczalnym typem
> geometrii jest "linia łamana".
>
> Teraz możemy się spierać czy linia łamana może być , okręgiem, łukiem itd.
>
> Dla mnie okrąg i łuk to NIE jest linia łamana.
>
> Pozdrawiam

Polskojęzyczne nazewnictwo niestety może być czasem mylące. Tutaj z pomocą przychodzi schemat w którym jest CURVE który przetłumaczony został na LINIA ŁAMANA. Gdyby intencją prawodawcy było ograniczenie geometrii do prostych odcinków wybrana została by jedna precyzyjna geometria LineString. Tu nie ma się o co spierać. Niestety czasem ograniczona wiedza na temat GML i jego typów generuje tego typu niepotrzebne spory.

Pisze Pan, że Łuk to nie linia łamana... ale tak Łuk może wchodzić w skład linii łamanej. Bo stosując polskie nazewnictwo wprost to w LINII ŁAMANEJ nie można by zamieścić pojedynczego odcinka - w końcu nie jest on nigdzie 'Łamany'.

> > > > > > Witam czy problem został jakoś trwale rozwiązany ? znowu mam
> taki
> > > > problem
> > > > > z
> > > > > > ośrodkiem , że chcą okrąg jedna linia nie odcinkami . Czy
> została
> > > > dodana
> > > > > > opcja aby np komory podziemne o zadanym promieniu rysować
> okręgiem
> > > nie
> > > > > > odcinkami ? Kiedyś pisaliśmy ,że fajnie było by dodać funkcje w
> > > której
> > > > > > bedzie wybór czy okra rysujemy okręgiem czy odcinkami
> > > > >
> > > > > W Mikromap od dawna przyjęliśmy, że wszelkie łuki będą rysowane
> > > > łamanymi,
> > > > > nie mamy obiektów typu okrąg czy łuk, musielibyśmy to dopiero
> > dorobić.
> > >
> > > > > Ale na szczęście nie musimy, gdyż GGK wydał interpretację
> > zabraniającą
> > > > > używania łuków w GML, ośrodek nie ma prawa tego żądać.
> > > > >
> > > > > Proszę wydrukować to pismo i przedstawić w Ośrodku:
> > > > > https://geoforum.pl/upload2/files/211223-pismo-ggk-g-rp.pdf
> > > > >
> > > > > Pytanie 10: Czy obiekty mogą zawierać łuki kołowe?
> > > > > Nie
> > > >
> > > > zadzwonie tam jutro do nich i im to powiem, ale te pabianice są nie
> > > > normalne. Inne ośrodki pracują też w ew mapie i nie mają takiego
> > problemu
> > > .
> > > >
> > > > Kiedyś już miałem taki problem i przerabialiście mi mikromape
> > >
> > > Mikromapa w którejś poprzedniej wersji generowała faktycznie okręgi a
> > nie
> > > linie łamane więc było to już dopracowane. Powoływane już wielokroć
> > pismo
> > > GGK odnośnie odpowiedzi na pytania nie zawiera żadnych wyjaśnień a już
> > > napewno nie zawiera podstawy prawnej. W zadanym zresztą pytaniu jest
> mowa
> > o
> > > konstruowaniu obiektów z wykorzystaniem łuków a my prosimy o możliwość
> > > rysowania okręgów, tak żeby studnia kanalizacyjna była rzeczywiście
> > > okręgiem. Cytowane pismo nie jest żadną podstawą prawną do
> udowadniania
> > > racji w PODGiK bo samo w sobie żadnej podstawy prawnej nie zawiera.
> > Geodeta
> > > mierząc studnię/ komorę kanalizacyjną pozyskuje o tym obiekcie
> > najczęściej
> > > dwie informacje tzn. jej geometryczny środek oraz średnicę i tak też
> > rysuje
> > > taki obiekt w programie za pomocą dwóch zmiennych. Nie znam
> racjonalnych
> > > powodów, dla których taki obiekt miałby się generować linią łamaną
> jako
> > > wielobok. Już pomijam fakt, że każdy węzeł(punkt) w obiekcie wnoszonym
> > do
> > > bazy bdot/egib/gesut powinien być wynikiem pomiaru geodety w terenie.
> > > Sztuczne dzielenie okręgów na linie łamane jest też sprzeczne z par.
> 18
> > > ust. 1 rozporządzenia w sprawie standardów. Dodatkowo generowanie
> plików
> > > gml z prezentacją okręgów jako zespołu odcinków generuje wiele
> wartości
> > > liczbowych (współrzędnych węzłów), które docelowo zaśmiecają bazę
> gesut.
> >
> >
> >
> >
> > tak więc nie można dodać opcji wyboru rysowania łukami czy odcinkami ?
>
> Probóje się zagłebić w temat to właśnie głownie programy stosują łuki , ale
> też w wiekszości jest możliwość wyboru .
> Turbo mapa głównie stosuje odcinki .
> Niestety ewmapa , na której wiekszość ośrodków działa stosuje łuki .

Chdziało by się powiedzieć na szczęście jest jakiś program, który umie w łuki i okręgi O zgrozo C-Geo też ma łuki - na stos!

> Polskojęzyczne nazewnictwo niestety może być czasem mylące. Tutaj z pomocą
> przychodzi schemat w którym jest CURVE który przetłumaczony został na LINIA
> ŁAMANA. Gdyby intencją prawodawcy było ograniczenie geometrii do prostych
> odcinków wybrana została by jedna precyzyjna geometria LineString. Tu nie
> ma się o co spierać. Niestety czasem ograniczona wiedza na temat GML i jego
> typów generuje tego typu niepotrzebne spory.
>
> Pisze Pan, że Łuk to nie linia łamana... ale tak Łuk może wchodzić w skład
> linii łamanej. Bo stosując polskie nazewnictwo wprost to w LINII ŁAMANEJ
> nie można by zamieścić pojedynczego odcinka - w końcu nie jest on nigdzie
> 'Łamany'.

Według polskiej definicji linii łamanej, łuk nie może wchodzić w skład linii łamanej.
Linia łamana składa się z odcinków prostych.
Jeśli w skład linii wchodzi łuk, wtedy taką linię określamy nazwą "krzywa".

Moim zdaniem błędne jest wnioskowanie, że jeśli w schemacie GML w kategorii GM_CURVE są możliwe również krzywe , to możemy je stosować. Albo powoływać się na błędy w tłumaczeniu schematu GML.
Ustawodawca napisał wprost w rozporządzeniu, że dozwolonym typem geometrii jest linia łamana.

Ograniczona wiedza na temat schematu GML nie ma w tym przypadku znaczenia.
To nie GUGIK ani Polacy wymyślili schemat GML. Rozporządzenia nie były tworzone po to, żeby obejmowały wszystkie możliwości schematu GML, tylko ze schematu GML są wykorzystywane tylko te funkcje, które są nam potrzebne do "obsługi" rozporządzenia.

Pozdrawiam

> > Polskojęzyczne nazewnictwo niestety może być czasem mylące. Tutaj z
> pomocą
> > przychodzi schemat w którym jest CURVE który przetłumaczony został na
> LINIA
> > ŁAMANA. Gdyby intencją prawodawcy było ograniczenie geometrii do
> prostych
> > odcinków wybrana została by jedna precyzyjna geometria LineString. Tu
> nie
> > ma się o co spierać. Niestety czasem ograniczona wiedza na temat GML i
> jego
> > typów generuje tego typu niepotrzebne spory.
> >
> > Pisze Pan, że Łuk to nie linia łamana... ale tak Łuk może wchodzić w
> skład
> > linii łamanej. Bo stosując polskie nazewnictwo wprost to w LINII ŁAMANEJ
> > nie można by zamieścić pojedynczego odcinka - w końcu nie jest on
> nigdzie
> > 'Łamany'.
>
> Według polskiej definicji linii łamanej, łuk nie może wchodzić w skład
> linii łamanej.
> Linia łamana składa się z odcinków prostych.
> Jeśli w skład linii wchodzi łuk, wtedy taką linię określamy nazwą "krzywa".
>
>
> Moim zdaniem błędne jest wnioskowanie, że jeśli w schemacie GML w kategorii
> GM_CURVE są możliwe również krzywe , to możemy je stosować. Albo powoływać
> się na błędy w tłumaczeniu schematu GML.
> Ustawodawca napisał wprost w rozporządzeniu, że dozwolonym typem geometrii
> jest linia łamana.
>
> Ograniczona wiedza na temat schematu GML nie ma w tym przypadku znaczenia.
> To nie GUGIK ani Polacy wymyślili schemat GML. Rozporządzenia nie były
> tworzone po to, żeby obejmowały wszystkie możliwości schematu GML, tylko ze
> schematu GML są wykorzystywane tylko te funkcje, które są nam potrzebne do
> "obsługi" rozporządzenia.
>
> Pozdrawiam

Nie, nie zupełnie nie tak. Owszem, to nie Polacy wymyślili schemat GML. Ale ustawodawca w schemacie dedykowanym pod to konkretne rozporządzenie użył typu CURVE, który powinien być przetłumaczony w rozporządzeniu jako Krzywa (słuszna uwaga) a nie linia łamana. Błędna tłumaczenie jednak nie podważa zapisów znajdujących się w schematach. I podkreślam raz jeszcze, w Naszych rodzimych schematach do tego konkretnego zastosowania.

> Nie, nie zupełnie nie tak. Owszem, to nie Polacy wymyślili schemat GML. Ale
> ustawodawca w schemacie dedykowanym pod to konkretne rozporządzenie użył
> typu CURVE, który powinien być przetłumaczony w rozporządzeniu jako Krzywa
> (słuszna uwaga) a nie linia łamana. Błędna tłumaczenie jednak nie podważa
> zapisów znajdujących się w schematach. I podkreślam raz jeszcze, w Naszych
> rodzimych schematach do tego konkretnego zastosowania.

Mogę się mylić, bo nie brałem udziału w tworzeniu rozporządzeń, ale domyślam się, że w pierwszej kolejności ustalono i zdefiniowano typy geometrii obiektów, a w następnym kroku przypisano im konkretne pojęcia i typy ze schematu GML. I jak Pan słusznie zauważył typ GM_CURVE może zawierać łuki, okręgi, linie itd. i sądzę, że dla naszej "linii łamanej" , zamiast wąskiego określenia GM_lineString twórca rozporządzenia wybrał GM_CURVE, które obejmuję więcej typów linii, w tym także naszą linię łamaną. Nie powoduje to błędnego działania schematu.
Raczej nie wiązało się to tłumaczeniem konkretnego pojęcia, tylko wybraniem odpowiedniego/dopuszczalnego pojęcia ze słownika GML do zdefiniowania konkretnego obiektu.
Więc to nie pojęcia ze słownika GML definiują nam co możemy robić, tylko rozporządzenie mówi nam jak elementy bazy BDOT, GESUT itd. mamy zapisywać za pomocą słownika GML. Jak Pan słusznie zauważył, czasami nie przekłada nam się to ładnie na dosłowne tłumaczenie, ale nie o to w tym chodzi.

Ale to są tylko moje przypuszczenia.

Pozdrawiam

> > Nie, nie zupełnie nie tak. Owszem, to nie Polacy wymyślili schemat GML.
> Ale
> > ustawodawca w schemacie dedykowanym pod to konkretne rozporządzenie użył
> > typu CURVE, który powinien być przetłumaczony w rozporządzeniu jako
> Krzywa
> > (słuszna uwaga) a nie linia łamana. Błędna tłumaczenie jednak nie
> podważa
> > zapisów znajdujących się w schematach. I podkreślam raz jeszcze, w
> Naszych
> > rodzimych schematach do tego konkretnego zastosowania.
>
> Mogę się mylić, bo nie brałem udziału w tworzeniu rozporządzeń, ale
> domyślam się, że w pierwszej kolejności ustalono i zdefiniowano typy
> geometrii obiektów, a w następnym kroku przypisano im konkretne pojęcia i
> typy ze schematu GML. I jak Pan słusznie zauważył typ GM_CURVE może
> zawierać łuki, okręgi, linie itd. i sądzę, że dla naszej "linii łamanej" ,
> zamiast wąskiego określenia GM_lineString twórca rozporządzenia wybrał
> GM_CURVE, które obejmuję więcej typów linii, w tym także naszą linię
> łamaną. Nie powoduje to błędnego działania schematu.
> Raczej nie wiązało się to tłumaczeniem konkretnego pojęcia, tylko wybraniem
> odpowiedniego/dopuszczalnego pojęcia ze słownika GML do zdefiniowania
> konkretnego obiektu.
> Więc to nie pojęcia ze słownika GML definiują nam co możemy robić, tylko
> rozporządzenie mówi nam jak elementy bazy BDOT, GESUT itd. mamy zapisywać
> za pomocą słownika GML. Jak Pan słusznie zauważył, czasami nie przekłada
> nam się to ładnie na dosłowne tłumaczenie, ale nie o to w tym chodzi.
>
> Ale to są tylko moje przypuszczenia.
>
> Pozdrawiam

Zgadzam się całkiem logiczna hipoteza, nie powiem mogło by tak być. Jednak żaden twórca oprogramowania nie może opierać się na takich wiotkich założeniach. I tutaj znowu schemat, na jego podstawie przeprowadzana jest np. pierwsza kluczowa walidacja składniowa. Jeśli w zamiarze ustawodawcy byłoby usunięcie łukow to właśnie tam, w schemacie xsd musiałoby się zawierać to ograniczenie. Inaczej to wszystko nie miałoby sensu. Dodatkowo w rozporządzeniu jest miejsce na ograniczenia. Różne atrybuty są pod tym względem sprawdzane. Gdyby intencją ustawodawcy było takie działanie mógłby nawet jeśli nie w schemacie zapisać w ograniczeniach. Nie ma czegoś takiego dlatego trudno byłoby podpierać się samą nomenklaturą "linii łamanej" ze słownika języka polskiego.

Ale gdybać możemy dalej
Kontynuując, więc "uczepilismy" się terminu linia łamana, ale jakie byłoby umocowanie niemożności stosowania łuków i okręgów w powierzchniach? Nawet jeśli przyjąć założenie skoro linie łamane nie mają łuków to powierzchnię też nie co byłoby już nadużyciem ale Ok. Tylko dlaczego okręgi miały by być wykluczone z poligonów? Bo są podobne do łukow? No bądźmy poważni.

> Kontynuując, więc "uczepilismy" się terminu linia łamana, ale jakie byłoby
> umocowanie niemożności stosowania łuków i okręgów w powierzchniach? Nawet
> jeśli przyjąć założenie skoro linie łamane nie mają łuków to powierzchnię
> też nie co byłoby już nadużyciem ale Ok. Tylko dlaczego okręgi miały by być
> wykluczone z poligonów? Bo są podobne do łukow? No bądźmy poważni.

Każdy łuk składa się z nieskończonej ilości punktów co uniemożliwia przetwarzanie przez komputery (nie posiadają nieskończonej mocy obliczeniowej). Przy generalizacji tego problemu może nie ma (o ile generalizacja jest w granicach rozsądku). Napisze ktoś że każdy odcinek prostej również tworzony jest przez n punktów i będzie miał rację lecz dla wizualizacji wystarczą dane początkowe i końcowe tego odcinka. W przypadku "idealnych" łuków jest to niemożliwe. Pozostaje kompromis generalizacji w granicach rozsądku. Mikromap robi to wystarczająco dobrze byśmy na wydruku (podglądzie) widzieli łuki dobrze wyprofilowane. Ilość węzłów jest zależna od promienia łuku względem środka okręgu którego częścią jest ten łuk.

> > Kontynuując, więc "uczepilismy" się terminu linia łamana, ale jakie
> byłoby
> > umocowanie niemożności stosowania łuków i okręgów w powierzchniach?
> Nawet
> > jeśli przyjąć założenie skoro linie łamane nie mają łuków to
> powierzchnię
> > też nie co byłoby już nadużyciem ale Ok. Tylko dlaczego okręgi miały by
> być
> > wykluczone z poligonów? Bo są podobne do łukow? No bądźmy poważni.
>
> Każdy łuk składa się z nieskończonej ilości punktów co uniemożliwia
> przetwarzanie przez komputery (nie posiadają nieskończonej mocy
> obliczeniowej). Przy generalizacji tego problemu może nie ma (o ile
> generalizacja jest w granicach rozsądku). Napisze ktoś że każdy odcinek
> prostej również tworzony jest przez n punktów i będzie miał rację lecz dla
> wizualizacji wystarczą dane początkowe i końcowe tego odcinka. W przypadku
> "idealnych" łuków jest to niemożliwe. Pozostaje kompromis generalizacji w
> granicach rozsądku. Mikromap robi to wystarczająco dobrze byśmy na wydruku
> (podglądzie) widzieli łuki dobrze wyprofilowane. Ilość węzłów jest zależna
> od promienia łuku względem środka okręgu którego częścią jest ten łuk.

Fajnie, tylko nie chodzi tutaj o wydruk czy wizualizacje, a o sposób zapisu danych. Aby zapisać łuk wystarcza 3 wartości. Aby zapisać "wystarczająco" zgeneralizowany łuk
danych musi byc więcej co nie jest optymalne w dobie wymiany danych pomiędzy różnymi systemami. Nie jest optymalne bo przy bazach jednostkowych, powiatowych, krajowych dochodzi efekt skali i trudność w przetwarzaniu takich elementów.

> > może ktoś podeśle wersję MM w której okręgi były faktycznie
> > okręgami.
>
> Sam chętnie taką wersję bym obejrzał

W wersji 5.72 okręgi były okręgami. W wersji 5.75 były już łuki. Sądzę że ostatnia wersja z okręgami to 5.73 lub 5.74. Mam wersję 5.72 z lutego 2019 z okręgami i wersję 5.75 z marca 2021 z odcinkami.

> > > Kontynuując, więc "uczepilismy" się terminu linia łamana, ale jakie
> > byłoby
> > > umocowanie niemożności stosowania łuków i okręgów w powierzchniach?
> > Nawet
> > > jeśli przyjąć założenie skoro linie łamane nie mają łuków to
> > powierzchnię
> > > też nie co byłoby już nadużyciem ale Ok. Tylko dlaczego okręgi miały
> by
> > być
> > > wykluczone z poligonów? Bo są podobne do łukow? No bądźmy poważni.
> >
> > Każdy łuk składa się z nieskończonej ilości punktów co uniemożliwia
> > przetwarzanie przez komputery (nie posiadają nieskończonej mocy
> > obliczeniowej). Przy generalizacji tego problemu może nie ma (o ile
> > generalizacja jest w granicach rozsądku). Napisze ktoś że każdy odcinek
> > prostej również tworzony jest przez n punktów i będzie miał rację lecz
> dla
> > wizualizacji wystarczą dane początkowe i końcowe tego odcinka. W
> przypadku
> > "idealnych" łuków jest to niemożliwe. Pozostaje kompromis generalizacji
> w
> > granicach rozsądku. Mikromap robi to wystarczająco dobrze byśmy na
> wydruku
> > (podglądzie) widzieli łuki dobrze wyprofilowane. Ilość węzłów jest
> zależna
> > od promienia łuku względem środka okręgu którego częścią jest ten łuk.
>
> Fajnie, tylko nie chodzi tutaj o wydruk czy wizualizacje, a o sposób zapisu
> danych. Aby zapisać łuk wystarcza 3 wartości. Aby zapisać "wystarczająco"
> zgeneralizowany łuk
> danych musi byc więcej co nie jest optymalne w dobie wymiany danych
> pomiędzy różnymi systemami. Nie jest optymalne bo przy bazach
> jednostkowych, powiatowych, krajowych dochodzi efekt skali i trudność w
> przetwarzaniu takich elementów.


Suma sumaru przechodząc do sedna . Można podważyć decyzje urzędu , który zarzuca brak stosowania łuków w pliku gml ?
Czy jedynym rozwiazaniem na ten prawny bałagan jak zawsze jest przystosowanie się do każdego urzędu i posiadanie funkcji wyboru w programie łuki/odcinki ???

> > > > Kontynuując, więc "uczepilismy" się terminu linia łamana, ale jakie
> > > byłoby
> > > > umocowanie niemożności stosowania łuków i okręgów w powierzchniach?
> > > Nawet
> > > > jeśli przyjąć założenie skoro linie łamane nie mają łuków to
> > > powierzchnię
> > > > też nie co byłoby już nadużyciem ale Ok. Tylko dlaczego okręgi miały
> > by
> > > być
> > > > wykluczone z poligonów? Bo są podobne do łukow? No bądźmy poważni.
> > >
> > > Każdy łuk składa się z nieskończonej ilości punktów co uniemożliwia
> > > przetwarzanie przez komputery (nie posiadają nieskończonej mocy
> > > obliczeniowej). Przy generalizacji tego problemu może nie ma (o ile
> > > generalizacja jest w granicach rozsądku). Napisze ktoś że każdy
> odcinek
> > > prostej również tworzony jest przez n punktów i będzie miał rację lecz
> > dla
> > > wizualizacji wystarczą dane początkowe i końcowe tego odcinka. W
> > przypadku
> > > "idealnych" łuków jest to niemożliwe. Pozostaje kompromis
> generalizacji
> > w
> > > granicach rozsądku. Mikromap robi to wystarczająco dobrze byśmy na
> > wydruku
> > > (podglądzie) widzieli łuki dobrze wyprofilowane. Ilość węzłów jest
> > zależna
> > > od promienia łuku względem środka okręgu którego częścią jest ten łuk.
> >
> > Fajnie, tylko nie chodzi tutaj o wydruk czy wizualizacje, a o sposób
> zapisu
> > danych. Aby zapisać łuk wystarcza 3 wartości. Aby zapisać
> "wystarczająco"
> > zgeneralizowany łuk
> > danych musi byc więcej co nie jest optymalne w dobie wymiany danych
> > pomiędzy różnymi systemami. Nie jest optymalne bo przy bazach
> > jednostkowych, powiatowych, krajowych dochodzi efekt skali i trudność w
> > przetwarzaniu takich elementów.
>
>
> Suma sumaru przechodząc do sedna . Można podważyć decyzje urzędu , który
> zarzuca brak stosowania łuków w pliku gml ?
> Czy jedynym rozwiazaniem na ten prawny bałagan jak zawsze jest
> przystosowanie się do każdego urzędu i posiadanie funkcji wyboru w
> programie łuki/odcinki ???


Jest taka możliwość , że jako wyjście z sytuacji zrobić w mikromapie dwie opcje ?

> > > > Kontynuując, więc "uczepilismy" się terminu linia łamana, ale jakie
> > > byłoby
> > > > umocowanie niemożności stosowania łuków i okręgów w powierzchniach?
> > > Nawet
> > > > jeśli przyjąć założenie skoro linie łamane nie mają łuków to
> > > powierzchnię
> > > > też nie co byłoby już nadużyciem ale Ok. Tylko dlaczego okręgi miały
> > by
> > > być
> > > > wykluczone z poligonów? Bo są podobne do łukow? No bądźmy poważni.
> > >
> > > Każdy łuk składa się z nieskończonej ilości punktów co uniemożliwia
> > > przetwarzanie przez komputery (nie posiadają nieskończonej mocy
> > > obliczeniowej). Przy generalizacji tego problemu może nie ma (o ile
> > > generalizacja jest w granicach rozsądku). Napisze ktoś że każdy
> odcinek
> > > prostej również tworzony jest przez n punktów i będzie miał rację lecz
> > dla
> > > wizualizacji wystarczą dane początkowe i końcowe tego odcinka. W
> > przypadku
> > > "idealnych" łuków jest to niemożliwe. Pozostaje kompromis
> generalizacji
> > w
> > > granicach rozsądku. Mikromap robi to wystarczająco dobrze byśmy na
> > wydruku
> > > (podglądzie) widzieli łuki dobrze wyprofilowane. Ilość węzłów jest
> > zależna
> > > od promienia łuku względem środka okręgu którego częścią jest ten łuk.
> >
> > Fajnie, tylko nie chodzi tutaj o wydruk czy wizualizacje, a o sposób
> zapisu
> > danych. Aby zapisać łuk wystarcza 3 wartości. Aby zapisać
> "wystarczająco"
> > zgeneralizowany łuk
> > danych musi byc więcej co nie jest optymalne w dobie wymiany danych
> > pomiędzy różnymi systemami. Nie jest optymalne bo przy bazach
> > jednostkowych, powiatowych, krajowych dochodzi efekt skali i trudność w
> > przetwarzaniu takich elementów.
>
>
> Suma sumaru przechodząc do sedna . Można podważyć decyzje urzędu , który
> zarzuca brak stosowania łuków w pliku gml ?
> Czy jedynym rozwiazaniem na ten prawny bałagan jak zawsze jest
> przystosowanie się do każdego urzędu i posiadanie funkcji wyboru w
> programie łuki/odcinki ???

Moim zdaniem można podważyć, bo w rozporządzeniu w załączniku nr 1 wprost jest napisane, że dozwolonym typem geometrii jest linia łamana (według polskiej definicji, jest to linia składająca się z odcinków prostych) oraz poligon (według polskiej definicji jest to linia łamana zamknięta).

Pozdrawiam

> > > może ktoś podeśle wersję MM w której okręgi były faktycznie
> > > okręgami.
> >
> > Sam chętnie taką wersję bym obejrzał
>
> W wersji 5.72 okręgi były okręgami. W wersji 5.75 były już łuki. Sądzę że
> ostatnia wersja z okręgami to 5.73 lub 5.74. Mam wersję 5.72 z lutego 2019
> z okręgami i wersję 5.75 z marca 2021 z odcinkami.

Zrobiliśmy możliwość eksportu okręgów, jako opcję eksportu

www.coder.pl/mikromap32.exe

---
Admin

> > > > > Kontynuując, więc "uczepilismy" się terminu linia łamana, ale
> jakie
> > > > byłoby
> > > > > umocowanie niemożności stosowania łuków i okręgów w
> powierzchniach?
> > > > Nawet
> > > > > jeśli przyjąć założenie skoro linie łamane nie mają łuków to
> > > > powierzchnię
> > > > > też nie co byłoby już nadużyciem ale Ok. Tylko dlaczego okręgi
> miały
> > > by
> > > > być
> > > > > wykluczone z poligonów? Bo są podobne do łukow? No bądźmy poważni.
> > > >
> > > > Każdy łuk składa się z nieskończonej ilości punktów co uniemożliwia
> > > > przetwarzanie przez komputery (nie posiadają nieskończonej mocy
> > > > obliczeniowej). Przy generalizacji tego problemu może nie ma (o ile
> > > > generalizacja jest w granicach rozsądku). Napisze ktoś że każdy
> > odcinek
> > > > prostej również tworzony jest przez n punktów i będzie miał rację
> lecz
> > > dla
> > > > wizualizacji wystarczą dane początkowe i końcowe tego odcinka. W
> > > przypadku
> > > > "idealnych" łuków jest to niemożliwe. Pozostaje kompromis
> > generalizacji
> > > w
> > > > granicach rozsądku. Mikromap robi to wystarczająco dobrze byśmy na
> > > wydruku
> > > > (podglądzie) widzieli łuki dobrze wyprofilowane. Ilość węzłów jest
> > > zależna
> > > > od promienia łuku względem środka okręgu którego częścią jest ten
> łuk.
> > >
> > > Fajnie, tylko nie chodzi tutaj o wydruk czy wizualizacje, a o sposób
> > zapisu
> > > danych. Aby zapisać łuk wystarcza 3 wartości. Aby zapisać
> > "wystarczająco"
> > > zgeneralizowany łuk
> > > danych musi byc więcej co nie jest optymalne w dobie wymiany danych
> > > pomiędzy różnymi systemami. Nie jest optymalne bo przy bazach
> > > jednostkowych, powiatowych, krajowych dochodzi efekt skali i trudność
> w
> > > przetwarzaniu takich elementów.
> >
> >
> > Suma sumaru przechodząc do sedna . Można podważyć decyzje urzędu ,
> który
> > zarzuca brak stosowania łuków w pliku gml ?
> > Czy jedynym rozwiazaniem na ten prawny bałagan jak zawsze jest
> > przystosowanie się do każdego urzędu i posiadanie funkcji wyboru w
> > programie łuki/odcinki ???
>
>
> Jest taka możliwość , że jako wyjście z sytuacji zrobić w mikromapie dwie
> opcje ?

Z kolei moim zdaniem nie ma takiej możliwości z uwagi na schematy stanowiące podstawę późniejszych walidacji. Z uwagi na schematy łuk nie może zostać zgłoszony jako błąd podczas walidacji pliku. To z kolei umożliwia ich stosowanie.

> > > > > Kontynuując, więc "uczepilismy" się terminu linia łamana, ale
> jakie
> > > > byłoby
> > > > > umocowanie niemożności stosowania łuków i okręgów w
> powierzchniach?
> > > > Nawet
> > > > > jeśli przyjąć założenie skoro linie łamane nie mają łuków to
> > > > powierzchnię
> > > > > też nie co byłoby już nadużyciem ale Ok. Tylko dlaczego okręgi
> miały
> > > by
> > > > być
> > > > > wykluczone z poligonów? Bo są podobne do łukow? No bądźmy poważni.
> > > >
> > > > Każdy łuk składa się z nieskończonej ilości punktów co uniemożliwia
> > > > przetwarzanie przez komputery (nie posiadają nieskończonej mocy
> > > > obliczeniowej). Przy generalizacji tego problemu może nie ma (o ile
> > > > generalizacja jest w granicach rozsądku). Napisze ktoś że każdy
> > odcinek
> > > > prostej również tworzony jest przez n punktów i będzie miał rację
> lecz
> > > dla
> > > > wizualizacji wystarczą dane początkowe i końcowe tego odcinka. W
> > > przypadku
> > > > "idealnych" łuków jest to niemożliwe. Pozostaje kompromis
> > generalizacji
> > > w
> > > > granicach rozsądku. Mikromap robi to wystarczająco dobrze byśmy na
> > > wydruku
> > > > (podglądzie) widzieli łuki dobrze wyprofilowane. Ilość węzłów jest
> > > zależna
> > > > od promienia łuku względem środka okręgu którego częścią jest ten
> łuk.
> > >
> > > Fajnie, tylko nie chodzi tutaj o wydruk czy wizualizacje, a o sposób
> > zapisu
> > > danych. Aby zapisać łuk wystarcza 3 wartości. Aby zapisać
> > "wystarczająco"
> > > zgeneralizowany łuk
> > > danych musi byc więcej co nie jest optymalne w dobie wymiany danych
> > > pomiędzy różnymi systemami. Nie jest optymalne bo przy bazach
> > > jednostkowych, powiatowych, krajowych dochodzi efekt skali i trudność
> w
> > > przetwarzaniu takich elementów.
> >
> >
> > Suma sumaru przechodząc do sedna . Można podważyć decyzje urzędu ,
> który
> > zarzuca brak stosowania łuków w pliku gml ?
> > Czy jedynym rozwiazaniem na ten prawny bałagan jak zawsze jest
> > przystosowanie się do każdego urzędu i posiadanie funkcji wyboru w
> > programie łuki/odcinki ???
>
> Moim zdaniem można podważyć, bo w rozporządzeniu w załączniku nr 1 wprost
> jest napisane, że dozwolonym typem geometrii jest linia łamana (według
> polskiej definicji, jest to linia składająca się z odcinków prostych) oraz
> poligon (według polskiej definicji jest to linia łamana zamknięta).
>
> Pozdrawiam

Moim zdaniem nie ponieważ nie wynika to ze schematów załączonych do rozporządzeń a na podstawie których odbywają się walidację przedmiotowych plików.
Dodatkowo mielibyśmy jeśli posiłkować się polska definicja linii łamanej (a przynajmniej wyżej przytaczana jej interpretacja która należało by jeszcze zweryfikować) to w bazie gestu i bdot nikt nie ma prawa wprowadzić obiektu składającego się z jednego odcinka (dwóch współrzędnych). Ponieważ zgodnie z tą definicją pojedyncza linia nie jest linia łamana, jest wg polskiej definicja (i tu proszę usiąść) jest odcinkiem.

> > > > > > Kontynuując, więc "uczepilismy" się terminu linia łamana, ale
> > jakie
> > > > > byłoby
> > > > > > umocowanie niemożności stosowania łuków i okręgów w
> > powierzchniach?
> > > > > Nawet
> > > > > > jeśli przyjąć założenie skoro linie łamane nie mają łuków to
> > > > > powierzchnię
> > > > > > też nie co byłoby już nadużyciem ale Ok. Tylko dlaczego okręgi
> > miały
> > > > by
> > > > > być
> > > > > > wykluczone z poligonów? Bo są podobne do łukow? No bądźmy
> poważni.
> > > > >
> > > > > Każdy łuk składa się z nieskończonej ilości punktów co
> uniemożliwia
> > > > > przetwarzanie przez komputery (nie posiadają nieskończonej mocy
> > > > > obliczeniowej). Przy generalizacji tego problemu może nie ma (o
> ile
> > > > > generalizacja jest w granicach rozsądku). Napisze ktoś że każdy
> > > odcinek
> > > > > prostej również tworzony jest przez n punktów i będzie miał rację
> > lecz
> > > > dla
> > > > > wizualizacji wystarczą dane początkowe i końcowe tego odcinka. W
> > > > przypadku
> > > > > "idealnych" łuków jest to niemożliwe. Pozostaje kompromis
> > > generalizacji
> > > > w
> > > > > granicach rozsądku. Mikromap robi to wystarczająco dobrze byśmy na
> > > > wydruku
> > > > > (podglądzie) widzieli łuki dobrze wyprofilowane. Ilość węzłów jest
> > > > zależna
> > > > > od promienia łuku względem środka okręgu którego częścią jest ten
> > łuk.
> > > >
> > > > Fajnie, tylko nie chodzi tutaj o wydruk czy wizualizacje, a o sposób
> > > zapisu
> > > > danych. Aby zapisać łuk wystarcza 3 wartości. Aby zapisać
> > > "wystarczająco"
> > > > zgeneralizowany łuk
> > > > danych musi byc więcej co nie jest optymalne w dobie wymiany danych
> > > > pomiędzy różnymi systemami. Nie jest optymalne bo przy bazach
> > > > jednostkowych, powiatowych, krajowych dochodzi efekt skali i
> trudność
> > w
> > > > przetwarzaniu takich elementów.
> > >
> > >
> > > Suma sumaru przechodząc do sedna . Można podważyć decyzje urzędu ,
> > który
> > > zarzuca brak stosowania łuków w pliku gml ?
> > > Czy jedynym rozwiazaniem na ten prawny bałagan jak zawsze jest
> > > przystosowanie się do każdego urzędu i posiadanie funkcji wyboru w
> > > programie łuki/odcinki ???
> >
> > Moim zdaniem można podważyć, bo w rozporządzeniu w załączniku nr 1
> wprost
> > jest napisane, że dozwolonym typem geometrii jest linia łamana (według
> > polskiej definicji, jest to linia składająca się z odcinków prostych)
> oraz
> > poligon (według polskiej definicji jest to linia łamana zamknięta).
> >
> > Pozdrawiam
>
> Moim zdaniem nie ponieważ nie wynika to ze schematów załączonych do
> rozporządzeń a na podstawie których odbywają się walidację przedmiotowych
> plików.
> Dodatkowo mielibyśmy jeśli posiłkować się polska definicja linii łamanej (a
> przynajmniej wyżej przytaczana jej interpretacja która należało by jeszcze
> zweryfikować) to w bazie gestu i bdot nikt nie ma prawa wprowadzić obiektu
> składającego się z jednego odcinka (dwóch współrzędnych). Ponieważ zgodnie
> z tą definicją pojedyncza linia nie jest linia łamana, jest wg polskiej
> definicja (i tu proszę usiąść) jest odcinkiem.



w takim razie jak to w polskim prawie bezsensowane jest spieranie się z ośrodkiem.
Czy jest możliwe , aby Coder dodał funkcje , która dała by możliwość wyboru w jaki sposób chcemy rysować okrąg ?

> > > > > > > Kontynuując, więc "uczepilismy" się terminu linia łamana, ale
> > > jakie
> > > > > > byłoby
> > > > > > > umocowanie niemożności stosowania łuków i okręgów w
> > > powierzchniach?
> > > > > > Nawet
> > > > > > > jeśli przyjąć założenie skoro linie łamane nie mają łuków to
> > > > > > powierzchnię
> > > > > > > też nie co byłoby już nadużyciem ale Ok. Tylko dlaczego okręgi
> > > miały
> > > > > by
> > > > > > być
> > > > > > > wykluczone z poligonów? Bo są podobne do łukow? No bądźmy
> > poważni.
> > > > > >
> > > > > > Każdy łuk składa się z nieskończonej ilości punktów co
> > uniemożliwia
> > > > > > przetwarzanie przez komputery (nie posiadają nieskończonej mocy
> > > > > > obliczeniowej). Przy generalizacji tego problemu może nie ma (o
> > ile
> > > > > > generalizacja jest w granicach rozsądku). Napisze ktoś że każdy
> > > > odcinek
> > > > > > prostej również tworzony jest przez n punktów i będzie miał
> rację
> > > lecz
> > > > > dla
> > > > > > wizualizacji wystarczą dane początkowe i końcowe tego odcinka. W
> > > > > przypadku
> > > > > > "idealnych" łuków jest to niemożliwe. Pozostaje kompromis
> > > > generalizacji
> > > > > w
> > > > > > granicach rozsądku. Mikromap robi to wystarczająco dobrze byśmy
> na
> > > > > wydruku
> > > > > > (podglądzie) widzieli łuki dobrze wyprofilowane. Ilość węzłów
> jest
> > > > > zależna
> > > > > > od promienia łuku względem środka okręgu którego częścią jest
> ten
> > > łuk.
> > > > >
> > > > > Fajnie, tylko nie chodzi tutaj o wydruk czy wizualizacje, a o
> sposób
> > > > zapisu
> > > > > danych. Aby zapisać łuk wystarcza 3 wartości. Aby zapisać
> > > > "wystarczająco"
> > > > > zgeneralizowany łuk
> > > > > danych musi byc więcej co nie jest optymalne w dobie wymiany
> danych
> > > > > pomiędzy różnymi systemami. Nie jest optymalne bo przy bazach
> > > > > jednostkowych, powiatowych, krajowych dochodzi efekt skali i
> > trudność
> > > w
> > > > > przetwarzaniu takich elementów.
> > > >
> > > >
> > > > Suma sumaru przechodząc do sedna . Można podważyć decyzje urzędu ,
> > > który
> > > > zarzuca brak stosowania łuków w pliku gml ?
> > > > Czy jedynym rozwiazaniem na ten prawny bałagan jak zawsze jest
> > > > przystosowanie się do każdego urzędu i posiadanie funkcji wyboru w
> > > > programie łuki/odcinki ???
> > >
> > > Moim zdaniem można podważyć, bo w rozporządzeniu w załączniku nr 1
> > wprost
> > > jest napisane, że dozwolonym typem geometrii jest linia łamana (według
> > > polskiej definicji, jest to linia składająca się z odcinków prostych)
> > oraz
> > > poligon (według polskiej definicji jest to linia łamana zamknięta).
> > >
> > > Pozdrawiam
> >
> > Moim zdaniem nie ponieważ nie wynika to ze schematów załączonych do
> > rozporządzeń a na podstawie których odbywają się walidację
> przedmiotowych
> > plików.
> > Dodatkowo mielibyśmy jeśli posiłkować się polska definicja linii łamanej
> (a
> > przynajmniej wyżej przytaczana jej interpretacja która należało by
> jeszcze
> > zweryfikować) to w bazie gestu i bdot nikt nie ma prawa wprowadzić
> obiektu
> > składającego się z jednego odcinka (dwóch współrzędnych). Ponieważ
> zgodnie
> > z tą definicją pojedyncza linia nie jest linia łamana, jest wg polskiej
> > definicja (i tu proszę usiąść) jest odcinkiem.
>
>
>
> w takim razie jak to w polskim prawie bezsensowane jest spieranie się z
> ośrodkiem.
> Czy jest możliwe , aby Coder dodał funkcje , która dała by możliwość wyboru
> w jaki sposób chcemy rysować okrąg ?

Już dodana

> > > > > > > > Kontynuując, więc "uczepilismy" się terminu linia łamana,
> ale
> > > > jakie
> > > > > > > byłoby
> > > > > > > > umocowanie niemożności stosowania łuków i okręgów w
> > > > powierzchniach?
> > > > > > > Nawet
> > > > > > > > jeśli przyjąć założenie skoro linie łamane nie mają łuków to
> > > > > > > powierzchnię
> > > > > > > > też nie co byłoby już nadużyciem ale Ok. Tylko dlaczego
> okręgi
> > > > miały
> > > > > > by
> > > > > > > być
> > > > > > > > wykluczone z poligonów? Bo są podobne do łukow? No bądźmy
> > > poważni.
> > > > > > >
> > > > > > > Każdy łuk składa się z nieskończonej ilości punktów co
> > > uniemożliwia
> > > > > > > przetwarzanie przez komputery (nie posiadają nieskończonej
> mocy
> > > > > > > obliczeniowej). Przy generalizacji tego problemu może nie ma
> (o
> > > ile
> > > > > > > generalizacja jest w granicach rozsądku). Napisze ktoś że
> każdy
> > > > > odcinek
> > > > > > > prostej również tworzony jest przez n punktów i będzie miał
> > rację
> > > > lecz
> > > > > > dla
> > > > > > > wizualizacji wystarczą dane początkowe i końcowe tego odcinka.
> W
> > > > > > przypadku
> > > > > > > "idealnych" łuków jest to niemożliwe. Pozostaje kompromis
> > > > > generalizacji
> > > > > > w
> > > > > > > granicach rozsądku. Mikromap robi to wystarczająco dobrze
> byśmy
> > na
> > > > > > wydruku
> > > > > > > (podglądzie) widzieli łuki dobrze wyprofilowane. Ilość węzłów
> > jest
> > > > > > zależna
> > > > > > > od promienia łuku względem środka okręgu którego częścią jest
> > ten
> > > > łuk.
> > > > > >
> > > > > > Fajnie, tylko nie chodzi tutaj o wydruk czy wizualizacje, a o
> > sposób
> > > > > zapisu
> > > > > > danych. Aby zapisać łuk wystarcza 3 wartości. Aby zapisać
> > > > > "wystarczająco"
> > > > > > zgeneralizowany łuk
> > > > > > danych musi byc więcej co nie jest optymalne w dobie wymiany
> > danych
> > > > > > pomiędzy różnymi systemami. Nie jest optymalne bo przy bazach
> > > > > > jednostkowych, powiatowych, krajowych dochodzi efekt skali i
> > > trudność
> > > > w
> > > > > > przetwarzaniu takich elementów.
> > > > >
> > > > >
> > > > > Suma sumaru przechodząc do sedna . Można podważyć decyzje urzędu
> ,
> > > > który
> > > > > zarzuca brak stosowania łuków w pliku gml ?
> > > > > Czy jedynym rozwiazaniem na ten prawny bałagan jak zawsze jest
> > > > > przystosowanie się do każdego urzędu i posiadanie funkcji wyboru w
> > > > > programie łuki/odcinki ???
> > > >
> > > > Moim zdaniem można podważyć, bo w rozporządzeniu w załączniku nr 1
> > > wprost
> > > > jest napisane, że dozwolonym typem geometrii jest linia łamana
> (według
> > > > polskiej definicji, jest to linia składająca się z odcinków
> prostych)
> > > oraz
> > > > poligon (według polskiej definicji jest to linia łamana zamknięta).
> > > >
> > > > Pozdrawiam
> > >
> > > Moim zdaniem nie ponieważ nie wynika to ze schematów załączonych do
> > > rozporządzeń a na podstawie których odbywają się walidację
> > przedmiotowych
> > > plików.
> > > Dodatkowo mielibyśmy jeśli posiłkować się polska definicja linii
> łamanej
> > (a
> > > przynajmniej wyżej przytaczana jej interpretacja która należało by
> > jeszcze
> > > zweryfikować) to w bazie gestu i bdot nikt nie ma prawa wprowadzić
> > obiektu
> > > składającego się z jednego odcinka (dwóch współrzędnych). Ponieważ
> > zgodnie
> > > z tą definicją pojedyncza linia nie jest linia łamana, jest wg
> polskiej
> > > definicja (i tu proszę usiąść) jest odcinkiem.
> >
> >
> >
> > w takim razie jak to w polskim prawie bezsensowane jest spieranie się z
> > ośrodkiem.
> > Czy jest możliwe , aby Coder dodał funkcje , która dała by możliwość
> wyboru
> > w jaki sposób chcemy rysować okrąg ?
>
> Już dodana

a jak ją znaleźć ?

> Moim zdaniem nie ponieważ nie wynika to ze schematów załączonych do
> rozporządzeń a na podstawie których odbywają się walidację przedmiotowych
> plików.
> Dodatkowo mielibyśmy jeśli posiłkować się polska definicja linii łamanej (a
> przynajmniej wyżej przytaczana jej interpretacja która należało by jeszcze
> zweryfikować) to w bazie gestu i bdot nikt nie ma prawa wprowadzić obiektu
> składającego się z jednego odcinka (dwóch współrzędnych). Ponieważ zgodnie
> z tą definicją pojedyncza linia nie jest linia łamana, jest wg polskiej
> definicja (i tu proszę usiąść) jest odcinkiem.

Moim zdaniem, ze schematów aplikacyjnych wynika, tylko tyle i aż tyle, że linię łamaną mamy definiować przy użyciu np GM_CURVE, co nie powoduje żadnego konfliktu, ani błędnego działania schematu.
Natomiast stosowanie łuków i okręgów stoi w sprzeczności i powoduje konflikt z załącznikiem nr 1 do rozporządzenia, który wprost definiuje zamknięty katalog dopuszczalnych figur geometrycznych.

Ujmę to w taki sposób (uwaga abstrakcyjny przykład ):
W rozporządzeniu o dozwolonych zwierzętach hodowlanych wykazane byłyby cztery konkretne zwierzęta: krowy, konie, kozy i owce. W dalszej części rozporządzenia zwierzęta te opisane byłyby jako ssaki.
I teraz według Pana argumentacji, rozporządzenie pozwala Panu hodować również tygrysy syberyjskie, bo przecież tygrys to też ssak

Przynajmniej ja tak odbieram Pana argumentację, jeśli jest inaczej proszę mnie poprawić

Pozdrawiam

> > Moim zdaniem nie ponieważ nie wynika to ze schematów załączonych do
> > rozporządzeń a na podstawie których odbywają się walidację
> przedmiotowych
> > plików.
> > Dodatkowo mielibyśmy jeśli posiłkować się polska definicja linii łamanej
> (a
> > przynajmniej wyżej przytaczana jej interpretacja która należało by
> jeszcze
> > zweryfikować) to w bazie gestu i bdot nikt nie ma prawa wprowadzić
> obiektu
> > składającego się z jednego odcinka (dwóch współrzędnych). Ponieważ
> zgodnie
> > z tą definicją pojedyncza linia nie jest linia łamana, jest wg polskiej
> > definicja (i tu proszę usiąść) jest odcinkiem.
>
> Moim zdaniem, ze schematów aplikacyjnych wynika, tylko tyle i aż tyle, że
> linię łamaną mamy definiować przy użyciu np GM_CURVE, co nie powoduje
> żadnego konfliktu, ani błędnego działania schematu.
> Natomiast stosowanie łuków i okręgów stoi w sprzeczności i powoduje
> konflikt z załącznikiem nr 1 do rozporządzenia, który wprost definiuje
> zamknięty katalog dopuszczalnych figur geometrycznych.
>
> Ujmę to w taki sposób (uwaga abstrakcyjny przykład ):
> W rozporządzeniu o dozwolonych zwierzętach hodowlanych wykazane byłyby
> cztery konkretne zwierzęta: krowy, konie, kozy i owce. W dalszej części
> rozporządzenia zwierzęta te opisane byłyby jako ssaki.
> I teraz według Pana argumentacji, rozporządzenie pozwala Panu hodować
> również tygrysy syberyjskie, bo przecież tygrys to też ssak
>
> Przynajmniej ja tak odbieram Pana argumentację, jeśli jest inaczej proszę
> mnie poprawić
>
> Pozdrawiam

Cóż za obrazowy przykład. Ok zagłębiając się w niego to proszę pamiętać, że nawet gdyby tak było w omawianym przypadku to sanepid obore nie sprawdzał by pod kątem 4 wymienionych gatunków, a właśnie pod kątem ssaków i nie wykryłby problemu z tygrysami...
Dodatkowo wspominany załącznik nie definiuje niczego wprost, tylko każe się domyślać. Nie każda definicja linii łamanej wyrzuca łuki ze swojego zbioru. Za to każda wyrzuca pojedyńczy odcinek i idąc za Pana rozumowaniem w bazie nie mogą występować obiekty zawierające pojedyncze odcinki? Wspominam o tym conajmniej trzeci raz i jeszcze się Pan do tego nie odniósł.
Ujmując to wg Pana zwierzęcej analogii, dopuszczalne są wyłącznie zwierzęta czarnej maści.

> > > > > > > > > Kontynuując, więc "uczepilismy" się terminu linia łamana,
> > ale
> > > > > jakie
> > > > > > > > byłoby
> > > > > > > > > umocowanie niemożności stosowania łuków i okręgów w
> > > > > powierzchniach?
> > > > > > > > Nawet
> > > > > > > > > jeśli przyjąć założenie skoro linie łamane nie mają łuków
> to
> > > > > > > > powierzchnię
> > > > > > > > > też nie co byłoby już nadużyciem ale Ok. Tylko dlaczego
> > okręgi
> > > > > miały
> > > > > > > by
> > > > > > > > być
> > > > > > > > > wykluczone z poligonów? Bo są podobne do łukow? No bądźmy
> > > > poważni.
> > > > > > > >
> > > > > > > > Każdy łuk składa się z nieskończonej ilości punktów co
> > > > uniemożliwia
> > > > > > > > przetwarzanie przez komputery (nie posiadają nieskończonej
> > mocy
> > > > > > > > obliczeniowej). Przy generalizacji tego problemu może nie ma
> > (o
> > > > ile
> > > > > > > > generalizacja jest w granicach rozsądku). Napisze ktoś że
> > każdy
> > > > > > odcinek
> > > > > > > > prostej również tworzony jest przez n punktów i będzie miał
> > > rację
> > > > > lecz
> > > > > > > dla
> > > > > > > > wizualizacji wystarczą dane początkowe i końcowe tego
> odcinka.
> > W
> > > > > > > przypadku
> > > > > > > > "idealnych" łuków jest to niemożliwe. Pozostaje kompromis
> > > > > > generalizacji
> > > > > > > w
> > > > > > > > granicach rozsądku. Mikromap robi to wystarczająco dobrze
> > byśmy
> > > na
> > > > > > > wydruku
> > > > > > > > (podglądzie) widzieli łuki dobrze wyprofilowane. Ilość
> węzłów
> > > jest
> > > > > > > zależna
> > > > > > > > od promienia łuku względem środka okręgu którego częścią
> jest
> > > ten
> > > > > łuk.
> > > > > > >
> > > > > > > Fajnie, tylko nie chodzi tutaj o wydruk czy wizualizacje, a o
> > > sposób
> > > > > > zapisu
> > > > > > > danych. Aby zapisać łuk wystarcza 3 wartości. Aby zapisać
> > > > > > "wystarczająco"
> > > > > > > zgeneralizowany łuk
> > > > > > > danych musi byc więcej co nie jest optymalne w dobie wymiany
> > > danych
> > > > > > > pomiędzy różnymi systemami. Nie jest optymalne bo przy bazach
> > > > > > > jednostkowych, powiatowych, krajowych dochodzi efekt skali i
> > > > trudność
> > > > > w
> > > > > > > przetwarzaniu takich elementów.
> > > > > >
> > > > > >
> > > > > > Suma sumaru przechodząc do sedna . Można podważyć decyzje urzędu
>
> > ,
> > > > > który
> > > > > > zarzuca brak stosowania łuków w pliku gml ?
> > > > > > Czy jedynym rozwiazaniem na ten prawny bałagan jak zawsze jest
> > > > > > przystosowanie się do każdego urzędu i posiadanie funkcji wyboru
> w
> > > > > > programie łuki/odcinki ???
> > > > >
> > > > > Moim zdaniem można podważyć, bo w rozporządzeniu w załączniku nr 1
> > > > wprost
> > > > > jest napisane, że dozwolonym typem geometrii jest linia łamana
> > (według
> > > > > polskiej definicji, jest to linia składająca się z odcinków
> > prostych)
> > > > oraz
> > > > > poligon (według polskiej definicji jest to linia łamana
> zamknięta).
> > > > >
> > > > > Pozdrawiam
> > > >
> > > > Moim zdaniem nie ponieważ nie wynika to ze schematów załączonych do
> > > > rozporządzeń a na podstawie których odbywają się walidację
> > > przedmiotowych
> > > > plików.
> > > > Dodatkowo mielibyśmy jeśli posiłkować się polska definicja linii
> > łamanej
> > > (a
> > > > przynajmniej wyżej przytaczana jej interpretacja która należało by
> > > jeszcze
> > > > zweryfikować) to w bazie gestu i bdot nikt nie ma prawa wprowadzić
> > > obiektu
> > > > składającego się z jednego odcinka (dwóch współrzędnych). Ponieważ
> > > zgodnie
> > > > z tą definicją pojedyncza linia nie jest linia łamana, jest wg
> > polskiej
> > > > definicja (i tu proszę usiąść) jest odcinkiem.
> > >
> > >
> > >
> > > w takim razie jak to w polskim prawie bezsensowane jest spieranie się
> z
> > > ośrodkiem.
> > > Czy jest możliwe , aby Coder dodał funkcje , która dała by możliwość
> > wyboru
> > > w jaki sposób chcemy rysować okrąg ?
> >
> > Już dodana
>
> a jak ją znaleźć ?

Linkuje od Admina:

Zrobiliśmy możliwość eksportu okręgów, jako opcję eksportu

www.coder.pl/mikromap32.exe

> Cóż za obrazowy przykład. Ok zagłębiając się w niego to proszę pamiętać, że
> nawet gdyby tak było w omawianym przypadku to sanepid obore nie sprawdzał
> by pod kątem 4 wymienionych gatunków, a właśnie pod kątem ssaków i nie
> wykryłby problemu z tygrysami...
> Dodatkowo wspominany załącznik nie definiuje niczego wprost, tylko każe się
> domyślać. Nie każda definicja linii łamanej wyrzuca łuki ze swojego zbioru.
> Za to każda wyrzuca pojedynczy odcinek i idąc za Pana rozumowaniem w bazie
> nie mogą występować obiekty zawierające pojedyncze odcinki? Wspominam o tym
> co najmniej trzeci raz i jeszcze się Pan do tego nie odniósł.
> Ujmując to wg Pana zwierzęcej analogii, dopuszczalne są wyłącznie zwierzęta
> czarnej maści.

Jeśli chodzi o odcinki, to zgadzam się z Pana wnioskami, że nie powinno się ich stosować. Absurd, ale tak wynika z przepisu.
Jeśli chodzi o załącznik, to tytuł załącznika oraz tabela tam zamieszczona dla mnie jest jasna i klarowna.
Ma Pan rację, z tym, że trzeba się domyślać co oznacza linia łamana, poligon itd. , bo w rozporządzeniu nie podano ich definicji.

W przypadku, gdy powstaje spór, co do znaczenia jakiegoś słowa użytego w rozporządzeniu bądź ustawie, sądy administracyjne rozstrzygają spór opierając się na oficjalnych słownikach języka polskiego.
Wszystkie słowniki języka polskiego jakie przejrzałem, jednoznacznie definiują co to jest linia łamana.
Jeśli Pan ma inny pogląd na linię łamaną, proszę nie mieć do mnie pretensji, nie ja jej użyłem w rozporządzeniu i nie ja wymyśliłem jej definicję w słownikach.


Rozporządzenie w sprawie BDOT i mapy zasadniczej z 2015 dopuszczało stosowanie takich elementów m.in. jak "punkt, linia, powierzchnia" więc jako linię można było też stosować linie zawierające łuki i krzywe.
W rozporządzeniu z 2021 jest inaczej.

Pozdrawiam

> > Cóż za obrazowy przykład. Ok zagłębiając się w niego to proszę pamiętać,
> że
> > nawet gdyby tak było w omawianym przypadku to sanepid obore nie
> sprawdzał
> > by pod kątem 4 wymienionych gatunków, a właśnie pod kątem ssaków i nie
> > wykryłby problemu z tygrysami...
> > Dodatkowo wspominany załącznik nie definiuje niczego wprost, tylko każe
> się
> > domyślać. Nie każda definicja linii łamanej wyrzuca łuki ze swojego
> zbioru.
> > Za to każda wyrzuca pojedynczy odcinek i idąc za Pana rozumowaniem w
> bazie
> > nie mogą występować obiekty zawierające pojedyncze odcinki? Wspominam o
> tym
> > co najmniej trzeci raz i jeszcze się Pan do tego nie odniósł.
> > Ujmując to wg Pana zwierzęcej analogii, dopuszczalne są wyłącznie
> zwierzęta
> > czarnej maści.
>
> Jeśli chodzi o odcinki, to zgadzam się z Pana wnioskami, że nie powinno się
> ich stosować. Absurd, ale tak wynika z przepisu.
> Jeśli chodzi o załącznik, to tytuł załącznika oraz tabela tam zamieszczona
> dla mnie jest jasna i klarowna.
> Ma Pan rację, z tym, że trzeba się domyślać co oznacza linia łamana,
> poligon itd. , bo w rozporządzeniu nie podano ich definicji.
>
> W przypadku, gdy powstaje spór, co do znaczenia jakiegoś słowa użytego w
> rozporządzeniu bądź ustawie, sądy administracyjne rozstrzygają spór
> opierając się na oficjalnych słownikach języka polskiego.
> Wszystkie słowniki języka polskiego jakie przejrzałem, jednoznacznie
> definiują co to jest linia łamana.
> Jeśli Pan ma inny pogląd na linię łamaną, proszę nie mieć do mnie
> pretensji, nie ja jej użyłem w rozporządzeniu i nie ja wymyśliłem jej
> definicję w słownikach.
>
>
> Rozporządzenie w sprawie BDOT i mapy zasadniczej z 2015 dopuszczało
> stosowanie takich elementów m.in. jak "punkt, linia, powierzchnia" więc
> jako linię można było też stosować linie zawierające łuki i krzywe.
> W rozporządzeniu z 2021 jest inaczej.
>
> Pozdrawiam

Myśli Pan, że celowo przemycono tam tę nieszczęsną linię łamaną? Rzeczywiście nie można tego wykluczyć. Ależ by to było działanie podstępem! Ale sprytu nie można by odmówić.

Dziękuję za przeprowadzony dialog! Wyjątkowo cenne i rzadkie doświadczenie. Niestety żadna większa konkluzja z tego nie wynika może prócz takiej, że póki nie będzie tzw. dobrej woli każda ze stron może okopywać się w swoich argumentach, których jak chyba pokazaliśmy nie brakuje

Pozdrawiam

> Dziękuję za przeprowadzony dialog! Wyjątkowo cenne i rzadkie doświadczenie.
> Niestety żadna większa konkluzja z tego nie wynika może prócz takiej, że
> póki nie będzie tzw. dobrej woli każda ze stron może okopywać się w swoich
> argumentach, których jak chyba pokazaliśmy nie brakuje
>
> Pozdrawiam

Również dziękuję i serdecznie pozdrawiam

Jaka by nie była ostateczne konkluzja, to należą się podziękowania dla CODER za wprowadzenie zmian satysfakcjonujących dla każdej ze stron. Dziękujemy.

> Jaka by nie była ostateczne konkluzja, to należą się podziękowania dla
> CODER za wprowadzenie zmian satysfakcjonujących dla każdej ze stron.
> Dziękujemy.

Tak święta prawda . Bardzo dziękujemy za pomoc i dołożenie funkcji . Czy to już bedzię standard i w każdej nastepnej wersji mikromapy bedzie ta wersja ? bo widze ,że na stronie nie ma tej wersji . Tylko ta wersja z linku z tej rozmowy ma tą funkcje.

> > Jaka by nie była ostateczne konkluzja, to należą się podziękowania dla
> > CODER za wprowadzenie zmian satysfakcjonujących dla każdej ze stron.
> > Dziękujemy.
>
> Tak święta prawda . Bardzo dziękujemy za pomoc i dołożenie funkcji . Czy to
> już bedzię standard i w każdej nastepnej wersji mikromapy bedzie ta wersja
> ? bo widze ,że na stronie nie ma tej wersji . Tylko ta wersja z linku z
> tej rozmowy ma tą funkcje.

Tak, zostanie. To rozwiązanie ma sporo wad, z których największą jest wydłużenie czasu eksportu, ale skoro jest opcją, nie musi się jej używać.

---
Admin