Som rad, ze sa diskusia o hike planneri takto dobre rozbehla. Po malej vymene emailov navrhol MisoB nasledujuci vzorec na vypocet priblizneho casu:

t = d/4 + st/600 - kl/1200

[t - cas v hodinach, d - dlzka v km, st - stupanie v m, kl - klesanie v m]

PRETO VYZYVAM KAZDEHO, CO MA DOMA MAPU S CASMI NECH ZOPAR USEKOV S TYMTO VZORCOM OTESTUJE. NAJLEPSIE USEKY, KTORE POZNA.

Bude to velka pomoc a cim viac usekov sa otestuje tym lepsie pre vsetkych buducich pouzivatelov.

Len na objasnenie vzorca a koeficientov: rata sa s priemernou rychlostou 4 km/h po rovine, priratuva sa 10 min na kazdych 100 m stupania, odratuva sa 5 min na kazdych 100 m klesania.

Vzorec bude isto potrebovat nejake korekcie. Pri prudkom klesani sa dostane do minusu :(.

Ja by som bol za to, aby klesanie nemalo minusovy vplyv na cas. Konkretne ja idem rychlejsie po rovine ako dole kopcom. A cim je kopec strmsi tym pomalsi je zostup. Mozno by stalo za to vyskusat nejaku nelinernu funkciu v pripade klesania - napriklad nejaky rozumny logaritmus. Matematici, ozvite sa :-)

Skusim ten treti clen v rovnici nejako upravit... Tak ako som ti pisal v maili, pri prudkom klesani (ale aj stupani) by mali byt koeficienty ine. Nebolo by ale asi dobre, aby sa kvoli nejakemu fikanemu vypoctu odhadu casu prilis predlzovala odozva systemu.
Mozno naozaj treba ten minusovy vplyv klesania vyhodit - hoci ja idem nadol rychlejsie (dokonca sa mi osvedcilo dolu strmsim usekom aj zbiehat - mensia zataz klbov?)... Ale to uz sme narazili na to, ako velmi individualny je cas. Ved aj ta rychlost po rovine (4 km/h) moze byt pre niekoho (alebo za urcitych podmienok) vela, pre ineho by sa hodilo 5 km/h (a stale to este nie je beh).

Pri tvorbe rovnice na vypocet casu sa vobec nemusis zatazovat uvahami o odozve systemu. Matematicke operacie sa zvladaju svizne. Problem je v algoritme, ktory vypocitava cestu - ten ked bezi pre cele slovensko, tak v cisto teoretickej rovine sa moze stat, ze potrebuje az 5.4miliona cyklov (2700edgov*2000vertexov). Preto som zaviedol obmedzenia na maximalne 10 lokalit. Potreba cyklov sa tak znizila na niekolko desiatok tisic a to sa uz da :-).
A aby to bezalo uplne najlepsie, tak spocitavanie vzorca moze vykonavat priamo SQL server, ktory fici daleko rychlejsie ako PHP CGI interpreter.

Mozno by stalo za uvahu ten vzorec postavit nie cisto na stupani a klesani, ale v pomere k vzdialenosti kde toto stupnie/klesanie bolo. Teda dostavame sa k ekvivalentu niecoho ako strmost.

Takze, ak tam ten treti clen nechame, navrhujem ho vynasobit nasledovnym (cim sa stane nelinearnym):
(300-kl/d)/300
Vyznam: pre miernejsie klesania v rozsahu od 0 do 300 m/km tento koeficient postupne klesa od 1 do 0, potom prechadza do minusovych hodnot. Takze pre klesanie 30% bude prispevok klesania na cas rovny 0 a pre strmsie klesanie sa bude celkovy cas predlzovat.
Vysledna rovnica:

t = d/4 + st/600 - kl(300 - kl/d)/360000

Medzitym, co som formuloval predosly prispevok, napisal si o tej strmosti... :)
Cela ta uprava ma samozrejme zmysel, len pre vypocet casu pre kratke useky, kde sa takto chapana strmost uplatni. Z dat, ktore mame k dispozicii totiz nijako nezistime, na akej casti dlzky useku sa stupalo resp. klesalo.
V globale (trebars ak sa vzorec pouzije na celu trasu) dava ten vzorec aj v povodnej podobe dobre vysledky, lebo tam sa faktor strmosti neuplatni...

Pekna praca, ale chyba mi tu trocha mapa.
Viem, ze to bude asi problem, ale nedalo by sa dohodnut s nejakym vydavatelstvom - ved by to bola aj ich reklama.
Dali by ste im tam, ze pouzivate ich mapy... s linkom na ich stranku...
Podobne to asi funguje aj na skrz.sk.

Pekna praca, ale chyba mi tu trocha mapa.
Viem, ze to bude asi problem, ale nedalo by sa dohodnut s nejakym vydavatelstvom - ved by to bola aj ich reklama.
Dali by ste im tam, ze pouzivate ich mapy... s linkom na ich stranku...
Podobne to asi funguje aj na skrz.sk.

Marcel, citas mi myslienky. V uplynulych dnoch prebehli rozhovory s ceskym vydavatelstvom SHOCart, avsak nepriniesli konkretne vysledky. Este sa pokusim kontaktovat VKU Harmanec, avsak necakam zazraky ani z ich strany. Vies, chcem po nich prilis vela prace za nejasnu kompenzaciu.

Ale heureka, mam riesenie! Prave prebieha alfa testing samostatneho mapoveho riesenia, ktore bude napojene na GKU geoportal. Jediny trabl je, ze tam nie su zachytene znacky.

A finally, musi prebehnut georeferencovanie (priradovanie suradnic) hiking obsahu a na tom sa budu musiet podielat vsetci citatelia co maju trosku blizko k GPS a navigacii. Ked bude obsah zreferencovany a mapove riesenie funkcne, potom sa budu len diat zazraky. K tomu este fotky v pripravovanej galerii budu tiez georeferencovane, takze secko bude spojene: urobis si trasu, ukaze ti mapu, fotky a relevantne clanky ..... haluza co?

Pozeral som ten geoportal a vyzera to, ze to bude super. Nic viac nepotrebujes, ak ti tento geoportal dokaze vyflusnut aspon mapu, kde su cesty, dediny a rieky. Co viac potrebujes?

Ved tam pisu este aj podlozie ci co... moc sa v tom nevyznam...

Otazka ale je, ci je mozne upravovat data z tej stranky - a to budes musiet, ak budes chciet kreslit znacenie.

Myslel som ci nebudes sahat na autorske prava...

na Geoportal sa pripojim cey WGS. Kedze GKU spristupnilo vrstvy svojho GISu cez tuto technologiu a este na to dali aj link na svojej stranke, nemoze byt reci o problemoch s publikaciou. Samozrejme tam dam poznamku, ze ide o ich data aby boli spokojni ":-).

No a dokreslovanie trackov, waypointov z GPS dat, pripadne dat od KST prebieha zasa ako vrstvenie na seba. Takze ja nebudem zasahovat do konkretnych vrstiev, len spravne na seba vrstvy poukladam.

Idealne by bolo keby aj KST mali MAPSERVER na ktory sa pomocou WGS pripojim ... nerobim si ale iluzie.