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: Leírás 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: Név Cím Weboldal Elérhetőség Kategória Geom String String String String Hivatkozás geom 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 DB POI kezelő alrendszer Megjelenítő alrendszer Lekérdezés Frissítés POI megjelenítés Útvonal megjelenítés Bevitel Szöveges információk Térkép megjelenítés Útvonaltervező alrendszer Felhasználói bevitel Időjárás figyelő alrendszer Útvonal tervezés Letöltés Információ elküldése
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 Név ID Geom Név Cím Weboldal Elérhetőség Geom ID Kategória Utcák Poi adatok SDO_GEOMETRY SDO_GEOMETRY 4.1.2. Segédtáblák, és kiegészítő táblák utca_id Egyirányú utcák
ID Név Szülő_POI_ID Program_ID POI_ID Kategória ID Név Utca típusok Alprogramok Ingyenes POI-k POI kategóriák a
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).