Kiskunmajsa és környéke turisztikai térinformatikai alkalmazás
Tartalomjegyzék 1. A RENDSZER RÖVID LEÍRÁSA..................................................................................................3 1.1. Elvárt funkciók: .......................................................................................................................3 1.2. Specifikáció .............................................................................................................................3 1.3. Funkciók ismertetése ...........................................................................................................3 2. RÉSZLETES SPECIFIKÁCIÓ .......................................................................................................4 2.1. Az egyes funkciók részletes leírása. ........................................................................................4 2.1.1. POI adatok, és programok kezelése..................................................................................4 2.1.2. Útvonaltervezés.................................................................................................................4 2.1.3. Időjárás figyelés................................................................................................................5 2.1.4. Költségtervezés.................................................................................................................5 2.1.5. Időbeosztás........................................................................................................................5 3. ALRENDSZEREK...........................................................................................................................6 3.1. POI kezelő alrendszer...............................................................................................................6 3.2. Megjelenítő alrendszer..............................................................................................................6 3.3. Időjárás figyelő alrendszer........................................................................................................6 3.4. Útvonaltervező alrendszer........................................................................................................6 4. ADATBÁZISTERVEZÉS................................................................................................................8 4.1. OpenStreetMap adatok.............................................................................................................8 4.1.1. Alaptáblák.........................................................................................................................8 4.1.2. Segédtáblák, és kiegészítő táblák......................................................................................8 5. MEGVALÓSÍTÁS..........................................................................................................................11 5.1. POI kezelő alrendszer.............................................................................................................11 5.1.1. Lekérdezés.......................................................................................................................11
1. A RENDSZER RÖVID LEÍRÁSA Cél: Egy olyan alkalmazás készítése, mely Kiskunmajsa és környékén segít a szabadidő eltöltésében.
1.1. Elvárt funkciók: •
Programok figyelése (rendezvények, események)
•
Útvonaltervezés (gyalog kerékpár autó)
•
Időjárás figyelés
•
Szállásadatbázis
•
Költségtervezés
•
Időbeosztás
1.2. Specifikáció 1.3. Funkciók ismertetése Programok figyelése Lehetőleg minden, a jövőben megrendezésre kerülő rendezvénynek, programnak elérhetőnek kell lennie. Keresés naptár szerűen, illetve kategóriák alapján. Legyen lehetőség programokat kiválasztani, elmenteni, visszatölteni. Útvonaltervezés Tetszőlegesen felvett pontok közötti útvonaltervezés. Kerékpárutakat, és gyalogos utakat is figyelembe kell venni. Legyen lehetőség útvonalakat menteni, és visszatölteni. Útvonaltervezés POI és programok között, illetve tetszőlegesen felvett pontok között. Részletes POI adatok POI adatok kategóriánként. Mentés, visszatöltés itt is lehetséges legyen. Időjárás figyelés Heti előrejelzés, min., max. hőmérséklet. Szállás adatbázis Szállások kiválasztásának lehetősége, szállás rögzítése. Költségtervezés Az egyes POI-knak, programoknak lehetnek költségeik (pl. belépőjegy, stb.). Legyen lehetőség ezek figyelésére, és rögzítésére is. Egyéb költségek rögzítésének lehetősége. Időbeosztás Legyen lehetőség sorrend megadására útvonaltervezéskor. Kezdési időpont megadása, illetve tartózkodási idő felvétele az egyes POI-khoz, programokhoz. Legyen lehetőség a POI-k, programok nyitvatartási idejének figyelésére is. Figyelmeztetés, ha egy POI-t akkor akar a felhasználó meglátogatni, amikor nincs nyitva. Automatikus sorrend meghatározás lehetősége nyitvatartási idő alapján.
2. RÉSZLETES SPECIFIKÁCIÓ 2.1. Az egyes funkciók részletes leírása. 2.1.1. POI adatok, és programok kezelése A POI adatok, és a programok, rendezvények együtt kezelhetők, hiszen a programok felfoghatók POI adatokként. Ezáltal csökken a rendszer bonyolultsága. A POI adatokat egy az alábbihoz hasonló táblázatban tároljuk majd. Felépítését az alábbi ábra mutatja be: Mező neve
Leírás
Típus
Név
POI neve
String
Cím
POI címe
String
Nyitva tartás
Nyitva tartás heti bontásban
Spec*
Nyitvatartási időszak
Az év mely időszakaiban tart nyitva
Spec**
Weboldal
Weboldal címe
String
Elérhetőség
Telefon, e-mail
String
Ingyenes?
Ingyenes-e?
Boolean
Kategória
POI kategóriája
Hivatkozás***
Geom
POI földrajzi koordinátái
Geom
ID
POI egyedi azonosítója
Szám (> 0)
Szülő ID
POI szülő POI-jának azonosítója
Szám (>= 0)
* Nyitva tartás: egy tömbben tároljuk el. A tömb 7*4 egész számot tartalmaz, azaz a hét minden egyes napjához 4 darab szám tartozik: nyitási óra, nyitási perc, zárási óra, és zárási perc. A tömb a hétfői nappal kezdődik. ** Hasonló tárolás elve, mint a nyitva tartás esetében: egy tömböt használunk, melyben 2*x elem van, ahol x jelenti azon időszakok számát az adott éven belül, amikor a POI nyitva tart. A tömb a következőképpen néz ki: nyitási dátum1, zárási dátum1, nyitási dátum2, zárási dátum2, … . A nyitva tartás mezőt ezek után úgy értelmezzük, hogy az érvényes minden nyitvatartási időszakra: ugyanúgy tart nyitva az első nyitvatartási időszakban, mint bármelyik másikban. *** A kategória egymással vesszővel elválasztott számokból áll (egy POI több kategóriába is tartozhat), melyek a kategóriatábla megfelelő soraira hivatkoznak. A táblázat legutolsó mezője a POI szülő POI-jára történő hivatkozást tárolja. Ennek akkor van értelme, amikor egy POI-nak lehetnek gyerek POI objektumai. Például egy rendezvényhez több program is tartozhat, ilyenkor a rendezvény lesz a szülő POI, a hozzá tartozó programok pedig a gyerek POI-k. Ha nincs szülő, a Szülő_POI értéke 0.
2.1.2. Útvonaltervezés A felhasználó a térképen pontokat hozhat létre, illetve már létező pontokat választhat ki (POI-kat, szállás) melyek között majd az útvonalat kell megtervezni, és megjeleníteni.
Az útvonalról részletes információ kérhető: • útvonal hossza • felvett pontokról információk, ha azok POI-k • becsült időtartam • költség Figyelembe kell venni az egyes útvonalszakaszok típusát is aszerint, hogy milyen járművel lehet rajtuk közlekedni. Három lehetőség van: autó, kerékpár, gyalog. Ezek egymást kizáró lehetőségek, tehát ha például egy útvonalszakasz típusa 'autó', az azt jelenti, hogy azon csak és kizárólag autóval lehet közlekedni. Ha egy útszakasz többféle típusba is beletartozik, akkor egyszerűen társítjuk hozzá a megfelelő típusokat, például: 'autó', 'kerékpár'. Lehetőséget kell biztosítani az útvonal elmentésére és visszatöltésére is.
2.1.3. Időjárás figyelés A met.hu oldalról származó időjárási adatok letöltése, és ezek hozzáadása a rendszerhez, valamint megjelenítése. Szerepelnie kell az aktuális időjárásnak, illetve az egy hetes előrejelzésnek is. Kiskunhalas időjárása lesz a mérvadó. Szállás adatbázis A szállások egy táblázatban tároljuk, melynek felépítése az alábbi: Mező neve Név
String
Cím
String
Weboldal
String
Elérhetőség
String
Kategória
Hivatkozás
Geom
geom
Típus
A táblázatot kézzel töltjük fel.
2.1.4. Költségtervezés Az útvonaltervezés előtt meg kell határozni az egyes szállások, illetve POI-k költségeit. Ez a felhasználó feladata lesz, mivel sok dolog befolyásolhatja az árakat, és ezt nem lehet minden egyes szálláshoz, POI-hoz nyilvántartani. A bevitel egy űrlapon keresztül történik, az előzőleg megadott útvonalterv alapján.
2.1.5. Időbeosztás Lehetőséget biztosítunk a POI-k sorrendjének megadására is. Az egyes POI-khoz továbbá tartózkodási időt kell rendelni. Mielőtt az útvonaltervet megjelenítenénk, meg kell vizsgálni, hogy a megadott tartózkodási idők, és nyitva tartások összhangban vannak-e, és ennek megfelelően értesíteni a felhasználót, illetve javítani a hibát.
3. ALRENDSZEREK A rendszert kisebb részekre, alrendszerekre bontjuk. Ez a következőképpen néz ki:
3.1. POI kezelő alrendszer Feladata: • Lekérdezések biztosítása: ◦ Keresés kategóriánként ◦ Adott távolságon belül levő POI-k ◦ Darabszám korlátozás ◦ Nyitva tartás alapján szűrés • Frissítés: ◦ Letöltés szerverekről ◦ Kézi bevitel Modulok: Lekérdező, Beviteli, Frissítő
3.2. Megjelenítő alrendszer Feladata: • POI-k, útvonalak, és térképek, szöveges információk megjelenítése. Modulok: POI megjelenítő, Térkép megjelenítő, Útvonal megjelenítő, Szöveges információk
3.3. Időjárás figyelő alrendszer Feladata: • Időjárás adatok letöltése, és ezek elküldése a megjelenítő alrendszer felé Modulok: Leöltő, Információ elküldő
3.4. Útvonaltervező alrendszer Feladata: • Útvonalak tervezése POI-k, és felhasználó által létrehozott pontok segítségével, illetve feltételek megadása (pl. csak kerékpárutak figyelembe vétele). • A bevitt adatok alapján az útvonal megtervezése. Modulok: Felhasználói bevitel (POI-k, feltételek, …), Tervező modul Az alábbi rajz az egyes alrendszerek, és moduljaik közötti összefüggést szemlélteti:
DB
POI kezelő alrendszer
Frissítés
Lekérdezés
Bevitel
DB
Megjelenítő alrendszer
POI megjelenítés
Szöveges információk
Útvonal megjelenítés
Térkép megjelenítés
Útvonaltervező alrendszer
Felhasználói bevitel
Időjárás figyelő alrendszer
Letöltés
Információ elküldése
Útvonal tervezés
4. ADATBÁZISTERVEZÉS A felhasznált adatbázis-kezelő rendszer : Oracle Databese 11gR2 (Windows) A rendszer az alábbi adatokat fogja felhasználni: • OpenStreetMap térképi adatok (POI-k, és utcák adatai) • Szálláshely adatok • Időjárás adatok Az adatbázist úgy tervezzük meg, hogy az egész rendszer később bővíthető legyen új szolgáltatásokkal. E célből a kezdeti táblák csak a legszükségesebb adatokat fogják tartalmazni. Amikor egy új szolgáltatás jelenik meg a rendszerben, melyhez szükség van új adatok társítására a már meglevő adatokkal, akkor egyszerűen új táblákat hozunk létre, és hivatkozunk a már meglevő adatokra. Ez okozhat némi redundanciát (az egyes ID-k a hivatkozások miatt sokszor jelenhetnek meg), de egyrészt nem kell olyan nagy mennyiségű adatot tárolni, hogy ez problémát okozna, másrészt pedig az ebből származó előny bőven kárpótol minket ezért.
4.1. OpenStreetMap adatok 4.1.1. Alaptáblák Ide az alábbi táblák tartoznak Utcák Mező neve
Típus
Név
VARCHAR2
ID
NUMBER
Típus
NUMBER
Geom
SDO_GEOMETRY Poi adatok
Mező neve
Típus
Név
VARCHAR2
Cím
VARCHAR2
Weboldal
VARCHAR2
Elérhetőség
VARCHAR2
Geom
SDO_GEOMETRY
ID
NUMBER
Kategória
NUMBER
4.1.2. Segédtáblák, és kiegészítő táblák Egyirányú utcák Mező neve
Típus
utca_id
NUMBER
Utca típusok Mező neve
Típus
ID
NUMBER
Név
VARCHAR2 Alprogramok
Mező neve
Típus
Szülő_POI_ID
NUMBER
Program_ID
NUMBER Ingyenes POI-k
Mező neve
Típusa
POI_ID
NUMBER POI kategóriák
Mező neve
Típus
Kategória ID
NUMBER
Név
VARCHAR2
5. MEGVALÓSÍTÁS Az egyes alrendszerek, és azok részeinek megvalósítási módját, valamint az alrendszerek közötti kommunikáció megvalósítását fogja ez a rész dokumentálni. Az alrendszerek, és azok részei Java nyelven készülnek.
5.1. POI kezelő alrendszer 5.1.1. Lekérdezés A lekérdező modult úgy kell megvalósítanunk, hogy az adatbázistervezéssel nyert bővíthetőség ne vesszen el. Azaz olyan lekérdező egységre van szükség, amelyhez lehetőség van lekérdezési feltételek hozzáadására dinamikusan (a modul leállítása, és „beleírása” nélkül).