CODER

Witam!
Kochamy MM, ale niestety PODGIK -ki wybierają Turbomap, MM nie wczytuje plików kcd, a import dxf czy dwg generowanych z Turbomap opuszcza wiele znaków, np. kropki rzędnych terenowych, zasuwy domowe. Czy można liczyć na rozwiązanie tego problemu w przyszłości, może z płatną aktualizacją MM ?

> Witam!
> Kochamy MM, ale niestety PODGIK -ki wybierają Turbomap, MM nie wczytuje
> plików kcd, a import dxf czy dwg generowanych z Turbomap opuszcza wiele
> znaków, np. kropki rzędnych terenowych, zasuwy domowe. Czy można liczyć na
> rozwiązanie tego problemu w przyszłości, może z płatną aktualizacją MM ?

Formatu KCD na pewno nie uda się dorobić, kilka razy już prosiłem tą firmę o udostępnienie dokumentacji tego formatu, bez rezultatu.
DXF łatwo można dostosować do wymagań Turbomap, tak jak zrobiliśmy z Ewmapą, o ile nie będzie tak, że każdy ośrodek wprowadza własne zmiany i ulepszenia. Proszę o przesłanie przykładowego pliku, rozpoznam problemy.

A co z GML? Od dwóch bodajże lat jest to bezwzględnie obowiązujący format wymiany danych w Polsce.

---
Admin

> > Witam!
> > Kochamy MM, ale niestety PODGIK -ki wybierają Turbomap, MM nie wczytuje
> > plików kcd, a import dxf czy dwg generowanych z Turbomap opuszcza wiele
> > znaków, np. kropki rzędnych terenowych, zasuwy domowe. Czy można liczyć
> na
> > rozwiązanie tego problemu w przyszłości, może z płatną aktualizacją MM
> ?
>
> Formatu KCD na pewno nie uda się dorobić, kilka razy już prosiłem tą firmę
> o udostępnienie dokumentacji tego formatu, bez rezultatu.
> DXF łatwo można dostosować do wymagań Turbomap, tak jak zrobiliśmy z
> Ewmapą, o ile nie będzie tak, że każdy ośrodek wprowadza własne zmiany i
> ulepszenia. Proszę o przesłanie przykładowego pliku, rozpoznam problemy.
>
> A co z GML? Od dwóch bodajże lat jest to bezwzględnie obowiązujący format
> wymiany danych w Polsce.

ROZPORZĄDZENIE RADY MINISTRÓW z dnia 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności, minimalnych wymagań dla rejestrów publicznych i wymiany informacji w postaci elektronicznej oraz minimalnych wymagań dla systemów teleinformatycznych (Dz.U z 2012r. poz.526), załącznik nr 3 nie przewiduje formatu *.kcd jako format wymiany danych geodezyjnych. Najlepiej niech autor Turbomapy dostosuje się do formatów wymienionych w tym załączniku, tak aby wszystkie obiekty wraz z atrybutami i ich wartościami były wiernie odwzorowane z *.kcd . (Turbomap mało nie kosztuje, pozostaje pytanie tabakiera do nosa, czy nos do tabakiery?)
Verbatim

> ROZPORZĄDZENIE RADY MINISTRÓW z dnia 12 kwietnia 2012 r. w sprawie
> Krajowych Ram Interoperacyjności, minimalnych wymagań dla rejestrów
> publicznych i wymiany informacji w postaci elektronicznej oraz minimalnych
> wymagań dla systemów teleinformatycznych (Dz.U z 2012r. poz.526), załącznik
> nr 3 nie przewiduje formatu *.kcd jako format wymiany danych geodezyjnych.
> Najlepiej niech autor Turbomapy dostosuje się do formatów wymienionych w
> tym załączniku, tak aby wszystkie obiekty wraz z atrybutami i ich
> wartościami były wiernie odwzorowane z *.kcd . (Turbomap mało nie kosztuje,
> pozostaje pytanie tabakiera do nosa, czy nos do tabakiery?)
> Verbatim

GML'a też tam nie ma.

> GML'a też tam nie ma.

Trochę wysiłku kolego nie zaszkodzi.
Jest w załączniku nr 2
Przejrzyj wszystkie załączniki i zapoznaj się jakie formaty obowiązują w przestrzeni publicznej w RP.
Verbatim

