Pročítal jsem tady ty příspěvky a zaujalo mě jak se zde, naprosto vážně, diskutuje myšlenka javascriptového renderingu mapovách dat v browseru na počítači u klienta..
Kdysi jsem někde viděl pokusy, které takto renderovaly (spíše stylizovaly) data do svg - a byla to i pro můj, ani ne 10 let starý komp,) smrtelná nálož na výkon. (mmtálně nemám, bohužel, po ruce link co to bylo za projekt) Možná se ale časy změnily a co bylo kdysi obskurní hříčkou, tomu dnes patří budoucnost...
Tak bych se rád zeptal, pokud se tady někdo v té problematice trochu orientuje, v čem jsem zaspal dobu, když si pořád ještě myslím, že jde o naprostý nesmysl:
- pokud mluvíme o renderingu jako o nějakém jpg/png výstupu z vektorových dat.
- na serveru se tedy ušetří výkon který by tam padl na rendering, ale při vyšší návštěvnosti stránek se tedy vše bude u každého uživatele renderovat separátně? Není to úhrnem mnohonásobně vyšší, zbytečně spotřebovaný výkon? A při každém novém zazoomování/odzoomování se v browseru spustí další rendering? ( Protože si samozřejmě uvědomujeme, že pro každé zvětšení jsou jiné popisky, jiné zobrazené entity - vpodstatě jiná mapa.. ) Nejsou zábavnější způsoby jak usmažit planetu? (Dobrá, nemusí tady být každý hned ekolog..)
- v čem bude spočívat náplň projektu jako je například zrovna tento? Pokud si každý upgraduje procesory a nakoupí ramky aby si mohl renderoat sám u sebe, tak si taky nejspíš bude renderovat po svém... přizpůsobí si zobrazení svým potřebám a nebude se obtěžovat nějakými bugreporty, aby se mu někdo v mapě možná někdy zobrazil ostrovy a neschovával značky pod řekou... Takže jaká položka zůstane v budoucnu částečně komerční mapě1.eu jako onen tahák na štědré přispivatele? Že by "tailing dat" ??!
- uff. TAILING DAT... Původně jsem se tomu chtěl jenom smát (než jsem zjistil, že jsem naprosto paralyzován údivem a zděšením) S prominutím, dlaždicování map je úžasná technologie, která svým nástupem nesmírně zrychlila (zinteraktivnila) práci s mapou a přitom ušetřila obrovské, jinak promrhané výpočetní výkony, oproti do té doby používaným WMS a CGI (python, php..) renderingem přímo do okna. Technologie, které generovaly na každé vyžádání nový, ale podruhé již nepoužitelný obrázek byly nahrazeny předrenderovanými sadami dlaždic, které na sebe navazovaly a stačilo je prostě jenom poslat a poskládat. Opakovaně, libovolněkrát. Přineslo to nějaká omezení, například ve volbě měřítka a nehodilo se to pro dynamiká data.. Odpusťte, že si tady dovoluji připomínat a po svém přeformulovávat něco, co je asi obecně známé, rozhodně tím nechci říct, že tomu někdo nerozumí.
Takže: jedny data na serveru, jedenkráte realizovaný rendering, rychlá mapa.
A pak příjde někdo jiný a začne tvrdit: pomalé mapy nevadí (pokud je si tou pomalostí vinen klient sám), duplicitní rendering neřešíme (nejsme přeci žádní ekologové.. ) A jak je do s těmi daty? To je pro mě právě veliká záhada. Když bych měl něco takového řešit já, tak dobrá, data u sebe máme jednou a posíláme je klientovi na vyžádání do okna, ať si tam s nimi dělá co chce. S client-side renderingem prostě padá tailing to je jednoduché. Alespoň se navrátíme k výhodám libovolného zoomu a dynamických dat..
Ale vy chcete mít,.. jestli tomu dobře rozumím (doufám, že ne) u sebe celý dataset ... dejmetomu 20krát ..??? pro každé zvětšení jednou?? A pro to nejmenší měřítko naporcované po 30m2??
Ehm. PRO CELOU EVROPU??? ,DDD .)
Áánebo .. mít pouze dlaždice, jak tady radil někdo nade mnou, předporcované po 100m2 .. a jako takové je budete posílat i když někdo bude na mapě hledat brouka ve zvětšení 20? Jak se vlastně v tomto modelu řeší zobrazení malých měřítek? Pro zobrazení celé Evropy se posílá celá Evropa?
Áánebo .. všechno zůstane při starém, jenom se dlaždice (datové) budou generovat na vyžádání (aby stroj nezahálel, když už nemusí renderovat?)
Prostě záhada. Možná by to chtělo vymyslet (a nebo nastudovat) něco jako WFS.
Odpusťte délku příspěvku, ale je tak akorát adekvátní mojí dezorientaci.
ČLÁNKY DO MAILU