W ewmapie jest taka funkcja, trzeba wejść przez Przeglądarkę obiektów, zaznaczyć pewną grupę obiektów np. punkty naturalne o określonej wysokości a następnie kliknąć grupowa modyfikacja danych,

ale jak każda zmiana z poziomu programu musi być zrobiona z jakimś operatem. Tzn wszystkie obiekty z wysokością będą miały dopięty nowy operat, a ten aktualny stanie się archiwalnym. Jest to pewne utrudnienie w pracy z taką bazą.

W rozwiązaniach z arkuszem kalk. można dowolnie ustalić operat, np. pozostawić aktualny.


równoległe odpowiadanie na posty ma też pewne ograniczenia... hihi
Po tej czynności można ograniczyć precyzję zapisu (SQL'em) dla niektórych obiektów.
z tym dodawaniem 13 czy 10 cm to już kiedyś dyskutowaliśmy.

w czasie edycji obiektu pod PPM jest menu gdzie możesz dodać lub odjąć jakieś elementy obiektu leżące na warstwach z listy (por. Cezary.K)
W ten sposób możesz dodać elementy z różnych warstw, ale tak samo możesz wyłączyć ten element, przenieść go na właściwą warstwę i dodać go z powrotem do obiektu. Po zapisaniu będziesz miał porządek

Znak północy z wzorca wydruku nie będzie reagował na skręcenia w Ewmapie. W tym celu trzeba by dodać taką strzałkę jako symbol na odrębnej drukowalnej warstwie w obrębie rysunku. Ta warstwa powinna mieć możliwość skręcania wydruku i wtedy strzałka ustawiona z kątem skręcenia 0 gradów, będzie zawsze wskazywała północ, niezależnie od skręcenia wydruku.

Cytat: Grzegorz92 w Poniedziałek 03 Styczeń 2022, 18:26:34
Dodatkowo np. skarpa po eksporcie nie ma wypełnienia, robiac obiekt po czym  wypełniam  ja przez generator jak to zwykle bywało dopóki nie wprowadzili obiektowania było ok

jeśli robisz wypełnienie skarpy generatorem tzn. że ta skarpa jest błędnie zbudowana. Pewnie tak jak zasugerował alcapone błąd tkwi w oznaczeniach gór dół skarpy

Jeżeli i tak część danych jest w różnym stanie to czym się tutaj przejmować?
Po prostu skasować tamte stare dane i wstawić nowe obiekty. Nic trudnego... hihi

zmiana numeracji nie jest czynnością tylko techniczną ponieważ skutkuje (przynajmniej potencjalnie) zmianami w kw.
za kilka lat będziemy robić wyjaśnienia wszystkich takich zmian numeracji, tak jak teraz robimy wyjaśnienia do zmiany numeracji działek.

rozumiem, że tą zmianę trzeba zrobić w ewopisie,
Najprościej to zrobić poprzez modernizację danych obrębu.

Jeżeli mowa o interpretacji producentów to dlaczego jest to wina rozporządzenia?
Moim zdaniem informatyk nie powinien dokonywać żadnych interpretacji. Jest napisane, że "można" to znaczy, że trzeba umieścić taką relację, ale nie tworzyć narzędzi do kontroli jej istnienia.

Ale jakich problemów się spodziewasz?
Ja nie szukam tutaj winnego, tylko sprawdzam przetargi na dostosowanie do nowego rozporządzenia.

To jest problem geodetów powiatowych, a nie wykonawców. A jeśli nie mogą mnie zmusić, bo rozporządzenie czegoś nie przewidziało to gdzie jest problem?

A dlaczego bubel? i to jeszcze tak imiennie winny znaleziony?
A może ktoś to przemyślał i faktycznie nie ma obowiązku takiego, bo tak będzie lepiej. Skoro zapisano możliwość to znaczy, że nie zapomniano.

Mój syn mówi, że bez sensu się uczyć rozwiązywania równań kwadratowych. A ja z uporem maniaka mu powtarzam, że tylko dlatego że Ty nie widzisz w tym sensu, nie świadczy, że tego sensu tam nie ma.

Ciekaw jestem co będą chcieli zrobić z takimi jak ja.
1,5 roku robię modernizację, a teraz na miesiąc przed końcem mi zmienią wersję programu... ech życie

kolejność dodawania operatu? hm chyba nie ALE

ważna jest kolejność zaznaczania checka "zmiany bezpośrednie"
To jest jakoś tak trochę dziwnie i (z obserwacji) chyba działa to tak:

1. jeśli zaznaczę check "ZB" ręcznie i dopiero przystąpię do importów to jest OK, wszystko co zaimportuję ma operaty z ośrodka, ale
2. jeśli nie zaznaczę tego haczyka i zacznę importować, to program usłużnie podpowie mi, że trzeba coś zaznaczyć. Jeśli wtedy zaznaczę "ZB" to program uzna, że mam wybrany operat "null" i taki przypisze do wszystkich elementów i obiektów importowanych.

Niestety Wykonawca nie może liczyć na to że opisy tych operatów zostaną u niego zaimportowane. Co to, to nie! same numery dostajemy.
Pewnie w pliku .emu dałoby się dodać też eksport z operatów i importować go u Wykonawcy, ale na razie tak nie jest.


Zresztą ja to czekam na to że plik emu, będzie plikiem "otwieralnym" a nie "importowalnym".
Nie muszę zakładać takich struktur jakie akurat ma tam ośrodek, Ja nie wiem czy tam jest bdot/gesut czy jeszcze się uchowały tylko warstwy, czy na bazach fb pracujemy i w jakiej wersji... Chciałbym nie musieć wiedzieć wszystkiego o bazie w podgik.
Dostałbym plik do roboty, otwieram go, zmieniam , zapisuję i oddaję. Komputer jest od tego żeby "komputował" (compute znaczy liczyć/przetwarzać) i niech to w końcu robi za mnie.

A na jakim wydruku się takie coś pojawia?

polski programisty to "normalna" klawiatura QWERTY
dziwne to są polskie "maszynistki" (QWERTZ czyli zamienione "Z" z "Y", inaczej rozmieszczone znaki diakrytyczne)

Jeżeli temat powtarza się z innymi programami to oznacza ustawienia regionalne windows.

A bazy które podłączasz są w tej samej wersji w jakiej masz zainstalowaną mapę? i z jakiej były pliki konfiguracyjne
polskie znaki to strona kodowa w jakiej jest plik zapisany. Kopiowałeś pliki czy kopiowałeś treść plików?