Mnohem osobnější.
Mnohem víc s vámi všemi.
Mnohem zábavnější.
Když někdo zmíní tento typ emocí u věci, nebo třeba dokonce nehmotné věci, tak to často vypadá poněkud podivně. Ten titulek je ale i s odstupem pro nás velmi výstižný. Pojďme se podívat proč.
![]() |
Photo by Shaira Dela Peña on Unsplash |
To, že technologie FME kanadské společnosti Safe Software dlouhodobě používáme na různých projektech, už musí být z různých informací, které publikujeme, docela patrné. Na našem webu toho sice nenajdete mnoho (on totiž už docela dlouhou dobu čeká na zásadní revizi, takže není velká motivace do starého něco přidávat), ale už několik let je FME přednáška pravidelnou součástí našich konferencí. Ať už jarní roadshow, kde jsme stagnující GISový rozvoj Autodesku nahradili nejen novinkami z vlastní kuchyně, ale právě i novinkami kolem FME.
FME kdysi přitáhl David Pavlíček. Tou nejpalčivější potřebou tenkrát byly konverze rastrů do formátu ECW. Klasické geoTIFFy a podobná zvěrstva sice byly vhodné pro staré desktopové aplikace (uživatel si načte pár snímků do oblasti kde pracuje), ale pro webové mapy, kde uživatel snadno zoomuje ve velkých rozsazích měřítek a pracuje s mapou, to je velmi neefektivní formát. Pomocí FME jsme slepili všechny snímky do jednoho megarastru a ten pak zkomprimovali do hierarchické waveletové reprezentace v ECW. Trvalo to přes týden, byl na to vyhrazený počítač s velkými disky a pamětí.
Kromě toho jsme používali FME na menší či větší úlohy při implementacích GIS systémů, migracích dat, atd. Jednou z těch zajímavějších úloh bylo třeba vytvoření polygonů uliční sítě. Vodárny potřebují pro odhady cen majetku dle ministerské metodiky vědět, zda se daná síť nachází pod zpevněnou nebo nezpevněnou plochou. Tato data samozřejmě historicky málokdo sbíral, tak jsme hledali způsoby, jak tuto informaci co nejlépe aproximovat. A jedním ze způsobů je z definičních čar ulic (třeba z RUIAN) odvodit polygony (fixní šířka) a protnout linie potrubí s těmito plochami. Současně to bylo využito i pro přiřazování prvků sítě do ulic. Města totiž plánují rekonstrukce podle ulic a je velmi vhodné mít možnost reportovat nebo analyzovat data právě podle příslušnosti k ulicím. Kromě odvození těch ploch je v tomto případě potřeba řešit i křižovatky, kde ta situace není vůbec jasná.
Prvním čistě FME projektem byl nástroj na automatizaci aktualizace geografické dokumentace pro Sev.en v roce 2015. Pracovníci dokumentace v dvouměsíčním cyklu ručně porovnávali aktuální databáze zájmového území a areálů společnosti s nově sebranými daty z terénního šetření a fotogrammetrie. Dodali jsme pracovní prostory FME pro detekci změn a harmonizaci vstupních dat s hlavní databází. Dopad na pracnost a kvalitu výstupu byl naprosto zásadní.
S koncem tohoto projektu se u nás hlavní iniciativy kolem FME chopil Luboš Lazar. Jako nováček přebral znalosti od Davida, který odcházel sloužit vlasti, a nejen že přebral, ale vyloženě znásobil. Ponořil se do FME naplno, udělal si certifikaci, a pro ostatní konzultanty v týmu byl od počátku FME guru a mentor na všech projektech.
![]() |
Photo by Luke Ellis-Craven on Unsplash |
Mezi migracemi dat do systémů GIS je třeba jasně vyzdvihnout BVS, kde Luboš mohl prokázat své čerstvé dovednosti. Podařilo se spojit data z několika různých zdrojů, které se více či méně překrývaly, měly jinou přesnost dat, jiné rozsahy atributů, nacházely se v několika tisícovkách výkresů. Výsledkem byla strukturovaná databáze nového GISu, topologicky čistá data a hlavně zdroje vytěžené skoro ze 100%. Daleko překročené očekávání zadavatele.
![]() |
Základní schéma datové migrace BVS |
Určitě nejde nezmínit i dvě velké integrační a automatizační implementace. První z nich je kontrola geodetických zaměření pro Innogy (dnes GasNet) pomocí FME Serveru. Uspěli jsme ve VŘ, protože jsme jako jediní dokázali dodat celé řešení na platformě FME, bez nutnosti dalšího vývoje. Zadavatel používá řešení pro automatické kontroly datových balíčků předávaných geodety. Provádí se komplexní kontrola DGN formátů a dalších přiložených souborů a metadat. Geodet má během pár vteřin odezvu na data která předal a zadavatel má jistotu čistoty dat bez nutnosti do toho ručně zasahovat.
Posledním větším dokončeným projektem byla automatizace vydávání dat z GISu do dalších systémů pro jaderné elektrárny společnosti ČEZ. Vydávají se výkresy plánů podlaží evidovaných v GIS, které tam podléhají změnovému řízení. Mají specifický standardizovaný grafický výstup do PDF, DWG a SVG a jsou opatřeny seznamy obsažených prvků a metadaty v přiložených XML souborech.
Výčet zde uvedený samozřejmě není a nemůže být kompletní. Aktuálně probíhají dva další velké FME projekty a blýská se na další.
Těch racionálních důvodů je celá řada, třeba:
![]() |
Photo by Nick Fewings on Unsplash |
Zhruba po měsíci se vracíme k sérii článků o novém systému hladin v twiGISu. V mezidobí jsme totiž měli pár neodkladných novinek k publikaci a blogové články přeci nejde psát každý den (kdo by to četl, že).
V seriálu jsme se zatím dozvěděli něco o režimech publikace hladin. Uvedli jsme si základní principy a technické možnosti. V tomto článku se podíváme na ten uživatelský konec: co se změnilo v aplikaci twiGIS pro uživatele, jak mohou nové hladiny používat.
Jako vždy pro nás bylo důležité hlavně zachovat jednoduchost a intuitivní ovládání pro laické uživatele, kterých je nejvíc a potřebují mít cestu co nejhladší. V hlavním panelu hladin proto zůstává jednoúrovňová struktura skupin a hladin, což je velmi přehledné a dobře ovladatelné na různých typech zařízení:
Teprve tlačítkem "Hladiny a styly" se uživatel dostane k podrobnému a složitému nastavení dané hladiny (rozepíšeme dále v článku). Kdo to nepotřebuje, tomu nehrozí jednoduché ukliknutí, kdo to potřebuje, má to na dva kliky.
Někomu by se zdálo, že to najednou začíná zabírat moc místa nad mapou. To samozřejmě ano, ale jen v případě, že to místo je k dispozici - na dostatečně velkém displeji. Následující animace zobrazují standardní skládání panelů twiGISu podle velikosti okna či obrazovky, a chování na mobilu.
V horní části, v sekci Zobrazení aplikace indikuje, v jakém režimu (jsme u těch režimů z dřívějších článků) aktuálně hladina funguje. Kromě toho, že to uživatel vidí, tak samozřejmě může na nějaký režim kliknout a aplikace změní měřítko mapy tak, aby se hladina do daného režimu dostala (říkali jsme si totiž, že režimy jsou vázány na měřítko).
Speciálním případem je režim Keš. U něj může uživatel volbou Použít rastr místo keše vynutit změnu režimu z kešovaných dat na online aktuální rastrová i v měřítcích, kde je keš definovaná.
Proč by to dělal? Důvody může mít dva: chce vidět aktuální nekešovaná data, nebo chce změnit nastavení hladiny v spodní sekci panelu, v sekci Hladiny.
Ta umožňuje zapínat a vypínat vnitřní podhladiny v případě, že je daná hladina tvořena kompozicí rastrových hladin ze zdroje, nebo že je tvořena několika vektorovými podhladinami (vektorová kompozice). Kromě toho také umožňuje přepínat styly vektorových hladin, pokud je stylů pro některou vektorovou hladinu (entitu) definováno více.
Na začátku animace je vidět přehledka vodovodní sítě - rychlá, kešovaná, dlaždicovaná, sdružující mnoho podhladin. Následuje přizoomování do detailu křižovatky. Po cestě se hladina automaticky přepne do Rastr online režimu (aktivují se podhladiny v panelu). Následuje zapínání/vypínání podhladin. Po odzoomování přepneme keš do online rastru i na úrovni té přehledky. Je znatelné pomalejší dotažení, ale je možné změnit nastavení kompozice (vypnout řady).
... a příště něco o vhodných strategiích nastavení režimů.
V minulém příspěvku jsme naznačovali technickou novinku, tentokrát si ji o něco přiblížíme.
Zjednodušeně: Dosáhli jsme toho, že dokážeme postavit podnikový informační systém GIS nad otevřenými produkty QGIS a PostGIS, samozřejmě s twiGISem vpředu. Se vším, co k firemnímu GISu patří!
Ta technologická cesta zahrnovala podporu databáze ze strany twiGISu, zvládnutí a metodické uchopení tvorby projektu QGIS a podnikové databáze a datové a aplikační logiky v PostGIS.
Výsledkem toho snažení však zdaleka není jen zjištění, že to jde, ale zejména zjištění, že to jde VELMI DOBŘE! A to ačkoliv je potřeba zmíněné produkty do té podnikovosti a inženýrské praxe občas trochu natlačit. To je naštěstí dobře možné díky té otevřenosti, flexibilitě, ale také naší pevné představě a vědomí, co takový systém musí umět. Výsledkem je opravdu funkční, výkonné a přitom svěží, lehké a flexibilní řešení. Jako důkaz chystáme případovou studii implementovaného řešení pro jednu významnou pražskou společnost.
Velký dík patří týmu programátorů a konzultantů, zasáhla do toho skoro každá ruka nebo hlava z divize GIS. Největší břemeno však odtahal Petr Průša. Nelze nezmínit a nepoděkovat také partě GISMentors. Jejich školení, rady a konzultace mají kvalitu i vhled, který nás posunul kupředu mnohem rychleji, než bychom se (zvláště v některých okamžicích a tématech) potáceli sami.
Samozřejmě je na stole otázka, zda tím opouštíme řešení na platformě Autodesk (AutoCAD Map 3D, oborové modely). Odpověď je, že nikoliv! Je to velmi důležitá součást našeho portfolia, významná zejména ve správě majetku s kombinací s Revit a BIM modely. Pomocí QGIS jsme jen otevřeli další cestu k určitým typům projektů a zákazníkům.
Pokud jste si rovněž v minulém videu všimli vložené videoukázky, tak tady ji máte kompletní, v celé kráse:
... a těšte se na tu případovku!
Určitě vás zajímá, kdy bude GISfórum 2020! Jak to bude se dozvíte opět ve videu. Kromě toho zde uvidíte i náhled docela zásadní technické novinky týkající se twiGIS a open source nástroje QGIS...
Příspěvky tady na blogu můžete sledovat přes RSS kanál (na konci stránky) a všechny obvyklé sociální sítě.
A nezapomeňte se nám ozvat! (tady, nebo na všech těch sítích)
To tu ještě nebylo! Ale ne ... doba nás prostě ponouká k poťouchlostem, jako je následující video.
Servisní modul twiGIS je nástroj pro odbavení (zatím) jedněch z nejpalčivějších a nejdůležitějších agend při správě majetku - provádění a evidence povinných a nezbytných prohlídek, kontrol, revizí. Doplněk GIS aplikace twiGIS, který ve videu prezentujeme na případu výtahů.
Tak a je tu pokračování. K dosavadním obvyklým režimům hladin si přidáme nějaké nové možnosti a hlavně možnosti jejich kombinace.
Tak jako se někdy v jedné rastrové hladině sejde několik různých entit (tříd, tabulek) - a je prezentována jako tzv. kompozice, může se podobná věc přihodit i u vektorů. Vektorová kompozice se chová jako jedna hladina, která je však uvnitř reprezentovaná několika dílčími vektorovými hladinami. Se všemi vlastnostmi jednotlivých vektorových hladin, tedy snapováním, možnostmi měnit styly na straně klienta, atd. Navíc je možné libovolně zapínat a vypínat jednotlivé vnitřní hladiny.
Hodí se zejména tam, kde chceme celou skupinu dat prezentovat uživatelům pro zjednodušení jako jednu hladinu, např. "Vodovod", "Základní mapa", "Cizí sítě", a přitom stále těžit z vektorové povahy dat, nebo v některých speciálních případech. V jednom z nedávných případů kolega použil kompozice na zobrazování zařízení v podzemních kolektorech. Hladina zobrazuje vlastní symbol zařízení, popisek, který má vlastní souřadnice a uživatelé jej umisťují na fixní místo, a vynášecí čáru mezi popiskem a symbolem. Data nese symbol, popisek a čára jsou pomocné (s popiskem lze ale hýbat), všechno dohromady se to chová jako jedna hladina.
Jedná se vlastně o to samé, co jsme zmiňovali v minulém článku: online či dynamické rastrové hladiny, renderované na straně serveru a poskytované do aplikace jako výsledný obrázek.
twiGIS umožňuje několik způsobů, jak tyto hladiny do klientské aplikace dostat. Prvním způsobem je režim Externí rastr, kdy je rastrový zdroj kontaktován napřímo webovou aplikací, tedy prohlížečem uživatele. Druhým je tzv. twiGIS online rastr, kdy se k poskytování dat do klienta používají serverové služby twiGISu.
Proč to odlišujeme a jaký je mezi tím rozdíl? Externí rastr je dobře použitelný např. pro veřejné neautorizované služby. Klientská aplikace stahuje např. veřejnou Ortofoto přímo z CUZK a žádným způsobem nedochází k zatěžování vlastních aplikačních serverů a zpomalování komunikace, což je u takových zdrojů je naprosto zbytečné.
Interní Online rastr se naopak používá tam, kde je vhodné přístup ke zdroji "skrýt" či autorizovat pomocí uživatelských oprávnění twiGIS. Jednoduchým případem je nakupovaná externí WMS či autorizovaná WMS našeho partnera, kdy nelze poskytnout přístupové údaje do uživatelských prohlížečů. Častějším případem jsou prostě vlastní rastrové hladiny poskytované přes vnitřní rastrový engine.
V obou případech může být rastrový zdroj jakýkoliv (WMS, WMTS, MapAgent, ...) a v obou případech může správce rozhodnout, zda budou data prezentována jako dynamicky renderované malé dlaždice (tiled) nebo tak, že se při každém pohybu mapy renderuje celý mapový výřez (singletile).
Jak jsme zmiňovali v minulém článku či dříve v tomto článku, různé režimy se chovají lépe či hůře v různých měřítcích či datových situacích. V twiGISu jsme umožnili kombinovat výhody různých režimů i nad jednou hladinou.
Definice hladiny v twiGISu probíhá tak, že založíte hladinu, řeknete, jak se bude jmenovat (např. Vodovod) a do hladiny přiřadíte datové entity - a to klidně víc než jednu (např. Potrubí, Hydrant, Uzávěr, Přípojka). Tím máme datový základ hladiny.
Aby bylo možné vůbec něco zobrazovat, je třeba hladině přiřadit definici stylu, která určí, jak budou jednotlivé prvky v mapě vypadat - na základě jejich vlastností, měřítka, atd. Prostě GISová klasika. Jako poslední věc je vhodné hladině přiřadit rastrový zdroj - tedy službu či mapový engine, který poskytuje rastrová data - viz rastrové režimy výše. (To samozřejmě není nutné, když má být hladina prezentována jen jako vektor.)
Posledním krokem je právě definice režimů, tedy způsobu, jakým je hladina v různých rozsazích měřítek prezentována uživateli. Typický příklad je takový, že v horních měřítcích se hladina chová jako rastrová keš a v dolních měřítcích jako vektor (či vektorová kompozice). Tedy dlaždice jsou tam, kde je jich relativně málo, snadno se aktualizují a skladují, ale mají velký efekt na rychlost aplikace, a vektory (či třeba nekešované online dynamické rastry) jsou tam, kde je třeba pracovat s aktuálním daty, editovat, snapovat, a správa dlaždic by už naopak byla velmi náročná.
Důležitá vlastnost je ta, že správce aplikace definuje hladinu, nastaví režimy a o zbytek se postará systém - vytvoří dlaždice kde je to třeba, automaticky uživateli přepíná režimy při používání aplikace, zajišťuje korektní chování například při výběrech (identifikaci) prvků v mapě, atd. Možné kombinace jsou technicky prakticky neomezené (reálný smysl samozřejmě dávají jen některé).
twiGIS tak dokáže velmi bezstarostně a přitom velmi efektivně zajistit publikaci téměř jakýchkoliv dat. Umí i takové kousky, že se přehledová hladina napojená na několik entit se zoomováním do detailu rozpadne na vektorovou kompozici, kde je možné s každou vektorovou entitou pracovat samostatně - měnit stylizaci, vypínat, snapovat, atd.
O různých scénářích použití a přínosech si napíšeme v dalších částech seriálu.
![]() |
Ukázková hladina v režimu rastrové keše na přehledce celého areálu. |
![]() |
Ukázková hladina v režimu online rastru při pohledu na jednotlivé budovy. |
![]() |
Ukázková hladina v režimu vektorové kompozice v detailu křížení sítě. |
twiGIS obvykle slouží jako interní firemní informační systém. Je nainstalovaný na serveru uvnitř sítě, je v doméně, díky doméně je nastaveno jednotné ověřování a SSO pomocí ActiveDirectory, atd.
Často je však potřeba tuto aplikaci používat i mimo vnitřní síť: v terénu, na mobilních zařízeních, z domova, atd. Tradiční přístupy, jak toho dosáhnout byly dosud dva:
Informace k nastavení řešení aplikační proxy a ověřování:
... tak tu máme zase vyjímečný stav, tak je možné se pořádně začíst ...
V rámci seriálu o nových možnostech publikace dat prostřednictvím mapových hladin v twiGISu začneme úplně od začátku, od vlastních mechanismů fungování hladin.V twiGISu byly historicky k dispozici dva hlavní způsoby publikace vlastních mapových dat: buď byla hladina vektorová, nebo se jednalo o tzv. dlaždicové keše. Jednalo se o dva krajní a vlastně protichůdné principy.
Základní vektorové hladiny jsou založeny vždy na jedné datové entitě (databázové tabulce), např. "Potrubí vodovodu", nebo "Místnosti". Vektorová data se načítají z databáze, do webové aplikace putují ve formě GeoJSON a vykreslují (nebo renderují, tzn. proměňují z vektorů na pixely podle dané stylizace) až v prohlížeči.
Mezi výhody patří zejména to, že aplikace v prohlížeči má k dispozici vlastní vektorová data - prvky se dají snadno a rychle vybírat a zvýrazňovat v mapě, dají se přímo editovat, je možné snadno uživatelsky měnit či přepínat stylizaci, na vektory se při editacích či měření a kreslení dají používat úchopové režimy (snapovat). Výhodou je rovněž to, že se distribuuje výkon CPU požadovaný na vykreslování na koncová zařízení.
Mezi hlavní nevýhody patří omezené možnosti stylizace, které umí prohlížeč efektivně vykreslit (typický problém "čáry s blesky" pro znázornění elektrického vedení). Vykreslování začne rovněž drhnout, když je v zobrazeném výřezu mapy těch prvků už příliš - například v přehledových mapách území, v malých měřítcích, nebo když se jedná o opravdu četná a hustá data. Čas zabere přenos vektorů na klienta i jejich vykreslení v prohlížeči.
Jedná se již o poměrně starý koncept, který vznikl zejména kvůli veřejným mapovým službám, které publikovaly poměrně malý počet hladin pro velké množství uživatelů. V takovém případě bylo velmi neefektivní vykreslovat daný mapový výřez pro každého uživatele znovu a znovu, a data byla proto předgenerována do mapových dlaždic v daném schématu (tzv. tilegrid). Zobrazení mapy v konkrétním měřítku pak znamenalo jen stažení a zobrazení potřebného množství malých obrázků, tedy akci poměrně nenáročnou, kterou zvládly tehdejší prohlížeče i první mobilní zařízení. Generování keší probíhá asynchronně na serveru, vykreslování tedy zatěžuje CPU serveru.
Pravé peklo s dlaždicemi ale nastává při potřebě jejich skladování a potřebné údržbě keší v aktuální podobě. To nemusí být problém pro nějakou obecnou podkladovou mapu, kde není příliš změn ani velká potřeba aktuálnosti. V případě dokumentace např. inženýrské sítě je ale aktuálnost keší zobrazujících průběhy potrubí a polohy zařízení dost klíčová a aktualizace se řeší i v řádu desítek minut od provedení změny v datech. Pro účel generování keší musí být na serveru nějaký renderovací software, typicky mapový server, který mění vektory na pixely podle stylizace. Plus software, který aktualizaci keší podle nějaké strategie (o tom někdy později) dokáže zajistit.
Zmíněné výhody rastrových keší spočívají zejména v jejich bleskurychlém zobrazení, bez velkého nároku na koncové zařízení. Díky serverovému renderovacímu jádru bežícímu v asynchronním režimu (tedy někdy v noci, ne když to zrovna uživatel potřebuje) je možné typicky použít bohatou stylizaci a je možné do jedné keše složit i více hladin (keš pak nereprezentuje jednu entitu, ale celou sadu entit/hladin/tabulek, třeba Vodovod, se vší strukturou uvnitř).
I nevýhody by měly být z řečeného zřejmé: jedná se zejména o náročnost údržby keší a jejich skladování. Keše jsou rovněž k dispozici jen v předem definovaných měřítcích, přičemž náročnost na čas generování a skladovací prostor roste s každým dalším detailnějším měřítkem exponenciálně (to teď víme co znamená, že?). Uživatel se tedy nemůže přizoomovat na křižovatku či budovu do měřítka 1:20, pokud předtím server nenageneroval stovky gigabajtů dat.
Další velké omezení je v tom, že tak jak jsou keše nadefinovány, tak jsou i zobrazeny. Pokud je jedna kešovaná hladina (kompozice) pro vodovod, tak z té kompozice nejdou uživatelsky "odepnout" přípojky, nebo nechat třeba jen hydranty. Navíc, když se hladiny začnou dělit, roste celkový problém kešování (s počtem hladin naštěstí jen lineárně), ale rovněž roste čas potřebný na zobrazení v aplikaci: při dvaceti zapnutých kešovaných hladinách se načítají a zobrazují stovky až tisíce dlaždic a to rozhodně není nic rychlého.
Nepříjemnou vizuální nevýhodou jsou rovněž "okrajové efekty" na přechodech mezi dlaždicemi. Řeší se to různě, ale vždy to je spíš bolest.
Po přečtení výše uvedeného je zřejmé, že ty dva uvedené principy jsou vlastně protichůdné:
WMS služby a jim příbuzné (někde se nazývají "dynamické rastrové hladiny") jsou předchůdcem a současně vlastně prerekvizitou rastrových dlaždicových keší. Fungují tak, že mapová aplikace požádá server o konkrétní výřez mapy, server jej vykreslí na základě své definice (typicky stylizace, datové zdroje) a zaslaných parametrů (třeba výčet podhladin) a vrátí aplikaci obrázek mapy a ta jej zobrazí. Tento klasický scénář byl v řadě aplikací nahrazen právě rastrovými kešemi, neboť velké množství požadavků na WMS či dynamické mapové služby znamenalo velkou zátěž na aplikační i databázový server, kde se ve špičkách nedostávalo paměti a CPU. Výhodou bylo to, že služby poskytovaly vždy aktuální data, bylo možné pracovat s podhladinami, atd. Některé mapové servery (např. MapGuide OpenSource) přitom dokáží renderovat data až s obdivuhodnou rychlostí.
Hybridní model, který však považujeme spíše za škodlivý, je takový, že mapa se vykresluje po dlaždicích, ty jsou však vždy dotazovány a online renderovány na serveru. Výsledek je sice ten, že prohlížeč si může po krátkou dobu některé dlaždice pamatovat, ale mapový server je utápěn stovkami malých dotazů.
WMTS (a příbuzné jako TMS, atp) můžeme rychle zařadit do kategorie rastrových dlaždicových hladin. Zda je to "uvnitř" keš nebo jsou dlaždice renderovány online už je na způsobu řešení, jak je zmíněno výše.
Tyto zdroje jsou v twiGISu historicky podporovány, typicky se ale používají zejména na externí mapové služby, jako veřejná ortofota, katastr, atd.
... no, to se rozepíšeme v pokračování tady na blogu. Jen si buďte jisti, že jsme na to kápli, těšte se a mějte se fajn!
Podle aktivity zde na blogu by se mohlo zdát, že nám virus neponičil chuťové buňky, ale spíše ty psací. A nebo že by snad nebylo o čem? Naštěstí ani jedno není pravda. Jen jsme se pohroužili do naší různorodé práce: vývoje produktů, zákaznických implementací, konzultací, analýz, ale přes léto rovněž i potřebného relaxu.
Takže co nás čeká? Máme velké manko v publikaci jak produktových novinek, tak zákaznických příběhů a referencí. Rádi bychom postupně vysypali ty důležité vlastnosti nového systému mapových hladin, které jsme představili při jarním vysílání LIVE2021. S dalšími a dalšími implementacemi se ukazuje, že to je opravdu unikátní způsob efektivní publikace mapových dat.
A nakonec trochu smutku: samozřejmě jsme připravovali klasické podzimní GIS Fórum, kde bychom se se všemi moc rádi setkali. Plánovali jsme termín na začátku listopadu v moc pěkné (a netradiční) lokalitě. Situace však osobním akcím nepřeje. GIS Fórum zatím nerušíme, ale zatím jsme ani neotevřeli registrace. Vymýšlíme, jak tuto výjimečnou akci nahradit.
Tedy: zůstaňte na příjmu, těšte se. Určitě je na co.💗
![]() |
Příklad trasování na síti |
Excited to see our Czech partner #CADStudio using FME's new #Revit reader to create IMDF files to get the Prague Airport into Apple Maps https://t.co/8kBLluCmjA Worth Czech'ing out for sure... pic.twitter.com/FBKF9K2VEV— Dale Lutz (@DaleAtSafe) January 6, 2020