Niestety, nie domykają się

a dlaczego?
drzewiej mogła

Zalezy mi tylko na "kreskach" i sybolice zgodnej z rozp2021.

No raczej droga nie może być linią łamaną ;-). tylko poligonem .
A tak poważnie jeżeli wspł. się domykają na tym samym ptk. to ręcznie jest to do zrobienia

Nie, nie chodzi o łuki,
Objekt jezdnia OTKJ powinienien byc według rozporządzenia poligonem a w pliku GML z Turmomapy jest linią (<gml:Curve <gml:LineStringSegment>)

czy maja państwo sposób jak to obejść?
Chodzi mi tylko o poprawna geometrie z symboliką, atrybuty zostawiam na zaś.

Ewmapa obsługuje łuki kołowe, ale czy zaimportuje takowe z GML?

Ewmapa obsługiwała i nadal obsługuje łuki. No chyba, że mówimy o klotoidach, spiralach, parabolach itp. , to wtedy zdecydowanie nie.

dzień dobry,
Cos sie zmieniło, polepszyło w kwestii importu z Turbomapy?
Mam plik gml z błędna geommetrią (np. jezdnie są krzywymi a nie poligonem), ewmapa tego nie zaimportuje.

Cytat: Ema w Piątek 25 Sierpień 2023, 11:15:29Niestety, już kilka razy podejmowałam próbę importu gml do EWMapy z Turbomap. Za każdym razem porażka. Dzień dzisiejszy także przyniósł niepowodzenie. Udało mi się zaimportwać bdot i egib (pojedynczo), niestety gesut generuje takie błędy:

Import nie został przeprowadzony z powodu błędów:

GESUT - Nieodpowiedni rodzaj geometrii dla obiektu: PL.PZGiK.x

Co ciekawe, plik wyświetla się na geoportalu geobidu. Ktoś ma pomysł jak to zaimportować? Ptaszek importuj bez geomaterii i importuj mimo konfliktu zaptaszkowane.

Poszukaj obiektu, który ma nieprawidłową geometrie i :
a) wystąp do operatora Turbomapy, żeby poprawił jego geometrię
b) doprowadź plik do tego aby opcja "importuj bez geometrii" mogła zadziałać - czyli usuń błędną geometrię tego obiektu:)

Niestety, już kilka razy podejmowałam próbę importu gml do EWMapy z Turbomap. Za każdym razem porażka. Dzień dzisiejszy także przyniósł niepowodzenie. Udało mi się zaimportwać bdot i egib (pojedynczo), niestety gesut generuje takie błędy:

Import nie został przeprowadzony z powodu błędów:

GESUT - Nieodpowiedni rodzaj geometrii dla obiektu: PL.PZGiK.x

Co ciekawe, plik wyświetla się na geoportalu geobidu. Ktoś ma pomysł jak to zaimportować? Ptaszek importuj bez geomaterii i importuj mimo konfliktu zaptaszkowane.

Ponieważ nie mam Ewmapy, załadowałem ten GML do C-GEO i wyeksportowałem do GML 2021. Wynik wczytałem na geoportal Geobidu .
Przy imporcie było dużo ostrzeżeń o błędach (np. brakujące atrybuty zrodlo, rzedna, itd. - nie było ich już w oryginalnym GML). Mimo tych błędów mapa na geoportalu została wygenerowana. Oczywiście nie polecam takiego przechodzenia między dwoma systemami PZGiK za pośrednictwem trzeciego oprogramowania. Zbyt dużo jest różnic w interpretacji przepisów i modeli danych w tych systemach by wynik był bezstratny.
Ponadto jestem pewien, że próba aktualizacji danych w Ewmapie na podstawie tego GML po konwersji w C-GEO nie zakończy się sukcesem przy imporcie do TurboEwid. Powód - jak wyżej.
Gdyby nasze geodezyjne urzędy: centralny, wojewódzkie i powiatowe były dobrze zarządzane i nadzorowane, takich sytuacji by nie było. Żaden ODGiK nie mógłby wydawać i potem żądać danych w różnych formatach i standardach w procesie aktualizacji mapy zasadniczej. Byłby wówczas w Polsce jeden, ten sam system do obsługi PZGiK w każdym ODGiK, który wydawałby i przyjmował GML zgodnie z przepisami niezależnie od lokalizacji.
Administracji jednak na tym specjalnie nie zależy, a twórcy systemów informatycznych nie będą podcinać gałęzi na której siedzą. Poza tym producenci realizują zamówienia na opracowanie systemów na podstawie przepisów, o których jakości wszystkim zainteresowanym wiadomo.

To chyba nie potrafię tego przez c-Geo ogarnąć.

Cytat: support w Czwartek 10 Sierpień 2023, 12:17:17Justek zobacz czy wejdzie ci ten plik

w przypadku obu plików gml znów mam podobne błędy importu

Konwersja ewmapą jest tak dopracowana, że PODGiK'i mogą ją robić własnymi środkami. Może nie jest całkiem "bezkosztowe", bo ośrodki dokumentacji nie muszą przeznaczać na to kwot wyrażonych w biletach narodowego banku polskiego, ale trzeba wyłączyć z bieżących działań jedną czy dwie ogarnięte osoby. Praca kosztuje ileś roboczogodzin (warunkiem łagodnego przejścia na rozporządzenie 2021 jest poprawne prowadzenie baz wg rozporządzenia 2015).
Wniosek z tego jest taki, że albo w PODGiK, z którego pochodzą "problematyczne" gml'e boryka się z jakimś bliżej nieokreślonym niedowładem, albo oprogramowanie w PODGiK jest ułomne. Myślę, że tą kwestię powinien rozstrzygnąć lokalny WINGiK.
Dla mnie nie do pomyślenie jest, żeby wykonawca musiał robić "kombinacje alpejskie" żeby wgrać dane do swojej bazy roboczej. Nie do pomyślenia jest też to, by wykonawca brał dane zgodne z rozporządzeniem 2015, a oddawał w 2021.

Cytat: Cezary.K w Czwartek 10 Sierpień 2023, 23:16:58Nie bardzo rozumiem, jakim sposobem można prowadzić jedną bazę zgodnie z dwoma różnymi rozporządzeniami? Nie wiem, czym kierowała się osoba decyzyjna w PODGiK, żeby do takiej sytuacji dopuścić. Może jestem za mało lotny, żeby to rozumem ogarnąć

wspaniała geomatyka i jej webewid pozwala na takie kwiatki. więcej: (nie pamiętam czy tu, czy na coder) ktoś napisał, że jeden z ośrodków chce aby zmodyfikowany gml oddawać w nowej wersji, konwertując na nowe rozporządzenie. czyli tak jak napisał Pan Sowa -> rączkami wykonawców. więc legislator miał rację: zmiana nie pociągnie kosztów po stronie starostw

Cytat: Cezary.K w Czwartek 10 Sierpień 2023, 23:16:58Nie bardzo rozumiem, jakim sposobem można prowadzić jedną bazę zgodnie z dwoma różnymi rozporządzeniami? Nie wiem, czym kierowała się osoba decyzyjna w PODGiK, żeby do takiej sytuacji dopuścić. Może jestem za mało lotny, żeby to rozumem ogarnąć

Ktoś mógł kierować się naiwna argumentacją że konwersja jest bezkosztowa więc pewnie najbardziej bezkosztowa wydała się tej osobie konwersja rękami wykonawców 🙃