Nie wiem czy ten pomysł przejdzie.
Jakby Geobid był zainteresowany udostępnianym takiej listy telefonów, to by to zrobił.
A skoro jest telefon ogólny i zanim zostaniesz połączony z właściwym pracownikiem to musisz wyłuszczyć sprawę, to pewnie jakiś powód ku temu mają.

Cytat: Kamil221 w Poniedziałek 08 Marzec 2021, 15:18:39
a moze ktos z was napisac jak prowidlowo zrobic export konturów do gmla żeby było Br-RIVa a nie (RIVa bądz Br samo albo Br pokrywajace sie z RIVa)?

Cytat: staw w Poniedziałek 08 Marzec 2021, 14:13:38
Obstawiam, że przy eksporcie do GMLa klasoużytki "rozbijane" są na kontury klasyfikacyjne i użytki gruntowe, bo tak jest zgodne z rozporządzeniem EGiB.

nie mam teraz dostępu do ewmapy, ale tam w oknie uzupełniania obrębów jest taki check o "Ignorowaniu numeracji punktów"

eee tam nie ma. Jest.
jak zaznaczysz do importu kontury, to u dołu ekranu po prawej stronie "zapali" się taka zielona fajka i przycisk kontury. Jak tam klikniesz to uzyskasz okienko z parametrami importu

Słownik nie zawiera wszystkich oznaczeń.
Można dodać ręcznie do słownika, ale łatwiej jest w zakładce kontury w imporcie zaznaczyć check "Imporotować brakujące oznaczenia konturów"

Tabelka niby ta sama, a jednak ładniejsza...

A swoją drogą to skąd się wzięła taka kolejność rejestracji przestrzeni nazw?
w kolejności wpływających wniosków?
no chyba nie powinno tak być, bo to by oznaczało, że nikt nie planował tego kto i jakie dane miałby publikować... przecież to pachnie anarchią. Napisali w ustawie, że trzeba rejestrować to rejestrują? trochę lipa...

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ę...

Plik -> Ustawienia -> Format

Wszystkie numery powiatów znajdziesz tutaj:
http://metadane.podgik.pl/ziudp.php

np dla powiatu białostockiego (ziemskiego) ta przestrzeń nazw dla egib'u to: PL.PZGiK.16.EGiB

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...

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.

Owszem. Nazywali to sobie "rozszerzone SWDE"

Ja importuję jednym plikiem. Z tym tylko, że dla budynków, które stoją na więcej niż jednej działce w pliku jest więcej niż jedna linijka z numerami działek.
Można by wyciąć przypisanie do działek i zaimportować ponownie tylko poprawne działki

delete from DZIALKI_BUDYNKI db
where db.id in (select db1.ID from dzialki_budynki db1, budynki b
where db1.status in (0,1) and db1.idbud=b.id and b.status in (0,1) and b.idobr=:OBREB)

ale to polecenie wytnie wszystkie powiązania dla wszystkich budynków w całym obrębie. Używać ostrożnie, mieć kopię bezpieczeństwa i nie mieć pretensji jak coś nie zadziała.

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.

ale w EwOpisie? to jakim sposobem  to importowałeś? "Zwykły" import działek do budynków dodaje powtarzającą się działkę? Wydawało mi się, że wtedy nie dopisuje kolejny raz... hm

Masz bazę wydaną do modernizacji czy to jest tylko roboczy plik, który nie będzie importowany?
Czy problemem są tylko powtarzające się działki czy czasem masz dwie działki dopisane ale jedna z nich jest nieprawidłowa?

Masz pełną poprawną listę działek do budynków? Wtedy można by wyciąć wszystkie wcześniejsze i zrobić jeden import na czysto.

Nie przesadzaj Czarku, kobieta też może wyciąć drzewa. W sieci pełno jest takich obrazków z dziewczętami z piłą motorową albo siekierą, tylko nie wiem czy ich stroje spełniają zasady BHP.