Wnioski Wykonawcy prac – Adam Augustynowicz

Transkrypt

Wnioski wykonawcy prac
„Wypracowanie i wdrożenie innowacyjnych metod integracji
danych katastralnych, mapy zasadniczej i Bazy Danych
Topograficznych oraz modernizacja usług publicznych
świadczonych przez Służbę Geodezyjną i Kartograficzną”
współfinansowanego z Mechanizmów Finansowych
Europejskiego Obszaru Gospodarczego
Zadanie: Prace eksperckie mające na celu opracowanie zintegrowanego modelu
danych katastralnych oraz mapy zasadniczej, zaprojektowanie struktury bazy
danych według przyjętego modelu danych, określenie niezbędnych standardów
technicznych dla projektu, opracowanie zasad aktualizacji Bazy Danych
Topograficznych danymi zawartymi w zintegrowanej bazie danych
Adam Augustynowicz
OPEGIEKA ELBLĄG
Dylemat modelowania

Modelując działamy w pewnej sytuacji prawnej, organizacyjnej,
technologicznej
Dążymy do tego, aby nasz model mógł być zaimplementowany
przy rozsądnym wykorzystaniu czasu, sił i środków

Oznacza to, że model musi być „REALISTYCZNY”
Dążymy do tego, aby nasz model był niezależny od zmian tej
sytuacji – chcemy, aby zarówno w obecnej sytuacji jak i w
wypadku jej zmian sam model był spójny i jednolity

Oznacza to, że model musi być „IDEALISTYCZNY”
Musimy pogodzić te dwa fakty,
musimy przyjąć pewne kompromisy…
Uwarunkowania początkowe.
INSPIRE i zmiany prawne
Uwzględniamy zasady i reguły zawarte w dyrektywie INSPIRE, oraz w projektach i
wytycznych implementacyjnych do dyrektywy INSPIRE, a w szczególności:

