Primo Rastrove mapy Google

[Lakva]

Tak jsem teď napsal poměrně dlouhou reakci, ve které jsem Dannyho dost spucoval, ale pak jsem se rozhodl si to ještě ověřit a na tu mapu kouknout v šochtli... a celou tu desetiminutovou filipiku jsem zase smazal.
On má, Míro, Danny pravdu, ta mapa je skutečně posunutá velmi znatelně na sever. Nebo na jih, podle toho, co považuješ za přesné, jestli vektory nebo rastr. Podívej se na střed Prahy, na oblast někde kolem Florence, a zjistíš co tím chtěl Danny říci. Já bych řekl, že to bude možná i 25 metrů!!!
Na plánování je to ještě použitelné, to si člověk v hlavě srovná, ale jako tapetu přes navigační mapu bych to rozhodně nedal...

P.S.: Příkládám screen:

[amatér]

To všechno jsem schopný pochopit, ale podívej se na mapu Prahy, kterou jsem dělal zde, pokud ji zvětšíš dostaneš stejný výsledek jako u té z17, byla by velká náhoda, kdybychom udělali stejnou chybu v souřadnicích.

[Jasper]

Já musím potvrdit co psal Lukáš ten posun tam je a opravdu hodně výrazný. S prahou od Mirka jsem bohužel nedělal screen ale včera jsem si s tím trochu dost hrál a ničeho jsem si nevšimnul ani ve 2D v místě bydliště. Já chápu že mapa je zkreslená a že popisky nesedí na 100% ale tady je to opravdu o hodně. Pro ilustraci. Na screenu Google je jasně vidět areál autobazaru který má 150x50 metrů takže ten posun je podle mě nejmíň 40 metrů.

Praha_vu5936.jpg

Google.jpg

[Danny_S]

Já jsem ted zkoušel Prahu OSM od amatéra a tam byl posun o 15-20m směrem na jih - rastrová mapa oproti té klas. vektorové.
U Prahy Z17 byl ten rozdíl menší. Beru to dle svého bydliště a umístění silnic a zákrut ve svém bydlišti.
Otázka je, jestli lze dosáhnout co nejpřesnějšího překryvu obou map nebo co nejmenšího posunu tak do 5m, aby to nebylo na prvního pohled tak doočibijící.
Otázka je, jestli se ten posun stane už při vytváření map nebo Primo špatně přepočítá souřadnice a vykreslí dle toho obě mapy přes sebe.
... nebo špatné koordinátory má ta vektorová mapa a rastrová z Google je přesná.

[Lakva]

Míro, na těch Tvých mapách mi to nepřijde tolik markantní... nicméně máš pravdu

Problém asi NEBUDE ve vektorových mapách - to bysme si dobře všimli, že nám tečka přesné pozice neustále plave velkej flák jižně od šipky na silnici.Takže problém musí vznikat buďto v Primu při vykreslení, nebo při převodu. Hádál bych tu první možnost, protože podobným způsobem je ujetá i výšková mapa - jenže ta má tak malé rozlišení a přesnost, že je to uplně jedno a není to pozorovatelné.
Je otázka, jestli je to tak všude, nebo jestli třeba v Izraeli (kterej se pokud vím objevil jako první - kdyžtak mě opravte) je ten problém taky a mají ho už origo mapy od N'n'G, nebo jestli to vzniká v tom udělátku od PSB.
Jinak mě se naopak zdá, že na větším rozlišení mapy je ten problém výrazně větší... Ale soudím podle okolí Florence, protože to tam jednak znám z dřívějška a jednak tam bydlí ségra.

[vu5936]

Ahoj, nad tím posunem jsem se taky pozastavoval, ale v procesu vytváření mapy se prostě nedá nic manuálně zkazit. V SASu se souřadnice nastavují číselně a podle toho se vykreslí obdélník výběru. SAS podle nich sám stáhne a pospojuje zdrojové dlaždice do jednotkových bloků. Navíc souřadnice musí být inkrementované po 0,125°, jinak nástroj od psb nezpracuje rastr, resp mapa se nevykreslí. Chyb tedy může být více, od napoziciování map Google vůči souřadnicím, při spojování stažených zdrojových dlaždic do jednotkových bloků až po kompilaci bloků v psb toolu. Místa, kde by ale mohla v průběhu procesu tvorby rastru udělat chybu obsluha a zdeformovat souřadnice, prakticky nejsou.

