Előzmények
gusty | hozzászólásai | válasz erre | 2014.04.02 08:25:05 (2859) |
Nem vita, csak tisztáztuk a számítási módok közti eltérést. részemről nem a pontosságon, vagy a jóságon van a hangsúly, hanem azon, hogy ugyanazt az értéket tudjam számolni.[ előzmény: (2857) R.Guszty, 2014.04.02 07:44:41] |
|
R.Guszty | hozzászólásai | válasz erre | 2014.04.02 07:44:41 (2857) |
Értem én, hogy elméleti a vita, de valójában nincs jelentősége. Igaz, hogy kissé fel kellett puhítani a "megtalálás" szabályait, hogy igazából ne kelljen megkeresni a ládát, de az azért elvárható a ládázótól, hogy legalább megközelítse, amennyire csak lehet. Ebben az esetben nem létezik - egy-két extrém esettől eltekintve -, hogy a cm-ek döntsenek a találat - nem találat kérdésében.[ előzmény: (2856) Old Eye, 2014.04.02 06:27:42] |
|
Old Eye | hozzászólásai | válasz erre | 2014.04.02 06:27:42 (2856) |
Uraim! Nem mentünk bele túl mélyen az erdőbe?
$lat1=47.42929489351809;
$lon1=19.09259894862771;
Értelmetlen ez a sok tizedesjegy, mert a túrázók/geoládázók GPS kütyüinek pontosságát 3-4 méternek vehetjük. Ezért mondjuk mi, térképszerkesztôk: Egy track nem track. Akkor vagyunk csak elégedettek, ha egy útvonal alatt kötegnyi track húzódik, a nyomvonalak átlagolásával húzzuk meg az út vonalát, de akkor se tartjuk azt abszolút pontosnak, de elegendőnek.
Lay-nak talán ki kellene egészíteni algoritmusát szórással. Ha a húsz méterről beszélünk, az mondjuk 18.5-21.5 m, azaz ha a számított távolság kisebb 18.500000 méternél, biztos 20 m-nél rövidebb, ha nagyobb 21.500000 méternél, biztos 20 m-nél hosszabb, ha a két érték közé esik, az éppen 20 m :-) [ előzmény: (2855) gusty, 2014.04.01 23:56:14] |
|
gusty | hozzászólásai | válasz erre | 2014.04.01 23:56:14 (2855) |
Hoppá!
Ugyanazt a képletet használjuk, csak ezek szerint én nagyobb pontossággal.
Mivel méterben számolom a távot, nekem az 111180 a szorzó.
Talán még az is belejágyszik az eltérésbe, hogy én az átváltásokat is SQL függvénnyel oldom meg.
Nálam így 3 cm alatti az eltérés, s így jön ki a 20 méter feletti a távolság. :)
SQL:
SELECT MIN(DEGREES(acos(SIN(RADIANS(lat))*SIN(RADIANS(".$gc->lat."))+COS(RADIANS(lat))
*COS(RADIANS(".$gc->lat."))*COS(RADIANS(lon-".$gc->lon."))))*111180) AS tav FROM track_data[ előzmény: (2854) LaySoft, 2014.04.01 20:39:23] |
|
LaySoft | hozzászólásai | válasz erre | 2014.04.01 20:39:23 (2854) |
Az eltérés abból adódik, hogy a pontos Vincenty formulát a track teljes hosszának kiszámításához használom. A ládáknak a track pontjaihoz viszonyított távolságát sql-el számolom, ezért egy lényegesen egyszerűbb és nem olyan pontos képletet használok erre a célra:
(((acos(sin(<lat1>*PI()/180)*sin(<lat2>*PI()/180)+cos(<lat1>*PI()/180)*cos(<lat2>*PI()/180)*cos(<lon1>*PI()/180-<lon2>*PI()/180)))*180*60/PI())*1.85)
Nem állt szándékomban a Vincenty formula sql-ben történő megvalósításával szenvedni.
Az eltérés így most:
20.080707244277 - 19.9867983700548 = 0.0939088742222 = kb. 9.4 cm.
Úgy gondolom belefér. Ha valakit zavar, akkor az adminnál reklamálhat, ő mindenható, akár 0 hosszú track-et 0 ponttal is elfogadhat, ill. le is húzhat bármit.
Egyébként először a track teljes hosszának számításához is a fenti képletet használtam, de mivel komoly eltérések jöttek ki egyéb programok által számolt távolságokhoz képest (összeadódtak a hibák), ezért néztem utána egy pontos képletnek, és így leltem a Vincenty formulára.[ előzmény: (2853) gusty, 2014.04.01 14:02:43] |
|
gusty | hozzászólásai | válasz erre | 2014.04.01 14:02:43 (2853) |
Valami nekem továbbra sem stimmel.
Van a hétvégi trackemben egy pont (GCGULT-2), amit a kupa szoftvere elfogad, 0.0199867983700548 értékkel, de nekem az általad linkelt képlettel is 20 feletti érték jön ki.
Nem a pontos érték izgat, hanem jó lenne, ha reprodukálni tudnám a kupa program által számított értékeket.
Én ezekkel számoltam:
Legközelebbi trackpont:
$lat1=47.42929489351809;
$lon1=19.09259894862771;
GCGULT-2:
$lat2=47.42928333;
$lon2=19.09233333;
Eredmény: 20.080707244277
[ előzmény: (2840) LaySoft, 2014.03.31 17:01:11] |
|
gusty | hozzászólásai | válasz erre | 2014.03.31 16:29:51 (2839) |
Egyébként lehetne a távolságszámítási algoritmust pontosítani? Nekem kicsit más számok jönnek ki, de ez származhat a képletből, R-ből is.[ előzmény: (2838) gusty, 2014.03.31 12:38:15] |
|
LaySoft | hozzászólásai | válasz erre | 2014.03.31 10:44:00 (2837) |
Nem értem a kérdésed.
A program kiszámolja a legkisebb téglalapot, amibe belefér a track. Ezt a téglalapot megnöveli 30-30 méterrel mind a négy irányba és ebbe a téglalapba eső ládákat vizsgálja, hogy 20 méteren belül vannak-e a track nyomvonalához viszonyítva.[ előzmény: (2836) Gábor75, 2014.03.30 20:11:16] |
|
Gábor75 | hozzászólásai | válasz erre | 2014.03.30 20:11:16 (2836) |
Ami pont 20 méteren kívül esik, annak mi a másik határa? Mennyire kell megközelíteni ahhoz hogy az "elutasított" cimkét megkapja? Szerintem 100 méteren túl nem lenne értelme jelölni ezeket a pontokat. [ előzmény: (2835) LaySoft, 2014.03.30 19:45:35] |
|
LaySoft | hozzászólásai | válasz erre | 2014.03.30 19:45:35 (2835) |
Most futtattam le az elfogadhatóság ellenőrzését az összes track-en. 13-at elutasított, megnéztem, jogos mindegyik, de azért ellenőrizze mindenki a sajátját! |
|
|
|