POI.cz - GPS Fórum pro MIO, GARMIN, TOMTOM

KML umožňuje jednu skvělou věc, umožňuje vytvářed podsložky, umí to pak využívat jak GoogleEarth, tak třeba iGo, sloučené POI by pak nebyly na jedné hromadě, ale měli by podskupiny a mohl bych hledat buďto ve všech nebo v jedné. Je velká škoda, že POI.cz téhle skvělé funkce nevyužívá.

Samozřejmě lze adresáře do sebe zanořovat, zkoušel jsem to až do 3 úrovně, iGO8 šlape perfektně.

Zde je ukázka: Je tak možné například celé poi.cz dát do jednoho osuboru a pak si vybrat co konkrétně chci zobrazovat/hledat.

Každá navigace má nějaké své speciality, třeba TomTom umožňuje pro rychlejší vyhledávání obalovat POI podle umístění. Ale tady je na všechny formáty jeden člověk, tak nemá čas řešit všechny detaily formátů. Kdyby si vzal na starosti jeden člověk jeden formát mohl by to dovést k dokonalosti. Takto můžeme jenom děkovat adminum, že máme tolik formátů a že to funguje. Investují do toho svoje peníze a čas. Nechť jim patří věčná sláva.

To ATom: To máš sice pravdu, ale KML využívá pouze pouťová omalovánka iGO 8. Já bych dal přednost tomu, kdybych měl pohromadě všechny bankomaty (např.), nezanořené, ale prostě všechny, před bankomaty sice zanořenými, ale obsahujícími tak 30% skutečnosti.
Jenže hledat ony bankomaty a dodávat je sem jako POI je práce, kdežto najít strukturu KML souboru na Google a pastnout ji sem (notabene když už to samé tady jednou je) je brnkačka, že?

Není problém, stačí poslat současný exportní filtr pro KML a strukturu tabulky a milerád upravím. A verzi PHP samozřejmě.

Tam nejsou všechny bankomaty? Minimálně ty, které používám, nabízí přímo na svých stránkách adresy všech bankomatů, stačí zadat adresu do mapy a máme souřadnice, zrovna zde bych problém neviděl, mnohem těší je to u takových restaurací, pokud nejsou zaregistrovány v někde v mapách, tak jediný způsob jak je tam dostat je ruční způsob a to je pak už opravdu nepříjemná práce a rozhodně to nemůže udělat jeden člověk.

ATom píše:...Je tak možné například celé poi.cz dát do jednoho osuboru a pak si vybrat co konkrétně chci zobrazovat/hledat.

Tak soudruzi - kontrolní otázka: Co udělá přístroj s nainstalovaným iGo 8, pokud do něj nahrajeme 100MB kml soubor s 200.000 body?

A taky bychom mohli tento server provozovat pouze v úterý, čtvrtek, sobotu a neděli a v pondělí, středu a pátek by se generoval KML soubor...

Ale to je naprostý nesmysl, server už teď umi libovolně sdružovat více zájmových bodů dohromady, obsahuje už předpřipravené skupiny, například čerpaci stanice, bankomaty a další, který je vytvořen pouhým smícháním několika existujících skupin. Jediné, co já chci, aby se toto smíchání neprovedlo jen tak, ale mezi každou kategorii se přidal <Folder><name></name>....<Folder> řetězec. Skupina bude obsahovat naprosto totéž co doposud a zátěž na server se taky nezmění, snad jen to seřazení podle skupin.

Navíc pochybuju, že server tyto úkony provádí pořád, určitě výsledné soubory cachuje.

Osobně jsem v IGO zkoušel zatím asi 7MB KML soubor z cca 7500 body a neznamená to pro něj vůbec nic, celkově tam mám asi 10MB KML souborů.

V principu exportu se změní jen to, že data při získání z databáze SQL dotazem setřídí podle kategorií a pak se jednoudchou podmínkou bude hlídat změna kategorie a při každé změně se tam vloží jednoduchý řetězec, toď vše.

Ale já reagoval (a dělal si srandu) POUZE na to "celé poi.cz dát do jednoho souboru"!

Že je možné přidat atribut "name" pro složku jsem nemaje google earth či iGo nevěděl. Opravdu není problém změnit způsob vytváření kml takovým způsobem, jak si přejete - horší to je (hlavně z hlediska času, právě kvůli tomu "cacheování"), kdyby se mělo nastavit volitelně, zda vše v jednom pytli anebo ne. Nemám iGo, tudíž nevím, jestli to třeba neudělá problémy při hledání atd.

Osobně jsem v IGO zkoušel zatím asi 7MB KML soubor z cca 7500 body a neznamená to pro něj vůbec nic

A těch téměř dennodenních výpadků po přetížení MySQL sis ještě nevšiml??? Ani 768 MB paměti, kterou platíme (za pěkný balík) už prostě nestačí...

Pro GoogleEarth, ani pro iGO8 se nic nezmění. GoogleEarth stále bude zobrazovat všechny POI pokupě, jen vlevo ve stromu přibudou složky a bude možné jednotlivé složky (např. typy čerpacích stanic povypínat a nechat jen některé). V iGO8 taktéž půjde hledat buďto v celém KML nebo jen v podskupinách, půjde nastavit jinou ikonku pro každou podskupinu a půjde pro každou skupinu nastavit jinou viditelnost.

KML je bezva formát, jdou tam přiřadit i ikony, nastavit barvu popisku a obsah bubliny, který se zobrazí při kliknutí na ikonu... toto však už na iGO nemá žádný vliv, nicméně mu to tam nevadí. To už jsou věci po kterých tam ale netoužím

Výpadek jsem naštěstí ještě moc nezaznamenal, jen si jednou za čas stáhnu pár věcí. My máme na serveru myslím 4GB RAM a taky to občas padá

Hned až budu mít trochu času, tak se na to juknu...

Díky moc. Kdyžtak s čímkoliv pomůžu, minimálně z otestováním.

Tak mě napadá, že pro to slučování ani není databáze potřeba, stačí jednotlivé skupiny vyexportovat samotatně a slučovat už pak jenb soubory, alespoň tedy u souborů jako XML a CSV.

Tak testuj...

Ještě se to musí celé uzavřít do <Document> </Document>, KML dovoluje jen jeden element na první úrovni. iGO8 to sice nevadí, ale Google Earh to striktně hlídá.

Taky by v názvech těch podskupin nemusel být zopakován název hlavní skupiny, tedy když mám CZ-Banka, tak v názvech podskupin už stačí CSOB místo CZ-Banka_CSOB.

Jinak super. Díky moc.

a 01 záznamy pro TomToma taky budou ?
Asi ne co, to není takjednoduchá úprava jako u XML.