.:: Ewmapa ::.

Matematyka mówi że powinno być 110.4 (reguły Bradisa Kryłowa ...czort wie jak to się pisze

Transformacja też może chyba być ...tyle że np u nas jest to przyrost h średnio o 17cm więc powinno być 110.52 = 110.5
Chyba że podgik zrobił zaokrąglanie w ewmapie co dało 110.30 ( w tej funkcji chyba nie działają reguły B-K)
Potem zrobili jakieś transformacje na Amsterdam (np. + 14cm) i wyszło 110,4

no właśnie u mnie jest dziwnie, bo mam mapę wywiadu wydrukowaną z geoportalu, gdzie rzędna na przewodzie jest 110.4 (etykieta2), PODGiK ma u siebie w informacji o obiekcie 110.35, ja mam też 110.35, a wyświetla mi się 110.3. Wyłapane przypadkiem,  moja robota nie dotyczyła inwentaryzacji eN i nic nie było w GESUT przeze mnie modyfikowane. Dla pewności jeszcze raz zaimportowałam bazę i jest to samo. Układ to Amsterdam. Chyba nie chodzi o transformację, bo gdy sama tworzę obiekt z rzędną 110.35 i etykietą2 to też mi zostawia 110.3.

W bazie PODGiK w monitorze zapytań dla bazy GESUT należy wykonać zapytanie:

select RZEDNAGORY, RZEDNADOLU from EW_OB_DD_335 where UIDO=(select UID from EW_OBIEKTY where NUMER = :"Wpisz id obiektu" and status=0)

Tak się składa, że wpisane rzędne nie są dokładnie takie, jak je wprowadzamy. Mają "dodatkowe" miejsca po przecinku. W ekstremalnych przypadkach może to powodować różnice w wyświetlaniu wartości rzędnych baz PODGiK i wykonawcy.
Kasia, daj znać, czy miałem rację 

Dziękuję za podpowiedź    to zapytanie sql-owe zadziałało, okazalo się że po przecinku jest jeszcze 12 cyfr. Nie wiem tylko dlaczego ewmapa tworzy taki ciąg cyfr, ale o to trzeba zapytać pewnie samych twórców programu. Dziękuję bardzo.