Informační systém o zpracování bioodpadů

V aerobních technologiích jsou využívány procesy rozkladu organického materiálu za přístupu vzduchu. Řadíme sem kompostování a technologii Bricolare.

Jedná se o technologie a procesy, které probíhají bez přístupu vzduchu. Hlavním zástupcem této skupiny je anaerobní digesce.

Při tomto procesu je bioodpad nejprve připraven na sušení mechanickou předúpravou, především předdrcením a vyjmutím škodlivých odpadů [13]. Následuje sušení a výsledný suchý produkt je tříděn a mechanicky upravován na suchý stabilizát, který je následně peletizován pro spoluspalování v uhelných elektrárnách a teplárnách.

Alkoholové kvašení je biochemický proces, při kterém jsou sacharidy přeměňovány na alkohol za přítomnosti kvasinek. Kvasinky vytvářejí enzymy, které přeměňují rostlinné cukry na ethanol a oxid uhličitý za vzniku tepla. Reálné využití technologie zpracování vhodných odpadů na bioethanol a další produkty závisí na ekonomické efektivnosti zpracovatelského závodu.

Hlavním zástupcem této skupiny je spalování.

Sem můžeme zařadit zplyňování a pyrolýzu.

Při výběru technologií jsme omezeni prostředím, kde bude portál nasazen. Webový portál poběží (stejně jako jeho předchozí verze) pod již existující doménou ecomanag.cz, na které se nachází (na doménách třetího řádu) hned několik webových projektů. Všechny tyto projekty fungují na redakčním systému YXY, který je postaven na následujících webových technologiích:

To jsou tedy tři základní stavební kameny redakčního systému YXY. Samotný redakční systém, který je v současnosti vyvíjen Janem Koprajdou, je tvořen z modulů. Vedle systémových modulů jsou základním modulem kategorie, na které můžeme vázat další moduly, například články.

V každém modulu je definována struktura databázových tabulek a příslušná aplikační logika. Výhoda modulů spočívá v tom, že do našeho projektu si můžeme importovat pouze ty moduly, které potřebujeme.

Ve vytvářené webové aplikaci pak definujeme tzv. pohledy (views), kde naprogramujeme aplikační logiku pro generování veřejných webových stránek. Prezentační logika, tedy HTML a CSS, je pak uložena v šablonách (templates).

Redakční systém YXY, který je postaven na výše zmíněném frameworku Django, poskytuje dvě různé uživatelské části. Jednak autentizovanou část, kde může přihlášený správce daných webových stránek editovat obsah a měnit různá nastavení webu a jednak veřejnou část, tedy generované webové stránky (v našem případě webový portál) přístupné všem uživatelům internetu.

Obě části systému YXY fungují ve stručnosti takto:

Pro úplnost ještě krátce popíšeme další nezbytné webové technologie, které při implementaci portálu využijeme:

Stanovení všech požadavků, které chceme implementovat, je jednou z nejdůležitějších částí analýzy a návrhu. Bez toho se neobejdeme u tvorby žádného softwarového produktu.

Samozřejmostí při tvorbě jakékoliv webové stránky by měla být dobrá přístupnost a použitelnost. Pokud vytvořený portál nebude přístupný, prezentované informace se nedostanou ke všem uživatelům, kteří je budou hledat. Lépe řečeno tito uživatelé je půjdou hledat jinam. Podobné je to s použitelností. Musíme implementovat takový portál, na kterém se uživateli podaří snadno a rychle najít nebo udělat to, co chce.

Pro splnění přístupnosti se musíme držet několika základních pravidel, především co se týká psaní zdrojového kódu XHTML. Jedná se zejména o správné vyplnění atributů alt u netextových prvků, atributů title u odkazů, správné používání sémantických značek pro nadpisy, odstavce, seznamy, tabulky a v neposlední řadě jednoduchý a snadno pochopitelný textový obsah stránek. Stránky musí být funkční i s vypnutými obrázky, kaskádovými styly a JavaScriptem. Další zásady tvorby přístupného webu najdeme například v české metodice Pravidla tvorby přístupného webu [19].

Dobrou použitelnost se pokusíme zajistit kvalitním grafickým designem portálu a logickým uspořádáním webových stránek. Vymyslet moderní, neokoukaný a zároveň dobře použitelný vzhled webových stránek není lehký úkol, ale pokud se nám to podaří, uživatelé si vzhled našeho webu zapamatují a rádi se budou vracet.