[vu5936]

Ahoj, jak jsem psal večer, dnes jsem podnikl srovnávací jízdu s HTC Touch Diamond 2 a Dejvidem 6 TMCBTFM současně.

Konfigurace:
Aby bylo srovnání rovnocenné, obě zařízení byla připojena na nabíječku. Kvůli srovnání výkonu pod zatížením, obě zařízení měla aktivní TMC (HTC přes HyperGPS driver), ale bez připojené antény. SW i content byly umístěné na SDHC class 4. SW výbava bylo: Primo 1.2.1, originální .dat file, originální GJ-AK skin 10.1 bez významnějších úprav ve skriptech, schémata ročních období Béanico, poslední TTS Zuzana, databáze radarů vlastní výroby 437kb a jiné grafické soubory POI, DA a JV v souboru branding.zip.
Konfigurace sys.txt a složka save byly zcela identické (klon), pouze se změněnými porty GPS a TMC podle zařízení. HTC mělo navíc v sys.txt zápisy pro nastavení paměti, bez nichž mi padá. Mapy NQ byly v odděleném adresáři. V Primu bylo zapnuté vše, co se dalo: TTS, 3D krajina, oboje 3D budovy, JV. Raster soubor mapy jsem použil svůj Prague_Google_Z17.raster velký 57MB. Jel jsem s nastavením v sys.txt raster_quality=1.

Cesta:
Cestu jsem naplánoval přímo z domova do práce, nicméně polovinu cesty jsem jel jinam na plánovanou zajížďku a ignoroval pokyny, aby zařízení musela stále přepočítávat. Cestou jsem vystřídal všechny typy cest i dopravních situací (kromě zastavení policií a bouračky). Jízdu po vesnicích v okolí Prahy, jízdu po teplické dálnici v oblasti Prahy, poskakování v zácpě po Kbelské a Průmyslové, kam jsem měl plánovanou zajížďku a jízdu přes centrum přes Vinohrady do Karlína. První polovinu cest jsem jel ve 3D, druhou polovinu ve 2D.

Zkušenosti:
K testu jsem přistupoval s obavami, že se budou obě zařízení hádat a překřikovat. To však nenastalo. Situaci naprosto s přehledem vyřešil pomalý GPS čip v HTC a obě zařízení se tak hlasově naprosto dokonale doplňovala. Dejvid 6 hlasově i graficky okamžitě reagoval na zrychlování, zpomalování i plánované změny směru, kdežto HTC při vyšších rychlostech (cca 50-70 km/h) dělalo všechno s cca 2s zpožděním. Vypadalo to tak, že Dejvid dokončil instrukci (i poměrně dlouhou typu: „Po 150 metrech odbočte do ulice Černokostelecká“) a poté ji začalo odříkávat HTC. Při nižších rychlostech si skákaly do řeči a i při 0 km/h a stání na světlech HTC začalo mluvit nejdříve v půlce věty Dejvida. Tomu odpovídalo i mnou dříve popisované chování, že díky pomalému čipu hlásí HTC změnu až po projetí křižovatkou. Toto zpoždění se týká pouze navigačních akcí. Ostatní akce a hlášení nevyžadující počítání polohy probíhaly současně.
Co se týče délky nabíhání obou navigací při současném startu, lehce vedl Dejvid, který předběhl HTC o zanedbatelných cca 2s. Za celou cestu ani jedno zařízení nespadlo na chybu paměti nebo Windows. Dříve mi to na HTC dělal rastr Prahy v Z16 od psb, ale soft reset a nebo tento nový rastr to zdá se vyřešil. Co NNG stále neopravilo je oznámení začátku úsekového měření, které jak HTC tak Dejvid stále oznamují až cca 30m po projetí pod první kamerou (HTC ještě později o délku věty).

