Ustawienia warstwy są prawidłowe. Zgodne z rozporządzeniami i zasadami redakcji mapy, więc nie muszą być zmieniane.
Skoro ta linia wyświetla się nie prawidłowo, tzn że to ta linia ma "złe" parametry. Pewnie "grubość linii" jest ustawiona jako "gruba"/"cienka" zamiast "domyślna" i dlatego jest drukowana i wyświetlana w szerokości 0.
Przestaw na domyślny i wydruki będą zgodne z założeniami rozporządzenia.

Zupełnie odrębną sprawą jest to czy powinna być możliwość edycji tych parametrów.
np. turbomap jest chwalony za to że nie popełnia się tam błędów polegających na zmienionej kolorystyce, symbolach czy rodzajach linii, bo nie da się wkleić elementów mapy niezgodnie z rozporządzeniem. Nie ma przy okazji też łatwej i prostej metody na dołożenie nowych warstw, jakichś tymczasowych ustawień itd...
W ewmapie przyzwyczailiśmy się, że możemy zmienić wszystko, ale przeciętny użytkownik mapy zasadniczej wcale tego nie docenia. Po co możliwość zmiany koloru, czy typu albo grubości linii? Jak nie ma takiej opcji to wszystko jest zgodnie z rozporządzeniem, a w przypadku zmiany prawa, program sam automatycznie zmieni na nowe poprawne wartości, bez ingerencji operatora.

W bazie, z której pochodzi ten zrzut, jakiś operator wymyślił, że on obejdzie zakaz i będzie lepszy niż system przewiduje. Znalazł lukę i w zmieniając grubość linii, spowodował, że elementy wyświetlają się niezgodnie ze schematem gml. Nie wiem po co? może taką linią były dawniej narysowane budynki nieogniodporne, albo jedne są z pomiaru, a inne z digitalizacji, albo jeszcze wiele innych lokalnych "rozszerzeń" treści mapy.
Ja daleki jestem od tego, żeby negować potrzebę dodatkowego oznaczania różnych elementów mapy. Prywatnie zgadzam się, że w zupełnie niepotrzebnych miejscach bazy bdot/gesut/egib są przeładowane, jednocześnie nie przenosząc w swojej treści różnych przydatnych informacji. Niestety pomysłów na dodatkowe oznaczenia jest kilka razy więcej niż powiatów w Polsce, bo te pomysły nie są aktualizowane w trakcie rozwoju baz i nie są ujednolicane nawet w ramach jednego ośrodka. To powoduje oczywiście później problemy takie jak w Twoim przykładzie.

Ja bym się nie przejmował i oddał wypełniając zgodnie z prawdą. Jeżeli ich program ma słownik władających to powinien dodać do słownika. PODGiK ma teraz tak dane rozpie... rzchnięte, że ten jeden władający to ich najmniejszy problem.  Jeśli będziesz o literkę inaczej miała nazwany ten podmiot, to sobie połączą, skoro decydują się na samodzielne docinanie do istniejących elementów (za co im chwała!) to ogarną też władającego siecią.

Wg ostatnich modeli danych to plik powinien się zwalidować nawet bez władającego

Cytat: Drafty w Czwartek 29 Czerwiec 2023, 08:15:03pani z ośrodka zadzwoniła do nas, że dwa dni robocze poprawiała sama nasz plik i robota przeszła. I prosi o pliki giv następnym razem...

Kawa jej się należy, a jeśli ładna to można nawet zaprosić

Trudno się z Cezarym nie zgodzić. W Ewmapie na pewno nie da się zrobić jakichś tematów.

zestaw warstw w egib, bdot czy gesut w bazach fdb jest stały i w zasadzie nie ma potrzeby aby go zmieniać. Podczas importu nie będzie w pliku żadnych nowych warstw, a parametry istniejących są stałe. Po co zatem miałaby być działająca funkcja o której piszesz?

Ze zdziwieniem potwierdzam takie zachowanie programu w v.14.11

Co ciekawe u mnie te przesunięcie zatrzasku "do przecięcia linii" zapina się 0,50m od punktu właściwego. Tak jakby miało to związek z okręgiem punktu stabilizowanego. Nie twierdzę, że zawsze tak się zapina, tylko, że u mnie nie chciało przypiąć się inaczej.

Tyle lat pracuję i nigdy na to nie natrafiłem. Ciekawostka! Fakt, że ja raczej nie używam redakcji numeracji punktów granicznych, stąd trudniej mi było zderzyć się z tym problemem z zatrzaskiem do numeru.

widoczność plamki na 20/30 metrów w słońcu... nie wiem co to za laser by musiałbyć 

A próbowałeś używać okularów obserwacyjnych? Tutaj pewnie czerwone by były potrzebne. najprostsze około 50 zł.

Cytat: mlodygeodeta w Czwartek 01 Czerwiec 2023, 11:01:00Cześć,
Mam kwadrat obłożony kostką o wymiarach 2m x 2m, w samym środku znajduje się tablica informacyjna, taka betonowa, o średnicy 1,30m i wysokości ok. 2m.

