search

kolesar-andras / turistautak-osm-api

turistautak.hu osm api
GNU General Public License v2.0
8 stars 5 forks source link

kettős api osm és turistautak.hu adatok egyesítésére #3

Open kolesar-andras opened 9 years ago

kolesar-andras commented 9 years ago

Készíthetnénk olyan apit is, ami friss osm adatot hoz le turistautak.hu adatokkal kiegészítve. Egyetlen letöltés kiváltana egy csomó műveletet:

Működése: a lekérés elején leszedi az osm api felől saját maga az adatot, nem kell tükör-adatbázist tartani. Ha esetleg besokall az api az egy IP címről történő sok lekérésre, akkor működhet replika-példányból is, de ennek kiépítése sok munkát és erőforrást igényel.

A fenti lista utolsó elemét, az osm objektumokhoz való illesztést részletezem alább:

A híd és kilométerkő itt az osm útra vonatkozik, viszont ugyanez az ötlet használható az eredeti apinál is, ott nyilván csak a turistautak.hu vonalára.

Az osm adatokkal is dolgozó változatnál is hasznos, ha a hidat mindkét vonalba beépíti, mármint az osm és turistautak.hu vonalba egyaránt, már ha van mindkettő. Sok út ugyanis egyáltalán nincs meg az osm-en, ekkor jól jön, ha a turistautak.hu vonalán már rajta van a híd.

A szerkesztő számára ez úgy tud megjelenni, hogy a letöltés máris tartalmaz egy csomó modified objektumot. Ilyen lesz az összes turistautak.hu-ról jövő elem, az új objektumokat jelentő negatív azonosítóval, valamint a röptében módosított osm objektumok az eredeti pozitív azonosítóikkal, vonalak vágása esetén részben újként.

A különböző forrású adatok közti szűrés megkönnyítésére javaslom, hogy kapjon minden változott objektum egy címkét, benne az elvégzett művelet leírásával. Legjobb, ha ez a címke nagybetűs, amelyet a feltöltés előtt a többi nagybetűs turistautak.hu címkével együtt kitörlünk. Kicsit általánosabban: ASCII kódja a kis 'a' előtti (mert a JOSM eszerint rendezi a címkéket), például a zárójellel kezdődő kulcs még a nagybetűseket is megelőzi.

Egy híd poi alapján elvágott vonal ezt kapná:

(automatikus híd)=poi 12345 alapján
bridge=yes
layer=1

Az apik közötti váltás teljesen szükségtelenné válik, ha a feltöltési műveleteket átirányítjuk vagy proxyzzuk az osm szerver felé. Így formailag a turistautak.hu szerver felé indul a lekérés, de az osm szerver végzi el.

Ugyanígy tudjuk megoldani, hogy a nyomvonalak letöltését is kiszolgálja ez a felület: egyszerűen továbbítja a kérést az osm szerver felé.

Javaslat a szolgáltatás címére: http://turistautak.hu/api-osm

nemethtamas commented 9 years ago

Szóval, ha jól értem, akkor ez az API lehúzná először az OSM felöl a kívánt területről az adatokat, majd hozzáadná a tuhu adatbázisából is ezt a területet, a tuhu adatokat osm módra felcímkézi, és egy rétegben tálalja a JOSM szerkesztőben? Ezzel nekem személy szerint az lenne a gondom, hogy hirtelen nem látnám át, hogy mi az, ami frissen került ide, és mi jött az osm-ről, bár gondolom, ez megoldható lenne egy térképrajz stílussal, ami kiemeli a tuhuról a frissen jött objektumokat. A másik a POI egyesítés: tegnap próbaképpen egy terülteken csak vadászleseket másoltam át tuhu apiról az osm-be. Ekkor jól jött volna, ha találok valami olyan plugint, ami jelez, hogy két hasonló poi van egymás közelében, viszont az automatikus egyesítés szerintem okozhat gondot is, pl. ha egy kisebb területen, mondjuk egy száz méteres sugarú körben van három névtelen forrás, a tuhu-n pedig kettő, akkor nem lenne könnyű ezt eldönteni scripttel. A harmadik: ha kézzel, kisebb adagokban másolgatjuk át mondjuk az utakat, van idő, és lehetőség pl. a műholdtérképpel összevetni, és javítani a geometrián

A negyedik: az én nagyon amatőr tudásomtól egy ilyen api felépítése annyira messze van, hogy még csak a segítségemet sem tudnám felajánlani :D

kolesar-andras commented 9 years ago

Igen, egy rétegben tálalná. Címkék alapján stílussal megkülönböztetve, szűrhetően.

A poi-k egyesítésére szerintem némi gyakorlati tapasztalattal tudunk jó algoritmust készíteni. Amúgy meg ellenőrizhető a működése, az automatizmusban érintett mindkét forrás lejönne egyértelműen felcímkézve:

