Dobrý den,v Civilu 3D 2010 (se service packem - tusim SP2) se pokouším vložit model terénu a ortofoto z Google Earth. Používám pro to příkaz ImportGEData. V Civilu mám nastavený souřadný systém "Czech/JTSK.Krovak". Importované ortofoto ale nesedí na DKM, kterou v tom místě mám a je zaručeně dobře. Vložené ortofoto je vzhledem k DKM natočené a v jiném měřítku. Dokonce jsou jinak i měřítka rastru X a Y. Na disku obrázky deformované nejsou, tedy je to až vložením v AutoCadu. Otočení celého rastru je o cca 6°. Když dám ImportGEMesh, tak mnohúhelníková síť má hranice trochu jinak než importovaný model TIN. Nicméně natočení přibližně odpovídá realitě. Ortofoto je ale prostě špatně. Google Earth mám verze 5.1.3533.1731.Ortofoto a hranice terénu po importu také neleží na sobě, což působí vyloženě nevěrohodně.

Také by mne vlastně zajímalo jak to teď je? Tento http://www.civil3d.cz/2009/06/zeme-5x-se-uz-pro-c3d-netoci.html článek již pozbyl platnosti, nebo problém stále přetvává? Respektive tento http://www.civil3d.cz/2009/09/lze-ulozit-wms-katastralni-mapy.html o trochu novější článek se již o tom problému nezmiňuje... Nebo se ten problém při použití Plex.Earth Tools vyřeší?Venca802010-01-28 12:12:15

Ten úhel 6º odpovídá zhruba rozdílu S-JTSK a severojižnímu směru.

U nas je ten rozdil uhlu cca 7.6°, takze to skutecne radove odpovida. Nicmene to nevysvetluje tu deformaci rastru (ImportGEimage) a to, ze hranice rastru (ImportGEimage), importovane 3D site (ImportGEmesh) a TIN povrchu (ImportGESurface) jsou rozdilne. Otoceni 3D site a TIN povrchu by odpovidalo skutecnosti a i jejich rozmer vypada realne, ale neni to jak zkontrolovat. To, ze hranice TIN a 3D site  nejsou stejne pusobi neduveryhodne. Nevite, jestli je to jen problem JTSK, nebo to blbe importuje i do jinych systemu?Je rozdil vysek v Google Earth a v Baltskem systemu konstantni (samozrejme chapu omezenou presnost zjednoduseneho terenu v Google Earth).
alfred2010-01-28 12:52:19

Pánové, je to tak, že tato funkce v C3D i ve verzi 2010 nefunguje stále, jak by měla. Proto oba moje výše zmiňované články včetně hrobečku platí.  Chyba je na straně Google a nejsme schopni to zatím zdárně vyřešit. Proto nabízíme aplikaci Plex.earth, která tento problém obchází po svém a funguje bez problémů. Pro zájemce bližší info zde. Export projektu do GE je v pořádku.Přesnost výšek je závislá na konkrétním území. Oveřil bych si to hrubě alespoň na mapy.cz nebo na geoportal.cenia.cz.

V článku píšete, že import povrchu nefunguje konkrétně do JTSK. Nebylo by to možné obejít přes jiný souřadný systém a teprve pak to převést v AutoCadu? Určitě si to vyzkouším, ale bohužel se souřadnými systémy a převody v Civilu moc zkušeností nemám, takže můžu pohořet na jiných neznalostech. Předpokládám, že pokud by funkce vůbec nefungovala, tak by jí Autodesk z programu odstranil...alfred2010-01-28 21:10:07

Dobrý den,co se týká jiných souřadných systémů nemám k nim bohužel moc podkladů...můžeme vyzkoušet WGS84. Ale v našich podmínkách je JTSK nejobvyklejší. Celá tato operace (vkládání obrázků) by měla být z hlediska uživatele co nejjednodušší a tím převádění z jednoho souřadného systému do druhého, výměna čb obrázku a barevný, spasování na sebe atd. úplně není...proto jdeme jinou cestou. Vaši poslední větu musím nechat bohužel bez komentáře...

A umi PlexEarth nacist model terenu, nebo jen snimky? O terenu jsem v popisu programu nenasel zminku.Vaši poslední větu můžu klidně dle libosti okomentovat....

V této verzi načítá jen snímky...s těmi povrchy to není taková sranda, protože GE limituje množství stažených dat, ale jednal jsem o tom.