skanuj0011 (63)

INSPIRE zdefiniowano pięć podstawowych zasad tworzenia i funkcjonowania struktury danych przestrzennych:

1.    Dane przestrzenne powinny być zbierane raz i utrzymywane na tym poziomie (w tym miejscu), na którym może to być robione najefektywniej.

2.    Powinno być możliwe łączenie bez problemów technicznych danych przestrzennych z różnych źródeł w całej Europie oraz korzystanie z nich przez wielu użytkowników dla wielu aplikacji.

3.    Powinno być możliwe korzystanie z danych zgromadzonych na jednym z poziomów zarządzania przez inne poziomy zarządzania.

4.    Dane przestrzenne potrzebne do dobrego zarządzania powinny być dostępne na warunkach nie ograniczających ich powszechnego użytkowania.

5.    Powinien być także zapewniony dostęp do informacji o tym jakie dane są dostępne, czy odpowiadają one potrzebom użytkowników i na jakich warunkach cą dostępne.

Powszechny dostęp do informacji przestrzennych może być zapewniony tylko technikami on-line. Potrzebne jest do tego respektowanie wspólnych standardów, więc stworzenie wspólnej infrastruktury technicznej. Jednym z elementów takiej infrastruktury są Gcoportale i normy 150.

W pierwszym okresie tworzenia infrastruktury danych przestrzennych największe zobowiązania są przypisywane administracji publicznej na poziomie krajowym i regionalnym. Powinna ona stworzyć warunki organizacyjne, techniczne, prawne i ekonomiczne do tworzenia i funkcjonowania infrastruktury. Oznacza to, że powinna być zapewniona koordynacja działań różnych instytucji, określona zawartość danych przestrzennych, zapewnione fundusze na stworzenie i funkcjonowanie infrastruktury, określone zasady dostępu do danych oraz standardy, zapewnione warunki do kształcenia potencjalnych użytkowników infrastruktury i zainicjowane prace badawcze.

Oczekuje się, że administracja publiczna stworzy i będzie udostępniać podstawowe dane przestrzenne. Zakres podstawowych danych jest różny w różnych krajach.

We wszystkich krajach użytkownicy danych postulują, aby jak największy zakres danych był dostępny bezpłatnie, ale w każdym z krajów zakres danych bezpłatnych i ceny za dane udostępniane komercyjnie są różne.

Z inicjatywy INSPIRE wynikną niedługo określone zobowiązania dla administracji publicznej na poziomie kraju, województwa i powiatu.

Koncepcja SIPu Mazowsza powinna więc uwzględniać zobowiązania, które w zakresie infrastruktury danych przestrzennych nałoży na regiony Komisja Europejska. Wyraża się to w między innymi tym, że:

1.    Baza Danych Ogólnogeograficznych powinna być ogólnodostępna dla wszystkich zainteresowanych tworzeniem danych przestrzennych i zapewniać jednolitą osnowę geometryczną dla tematycznych baz danych w skali województwa.

2.    Bazy danych „Pokrycie terenu" i „Gleby" powinny być tworzone zgodnie z kryteriami regionalnych baz danych, przyjętymi przez agendy Komisji Europejskiej.

3.    Metainformacja według normy ISO, intranet i internet umożliwią dostęp do danych dla szerokiego kręgu użytkowników spoza Urzędu Marszałkowskiego.

4.    Prace badawcze i szkolenia stworzą szansę na dobrą jakość danych i na zwiększenie kompetencji użytkowników danych przestrzennych.

Mazoioiccki System Informacji Przestrzennej musi uwzględniać zasady funkcjonowania Państwowego Zasobu Geodezyjnego i Kartograficznego (PZGK) oraz projektowaną infrastrukturę danych przestrzennych (SDI). SD1 będzie obejmować całość danych przestrzennych na obszarze województwa, a nie tylko te, które tworzą SBDP - czyli System Baz Danych Przestrzennych. SBDP jako składnik SIPu Mazowsza będzie zawierał część danych formalnie należących do Państwowego Zasobu Geodezyjnego i Kartograficznego i ta część będzie udostępniana według zasad obowiązujących dla zasobu. Relacje między wymienionymi wyżej trzema składnikami będą przedstawione w dalszych rozdziałach.

3. Wyniki uzyskane w poszczególnych zadaniach badawczych

Zadania badawcze (było ich 10) wymieniono w punkcie 1.3. W niniejszym rozdziale są przedstawione syntetycznie założenia i cele każdego z zadań badawczych, zastosowane metody oraz uzyskane wyniki. Tam gdzie jest to uzasadnione, cele i metody badań nawiązują do rozwiązań opisywanych w literaturze. Wyniki badań opisano pełniej w raportach przejściowych i w raportach z projektów pilotowych. Łącznie te raporty zawierają ponad 1000 stron. Raportom towarzyszą CD-ROMy z danymi źródłowymi i bazami danych stworzonymi podczas testowania metod. Niniejszy tekst ze względu na objętość przedstawia tylko syntezę z wyników badań.

3.1. Określenie użytkowników i funkcji Systemu

Do niedawna w projektowaniu systemów informacji przestrzennej przeważało podejście technologiczne eksponujące wymagania sprzętowe, oprogramowanie i strukturę baz danych. Mniej uwagi poświęcano końcowym użytkownikom systemu, ich potrzebom i umiejętnościom korzystania z zaawansowanych technologii informatycznych. Rodziło to frustracje wśród użytkowników, zwłaszcza gdy oni stanęli przed barierą skomplikowanego oprogramowania. Powodowało też niepełne wykorzystanie możliwości systemów i zahamowanie ich rozwoju w instytucji.

Dlatego obserwatorzy rozwoju implementacji GIS zaproponowali przenieść akcenty z technologii na użytkownika i jego potrzeby. A. Frank |18] pisał wprost, iż należy dowartościować użytkownika i postawić go w centrum systemu. Jest to możliwe między innymi dzięki temu, że współczesne możliwości sprzętu i oprogramowania są bardzo duże i nie stwarzają ograniczeń dla GISu, a równocześnie korzystanie z oprogramowania jest coraz łatwiejsze. Więc zamiast pytań o konfigurację sprzętu i oprogramowanie, zasadnicj-sze są pytania, jak wykorzystać dla spełnienia potrzeb użytkowników setki funkcji oferowanych pr/ez oprogramowanie. Ważniejsze staje «=ię określenie, jaki produkt końcowy może otrzymać użytkownik i decydent w wyniku analiz przestrzennych i modelowania niż zdefiniowanie, jakie mają być parametry komputerów i oprogramowania.

Są już wprawdzie pierwsze próby metod badania użytkowników, zarówno w projektach typowo GISowych, jak i przy projektowaniu klasycznych baz danych, ale pełnej metodyki nadal nie ma. Najwięcej można skorzystać z tych fragmentów metodyki projektów klasycznych (nieprzestrzennych) baz danych, w których mówi się, jak dojść do logicznego projektu bazy danych. Można też przenosić analogie z innych zakresów projektowania inżynierskiego, np. z takich projektów urbanistycznych i architektonicznych, w których przedkłada się funkcjonalność nad formę zewnętrzną.

27