> > Witam!
> > Kochamy MM, ale niestety PODGIK -ki wybierają Turbomap, MM nie wczytuje
> > plików kcd, a import dxf czy dwg generowanych z Turbomap opuszcza wiele
> > znaków, np. kropki rzędnych terenowych, zasuwy domowe. Czy można liczyć
> na
> > rozwiązanie tego problemu w przyszłości, może z płatną aktualizacją MM
> ?
>
> Formatu KCD na pewno nie uda się dorobić, kilka razy już prosiłem tą firmę
> o udostępnienie dokumentacji tego formatu, bez rezultatu.
> DXF łatwo można dostosować do wymagań Turbomap, tak jak zrobiliśmy z
> Ewmapą, o ile nie będzie tak, że każdy ośrodek wprowadza własne zmiany i
> ulepszenia. Proszę o przesłanie przykładowego pliku, rozpoznam problemy.
>
> A co z GML? Od dwóch bodajże lat jest to bezwzględnie obowiązujący format
> wymiany danych w Polsce.

System EWID2007, w skład którego wchodzi TURBOMAP, potrafi generować GML. W taki formacie wydaje chociażby dane EGiB w postaci geometrycznej i opisowej, więc czemu nie BDOT500 i GESUT? Mam swoją teorię. Dane zawarte w bazach powiatowych (BDOT500 i GESUT) nie są dostosowane do eksportu do GML i to cała tajemnica. Wcisnęli się z buciorami ze swoim produktem robiąc byle jakie konwersje dotychczasowych numerycznych map zasadniczych, byle wyglądało i działało i teraz będą wyciągać dodatkową kasę za przerobienie tych baz do umożliwiającej eksport do GML... albo geodeci zrobią to "przy okazji" swoich prac.
Także posłuchajcie... CODER nie jest w stanie dostosować importu nawet jakby dostał specyfikację formatu, gdyż zawartość tych baz jest niezgodna z przepisami. Zamiast obiektów BDOT500 i GESUT byłyby pseudo warstwy po EWMAPACH, GEOMAPACH i innych zagarniętych.

> > > Witam!
> > > Kochamy MM, ale niestety PODGIK -ki wybierają Turbomap, MM nie
> wczytuje
> > > plików kcd, a import dxf czy dwg generowanych z Turbomap opuszcza
> wiele
> > > znaków, np. kropki rzędnych terenowych, zasuwy domowe. Czy można
> liczyć
> > na
> > > rozwiązanie tego problemu w przyszłości, może z płatną aktualizacją MM
> > ?
> >
> > Formatu KCD na pewno nie uda się dorobić, kilka razy już prosiłem tą
> firmę
> > o udostępnienie dokumentacji tego formatu, bez rezultatu.
> > DXF łatwo można dostosować do wymagań Turbomap, tak jak zrobiliśmy z
> > Ewmapą, o ile nie będzie tak, że każdy ośrodek wprowadza własne zmiany i
> > ulepszenia. Proszę o przesłanie przykładowego pliku, rozpoznam problemy.
> >
> > A co z GML? Od dwóch bodajże lat jest to bezwzględnie obowiązujący
> format
> > wymiany danych w Polsce.
>
> System EWID2007, w skład którego wchodzi TURBOMAP, potrafi generować GML. W
> taki formacie wydaje chociażby dane EGiB w postaci geometrycznej i
> opisowej, więc czemu nie BDOT500 i GESUT? Mam swoją teorię. Dane zawarte w
> bazach powiatowych (BDOT500 i GESUT) nie są dostosowane do eksportu do GML
> i to cała tajemnica. Wcisnęli się z buciorami ze swoim produktem robiąc
> byle jakie konwersje dotychczasowych numerycznych map zasadniczych, byle
> wyglądało i działało i teraz będą wyciągać dodatkową kasę za przerobienie
> tych baz do umożliwiającej eksport do GML... albo geodeci zrobią to "przy
> okazji" swoich prac.
> Także posłuchajcie... CODER nie jest w stanie dostosować importu nawet
> jakby dostał specyfikację formatu, gdyż zawartość tych baz jest niezgodna z
> przepisami. Zamiast obiektów BDOT500 i GESUT byłyby pseudo warstwy po
> EWMAPACH, GEOMAPACH i innych zagarniętych.
Słusznie prawi.