Co se týká struktury webového portálu, musíme dbát na snadno pochopitelnou navigaci, logické zanoření podstránek a zajistit, aby se uživatel při procházení stránek neztratil. K tomu nám pomůže například tzv. drobečková navigace (odkazy do hierarchicky vyšších úrovní), mapa webu, případně vyhledávání.

Dalším požadavkem na webový portál je stanovení obsahu. Co bude portál obsahovat? Jinak řečeno jaká je cílová skupina uživatelů? Z povahy portálu je cílovým uživatelem každý obyvatel České republiky. Jak už jsme uvedli dříve, portál by měl poskytovat informace o tom, jak správně třídit odpad, co se s odpadem z kontejnerů děje a jakým způsobem je dále zpracováván a využíván. Cílovým uživatelem je také každý, koho zajímají informace o společnostech zpracovávajících odpad a kontakty na ně. Těmito uživateli mohou být nejen občané, ale i firmy a organizace.

Při určení struktury celého portálu a jednotlivých sekcí můžeme částečně vyjít z původního portálu BI-OD-IS (viz „Analýza stávajícího řešení“) a především pak z kapitoly 2 – „Bioodpady“ této práce, kde jsme se zabývali základními informacemi o bioodpadech a z kapitoly 3 – „Analýza existujících portálů o bioodpadech“ o analýza portálů s podobnou tématikou. Po pečlivém zvážení budou hlavní sekce portálu následující:

Dále bude portál obsahovat odkazy na podobné portály, případně další vhodné informace. Vytvoříme také interaktivní mapu zpracovatelů odpadu, takže i tato mapa bude mít na portálu své vhodné umístění.

Co se týká uživatelských rolí, vyjdeme z toho, co nám nabízí výše zmíněný redakční systém YXY. Rozlišíme dvě uživatelské role:

Hlavní moduly redakčního systému, které budeme používat jsou dva: články a kategorie.

Po ujasnění požadavků je následujícím krokem tvorby každé webové stránky nebo aplikace vytvoření grafického návrhu. Je to možná krok nejdůležitější, protože grafický vzhled a informace v něm obsažené je to, co každý návštěvník stránek po celou dobu používání vnímá. Jaký dojem na něj vzhled udělá obvykle rozhoduje o celkovém dojmu z používání webových stránek. Důležitou součástí designu je navigace, která musí být jasně zřetelná a umístěná tam, kde jsou uživatelé internetu zvyklí – tedy nahoře v hlavičce nebo v levé části stránky.

Obrázek 4.3. Grafický návrh portálu vytvořený v editoru Gimp

Budeme vytvářet grafický vzhled domovské stránky, vzhled ostatních stránek bude podobný. Použijeme grafický editor Gimp^[15], který je volně dostupný jako open source.

