korábban már feltöltött nyomvonalak felismerése

Annak érdekében, hogy ez a fejlesztés belátható időn belül elkészüljön és józan keretek között használható is legyen, a teljes nyomvonal-adatbázissal való összehasonlítást félreteszem.

Helyette azt javaslom, hogy használjuk az OSM apit arra, amire való: adott helyen levő nyomvonalpontok letöltésére. Ez a hely lehet egészen kicsi is, akár pontszerű is. Kipróbáltam, hogy mit hoz le, ha egy nyomvonalból kiválasztok egyetlen pontot és azt teszem meg a befoglaló téglalap mindkét sarkának, lehozta.

https://api.openstreetmap.org/api/0.6/trackpoints?bbox=16.6519157,46.5779439,16.6519157,46.5779439&page=0

Mivel előfordulhatnak kerekítési hibák, sőt vannak is, ezért érdemes némi ráhagyással dolgozni. Az OSM által megkülönböztetett legkisebb egység a WGS84 koordináta 7 tizedesjegye, így néz ki a letöltésben:

  <trkpt lat="46.5779439" lon="16.6519157">
    <time>2010-08-11T17:08:45Z</time>
  </trkpt>

Az eredetiben így volt:

  <trkpt lat="46.577943983" lon="16.651915731">
    <ele>299.588013</ele>
    <time>2010-08-11T17:08:45Z</time>
  </trkpt>

Látszik, hogy nem kerekítette a koordinátát, hanem csonkolta a hetedik tizedesjegy után. Hasonló kavarás előfordulhat OSM szerveren kívül is, például a Garmin .gdb átalakítására használt programban.

Emiatt érdemes ráhagyni néhány tizedesjegyet, első körben az öt tizedest javaslom, ami körülbelül egy négyzetméternek felel meg a valóságban. A fenti példa esetén:

https://api.openstreetmap.org/api/0.6/trackpoints?bbox=16.65191,46.57794,16.65192,46.57795&page=0

A kellően kicsi befoglaló téglalappal három legyet ütünk egy csapással:

gyorsan választ kapunk a szervertől
kis adatmennyiséget kell csak mozgatnunk
nem kell lapoznunk a találatok között, valószínűtlen hogy egy négyzetméteren 5000 pontnál több legyen

Lekérjük tehát a vizsgált nyomvonal tetszőlegesen választott pontját, majd elemezzük a választ.

ha nincsenek benne pontok, akkor gyorsan megkaptuk a választ
ha vannak, megnézzük a koordinátáit
- ha van köztük olyan, ami egyezik a vizsgált pont 7 tizedesre csonkított formájával, akkor csak ezt/ezeket vizsgáljuk
- ha nincs, akkor kiszámoljuk a kapott pontok koordináta-különbségeit
a koordináta-egyezéssel szűkített listának megnézzük az időbélyegeit is, benne van-e a keresett pont
- ha egyezik az eredetivel, akkor tuti hogy ezt a pontot feltöltötték
- ha nem találjuk meg, akkor felírjuk a különbségeket, lehet hogy időzóna-eltérés miatt pontosan egy-két órával különbözik az időbélyeg

Az eredményektől függően megnézünk még egy-két koordinátát a nyomvonal teljesen más részeiről is. Ha mindegyik megvan, akkor teljesen biztosak lehetünk. Ha néhány megvan, a többi nincs, akkor lehet hogy megszűrték vagy vágták a nyomvonalat.

A végén elmondjuk a felhasználónak, hogy mit találtunk, bizonytalanság esetén döntsön. Ha éppen tömeges feldolgozást végzünk, akkor valószínűséget összehasonlítjuk a beállított küszöbértékkel és aszerint megyünk tovább.

Nem fárasztanám a gépet a gpx fájl teljes kiolvasásával, felhasználhatjuk hogy a gpsbabel és az osm api is szépen soronként formázza a szöveges állományt, így kedvenc posix/unix/linux szövegfeldolgozó parancsainkkal hatékonyan tudunk mintát venni a nagy állományokból is. Az első nyomvonalpont koordinátái így kaphatjuk meg:

$ grep -m 1 "<trkpt " track.gpx
      <trkpt lat="46.540449467" lon="16.694484567">

A fenti módszerrel ideális esetben a másodperc töredéke alatt eldönthető, hogy fel van-e már töltve az OSM nyomvonalai közé. A legnagyobb időigénye az OSM API válaszának van, addig egy kicsit pihen a gép a feldolgozás közben.

Ha nyomvonalanként (vagy azon belül fájlonként?) megússzuk néhány API lekérésből, akkor nem jelentünk különösebben nagy terhelést az OSM szervernek. A feltöltés ennél sokkal megerőltetőbb számukra. Annak érdekében hogy ne okozzunk dugót az utófeldolgozónak, úgyis be kell építenünk várakozást az automatizmusba.

kolesar-andras / turistautak-osm-track-import

korábban már feltöltött nyomvonalak felismerése #5