Zkusil jsem v GeoGetu nastavit filtr s výběrem keší podél trasy a vrátilo se mi méně keší, než bych čekal.
Filtr má nastaveno blíže než 10km od trasy a ve výběru chybí keše ve vzdálenosti dále než cca 7km od trasy.
Vypadá to, že je to podél celé trasy, relativně systematicky. Mohu poskytnout data, z kterých jsem vycházel (asi to zkusím
zjednodušit, teď mám 36 bodů v trase a cca 1700 keší ve výsledku).
Kde může být problém?
nemáš nastavený filtr na souřadnice finálek? nebo ti mizí i tradičky?
Ne, korigované souřadnice jsem měl vypnuté, aby se mi to lépe porovnávalo. Týká se to i tradiček, samozřejmě.
Jinak tedy jak jsem na to přišel - udělal jsem si vlastní implementaci blízkosti k trase (viz
https://github.com/Epsidon/PhoneGapExperiments/blob/master/Data/src/DistanceAlgorithm.java )
jako sqlite extension, udělal jsem dotaz do geoget databáze a porovnal výsledky. Měření jsem prováděl v Mapsource.
Vzdálenost k trase je definována jako nejkratší vzdálenost k úsečkám trasy.
Podle měření v mapě jsem měl ve výsledku dotazu správné keše, v GeoGetu některé chyběly.
Ucel toho filtru není vybrat to na metr přesně, ale vybrat kese v nějakém rozumném pádu podél cesty, která muze být dlouhá a křivolaká. A nebo je naopak velmi přibližná, nebo kombinace obojího. Proto u tohohle filtru přesnost nehraje roli, protože už na vstupu jsou nepřesná data.
Proto se to počítá vlastně stejně jako ty, ale ta trasa prochází napřed optimalizaci, aby se počet úseček zredukoval, to ale prinese nějakou další nepřesnost, takže se klidně může stát, že nějaké vzdálenější body vypadnou, ačkoliv se zdá, že jsou dost blízko.
Ergo, zkus o něco zvednout vzdálenost.
Promiň, ale nejde o metry, ale do výběru se nedostane řada keší, které jsou mnohem blíže, než daná vzdálenost (odhadem je to cca 20% keší).
Udělal jsem malý soubor dat, na kterém je to dobře vidět.
Trasa má jen dva úseky:
49.18924 14.68505
49.21782 14.7251
49.24437 14.72913
Vybral jsem jen tradičky do 5km od trasy.
GeoGet mi vybral 41 keší, viz soubor 11-12-13-5km-malo.ggt
Ve výběru chybí 8 keší:
GC812B8 4,5km
GC2QZ6H 4,6km
GC28N64 4,1km
GC28N5C 4,9km
GC9B9V5 4,5km
GC5WQ2C 3,5km !
GC281N6 3,8km !
GC1YD3H 4,9km
Plný seznam je v souboru 11-12-13-5km-ok.ggt.
Já jich našel na první pokus hned 71, ale pak jsem si řekl, že asi nechceš archivované. Po jejich vypuštění jsem taky na 41, takže se mi to chová stejně. To je v zásadě dobrá zpráva, mohu zkusit zapátrat, proč tomu tak je.
Jo, to jsem zapomněl napsat - jasně, nejsou tam archivované. Ale mohou tam být disablované.
Věc se má takhle - je tam použitý dosti starý a nepřesný algoritmus, a dost možná je v něm chyba, protože ty úlety s 3.5 kilometry jsou fakt podivné. Proto jsem si rekl, ze to raději napíšu jinak a snad lépe.
První pokus nového algoritmu ukázal smysluplných 48 keší. Chybí jen GC28N5C, která je ale podle mne o pár metrů nad pětikilometrovou hranicí. Použitý rychlejší, ale nepřesnější GreatCircle mi spočítal 5.007. Přesnější Vincenty mi vyšel 5.011. Kontrolně jsem zkusil i dva různé online výpočty, které vyšly ve stejných mezích. (Sranda je, že každý dal unikátní číslo - holt, každá implementace má nějakou svoji nepřesnost.)
Ta GC28N5C je vzdálena od trasy 4.89km, keš je na N 49° 13.557 E 014° 38.710 (49.22595, 14.64517), nejbližší (kolmý) bod na trase je na N49 11.775 E14 41.692 (49.19625, 14.69487). Všechny výpočty dělám pomocí Great Circle (poloměr Země 6371.008km). Vincenty je tady určitě zbytečný.
Měříš vzdálenost skutečně od kolmice? Totiž tvých 5.007 je nápadně blízko k začátku trasy (mě vychází 5.006).
Jinak tedy ještě k algoritmu, co používám já (a je to pěkně popsáno na stackoverflow, jak jsem odkazoval):
1) vypočítám bod T, na "velké kružnici" (definované body A a B, to je úsek trasy), který je nejblíže k bodu C (tedy testovaná keš)
2) otestuji, zda bod T leží mezi A a B (ta kratší část z dané kružnice),
a) pokud ano, vypočtu vzdálenost mezi C a T
b) pokud ne, vypočtu vzdálenosti mezi C a A, C a B, a vezmu tu kratší
Vypadá to složitě, ale ve skutečnosti je to jen pár goniometrických výpočtů, a chodí to docela rychle.
Pro vyhledání v databázi je prakticky nutné ještě udělat boxing nebo použít spatial index.
Ano, o kolmici se snažím, ale nebyl už čas to večer víc zkoumat. Jak jsem řekl, byl to první nástřel.
Ta GC28N5C je vzdálena od trasy 4.89km, keš je na N 49° 13.557 E 014° 38.710 (49.22595, 14.64517), nejbližší (kolmý) bod na trase je na N49 11.775 E14 41.692 (49.19625, 14.69487). Všechny výpočty dělám pomocí Great Circle (poloměr Země 6371.008km). Vincenty je tady určitě zbytečný.
Měříš vzdálenost skutečně od kolmice? Totiž tvých 5.007 je nápadně blízko k začátku trasy (mě vychází 5.006).
Jednoduchý test s dvoubodovou trasou Veselí - Miličín by mi v takovém případě udělal dvě bambule kolem koncových bodů, a Tábor by vynechal. Ale ono mi to udělalo krásný pruh. :huh: Jdu to zkontrolovat.
Použitý nový algoritmus je jiný než tvůj, trochu méně přesný, nicméně velmi rychlý. Pro daný účel (sakra, hoď mi nějaké keše podél trasy a poloměr tam nějaký odhadnu) mi ta přesnost přijde bohatě dostatečná. V porovnání s tvým demostračním vzorkem se to liší jen o tu jednu hraniční kešku (unikla o 9 metrů).
Takže je to určitě lepší než doposud, je to i rychlejší, a tvému kódu se to hodně přiblížilo. Určitě najdeš odlišnosti od tvého způsobu, ale nemá smysl pro daný účel tím víc ztrácet čas. Puristé si vždycky mohou napsat vlastní supepřesný plugin. ;)
A mohl bys ten algoritmus víc popsat?