Základem grafického návrhu jsou barvy. Musíme vybrat takovou paletu barev, které se k sobě budou hodit a zároveň vystihnou zaměření portálu. Jako základní barvu textu zvolíme tmavě šedou na bílém pozadí stránky. Barvu loga portálu a nadpisů vybereme zelenou (v šestnáctkovém zápisu #007700 ) a pro nadpisy barvu oranžovou (#C34400).

Barvy máme vybrány, můžeme se pustit do samotného designu. Stránky budou mít pevnou šířku, optimalizovanou pro momentálně nejpoužívanější rozlišení 1024 x 768 px. V horní části stránky bude hlavička s tématickým obrázkem, logem, vyhledávacím políčkem a hlavní navigací. Pod hlavičkou bude hlavní obsah stránek.

Zvolíme klasické dvousloupcové rozvržení – vpravo užší sloupec pro výpis méně důležitých informací a vlevo hlavní blok pro výpis článků a dalších textů. Tento blok však bude na úvodní stránce ještě rozdělen na čtyři přibližně stejně velké bloky, které budou sloužit jako rozcestník do hlavních sekcí portálu. Těmito sekcemi budou články, informace o bioodpadech, o nakládání s bioodpady a legislativa. Bude zde náhled obsahu jednotlivých sekcí a vhodné ilustrační obrázky.

V pravém sloupci budou informace o portálu, odkaz na vytvořenou interaktivní mapu, odkaz na statistiky a na jiné podobné portály. Úplně dole bude nezbytná patička s odkazy například na domovskou stránku a na mapu webu. Vytvořený grafický design můžeme vidět na obrázku 4.3 – „Grafický návrh portálu vytvořený v editoru Gimp“.

První z diagramů, který budeme vytvářet je Diagram případů užití (Use case diagram). Ten se používá pro zachycení interakce uživatelů se systémem. Modeluje se pomocí jazyka UML, což je grafický jazyk pro modelování objektů programových systémů. K jeho nakreslení použijeme volně dostupný modelovací nástroj ArgoUML^[16].

Nejprve na základě předchozí analýzy stanovíme seznam hlavních událostí, které na našem portálu mohou nastat:

Tyto události zakreslíme do Diagramu případů užití. Role Uživatel a Správce jsou vně systému a případy užití uvnitř. Viz obrázek 4.4 – „Diagram případů užití“.

Obrázek 4.4. Diagram případů užití

Diagram datových toků zachycuje nějaký programový systém jako síť procesů předávajících si mezi sebou data a plnící určité funkce. Poskytuje funkčně orientovaný pohled na systém. Nakreslíme jej modelovacím nástrojem Visual Paradigm^[17], který je pro nekomerční použití možné získat zdarma.

Vedle procesů, které mohou být dále dekomponovány na podprocesy, jsou zde terminátory reprezentující externí entity (v našem případě Uživatel a Správce) komunikující se systémem. S procesy jsou spojeny pomocí toků. Uložená data jsou modelována pomocí pamětí.

V našem případě zakreslíme především procesy editace obsahu Správcem a procesy zobrazující informace Uživateli. Základním diagramem je kontextový diagram, který poskytuje celkový pohled na modelovaný systém. Ten je zobrazen jako jeden proces komunikující s terminátory (obrázek 4.5 – „Kontextový diagram“).

Obrázek 4.5. Kontextový diagram

Následuje tzv. diagram 0. úrovně, kde jsou rozkresleny hlavní procesy případně paměti. Pro náš portál jsou to procesy pro editaci článků, kategorií a jednotlivých organizací a jeden proces pro prezentaci dat. Všechny tyto procesy používají data uložená v pamětech Články, Kategorie a Organizace, které zde také zakreslíme. Pro větší přehlednost diagramu budeme některé datové toky sdružovat do jednoho, takže například tok nová/editovaná/smazaná kategorie jsou ve skutečnosti tři velmi podobné toky (obrázek 4.6 – „DFD 0. úrovně“).

Pro každý proces z 0. úrovně nakreslíme další diagram (tzv. minispecifikaci) 1. úrovně, který představuje podrobnější specifikaci daného procesu. Zde se postupuje tak, že zakreslíme všechny nové podprocesy a zkopírujeme všechny používané terminátory a paměti z 0. úrovně.

Takže pro náš případ máme čtyři diagramy 1. úrovně – pro Evidenci článků (obrázek 4.7 – „DFD 1. úrovně – Evidence článků“), Evidenci kategorií (obrázek 4.8 – „DFD 1. úrovně – Evidence kategorií“), Evidenci organizací (obrázek 4.9 – „DFD 1. úrovně – Evidence organizací“) a Prezentaci dat (obrázek 4.10 – „DFD 1. úrovně – Prezentace dat“).

Mohli bychom pokračovat dále a vytvořit specifikaci i druhé, případně dalších úrovní, ale to už bychom pouze podrobněji modelovali aplikační logiku redakčního systému YXY.

Obrázek 4.6. DFD 0. úrovně

Obrázek 4.7. DFD 1. úrovně – Evidence článků

Obrázek 4.8. DFD 1. úrovně – Evidence kategorií

Obrázek 4.9. DFD 1. úrovně – Evidence organizací

Obrázek 4.10. DFD 1. úrovně – Prezentace dat

Pro správné pochopení oblasti (domény) bioodpadů je velmi vhodné vytvořit také konceptuální datový model. Ten nám umožní ujasnit si vztahy mezi daty, která bude portál obsahovat, a zjistit, zda nebude nutné redakční systém rozšířit o nějakou chybějící funkcionalitu.

Konceptuální (neboli pojmový) datový model se v softwarovém inženýrství používá nejen pro zachycení vztahů mezi entitami, ale také pro správné pochopení významu všech pojmů v modelované oblasti (v našem případě zpracování bioodpadů). Při modelování je kladen důraz na přesnou a jednoznačnou definici všech entit tak, aby všichni, kdo se s modelem seznámí, jej pochopili stejným způsobem.

Náš model byl vytvořen pomocí metody HIT [20]. Jejím výsledkem je jednak entitně relační diagram (ER diagram) a jednak definice entit a příslušných vazeb. Pro nakreslení ER diagramu byl použit jednoduchý open source editor diagramů Dia^[18].

Na vzniku tohoto konceptuálního datového modelu se vedle autora této práce podíleli také Milan Havel, Milan Vymazal a Jan Walter.

4.3.6.1 Definice kernel entit

4.3.6.2 Definice asociativních entit

4.3.6.3 Definice vazeb

4.3.6.4 Entitně-relační diagram

Jaká je specifická funkcionalita, kterou nedokážeme vytvořit v rozhraní redakčního systému a kterou musíme naprogramovat? Především je to komplexní titulní stránka, která bude sloužit jako rozcestník. Chceme na ní zobrazovat náhledy ostatních sekcí neboli, v řeči redakčního systému, kategorií (viz grafický návrh na obrázku 4.3 – „Grafický návrh portálu vytvořený v editoru Gimp“). Pro každou tuto sekci musíme napsat příslušný pohled.

Koncept frameworku Django, který je do značné míry založen na dědičnosti, nám to velmi usnadní. Když nahlédneme do systémových pohledů (soubor views.py), najdeme zde třídy pro různé moduly. V každé třídě je několik funkcí a jednou z nich je i funkce pro výpis dat na titulní stránce.

Pokud si nyní v hlavním adresáři našeho portálu vytvoříme svůj soubor views.py a v něm napíšeme svoji funkci pro výpis dat na titulní stránce (se stejným názvem jako v hlavním systémovém souboru views.py), tak Django bude používat tuto naši specifickou funkci. Ostatní systémové funkce, které jsme „nepřepsali“ zůstanou netknuté.

Kód bude v tomto případě poměrně jednoduchý. Podle identifikátoru id každé kategorie, kterou chceme na titulní stránce zobrazit, tuto kategorii uložíme do proměnné a pošleme její obsah šabloně starající se o zobrazování úvodní stránky (viz „Tvorba šablon“). Například pro kategorii bioodpad bude kód vypadat následovně:

Druhou specifickou funkcionalitou našeho portálu je statistika zpracování a produkce bioodpadů. V konceptuální datovém modelu (viz „Konceptuální datový model“) jsme tyto statistiky zakreslili jako asociativní entity Zpracování a Produkce.

Kde však tato data získat? V kapitole 3 – „Analýza existujících portálů o bioodpadech“, kde jsme analyzovali podobně zaměřené portály, jsme zmínili i Informační systém odpadového hospodářství (ISOH). Ten všechna tato statistická data shromažďuje. Nejjednodušší možností by tedy bylo uvést na ISOH odkaz.

Nás však zajímají data pouze o bioodpadech, ale ISOH obsahuje statistiky zpracování a produkce všech odpadů. A pak také forma, jakou jsou data v ISOH prezentována – pomocí kódů odpadů, způsobů nakládání, okresů a krajů – je pro neznalého uživatele nepřehledná. Nemluvě o přístupnosti a použitelnosti při zadávání kódů odpadů přes vyskakovací okna. Proto se nám nabízí možnost napsat algoritmus, který bude vybraná data z ISOH načítat a zobrazovat v přehlednější a srozumitelnější formě přímo na našem portálu.

Nejprve vytvoříme vyhledávací HTML formulář podobný tomu v ISOH, avšak s tím rozdílem, že uživatel bude zadávat parametry přes výběrová pole (selectbox). Navíc nebudeme uvádět pouze kódy bioodpadů (respektive metod zpracování, okresů, krajů), ale celé názvy. Pro výběrové pole s odpady se samozřejmě omezíme pouze na ty biologicky rozložitelné (jejich seznam získáme například z webu MŽP, viz [10]). Náš nový formulář budeme odesílat na stránku, která bude nalezená data zobrazovat.

Teď se vrátíme do našeho souboru views.py a v něm napíšeme algoritmus, který bude parametry zadané uživatelem zpracovávat, stahovat statistiky bioodpadů z ISOH a posílat vyfiltrované údaje příslušné šabloně pro zobrazení.

Pro naše potřeby existuje v jazyce Python knihovna urllib, kterou si do našeho souboru views.py importujeme. Tato knihovna umí uskutečnit HTTP požadavek metodou POST a odeslat jej na zadané URL. V našem případě odešleme parametry zadané uživatelem na stejné URL jako původní formulář v ISOH a dostaneme zpět celý obsah stránky s nalezenými statistikami. Nesmíme zapomenout na nastavení správného kódování. Zde je část kódu, který toto celé provede:

if request.method == 'POST':
    params = urllib.urlencode(
        {'eokres': request.POST['eokres'],
         'ekraj': request.POST['ekraj'],
         'pokres': request.POST['pokres'],
         'pkraj': request.POST['pkraj'],
         'kodp': request.POST['kodp'],
         'nakl': request.POST['nakl'],
         'ktg': request.POST['ktg'],
         'row_cnt': request.POST['row_cnt'],
         'rok': request.POST['rok']}
    )
    url = urllib.urlopen('http://isoh.cenia.cz/groupisoh/fin.php', params)
    isoh_page = url.read().decode('windows-1250')

Nyní přichází ta složitější část a to vyfiltrování požadovaných informací. K tomu využijeme regulární výrazy. Prozkoumáním stránky, kterou ISOH vrací, zjistíme strukturu HTML tabulky, ve které jsou data umístěna. Chceme z ní získat obsah jednotlivých buněk. Pro větší přehlednost, stejně jako ve formuláři, doplníme všechny kódy o celé názvy a zobrazíme data v nové, přehlednější tabulce.

Nejprve tedy regulárními výrazy načteme všechny řádky tabulky (značky <tr>), poté pro každý řádek projdeme jednotlivé buňky (značky <td>) a odstraníme přebytečné znaky (např. nedělitelné mezery) které se v kódu nachází. Vyfiltrovaná data uložíme do seznamu a odešleme k zobrazení v příslušné šabloně. Tvorba šablon je popsána v části „Tvorba šablon“. Celý soubor views.py je možné najít na přiloženém CD. Vyhledávání statistik je v portálu na adrese http://bioodpady.ecomanag.cz/statistiky/.

Šablony jsou v Djangu vlastně soubory HTML, které navíc obsahují jakousi logiku pro zobrazování dynamického obsahu. Než šablony vytvoříme, musíme nejprve „rozřezat“ náš grafický návrh do HTML a CSS kódu. Při tom musíme mít neustále na paměti přístupnost a sémantickou kvalitu kódu a používat HTML značky pouze k tomu, k čemu byly určeny. Tedy značky h1 až h6 pro nadpisy, značky p pro odstavce, značky ul pro neuspořádané seznamy a tak dále. To ocení nejen hendikepovaní uživatelé, ale i vyhledávače, které budou moci lépe indexovat obsah našeho portálu.

Vytvořením HTML a CSS kódu bychom měli dostat webovou stránku vizuálně shodnou s navrženou grafikou. Navíc budeme potřebovat ještě několik JavaScriptových souborů, například pro interaktivní menu. To bude docela rozsáhlé, proto jej pro větší přehlednost zpracujeme jako rozbalovací menu.

Toho docílíme JavaScriptovým frameworkem jQuery a jeho rozšířením Droppy^[19], které umožňuje jednoduchým způsobem změnit seznam odkazů, na interaktivní menu. JQuery využívá tzv. selektory, s jejichž pomocí je možné vybrat libovolný HTML element a přiřadit mu různé vlastnosti. Takže pokud do hlavičky stránky vložíme odkazy na příslušné skripty (jeden pro jQuery a jeden pro Droppy) a označíme si naše menu třídou navigation, tak jediný JavaScriptový kód, který musíme napsat je tento:

<script type="text/javascript">
    $(document).ready(function(){
        $(function() {
            $('.navigation').droppy();
        });
    })
</script>

Po načtení stránky (funkce ready()) se seznam odkazů změní na pěkné rozbalovací menu (funkcí droppy()). Samozřejmě myslíme i na uživatele s vypnutým JavaScriptem, kteří menu také mohou používat. Hlavní položky totiž stále zůstanou klikatelné a podpoložky jednotlivých sekcí jim zobrazíme až po navštívení příslušné sekce.

Redakční systém YXY již obsahuje základní šablony pro všechny moduly. Některé tedy můžeme využívat v našem portálu, aniž bychom je všechny museli nahrazovat vlastními. Některé však budeme muset změnit pro doplnění vlastního HTML kódu. Základní šablonou je soubor base.html. Ta představuje jakousi kostru pro všechny stránky. V ní budeme mít HTML kód pro hlavičku s menu, boční sloupec a patičku. Šablonovací systém Djanga je založen na tom, že každý významný blok stránky, například hlavičku, obsah, menu atd. obalíme značkou block s názvem bloku. Například:

{% block content %}
    obsah bloku
{% endblock %}

Když potom vytvoříme novou šablonu, která bude nějakou již existující šablonu rozšiřovat, tak v ní můžeme jednoduše změnit pouze některé bloky. Jako příklad uveďme třeba šablonu home.html pro úvodní stránku, kde definujeme pouze obsah bloku content, ve kterém je hlavní obsah stránky. Ostatní bloky, jako hlavičku nebo boční sloupec zdědíme ze základní šablony base.html. Podobné je to se šablonou main.html, která se stará o zobrazování obsahu článků, kategorií a dalších modulů. Náš portál bude obsahovat ještě další dvě specifické šablony. Jedna pro formulář sloužící k vyhledávání statistik (viz výše) a druhá pro výpis výsledků vyhledávání.

Jak už jsme zmínili v předchozích částech, šablony slouží především pro vypisování dynamického obsahu. Například hlavní menu se mění podle toho, jaké kategorie správce vytvoří a pojmenuje v administračním rozhraní redakčního systému. Podobně jako existuje výše zmíněná značka block pro definici bloků, existují i další značky, například for pro výpis dat z nějakého pole prvků, if pro podmínky a mnoho dalších, které můžeme najít v dokumentaci Djanga [21]. Pro dvouúrovňové menu by kód vypadal takto:

<ul class="navigation">
   {% for nav in left_navigation %}
   <li>
     <a href="{{ nav.get_absolute_url }}">{{ nav.get_title }}</a>
     {% if nav.get_children %}
     <ul>
        {% for child in nav.get_children %}
        {% if child.navigation %}
        <li>
           <a href="{{ child.get_absolute_url }}">{{ child.get_title }}</a>
        </li>
        {% endif %}
        {% endfor %}
     </ul>
     {% endif %}
   </li>
   {% endfor %}
</ul>

V této chvíli můžeme říci, že náš portál je po technologické stránce hotový. Zbývá již jen vytvořit v administraci všechny kategorie a naplnit je obsahem. V části „Požadavky na webový portál“, kde jsme stanovili požadavky na webový portál, jsme určili (vedle úvodní stránky) tyto základní kategorie (sekce):

Jedním z požadavků bylo vytvořit interaktivní mapu kompostáren a bioplynových stanic (BPS) podle dodaného seznamu těchto zařízení. Pro tvorbu mapy jsme zvolili webovou aplikaci Google maps^[20], která umožňuje registrovanému a přihlášenému uživateli vytvořit vlastní mapu s různým obsahem.

Pro jednodušší zanášení dat do mapy bylo nejprve nutné převést data ze souboru xls do vhodného formátu, konkrétně HTML, který aplikace Google maps podporuje. Abychom data mohli snadno automaticky zpracovat, rozhodnutí padlo na import do databáze MySQL na lokálním PHP serveru, který je možné snadno zprovoznit na libovolném operačním systému.

Soubor xls jsme nejprve uložili (v aplikaci OpenOffice) do formátu csv. Poté jsme jej převedli do formátu sql (z využítím webové aplikace^[21]) a ten importovali do databáze MySQL v aplikaci phpMyAdmin.

Díky tomuto (možná trochu komplikovanému, ale účinnému) postupu jsme získali tabulku v databázi MySQL. Poté stačilo napsat skript v jazyce PHP a vygenerovat si přehlednou HTML stránku kompostáren a BPS, a to v takové podobě, abychom mohli jednotlivá zařízení se všemi podrobnostmi snadno kopírovat do vytvářené mapy.

Pro založení vlastní mapy v aplikaci Google maps je nejprve nutné pod odkazem Moje mapy zvolit Vytvořit novou mapu, zadat název, případně popis mapy, nastavit ji jako veřejnou a poté je možné začít přidávat různé lokality na jakémkoliv místě na Zemi.

Náš postup byl takový, že ze seznamu kompostáren a BPS jsme pro každé zařízení vyhledali na mapě jeho adresu. Pokud adresa nebyla známa a nebylo možné ji ani dohledat na internetu, tak jsme místo konkrétní adresy nalezli pouze obec, ve které se dané zařízení nachází. Nalezenou lokalitu jsme pak přes volbu Uložit jako... přidali do naší mapy.

Lokalitu je poté možné upravit a přidat k ní popis, tedy v našem případě název zařízení, adresu, případně kapacitu, vstupní suroviny, které kompostárna respektive BPS zpracovává a také jméno a kontakt na provozovatele – to vše v podobně HTML kódu, který jsme si vygenerovali způsobem popsaným výše. Lokality lze odlišit pomocí ikon, které se na mapě zobrazují. Pro kompostárnu padla volba na zelenou ikonu a pro BPS na modrou. Tímto způsobem jsme do mapy zanesli přibližně 300 kompostáren a BPS, což bylo sice časově velmi náročné (zejména kvůli dohledávání neznámých adres), ale výsledkem je kvalitní a podrobná mapa.

Obrázek 4.11. Vytvořená mapa kompostáren a bioplynových stanic

Po vytvoření mapy je pak možné přes volbu Odkaz získat kód pro vložení mapy do webové stránky. Na našem portálu se mapa nachází v sekci Nakládání. Menší nevýhodou je, že pokud je položek příliš mnoho, zobrazí se jich v mapě vložené do stránek jen část. Pro zobrazení všech položek je nutné zobrazit si mapu přímo v aplikace Google maps. Ukázku mapy můžeme vidět na obrázku 4.11 – „Vytvořená mapa kompostáren a bioplynových stanic“.

Všechny podstatné části průběhu implementace a hlavní funkce portálu jsme již popsali. Pro úplnost ještě doplníme, že na portálu je možné i vyhledávat informace. K tomu jsme využili službu Vlastní vyhledávač Google^[22], který umožňuje prohledávat vybrané webové stránky pomocí Googlu a výsledky zobrazovat na zvolené stránce. Vyhledávací políčko je umístěno v hlavičce každé stránky. Nevýhodou je, že trvá hodně dlouho, než Google zaindexuje nově vytvořený web, proto bude vyhledávání plně funkční až po delší době. Mezitím mohou uživatelé pro rychlejší nalezené požadovaných informací použít mapu webu. Odkaz na ni je v patičce.

Pokud se autor snaží o dobrou přístupnost svých webových stránek, bývá dobrým zvykem umístit v patičce také odkaz na tzv. prohlášení o přístupnosti. Zde jsou obvykle popsány základní principy přístupnosti, které autor na svém webu dodržuje, případně je uvedeno, kde by mohly být s přístupností problémy.

Nyní když máme portál hotový, musíme jej ještě pečlivě otestovat, zda všechno funguje tak, jak má a jestli je jsou splněny všechny požadavky. Procházením stránek portálu zjistíme, zda správně fungují všechny odkazy. Zkusíme také pomocí nástrojů v prohlížeči vypnout obrázky, kaskádové styly a JavaScript, abychom se přesvědčili, jestli je portál plně funkční i bez těchto doplňků. Případné nedostatky odstraníme. Pro kontrolu přístupnosti se navíc dají použít automatické nástroje, například Cynthia Says^[23]. Avšak na tyto nástroje se nelze stoprocentně spolehnout, protože nám například neřeknou, zda atribut alt u obrázku má adekvátní obsah. To už musíme zkontrolovat sami.

Dalším krokem je otevření a otestování portálu ve všech nejpoužívanějších prohlížečích. Těmito prohlížeči jsou zejména Internet Explorer (verze 7 a 8), Mozilla Firefox, Google Chrome, Safari a Opera. Žádný prohlížeč totiž není dokonalý a každý může zobrazit určitou webovou stránku trochu jinak. Případné nalezené chyby opravíme.

Nakonec ještě otestujeme validitu XHTML kódu. K tomu použijeme validátor konsorcia W3C^[24]. Po zkontrolování všech stránek a opravení několika drobných chyb můžeme prohlásit kód za validní podle specifikace XHTML 1.0 Strict.