przechowywanie, udostępnianie oraz utrzymywanie i aktualizowanie danych
przestrzennych powinno się odbywać na tym poziomie gdzie będzie to robione
najefektywniej;
powinno być możliwe łączenie w jednolity sposób danych przestrzennych
pochodzących z różnych źródeł i wspólne korzystanie z nich przez wielu użytkowników
i wiele aplikacji;
powinno być możliwe łatwe wyszukiwanie danych przestrzennych oraz dokonywanie
oceny ich przydatności dla określonego celu.
Uwzględniamy projekt Ustawy o Infrastrukturze Informacji Przestrzennej
Wymagania organizacyjne
Co jest istotne w organizacji prac, aby optymalnie „wpasować
się” w rzeczywisty stan danych?
1
Opieramy się na analizie zakresu
tematycznego rejestrów i baz danych
prowadzonych przez Służbę Geodezyjną i
Kartograficzną, w odniesieniu do
kompetencji samorządowej i rządowej
administracji publicznej, oraz
przedsiębiorstw i jednostek
organizacyjnych gmin, powiatów,
województw i Skarbu Państwa.
2
Zachowujemy zakres informacyjny
danych w stosunku do obecnie
prowadzonych baz danych, ale też
eliminujemy zbędną redundancję danych
we wszystkich bazach danych
podlegających opracowaniu.
Staramy się zidentyfikować znaczące
atrybuty oraz usunąć nieistotne cechy
obiektów w odniesieniu do danego modelu
georeferencyjnego.
3
Zakładamy, jeśli tylko jest to realne,
wykorzystanie przez poszczególne
modele georeferencyjne Państwowego
Rejestru Nazw Geograficznych jako
głównego - źródła identyfikatorów „nazw”
obiektów (w razie potrzeby rekomendując
rozszerzenie PRNG), oraz rejestrów
Państwowego Rejestru Granic PRG i
TERYT.
4
Określamy spójne wartości
słownikowe w oparciu o
obowiązujące akty prawne,
wykorzystywane przez poszczególne
modele georeferencyjne oraz
pomiędzy modelami
georeferencyjnymi.
Produkty prac eksperckich
Raport z analizy
porównawczej
Konsultacje
środowiskowe
Specyfikacja dla OOP
Opis zasad interoperacyjności
oraz opracowanie szczegółowych zasad
logicznych i procedur organizacyjnych
wymiany danych pomiędzy bazami danych
Specyfikacja dla OMG
Specyfikacja dla PMG
Opis wytycznych i zaleceń implementacji
schematu aplikacyjnego w środowisku
relacyjnej lub relacyjno-obiektowej bazy
danych oraz wymagań dla systemów
zarządzania tymi bazami danych
Opis koncepcji identyfikatorów,
koncepcji wersjonowania,
koncepcji „nil reason”
Rekomendacje aktów prawnych
Koncepcja identyfikatorów…
BDOTMZ:
Drzewo
D1
EGB:
Budynek
B1
Zabytki:
Budynek
Z1
EGB:
Budynek
B2
Identyfikator – jak z
nazwy wynika - musi
pozwolić nam
zidentyfikować każdy
obiekt, któremu taki
identyfikator
przydzieliliśmy.
Musi mieć więc
unikalną wartość.
Zatem:
B1 ≠ B2
B1 ≠ Z1
B1 ≠ D1
Z1 ≠ D1 itd.
Założenia dla koncepcji identyfikatorów…
Lp. Założenie 1.
Każdy Obiekt IIP powinien posiadać atrybut, który pozwoli na jego identyfikowanie w jednolity sposób (atrybut ten nazywany będzie w dalszej częsci Identyfikatorem IIP). 2.
Jeśli Obiekt IIP może być użyty jako referencyjny powinien posiadać unikalną w skali całego kraju wartość Identyfikatora IIP, w innym wypadku nie powinien mieć określonej wartości Identyfikatora IIP. 3.
Identyfikator IIP musi zapewnić możliwość użycia obiektu przez inne organizacje, jako jednoznacznych referencji do obiektów. 4.
Przy opracowaniu koncepcji identyfikatorów IIP należy zachować maksymalną zgodność z koncepcją identyfikatorów wg zaleceń INSPIRE, zgodnie z Generic Conceptual Model. 5.
Struktura identyfikatora IIP powinna składać się z trzech części: a. przestrzeni nazw identyfikującej źródło danych, b. lokalnego identyfikatora, nadanego przez dostawcę danych, który musi być unikalny w ramach przestrzeni nazw c. identyfikatora wersji obiektu IIP
6.
Dla wszystkich obiektów IIP przestrzenie nazw powinny być zdefiniowane w sposób, który będzie gwarantował unikalność identyfikatora IIP (pod warunkiem unikalności lokalnego identyfikatora w ramach przestrzeni nazw).
7.
Wartość przestrzeni nazw i identyfikatora lokalnego dla obiektu IIP nie może ulec zmianie przez cały jego „cykl życia”. 8.
Identyfikator IIP nie musi dostarczać informacji, kto jest dostawcą danych dla obiektu. 9.
Struktura identyfikatora IIP powinna być tak dobrana, aby ograniczyć konieczne nakłady prac nad istniejącymi systemami (także danymi, którymi one zarządzają) niezbędne do zapewnienia zgodności z niniejszą koncepcją. Por. punkt Jednolitość identyfikatora Unikalność identyfikatora Lp. Założenie
Jednolitość identyfikatora Niezmienność identyfikatora Wartość przestrzeni
nazw i
Uniwersalność identyfikatora Budowa jednolitych dla całego identyfikatora lokalnego
dla
kraju identyfikatorów Budowa jednolitych dla całego obiektu IIP nie może
ulec
kraju identyfikatorów zmianie przez cały jego „cykl
życia”.
Budowa jednolitych dla całego 7
kraju identyfikatorów Niezmienność identyfikatora Identyfikowalność źródła danych
Uniwersalność identyfikatora Budowa jednolitych dla całego kraju identyfikatorów Zagadnienie
Niezmienność
identyfikatora
Koncepcja referencji
Referencje pozwalają wskazać obiekty powiązane pewną relacją.
Zakładamy, że jest to relacja wynikająca z logicznych uwarunkowań (nie
opisujemy w ten sposób „na siłę” relacji przestrzennych, dających się wyznaczyć z
analiz topologicznych)
np. obiekt „odcinek rzeki lub kanału” (model
TBD) może odwołać się do obiektu „ciek”
(model PRNG). Ten sam „odcinek rzeki lub
kanału” nie może wskazywać na więcej niż
jeden obiekt „ciek”, ale ten sam obiekt „ciek”
może być wskazywany przez wiele różnych
obiektów „odcinek rzeki lub kanału” a także
przez inne obiekty np. „odcinek rowu
melioracyjnego”
TBD::o2
TBD::o1
TBD::o3
Referencje
Referencje
PRNG::c1
Koncepcja wersjonowania…
BDOTMZ:
Drzewo
wersja 2
EGB:
Budynek
wersja 1
Zabytki:
Budynek
wersja 1
EGB:
Budynek
wersja 2
Oznaczenie wersji – jak
z nazwy wynika - musi
pozwolić nam
rozpoznać różne wersje
(stany) obiektów
przestrzennych.
Zatem:
wersja 1 ≠ wersja 2
a jeszcze lepiej
wersja 1 < wersja 2
Założenia dla koncepcji wersjonowania…
Lp. Założenie 1.
Każdy Obiekt IIP powinien posiadać atrybuty, które pozwolą na jego wersjonowanie w jednolity sposób (atrybuty te nazywane będą w dalszej części atrybutami wersjonującymi). 2.
Możliwość wersjonowania nie musi być wykorzystywana w danym zbiorze danych lub dla danego typu obiektu. 3.
Jeśli obiekt IIP jest wersjonowany powinna być zapewniona możliwość odtworzenie jego stanu w dowolnym momencie jego życia. 4.
W zbiorze danych przestrzennych mogą wystąpić różne wersje tego samego obiektu IIP – w takim wypadku wersje te muszą mieć takie same wartości przestrzeni nazw i lokalnego identyfikatora a różne wartości identyfikatora wersji. 5.
Koniec „życia” obiektu świata rzeczywistego musi powodować (z pewnym dopuszczalnym opóźnieniem) koniec życia reprezentującego go obiektu IIP. 6.
Schemat opisu „cyklu życia” obiektu IIP oparty jest o zasadę „celowości życia” obiektu, tj. „życie” obiektu przestrzennego trwa w celu reprezentacji obiektu świata rzeczywistego lub pewnych faktów z nim związanych (jest to zasada niezależna od własności poszczególnych, konkretnych typów obiektów). 7.
Koncepcja niniejsza nie określa aspektów wersjonowania „zewnętrznych” obiektów (danych) powiązanych z obiektem IIP zarówno w sposób jawny (zamodelowany, np. informacje o właścicielach działki EGB), jak i ukryty (niemodelowany, ale znany, np. informacje z ewidencji dróg). 8.
Zasady wersjonowania powinny być tak dobrane, aby ograniczyć konieczne nakłady prac nad istniejącymi systemami (także danymi, którymi one zarządzają) niezbędne do zapewnienia zgodności z niniejszą koncepcją. Por. punkt Jednolitość wersjonowania
Uniwersalność wersjonowania
Uniwersalność wersjonowania Opis zmian stanu obiektu w czasie Lp. Założenie
Opis zmian stanu obiektu w czasie Jeśli obiekt IIP jest
Uniwersalność wersjonowania
wersjonowany powinna
być
zapewniona możliwość
odtworzenie jegoUniwersalność wersjonowania stanu w
dowolnym momencie jego
życia.
Uniwersalność wersjonowania 3
Opis zmian stanu obiektu w czasie Zagadnienie
Uniwersalność
wersjonowania
Koncepcja reguły „nil reason”…
BDOTMZ:
Drzewo
KatIstnienia
EGB:
Budynek
KatIstnienia
Zabytki:
Budynek
KatIstnienia
EGB:
Budynek
KatIstnienia
?
Podobnie jak
identyfikowanie
obiektów wielkie
znaczenie ma dla nas
jednoznaczne,
jednolite, uniwersalne
określanie wartości
atrybutów
obligatoryjnych w
sytuacji, gdy nie ma
możliwości ich
wypełnienia
Założenia dla reguły nil reason…
Lp. Założenie
Lp. Założenie 1.
Dla każdego obiektu IIP należy określić jednolite zasady stosowania reguły „nil reason”, tj. reguły postępowania w przypadkach, w których podczas wypełniania poszczególnych wartości atrybutów obiektu nastąpi problem niemożności ich wypełnienia wynikający np. z braku informacji lub braku dostępu do informacji, lub w szczególnych przypadkach, gdy informacje nie mają zastosowania w odniesieniu do opisywanego obiektu. 2.
Zasady reguły „nil reason” powinny być tak dobrane, aby ograniczyć konieczne nakłady prac nad istniejącymi systemami (także danymi, którymi one zarządzają) niezbędne do zapewnienia zgodności z niniejszą koncepcją. 3.
Techniczne aspekty stosowania reguły „nil reason” w konkretnej implementacji modelu nie są analizowane w niniejszej koncepcji. 3
Por. punkt Dla każdego obiektuJednolitość reguły „nil reason” IIP należy
określić jednolite zasady stosowania
reguły „nil reason”, tj. reguły
postępowania w przypadkach, w
Konstrukcja reguły „nil reason” których podczas wypełniania
poszczególnych wartości atrybutów
Konstrukcja reguły „nil reason” obiektu nastąpi problem
niemożności
ich wypełnienia wynikający np. z braku
informacji lub braku dostępu do
informacji, lub w szczególnych
przypadkach, gdy informacje nie mają
zastosowania w odniesieniu do
opisywanego obiektu.
Zagadnienie
Jednolitość
reguły „nil
reason”
Znaczenie wartości typu NilReasonEnumeration
Wartość
Definicja z ISO 19136
inapplicable
there is no value
brak wartości
missing
the correct value is not readily available to the sender of this data. Futhermore, a correct value may not exist
prawidłowa wartość atrybutu nie jest znana, właściwa wartość może nie istnieć
template
the value will be available later
prawidłowa wartość będzie dostępna w przyszłości
unknown
the correct value is not known to, and not computable by, the sender of this data. However, a correct value probably exist
prawidłowa wartość nie jest znana, ale właściwa wartość prawdopodobnie istnieje
withheld
the value is not divulged
wartość nie jest ujawniona (tajna?)
other
other brief explanation
inne zwięzłe wyjaśnienie
Koncepcja dziedziczenia
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
idIIP: IdentyfikatorIIP
startObiekt: DateTime
startWersjaObiekt: DateTime
koniecWersjaObiekt: DateTime
koniecObiekt: DateTime
referencja: PowiazanieObiektow
geometria: Geometria
OOP
rodzajReprGeom: RodzajReprGeom
uwagi: CharacterString
uzytkownik: CharacterString
zrodloDanychAtr: ZrodlaDanych
zrodloDanychGeom: ZrodlaDanych
katIstnienia: KatIstnienia
OOG
rodzajdrzewa: RodzajDrzewa
informacjadodatkowa: CharacterString
Dziedziczenie atrybutów dla klasy
Drzewo z pakietu BDOTMZ…
Jak widać klasa taka dziedziczy
13 atrybutów z klas
abstrakcyjnych OOP i OOG i
wprowadza 2 atrybuty
„specyficzne dla siebie”.
Klasa Drzewo
(z pakietu BDOTMZ)
Koncepcja metadanych
Opieramy się na normach ISO 19115, 19139.
Na podstawie modelu metadanych dla serii i zbiorów danych
określonego w normie ISO 19115 oraz struktur do opisu usług
geoinformacyjnych określonych w normie ISO 19119
zdefiniowano Polski Profil Metadanych.
M
Profil ten został opracowany przez zespół ekspertów i
opublikowany przez GUGiK w lutym 2008. Celem tego
opracowania było określenie profilu metadanych w zakresie
informacji przestrzennej, spójnego z przepisami
implementacyjnymi Dyrektywy INSPIRE.
Profil gwarantuje porównywalność metadanych powstających
w różnych instytucjach i grupach zawodowych.
Zakładamy zgodność metadanych dla naszego modelu (wszystkich modeli
szczegółowych) z Polskim Profilem Metadanych.
Koncepcja słownikowania dla zbiorów i serii
Przypomnienie:
Jeśli zasób jest zbiorem danych przestrzennych lub serią
zbiorów danych przestrzennych, wtedy musi być użyte
co najmniej jedno słowo kluczowe, opisujące
właściwy temat INSPIRE (zgodnie z Aneksami I, II
lub III Dyrektywy INSPIRE) zaczerpnięty z ogólnego
wielojęzycznego tezaurusa środowiskowego (GEMET)
http://www.eionet.europa.eu/gemet
Dla każdego słowa kluczowego powinny być określone następujące elementy metadanych:
Wartość słowa kluczowego: jest potocznie używanym słowem, sformalizowanym słowem lub
frazą stosowaną do opisu danego tematu. Z uwagi na fakt, że kategoria tematyczna jest zbyt
ogólna dla szczegółowych zapytań, słowa kluczowe pomagają uszczegółowić wyszukiwanie pełnych
tekstów oraz pozwalają na wyszukiwanie strukturalnych słów kluczowych.
Standardowy słownik źródłowy: jeśli wartość słowa kluczowego pochodzi ze Standardowego
Słownika (np. tezaurusa), przykładowo z GEMET, wtedy musi być podane odniesienie do
źródłowego Standardowego Słownika.
Koncepcja jakości dla zbiorów i serii danych
Zgodnie z normą ISO 19113 jakość danych
przestrzennych charakteryzuje się określając ich
następujące cechy stanowiące elementy jakości
danych przestrzennych:
• kompletność,
• zgodność logiczną,
• dokładność położenia,
• dokładność czasową,
• dokładność tematyczną.
Jakość danych przestrzennych podaje się dla zbioru
danych przestrzennych, serii zbiorów danych
przestrzennych lub wyodrębnionego podzbioru
danych przestrzennych o wspólnych cechach
umożliwiających określenie jakości.
Koncepcja formatu wymiany danych
Przypomnienie:
OpenGIS® - Geography Markup Language (GML) jest
szczególnym zastosowaniem – tzw. gramatyką (grammar)
języka XML do opisu obiektów przestrzennych (feature).
GML
GML służy jako język modelowania systemów
geograficznych, jak też otwarty format wymiany danych,
w szczególności dla „transakcji geograficznych” w sieci
internet.
Norma ISO 19136 odpowiada specyfikacji GML 3.2.1.
Jak to jest przeważnie z „gramatykami” XML-owymi GML związany jest z dwoma
częściami – schematem, który opisuje dokument i samym dokumentem, który zawiera
konkretne dane (pewna analogia do klas i ich instancji - obiektów).
Idea interoperacyjności
w ramach Krajowej IIP i Europejskiej IIP
Baza Danych
Ogólnogeograficznych
danych georefererencyjnych
Zintegrowana powiatowa baza
Baza Danych
Topograficznych
Baza Danych
Obiektów Topograficznych
Objętych Zakresem
Mapy Zasadniczej
Baza Danych
Geodezyjnej Ewidencji
Sieci Uzbrojenia
Terenu
Baza Danych
Ewidencji Gruntów
i Budynków
Baza Danych
Szczegółowych
Osnów geodezyjnych
KRAJ
WOJEWÓDZTWO
POWIAT
Modelowane aspekty
rzeczywistości
Korporacyjny punkt widzenia. Jest najbardziej
„odgórny”. Koncentruje się na strategicznych celach,
zakresie, społecznościach korzystających z systemu.
Określa biznesowe wymagania wobec systemu.
Informacyjny punkt widzenia. Koncentruje się
na tym jakie informacje obejmuje system, jak
powinny być one usystematyzowane, zarządzane,
interpretowane.
Obliczeniowy punkt widzenia. Koncentruje się
na dekompozycji funkcjonalności systemu.
Inżynieryjny punkt widzenia. Koncentruje się na
mechanizmach niezbędnych do zapewnienia pracy w
środowisku rozproszonym.
Technologiczny punkt widzenia. Koncentruje się
na wyborze technologii (np. platforma sprzętowoprogramowa), która będzie optymalna dla systemu.
To „dziś” modelujemy!
Wykorzystano materiały z http://en.wikipedia.org
Tego „dziś” nie modelujemy!
„Reference Model of Open Distributed Processing”
(RM-ODP, ITU-T Rec. X.901-X.904 | ISO/IEC 10746).
Jeden czy wiele modeli?
Jednolity Model Danych
(JMD) jest jeden.
OOP
Częścią JMD jest
specyfikacja klasy Ogólny
Obiekt Przestrzenny (OOP)
oraz Ogólny Model
Geodezyjny (OMG), a także
szczegółowe modele
georeferencyjne.
OMG
OOG
M-EGB
Działka
M-…
…
…
Specjalizacja
poszczególnych części
„postępuje” od góry do dołu
rysunku.
Koncepcja interoperacyjności
Obiekty – identyfikacja,
powiązania, redundancje
Zasady i procedury
Czy chcemy, żeby w modelu znalazły się dwie klasy dla
reprezentacji takich samych obiektów świata rzeczywistego?
Czy dopuszczamy redundancję?
Czy budynek reprezentowany będzie przez obiekt w bazie
EGB a równocześnie ten sam budynek będzie
reprezentowany przez obiekt w bazie TBD?
Redundancja nie zawsze jest zła lub możliwa do eliminacji.
Redundancja powinna zachowywać jednoznaczność i powiązanie danych.
• Budynki w EGIB odpowiadają stanowi prawnemu
• Budynki w TBD odpowiadają stanowi w terenie
Zastosowanie takich danych może być różne…
Podsumowanie

