„Útvonalkezelés fejlesztése” változatai közötti eltérés

A lap jelenlegi, 2009. május 16., 08:50-kori változata

Fejlesztési javaslat (projektötlet), mely az alábbi problémákra és igényekre adna a lehetőségekhez képest minél jobb megoldást:

Problémák és igények

• instabilitás: az útvonalak kezelése – még a szakasz-szétbontásos öröklés ellenére is – nem stabil, azaz gyakran előfordul, hogy valaki létrehoz egy útvonalat és "kiszerkesztik alóla" a térképet. Ennek esetei pl. (de össze lehetne gyűjteni a hasonló eseteket, hátha nem gondolok mindenre):
  • egy adott helyen a térképfinomítás jegyében módosítják a topológiát (pl. egy kereszteződésből két ellentétes T elág. lesz, vagy egy T vagy Y elág.ból delta lesz), emiatt az útvonal „szétesik”. Sőt, ilyenkor gyakran megfordulnak egyes útvonalrészek, ami az itinert használhatatlanná teszi (mivel a részek irányításának meghatározása az összefüggőségen alapul).
  • egy szakaszra nem lehet „stabilan” hivatkozni az azonosítójával, mert ha a szakasz irányát megfordítják, akkor a szakasz azonosítója is az ellentétes irányt fogja jelölni. Ha a szakasz be van fűzve egy útvonalba, akkor ez automatikusan lekezelődik az összefüggőség végett (kivéve a fenti eseteket), különben viszont nem (ha pl. egy szakaszból áll az útvonal).
  • bizonyos szerkesztési műveletek (pl. egy szakasz meghosszabbítása) eleve elrontják egy útvonal konzisztenciáját.
  • ha a valóságban is változás történik, pl. egy útszakasz járhatósága az adott járművel romlik (ahhoz képest, ami alapján a felhasználó tervezte az útvonalat), vagy egy szakasz megszűnik ill. lekerítik, vagy ha jelzett út volt és most már nem az, stb. akkor az erre hivatkozó útvonal lapján a megszűnésre/módosulásra vonatkozóan nincs semmilyen értesítés vagy ajánlott kerülő lehetősége.
• útvonaltervezés korlátozottsága: csak szakaszvégponttól szakaszvégpontig lehet útvonalat tervezni, de gyakran tetszőleges POI-tól POI-ig kellene,
• itiner „üressége”, az útvonal szakaszolatlansága: az itiner sok értékes adatot tartalmaz, viszont nincs mód arra, hogy helyszíneket, névvel (akár POI-kat ikonnal) feltüntessünk rajta, az útvonal leírásba könnyen belinkeljünk útmenti fontos POI-kat, illetve hogy szakaszoljuk az útvonalat. Túra tervezésekor ez rendkívül fontos lenne, hogy tudjam, mikor hol leszek (név szerint), mettől-meddig hány óra, milyen jelzés, mit fogok ott találni, stb... Azok számára ez még fontosabb, akik nem GPS-szel túráznak, hanem egy kinyomtatott útvonal oldal +itiner alapján mennek.
  • útvonalat lehessen szakaszolni, itinerben útpontok (POI-k vagy nevek) jelenjenek meg, a táv-idő, stb. bontás ehhez is igazodjon,
  • útvonalhoz fontos POI-k vagy csomópontok kötése (linkelése) a szövegben, ezek megjelenítése az itinerben útpontként, ez alapján szakaszolási lehetőség.
• az itiner és útvonal oldal használhatóságának továbbfejlesztése
  • térkép, navigációs helyszínrajzok fejlesztése...

Megoldási javaslatok

Szlogen: „Az útvonal több mint szakaszok sorozata”: (leginkább akkor, ha valaki pl. ajánlott túrát akar feltenni, s nem egy egyszeri alkalomra szóló, temporális útvonalat).

• A szakaszsorozatnak szükség szerint (szakadás esetén mindenképp) újra kell tudnia generálódni. Ha a változás kicsi (mert csak egy helyi topológiai szerkesztés volt), akkor az újragenerálás lehet automatikus. Ha nem lehet újratervezni, vagy túl nagy eltérést jelent (pl. mert egy útszakasz megszűnt fizikailag is, vagy lekerült róla a jelzés), akkor ezt az útvonal oldalán jelezni kell, hogy „validálni kell” (újraszerkeszteni) az útvonalat. Ez utóbbi nevezhetjük a trail section számára „killer change”-nek...
• az újragenerálódás alapja az az útvonaltervezési szempont, ami alapján a felhasználó az útvonal adott szakaszát meghatározta (pl. gyalog mennyire járható, biciklis útvonal-e, milyen turistajelzés, s hasonlók). Ezért szakaszonként ezeket a szempontokat is tárolni kell.
• az útvonal nem feltétlenül összefüggő (legalábbis jelen állás szerint nem). Jelezni és tárolni kell azokat a rész-szakaszokat, amelyek összefüggnek egymással, s azokat, ahol szándékos szakadás van.