A osm poi eredeti helyén, felcímkézve turistautak.hu url-lel és esetleges plusz tulajdonságokkal, például a forrás nevével, plusz hogy mi történt:

(kiegészítve)=node 123456789 és poi 12345

Mellette pedig a turistautak.hu poi is az eredeti helyén, ezzel a címkével:

(felhasználva)=node 123456789 és poi 12345

Ha jól teszi a dolgát, akkor a (felhasználva)=* címkéjűeket egy mozdulattal lehet törölni. Ha olyat egyesített amit nem kellett volna, akkor az osm pont visszaállítható, a turistautak.hu-ról jött pont meg felhasználható másképpen.

Ahogyan írod, továbbra is kisebb adagokban, műholdképpel és nyomvonalakkal összevetve használnánk, csak a feladat kézimunka-igényét csökkentenénk jelentősen.

grinapo commented 9 years ago

Nekem az vált be eddig a tesztelés során hogy két rétegben van a két lehívott db, osm-re megyek és nézem hogy a háttérben szürkével mit látok a tuhu rétegen. Ami kell az copy/paste, majd illesztem. Én biztos nem használnám ezt az automatikusan egyesített réteget mert nem tudom egyszerűen kontrollálni az átfedéseket. (Lehet hogy lehetne egy JOSM stílust csinálni neki [hogy azonnal látszódjon a tuhu source adat] de ezzel még kísérleteznem kell.)

nemethtamas commented 9 years ago

"Lehet hogy lehetne egy JOSM stílust csinálni neki [hogy azonnal látszódjon a tuhu source adat] de ezzel még kísérleteznem kell" Én is ilyenen gondolkoztam, szerintem a mostani címkeszeparátort alkalmazva rögtön ki lehet szúrni, ami frissen lett átemelve, és tartalmazza a tuhu címkéket http://heyjoe.hu/tuhuimport.mapcss

kolesar-andras commented 9 years ago

Kipróbáltam az osm apira való átirányítást, működik. Annak érdekében, hogy a változás ne okozzon gondot a szerkesztőknek, ez a lehetőség csak módosított api url használatával működik:

http://turistautak.hu/api-osm

Ezen a címen csak a térképadatok letöltését szolgálja ki a turistautak.hu, valamint az üres lekérést, amelyben elmagyarázza a használatát. Minden mást továbbít az éles osm api felé.

A legtöbb osm szolgáltatás működik tehát akkor is, ha a fenti turistautak.hu api van beállítva:

A feltöltéseket még nem sikerült átirányítanom, a JOSM nem veszi figyelembe a HTTP átirányítást, pedig próbáltam 301, 302, 303, 307 kódokkal is. Minden bizonnyal azzal függ össze, hogy a feltöltések nem GET, hanem PUT lekérések formájában mennek. A szerver jól válaszol, szerintem a JOSM vagy az általa használt Java összetevő nem kezeli megfelelően.

nemethtamas commented 9 years ago

Nekem ezzel az API címmel csak a tuhus adatok jönnek, és OSM nyomvonalak, pedig, ha jól értettem, az som adatoknak is jönnie kellene?

kolesar-andras commented 9 years ago

Még csak az első lépésnél tartok az alábbi négyből.

  1. Az adatletöltésnél (GET /api/0.6/map) csak turistautak.hu-ról dolgozik. A többi fajta lekérést átirányítja az osm felé. Ahogyan tapasztaltad, a nyomvonalak (GET /api/0.6/trackpoints) már az osm-ről jönnek.
  2. A következő lépés az lesz, hogy az api lekéri ugyanazt a befoglaló téglalapot az osm-ről is, a kimenő adatban a kettőt összefűzve adja ki.
  3. Értelmezi az osm tartalmat annak érdekében, hogy a közös töréspontok ne duplázódjanak meg. Ez különösen akkor fontos, ha már van turistautak.hu-ról átvett vonal a letöltésben, így az osm node pontosan ugyanott van, mint ahová a turistautak.hu adat mutat.
  4. A beállított szabályrendszer alapján az osm adaton is módosít, ekkor tud például hidat tenni osm útra.
nemethtamas commented 9 years ago

Értem. Akkor jelentem, eddig működik :)

kolesar-andras commented 9 years ago

A második lépés eléréséhez elég volt 10 sort írnom. Most már lejön az osm adat is.

Jó hír, hogy a feltöltés is működik ugyanezen az apin keresztül. Amikor először próbáltam, valami központi szerverhiba lehetett, mert közvetlenül is az is 500 Internal Server Error-t mondott.

nemethtamas commented 9 years ago

Igen, szépen jönnek már mindkét adatbázis vonalai.