Opracowana dokumentacja jest opracowaniem

Kompleksowym
Jednorodnym
Jednoznacznym
Spójnym
Opracowana dokumentacja może

Być podstawą do głębszej dyskusji nad zarządzaniem bazami danych
Umożliwić ocenę zależności i powiązań danych z innymi resortami
Stanowić wkład merytoryczny do standardów technicznych
Ułatwić proces ujednolicania i integracji zasobów
Ujednolicić sposób aktualizacji zasobów
Być podstawą modyfikacji systemów informatycznych przez ich twórców
Rekomendacja 1
Utworzone w ramach niniejszego projektu specyfikacje
georeferencyjnych modeli danych powinny zostać
dołączone jako załączniki do odpowiednich tematycznie
aktów prawnych dotyczących przepisów technicznych i
organizacyjnych prawa geodezyjnego i
kartograficznego.
Rekomendacja 2
Do aktów prawnych, dotyczących przepisów technicznych i
organizacyjnych prawa geodezyjnego i kartograficznego,
powinny zostać dołączone jako załączniki specyfikacje
ogólnego obiektu przestrzennego OOP oraz ogólnego
modelu geodezyjnego OMG ze względu na ścisły związek z
poszczególnymi modelami georeferencyjnymi.
Akty prawne dotyczące przepisów technicznych i
organizacyjnych innych resortów powinny uwzględniać
specyfikację ogólnego obiektu przestrzennego OOP jako
wspólnego przodka wszystkich danych
przestrzennych KIIP
Rekomendacja 3
Wymiana danych pomiędzy poszczególnymi odbiorcami i
użytkownikami danych powinna odbywać się za pomocą
plików GML.
Rekomendacja 4
Do odpowiednich tematycznie aktów prawnych dotyczących
przepisów technicznych i organizacyjnych prawa
geodezyjnego i kartograficznego, powinny zostać dołączone
jako załączniki definicje schematu GML zapisane w postaci
pliku XSD (opracowane w ramach niniejszego projektu i
dołączone do specyfikacji poszczególnych modeli
georeferencyjnych)
Aktualizacje modelu powinny uwzględniać pliki konwersji i
dostosowania danych do nowych modeli.
Rekomendacja 5
Z obowiązujących przepisów geodezyjnych i instrukcji
technicznych powinny zostać usunięte fragmenty, aneksy,
załączniki (bądź całe dokumenty) dotyczące technicznych
aspektów prowadzenia bazy danych, a mianowicie
schematu aplikacyjnego, katalogu obiektów, atrybutów,
relacji, itp.
Rekomendacja 6
W obowiązujących przepisach geodezyjnych i instrukcjach
technicznych powinny pozostać fragmenty dotyczące
reprezentacji kartograficznej jako obowiązujące.
Zgodnie z projektem ustawy o infrastrukturze danych przestrzennych (rozdział 7,
art. 22, ust. 1) punkt b)) standardowymi opracowaniami kartograficznymi,
tworzonymi na podstawie odpowiednich zbiorów danych, zawartych w bazach
danych opracowywanych w ramach niniejszego projektu są:
mapa ewidencyjna w skalach 1:500, 1:1000, 1:2000, 1:5000,
mapa zasadnicza w skalach 1:500, 1:1000, 1:2000, 1:5000,
mapy topograficzne w skalach: 1: 10000, 1:25000, 1:50000, 1:100000,
mapy ogólnogeograficzne w skalach: 1: 200000, 1:500000, 1:1000000.
Reprezentacje kartograficzne dla poszczególnych opracowań kartograficznych
zawarte są w obowiązujących instrukcjach:
dla mapy ewidencyjnej - instrukcja techniczna K-1 „Mapa zasadnicza”, GUGiK 1998,
dla mapy zasadniczej - instrukcja techniczna K-1 „Mapa zasadnicza”, GUGiK 1998,
dla mapy topograficznej - wytyczne techniczne „Baza Danych Topograficznych (TBD)”
– część 3, GUGiK 2003.
Rekomendacja 7
W aktach prawnych (odpowiednich rozporządzeniach),
dotyczących zmian przepisów technicznych i organizacyjnych
prawa geodezyjnego i kartograficznego, powinien zostać
wprowadzony okres przejściowy umożliwiający
dostosowanie istniejących baz danych do specyfikacji modeli
opracowanych w ramach niniejszego projektu. Projekty
aktów wykonawczych powinny również określać czas trwania
okresu przejściowego.
Rekomendacja 8
Wymagana jest zmiana podejścia z prowadzenia map na
prowadzenie baz danych w treści obowiązujących
przepisów geodezyjnych i instrukcji technicznych.
Mapy powinny być traktowane jako opracowania
kartograficzne wykonane na podstawie prowadzonych baz
danych.
Rekomendacja 9
Akty prawne, dotyczące przepisów technicznych i
powinny obligować organy publiczne odpowiedzialne za
gromadzenie, aktualizację lub udostępnianie danych
przestrzennych (zgodnie z projektem ustawy o
infrastrukturze danych przestrzennych (rozdział 2, art. 5,
ust. 2)) do tworzenia, aktualizacji lub udostępniania
zbiorów metadanych zgodnie ze specyfikacją zawartą w
dokumentacji modeli - OOP.
Rekomendacja 10
powinny określać organy wiodące odpowiedzialne za
organizowanie, koordynowanie i monitorowanie tworzenia i
aktualizowania zbiorów metadanych w zakresie
przyporządkowanych tym organom tematów danych
przestrzennych, zgodnie z projektem ustawy o
ust. 1).
Rekomendacja 11
Akty prawne dotyczące przepisów technicznych i
powinny obligować organy publiczne odpowiedzialne za
gromadzenie, aktualizację lub udostępnianie danych
przestrzennych do wprowadzania rozwiązań
technicznych zapewniających interoperacyjność
zbiorów i usług danych przestrzennych oraz, w
uzasadnionych przypadkach, harmonizację zbiorów
danych przestrzennych, zgodnie z projektem ustawy o
ust 1).
Rekomendacja 12
Akty prawne, dotyczące przepisów prawa geodezyjnego i
kartograficznego, powinny obligować organy publiczne odpowiedzialne
za gromadzenie, aktualizację lub udostępnianie danych przestrzennych
do tworzenia i utrzymywania, co najmniej następujące usługi danych
przestrzennych (zgodnie z projektem ustawy o infrastrukturze danych
przestrzennych (rozdział 4, art. 9, ust. 1):

usługi wyszukiwania, umożliwiające wyszukiwanie zbiorów oraz usług danych
przestrzennych na podstawie zawartości odpowiadających im metadanych oraz
umożliwiające wyświetlanie zawartości metadanych,
usługi przeglądania, umożliwiające co najmniej: wyświetlanie, nawigowanie,
powiększanie i pomniejszanie, przesuwanie lub nakładanie na siebie
zobrazowanych zbiorów danych przestrzennych oraz wyświetlanie zawartości
metadanych,
usługi pobierania, umożliwiające pobieranie kopii całych zbiorów danych
przestrzennych lub części takich zbiorów oraz, gdy jest to wykonalne, dostęp
bezpośredni,
usługi przekształcania, umożliwiające przekształcenie zbiorów danych
przestrzennych w celu osiągnięcia interoperacyjności,
usługi umożliwiające uruchamianie usług danych przestrzennych.
Rekomendacja 13
powinny obligować organy publiczne, które na podstawie
odrębnych przepisów pobierają opłaty za usługi danych
przestrzennych (usługi wymienione w projekcie ustawy o
infrastrukturze danych przestrzennych – rozdział 4, art. 9
ust. 1 punkt 2-5) do zapewnienia dostępności usług w
zakresie handlu elektronicznego (zgodnie z projektem
ustawy o infrastrukturze danych przestrzennych (rozdział 5,
art. 15, ust. 6).
Dziękuję za uwagę

Podziękowania dla osób, które zgłosiły uwagi w ramach
konsultacji branżowych