Ohledně rastrů, kvůli kterým jsem test dělal:
Začal jsem ve 3D zobrazení. Při stání před barákem Dejvid načetl zhruba polovinu segmentů rastru. HTC nezobrazil ani kousek. Při průjezdu vesnicemi se Dejvid snažil průběžně zobrazovat segmenty. Většinou pokryl pravý dolního roh a dále se snažil zobrazit segmenty kolem cesty. Pokryl zhruba 2/3 screenu nesouvislou plochou, až na horizont se nikdy nedostal. HTC stále nezobrazovalo nic. To mi už bylo divné, tak jsme udělal soft reset, až pak se chytlo. Jízda po dálnici byla lepší, obě zařízení průběžně vykreslovala většinu segmentů, i když jejich vykreslování bylo trhané. Zajímavé bylo, že obě zařízení zobrazovala tytéž segmenty. Pokud nějaké chyběly, tak na obou takřka stejně, pouze Dejvid byl při vykreslování i v reakcích krapet rychlejší. Při jízdě na Kbelské se situace zlepšila do té míry, že se rastry ukazovaly často kompletní. Neplatilo však, že by se načetly a zobrazily celé při stání. Zobrazování naopak pomáhal pohyb, kterým je iniciovaný přepočet grafiky. Obecně mohu říci, že zobrazení rastrů po cestě pokrývalo v průměru 50% screenu, většinou v různých, nesouvislých segmentech a na obou zařízeních prakticky stejně. K vyplnění celé plochy screenu (před pás horizontu) došlo pouze v pár případech. Horizont se nepokryl prakticky nikdy.
2D zobrazení pro mne bylo naopak velké překvapení. Pokrytí rastrem bylo 100% na obou zařízeních při jakýchkoliv městských rychlostech. Obě zařízení překreslovala rastr naprosto plynule a vše stíhala. HTC jako předtím vykreslovalo rastr se zpožděním, které bylo dané zpožděním GPS čipu. Náhled ve 2D působil subjektivně velmi realisticky a s doplněnými ulicemi byl velmi pěkný, na rozdíl od 3D, kde barevné šmouhy na rovině nejsou nic moc. Na jízdu ve 2D jsem si ale už odvykl...

Závěr se mi moc dělat nechce, vzhledem k tomu, že jsou obě zařízení konstrukčně odlišná a jsou optimalizovaná na jiný účel. Velmi zde však vynikla pomalost GPS čipu v HTC, čehož si člověk za provozu až tak nevšimne (nebo si zvykne), ale při srovnání je to opravdu hodně (rozdíl jedné dlouhé navigační hlášky). Naopak displej Dejvida byl v porovnáním s HTC o mnoho kategorií horší. Ač vysvícený na maximum, byl nekontrastní a zašedlý. Nedá se ale porovnávat lesklý skleněný displej se 2/3 úhlopříčkou u PDA zařízení dělaného na efekt a za cenu 10 tisíc ve své době, s poloznačkovým čínským PNA za 3 tisíce i se SW. Je to opravdu o přímém srovnání dvou kusů položených vedle sebe, které nikdo v praxi dělat nebude. Samostatný Dejvid 6 je pěkné zařízení, kterému se oči přizpůsobí a sám o sobě ostudu neudělá. Pokud bych tedy měl porovnat oba kusy jenom z pohledu zobrazován rastrů, je na tom Dejvid 6 pouze o malý kousek lépe. Pokud bych měl vyjádřit tento celkový dojem nějakým číslem, tak by vedl o nějakých 10-15%.

[Jasper]

Mě napadlo něco v souvislosti s tím posunem ale nejsem odborník a nerozumím tomu tak mě prosím hned nepucujte pokud napíšu kravinu jo. Nemůže ten posun způsobovat skutečnost že ty snímky nejsou dělány kolmo k zemi ale pod úhlem. Když se podívám na ty auta a budovu v bazaru tak je ten úhel dost evidentní.

[amatér]

Bingo
Opravdu záleží mimo jiné i na úhlu snímání.

[pithy]

Ahoj, jak jsem psal večer, dnes jsem podnikl srovnávací jízdu s HTC Touch Diamond 2 a Dejvidem 6 TMCBTFM současně.........

to vu5936
díky za tvou práci. Vyjdu z rady Dannyho_S a budu zkoumat proč to na mém Dajvidu nejde. (ale až mi dojde zpět ze servisu).