„Trip”: új útvonalfogalom, mely a route-ot felváltaná és magába olvasztaná:

• az útvonal általános paraméterei, adatai (hossz, ált.leírás, találkozási pont, fórum, stb.) a trip objektumba kerülnének.
• az útvonal ezen belül szakaszokra (trip section) lenne bontva, amelyek a leginkább megfelelnének a mostani route-nak, azzal bővítve, hogy:
  • saját útleírás-rész tartozhat hozzájuk, saját fotók is akár,
  • egy jól definiált kiinduló- és egy jól definiált végpontjuk van (POI),
  • egy jól definiált tervezési szempontrendszer alapján készültek, mely tárolódik,
  • szakaszok sorozata, mely a fenti tervezési szempontnak megfelel (nem feltétlenül a legrövidebb, mert a felhasználó a térképen is kijelölgetheti a szakaszokat, de ekkor is előre be kell állítani, hogy van-e tervezési restrikció),
  • a szakasz bármely esetben garantáltan, összefüggően és a szempontrendszernek megfelelő, a kiinduláskor létrehozotthoz képest nem „túl hosszú”, azaz nem „teljesen más” útvonallal összeköti a kiindulópontot a végponttal; vagy ha ilyen útvonal nincs, akkor invalid státusba kerül és a korábbi, még „működő” verzió adataival jelenik meg:
    • a szakaszazonosítók a fentiek alapján útvonaltervezéssel generálódnak (a POI-k miatt lehetne rész-hivatkozás is, a POI-hoz legközelebbi node-tól [?] – ez a [Turistautak logikai hálózata] c. részben szereplő NOI általánosításaként is felfogható) és letárolódnak
    • a geometria vagy legalább valamely jellemző adat (pl. hossz) cache-elésként és összehasonlításképp letárolódik,
    • ha valamely szakasz(ok) geometriája megváltozik, akkor az ahhoz/azokhoz kapcsolódó szomszédos szakaszokra (vagy kezdő- ill. végpontokra) vonatkozóan az összefüggőség ellenőrződik, és ha nem összefüggő, újragenerálódik a szakaszsorozat adott része. Ha nem lehet újragenerálni, vagy bizonyos „hasonlósági” feltételeknek nem felel meg az új a régihez képest (mondjuk jóval hosszabb, ld. a cache tárolást feljebb), akkor az a trip section „invaliddá” válik (a tárolt régi adatok alapján látható maradhat, mondjuk kiemelve) és az útvonal szerkesztőjének kell rendeznie a hibát (ha akarja). Ilyenkor az útvonal fő verziószáma nő eggyel.
• az útvonal „trip section”-jei hierarchikusan szervezhetők*, az útvonal (trip) többféle finomságú kifejtését lehetővé teendő. Ezt a kezelőfelületen egy a fájlrendszer környvtárstruktúrájához hasonló „lenyithatós” faszerkezetben lehetne megjeleníteni. [Később akár, ha különösebb teljesítményproblémát nem jelent, a trip section-ök is alábonthatók lehetnének bizonyos köztes érintett POI-k szerinti szakaszokra].
• a „trip secion”-ök kezdő- és végpontjai megjelennének az itinerben, névvel és ikonnal, ezek szakaszolnák az itinert. Valójában így az itiner több itinerből lenne így összerakva, a trip section-ök szerint.
• a trip section-ökből tetszőlegesen további új trip-ek lennének építhetők, azaz ezeket klónozni** lehetne új útvonalak (trip-ek) létrehozásához.
• a trip section-ökhöz saját útleírás is tartozik, de a határpontokon lehessen egy navigációs utasítást is adni (ez akkor lesz fontos, ha meglévő section-ökből rakunk össze útvonalat, és egyikről a másikra „át kell vezetni”) – persze ez lehet, hogy megspórolható, ha mindig klónozni kell és a szöveget módosítjuk...
• szintén fontos kérdés, hogy a hierarchia egyes szintjein kialakuló „összetett” szakaszokhoz lehessen-e általános leírást, „kivonatot adni”. Pl. ha egy hosszú, többnapos túra van egy trip-ként tárolva, akkor bizonyos szöveges információkat jó megadni naponként is...
• egy útvonal böngészésekor, különböző résztáv- és idő adatok, itinerek generálásához a trip section-ök tetszőlegesen kijelölhetők lennének egy útvonalon belül és a kijelölt trip section-ök itinere lekérdezhető lenne.

MEGGONDOLADNÓ*: a trip objektumok egymásba ágyazhatók-e és így jön létre a hierarchia, vagy a hierarchia a trip-en belül van.

MEGGONDOLANDÓ**: egy-egy trip section-re hivatkozhat-e egyszerre két útvonal, azaz ha az egyikben szerkesztik, akkor a másikban is változik (van előnye, de vigyázni kell pl. a kezdő-végpont változásokkal...?!)