a czyli słup ogłoszeniowy...
też bym zrobił inną budowlą.

Cytat: Pan Sowa w Czwartek 25 Maj 2023, 11:02:33opcja stan na dzień nie została stworzona żeby doczytywać i nakładać na siebie kolejne stany, tylko do ładowania jednego konkretnego stanu..

wrrr a co to za powód, żeby nie działało poprawnie?
ale hasło "nie wiedzą do końca co będzie wyświetlane" to już mnie rozłożyło na łopatki...

"losowo" to na pewno nie, to w końcu tylko algorytm, ale fajnie by było spróbować zaobserwować jakąś właściwość, kiedy występują te zachowania niestandardowe.

Cytat: Lupus w Czwartek 18 Maj 2023, 20:52:39Słabo znam się na Javie, ale na algorytmach trochę tak. Ten akurat zaokrągli do najbliższej parzystej ZAWSZE, tzn nawet wtedy kiedy bliższa będzie nieparzysta. 1,5 spoko zaorkągli się do 2, ale 1,4 też się zaokrągli do 2.

zresztą tutaj popełniłem błąd, myśląc, że w js jest już funkcja roundToNearestEven(value) i zamiast poczytać co ona faktycznie robi i jak jest skonstruowana to założyłem, że robi to co mi się wydawało że powinna robić.

Cytat: Pan Sowa w Czwartek 18 Maj 2023, 21:25:33Nie no wrzuć to sobie do konsoli i potestuj. Zaokrąglanie odbywa się do 2 miejsc po przecinku. Jak dla mnie uzyskuje poprawne wyniki.

Dzisiaj miałem trochę więcej czasu i sobie potestowałem

145.365 => 145.37
145.355 => 145.35

Problem leży w tym jak komputer "zaokrągla" przy obliczeniach w systemie dwójkowym. Pół po przejściu przez 0/1 i z powrotem staje się 0,4999999999 albo 0,500000000001 a nigdy tak naprawdę 0,5. To dało by się jakoś przewidzieć, ale chyba nie ma sensu, bo jakby miało to by już dawno było policzone i zrobione, a my nie wysyłamy lotów na Marsa.

math.round to zwykłe zaokrąglanie do najbliższej całkowitej, matematyczne, czyli niestosujące się do zasad Bradisa-Kryłowa
nawet jeśli zaokrąglisz wartość pomnożoną przez 100 a wynik tego zaokrąglenia przez 100 podzielisz.

Moim zdaniem tutaj taka funkcja zda egzamin

function roundToNearestEven(value) {
  return 2 * Math.round(value *100/ 2) /100;

a w zasadzie lepiej jeszcze by było zrobić taką funkcję

function roundToNearestEven(value, ilznak) {
  return 2 * Math.round(value *10^ilznak/ 2) /10^ilznak;

wtedy możemy jeszcze regulować ile znaków po przecinku byśmy sobie życzyli.

Niezależnie czy ten algorytm działa czy nie, to jaka to różnica, że obetniesz albo zaokrąglisz do parzystej współrzędną wysokościową?
Stosowanie zasad obliczeń Bradisa-Kryłowa, w tym zaokrąglanie ma sens w geodezji tylko i wyłącznie przy wyrównaniu ścisłym oraz przy obliczaniu powierzchni działek, częściowo też zgadzam się przy obliczaniu i zaokrąglaniu współrzędnych punktów granicznych.
Działki, bo się nie będą poprawnie sumowały do powierzchni obrębu, a w zasadzie powinienem napisać, że się będą sumowały lepiej zamiast poprawnie. Ideału nie będzie i tak, ale statystycznie będzie lepiej.
Punkty graniczne tylko częściowo, bo ten jeden cm nie ma to żadnego praktycznego znaczenia, ważne jest żeby zawsze i wszystkie programy liczyły tak samo. Większe różnice są na stosowaniu poprawki odwzorowawczej, niż wynika to z problemu zaokrąglenia współrzędnej na poziomie mm

Cytat: Cezary.K w Piątek 19 Maj 2023, 08:40:40Ten aspekt uznałem za mało istotny

I ja też jestem tego zdania, dopóki mówimy o rzędnych terenu.

OK

pewnie mógłbym sobie potestować do jakiej wartości zaokrągli się 145.365, a do jakiej 145.355 pewnie z obu wyjdzie 145.36

a jakie będzie zaokrąglenie tym algorytmem wartości 145.367?

Cytat: Pan Sowa w Czwartek 18 Maj 2023, 20:41:00// Zaokrąglij wartość do 2 miejsc po przecinku według zasady najbliższej parzystej
      value = roundToNearestEven(value);

Słabo znam się na Javie, ale na algorytmach trochę tak. Ten akurat zaokrągli do najbliższej parzystej ZAWSZE, tzn nawet wtedy kiedy bliższa będzie nieparzysta. 1,5 spoko zaorkągli się do 2, ale 1,4 też się zaokrągli do 2.