To jedno jest poza sporem.
W myśl starej zasady, że jak nie wiadomo o co chodzi to wiadomo o co chodzi.

wg Krakowa, to nawet bardzo złą.
Ale możesz jeszcze pójść właściwą ścieżką, wystarczy, że poprosisz ich o pomoc, wystawią Ci nawet fakturę...

Problem jest nie tylko w zakresie K1. Namieszało się w bazie EGiB pod względem atrybutu ZRD. Modernizacje wykonywane pod wcześniejszymi wersjami rozporządzenia miały inaczej zdefiniowane atrybuty ZRD, których nie da się "mechanicznie" przerobić na obecną wersję. W tej sytuacji w bazie funkcjonują nie jednoznaczne atrybuty (co wg. mnie podważa ich sens) na. w wyniku aktualizacji dawniej zrobionej bazy dzisiaj wykonywanymi operatami. Protezy stosowane w programach (np. ZRD11) nie mieszczą się w słowniku.

Cały problem polega na zaimportowaniu danych z bazy (GML lub SWD) Turboewida do jakiegoś programu jako bazę roboczą do modernizacji aby później wygenerować GML do zasilenia bazy Turboewida.
A może idę złą drogą?

Akurat w tym przypadku owszem, ale problem jest jakby szerszy i może być rozpatrywany też w kierunku ewmapy

Chociaż akurat przykład z K1, moim zdaniem, jest nietrafiony, ponieważ podgik nie powinien mieć żadnych innych elementów na mapach niż te które są w rozporządzeniu. Rozumiem, że czasami są na starych mapach takie "fajne" elementy, do których wszyscy jesteśmy przyzwyczajeni i lubimy z nich korzystać. Aż żal ściska 4litery jak mam usunąć śliczny znaczek żywopłotu i zastąpić go zwykłą kreską "innego obiektu przyrodniczego", albo przez lata elegancko kreślone warstwice mam po prostu usunąć...ech jak żyć...
Jeśli jakiś ośrodek nie chcąc tracić jakichś elementów, które nie są przewidziane nowymi przepisami i w tym celu korzysta w dalszym ciągu z symboli K1 obok bazy obiektowej to czyja jest to wina? Raczej nie autorów ewmapy.

I teraz pozostaje pytanie czy "c-geo albo mikromapa przyjmie takiego mixa?" otóż przyjmie chociaż nie za pośrednictwem gml'a, bo ten format nie przewiduje przekazywania symboli z K1...

Ale rzecz dotyczy ewopisu

a czy PODGiK prowadzi kompletną obiektową bazę? ewmapa przyjmuje tylko obiekty zgodne z rozporządzeniami. jeśli PODGiK ma jeden jedyny symbol z K-1 to za chiny ludowe nie wejdzie to do ewmapy. takiego mixa przyjmie c-geo i mikromapa.

Czyli reasumując. Geobid ma program ściśle realizujący zapis schematu GML, natomiast Geomatyka trochę od tego odstąpiła. Gwarantując sobie trochę monopolu i kasy oczywiście.

Oczywiście, że to jest problem Geobidu.
Wystarczyłoby się nie trzymać tak kurczowo zapisów rozporządzenia i dopuścić nieznaczne różnice w schemacie. Zgłosić błąd niekrytyczny, obciąć część tekstu, który się nie wczytuje i nagle się okaże, że można z tego pliku korzystać. Nie będziemy mieli pełnej nazwy czy adresu Sądu rejonowego, który prowadzi tą albo inną księgę wieczystą. No i cóż się złego stało?
Autorzy C-geo wychodzą z założenia, że nie muszą zbawiać świata, tylko ich program ma działać.
Zresztą C-geo nie jest konkurencją dla ewopisu  czy turboewida. To jest program dla wykonawców. Większa różnorodność w puli klientów powoduje, że mało kogo obchodzi dlaczego się nie wczytuje ten gml. Po prostu przesiądą się na inny soft.
W przypadku Ewopisu i Ewmapy jako programów dla podgików, to już nie jest takie oczywiste, bo koszty przesiadki są ogromne.

Z tym Trboewidowym GML jest o tyle dziwnie, że nie importuje się do Ewopisu ale importuje się bez problemu do C-Geo. Więc pytanie czy to nie problem ewopisu?

Owszem. Nazywali to sobie "rozszerzone SWDE"

Dzięki Lupus za wyjaśnienie. Niestety wnioski są mało optymistyczne.. Albo schemat GML jest nie jednoznacznie opisany, albo któryś z pogromów (chyba Turboweid) nie realizuje ściśle tego schematu.  Tak na marginesie Geomatyka robiła podobne manewry z SWD

Cytat: maciekwu w Piątek 26 Luty 2021, 12:24:32
"Błąd krytyczny :Trying to store a string of length 96 into a field that can only contain 84

Niektóre zmienne za względu na ich charakter i rodzaj danych jakie przechowują mają ograniczenia ilościowe, żeby bazy nie były nadmiernie rozbudowane. (np dane typu PRAWDA/FAŁSZ można zapisać słowem 5 znaków, albo cyfrą 1/0).  Rozporządzenie definiuje dosyć dokładnie jakie dane mają być przekazywane w jakich strukturach.
Jednak żeby nie było zbyt łatwo to "krakowiacy" w swoim programie uznali, że wiedzą lepiej i niektóre dane przechowują w innych typach zmiennych niż  pozostałe firmy. Dzięki temu do ich programu dane wydane z innych wchodzą, a gml wydany z TurboEwida wczytuje się poprawnie tylko do TurboEwida.

To jest oczywiste.
Po imporcie pliku gml nowoutworzona baza przyjmuje wagę około 30Mb sądzę więc, że jakieś dane do niej przechodzą z pliku GML. Gdy otwieram bazę to brak w niej jest danych.

Plik fdb to baza firebird a nie GML
Do fdb musisz podać właściwą ścieżkę w konfiguracji baz

założyłem nową bazę i usiłuję do niej zaimportować dane z pliku GML wygenerowanego z Turboewida. Po imporcie otrzymuję raport z błędem krytycznym
"Błąd krytyczny :Trying to store a string of length 96 into a field that can only contain 84
Niezidentyfikowano obiektu : KR_ObiektKarto".
Program nie widzi żadnych danych. Waga pliku fdb jest około 30Mb.
proszę o radę jak to pokonać jeżeli się da?