További segítség lehet a trip section-ök stabil, kényelmes kezeléséhez:

• Egyes szerkesztési műveleteket ellenjavasoljunk (a térképszerk. leírást kell csak bővíteni):
  • csomópont szerkesztésnél mindig gondoljunk az esetleg átmenő útvonalakra (bármely irányból bármely irányba mehet), törekedjünk a topológiai hatás minimalizálására,
  • ne hosszabbítsunk meg szakaszt,
  • lehetőleg ne töröljünk szakaszt hacsak nem tényleg megszűnt az átjárás vagy teljesen téves irányú kapcsolat került be, próbáljuk a törlendő szakaszt beolvasztani, ha fizikailag értelmezhető,
  • ha csak lehet, ne bontsunk szét szakaszcsomópontot, hanem próbáljuk a közös node-ot áthelyezni és új szakasszal kiegészíteni (pl. T-ből delta esetében, de ha meglesz az aut. újratervezés, akkor meg inkább szét lehet bontani, mert a rsz. úgyis kiegészíti a szakadást)
• ezen kívül sok gondot okoz az irány megfordítása, ezt lehetőleg kerüljük: a szakasz iránya az egyirányúságnál és a szakaszra való hivatkozásnál egyaránt megjelenik, ezeket függetlelíteni kell egymástól (0-1-2 értékű egyir. paraméterrel, vagy a hivatkozás default irányára vonatkozó „reversed” flag-gel),

POI kapcsolása útvonalakhoz:

• a szakaszleíró (trip section) stringbe tetszőleges POI-tól (ill. koordinátától?) tetszőleges másikhoz lehessen útvonalat terveztetni (kezelése részleges szakaszhivatkozással v. temporális szakasz generálásával, vagy „POI-köldökzsinórral”, mellyel a POI-kat a mindenkor aktuális szakaszhálózathoz köthetjük [szakaszvégponthoz vagy node-hoz, ez egy indexelés-szerű, automatikusan kezelt hivatkozás lehetne minden POI-nál, a részletei még nincsenek teljesen kidolgozva]).
• a geoládák leírásaihoz hasonlóan az útleírásba is lehessen „könnyen, szépen” POI-t bekapcsolni. (később ezek a POI-k szintén megjelenhetnének az itinerben, ha megoldható...)
• a fentiek alapján, ha van a POI-val kapcsolata egy útvonalnak, akkor a POI oldalán lehessen megjeleníteni vagy lekérdezni, hogy mely útvonalak vezetnek oda.

Útvonal oldal usability fejlesztések még:

• a kis térkép „valódi térkép” legyen, vagy legalábbis egészüljön ki nagyítással, panneléssel, POI info kérés kattintással, szakasztulajdonságok lekérdezésével...
• navigációs kis képek (fordulási pontok helyszínrajzai) fejlesztése, POI-k megjelenítése, nyilak feltüntetése (északi irány és haladási irány jelölése) esetleg – aut.generált, de akár finomítható – szöveges navigációs utasítással,
• útvonal beágyazhatósága más webhelyre – „powered by turistautak.hu”: egy útvonalra való hivatkozás ne csak linkként és esetleg kézzel beillesztett képként (kis térkép, magassági profil) legyen lehetséges, hanem „panelként” be lehessen illeszteni más weboldalakba, partneroldalakba, akik túrákat, útleírásokat, megközelíthetőséget ajánlanak. Hogy az útvonal adatait ne kelljen duplikálni a másik weboldalon és az útvonal változásakor a mindenkori aktuális itiner, adatok jönnenek be, valamint a tu.hu-n lévő fórum és képfeltöltési lehetőséget jobban propagáljuk.
  • ki kellene dolgozni egy panel modul funkcionalitását, amit a tu.hu által bármely útvonalhoz generált HTML kódként, a tu.hu-ra hivatkozva be lehet szúrni. Ez akár több méretben (minimál, kifejtett), vagy paraméterezhető módon, különböző elrendezésű és finomságú tartalommal lenne megtöltve (pl. név, táv-szint, gyalog/bicikli, nehézség, mag.profil kicsiben, mikor frissült, akár kis térképpel), minél kisebb helyen, kattintható elemekkel, amik a tu.hu funkcióit hívják meg ill. az útvonal tu.hu-s lapjára linkelnek rá. Mivel az útvonalak nem gyakran változnak, cache-elni is lehetne ennek tartalmát, részben vagy egészben. Lehetne regisztrációhoz is kötni, a Google API-hoz hasonlóan.

MEGJEGYZÉS: A fenti szövegben POI-k helyett NOI is érthető, ha a Turistautak logikai hálózata is megvalósul, s ekkor a „trip section” helyén állhat „trail section” is (a user választása szerint).

KÉSŐBBI FEJLESZTÉSI LEHETŐSÉG? nyelvfüggetlen navig.utasítások generálása, walkonweb.org kapcsolat...?

Típusreform vonzata: nincs!