Model Podstawowy

Koncepcja harmonizacji danych
przestrzennych w Polsce
dr Zenon Parzyński
• Główny Urząd Geodezji i Kartografii
• Wydział Geodezji i Kartografii
Politechniki Warszawskiej
Polska droga do INSPIRE
Jest dwuetapowa
1. „Unowocześnienie” geodezji poprzez zmiany
przepisów prawa
2. Dostosowanie danych do wymogów Dyrektywy
INSPIRE (reguły implementacyjne, a w tym
specyfikacje danych)
Uporządkowanie i
unowocześnienie „geodezji” (1)
• Instrukcje i wytyczne techniczne obowiązujące nie były
zharmonizowane ze sobą.
K1_Dzialka
G5_Dzialka
+geometriaOb : GM_Complex
+nrEwidencyjny : CharacterString
+nrAdresowy : CharacterString
+nazwaWlasna : CharacterString
+przedstawienieGraficzne : Grafika
+elementyPrzedstawieniaGraficznego : Grafika
+geometria : GM_Complex
+idDzialki : CharacterString
+idRejonuStatystGUS : CharacterString
+wartosc : Currency
+polePow : float
+doklZapisuPola : Integer
+nrRejestruZabytkow : CharacterString
+dataUplywuWladania : Date
+dataWerifikacjiDanych : Date
+dataUtworzeniaObiektu : Date
Uporządkowanie i
unowocześnienie „geodezji” (2)
• Przy opracowywaniu modeli baz danych jest
wykorzystywana:
– metodyka modelowania pojęciowego,
– zapis schematów aplikacyjnych w UML,
– zapis schematów aplikacyjnych w GML, które będą
standardami wymiany danych,
– integracja z normami ISO-EN serii 19100 (np.
geometria, topologia, jakość, metadane,
odniesienia przestrzenne).
Koncepcja Ogólnego Modelu
Geodezyjnego (OMG)
OMG_DokumentPrawny
*
OMG_ObiektRejestrowy
OMG_PrawaOgraniczeniaOdpowiedzialnosc
*
*
1..*
OMG_Osoba
*
*
OMG_OsobaGrupowa
OMG_Nieruchomosc
*
OMG_Dzialka
OMG_ReprezentacjaGeomITopol
*
*
*
OMG_OsobaPrawna
*
*
OMG_InnyObiektRejestrowy
OMG_PunktPomiarowy
OMG_Mapa
OMG_OsobaFizyczna
* *
*
OMG_Budynek
*
*
*
*
OMG_DokumentPomiarowy
*
Pachelski W., Parzyński Z. „Aspekty metodyczne wykorzystania norm serii ISO 19100 do budowy
geodezyjnych składników krajowej infrastruktury danych przestrzennych” PTIP, Warszawa, 2007
OMG w praktyce – Model
Podstawowy
Model Podstawowy
Model Podstawowy składa się z 5 modeli, w których są umieszczone
definicje klas wykorzystywanych w budowanych schematach
aplikacyjnych
Model Podstawowy Dokument
class Dokument
«CodeList»
DC_RodzajDokumentu
«DataType»
BT_Dokument
+
+
+
+
+
+
+
opis: CharacterString [0..1]
rodzaj: DC_RodzajDokumentu
status: DC_StatusDokumentuKod
sygnatura: CharacterString [0..1]
tytul: CharacterString
wydawca: CharacterString
zasobSieciowy: CI_OnlineResource [0..*]
«voidable»
+ data: Date [1..*]
+
+
+
+
+
+
+
+
+
+
+
decyzja
inny
orzeczenie
rozporzadzenie
protokol
uchwala
umowa
ustawa
wyciagZKW
zarzadzenie
zawiadomienie
«Enumeration»
DC_StatusDokumentuKod
obowiazujacy
nieobowiazujacy
class Typy podstawowe
Model Podstawowy – «FeatureType»
BT_OperatTech
Typy Podstawowe
+ dataUtworzenia: Date
lokalnyId: CharacterString
«enumerat...
BT_Baza
«DataType»
BT_Identyfikator
+
+
+
przestrzenNazw: CharacterString
wersjaId: CharacterString [0..1]
constraints
{Dozwolone znaki dla atrybutów lokalnyId i przestrzenNazw}
«DataType»
BT_Zbior
+
+
+
+
+
+
+
+
+
dataAktualizacji: Date [0..1]
dataUtworzenia: Date
opis: CharacterString [0..1]
postacElektroniczna: Boolean
rozszerzenie: CharacterString [0..*]
autor: CI_ResponsibleParty [1..*]
tytul: CharacterString
zasobSieciowy: CI_OnlineResource [0..*]
rodzajZawartosci: BT_RodzajElementu [1..*]
+
+
+
+
+
+
+
idOpracowania: CharacterString [1..*]
metadane: MD_Metadata
odniesienieDoBazy: BT_Baza
wykonawca: CI_ResponsibleParty
zasiegRoboty: LinearRing
zasobSieciowy: CI_OnlineResource [0..*]
zawartosc: BT_Zbior [1..*]
«Voidable»
+ idZgloszenia: CharacterString
+ zleceniodawca: CI_ResponsibleParty
constraints
{warunek na zasób sieciowy}
«CodeList»
BT_UkladWys
constraints
{warunek na postać elektroniczną}
{warunek na rozszerzenie}
«DataType»
BT_CyklZyciaInfo
+
+
koniecWersjiObiektu: DateTime [0..1]
poczatekWersjiObiektu: DateTime
constraints
{Koniec wersji obiektu}
«CodeList»
BT_RodzajElementu
+
+
+
+
+
+
+
dowodyIKopieDoreczen
dziennikPomiaru
inny
protokol
roboczaBazaDanych
sprawozdanieTechniczne
szkicPomiarowy
+
+
+
+
+
+
+
+
+
+
Kronsztadt60
Kronsztadt86
Kronsztadt2006
Amsterdam55
Amsterdam2000
EUREF89
ETRF2000
ETRF2008
Pulkowo42
EVRS2007
EGiB
GESUT
BDNMT
BDOrto
BDOT10k
BDOT500
BDSOG
BDZLiS
EMUiA
PRG
PRNG
PRPOG
RCiWN
BDOO
«CodeList»
BT_UkladGeod
+
+
+
+
+
+
+
+
+
+
EUREF89
ETRF2000
ETRF2008
Pulkowo42
PUWP1992
PUWP2000
PUWP1965
PUWP1942
PUWPBG
UTM
Model Podstawowy –
Referencja pomiędzy obiektami
class Obiekt przestrzenny
«FeatureType»
BT_ObiektPrzestrzenny
+obiekt
0..*
+zbior
0..*
«FeatureType»
BT_ReferencyjnyObiektPrzestrzenny
+
idIIP: BT_Identyfikator
«FeatureType»
BT_ZbiorDanychPrzestrzennych
+
idIIP: BT_Identyfikator
«voidable»
+ metadane: MD_Metadata
class Referencja pomiędzy obiektami IIP
«Union»
BT_ReferencjaDoObiektu
+
idIIP: BT_Identyfikator
BT_Obiek tPrzestrzenny
+obiekt
«FeatureType»
BT_ReferencyjnyObiektPrzestrzenny
+
idIIP: BT_Identyfikator
Model Podstawowy – przykłady
wykorzystania – nazwy geograficzne
class Miejscowość
«FeatureType»
AD_Miejscowosc
+
+
+
+
+
+
+
+
idIIP: BT_Identyfikator
cyklZycia: BT_CyklZyciaInfo
nazwa: AD_EndonimStandaryzowany
nazwaMiejscowosciWJezykuMniejszosci: AD_EndonimStandaryzowany [0..*]
powierzchnia: Area [0..1]
pozycja: GM_Point
rodzaj: AD_RodzajMiejscowosciKod
waznyDo: DateTime [0..1]
«voidable»
+ zrodloInformacji: BT_Dokument [1..*] {ordered}
+ geometria: GM_MultiSurface
+ idTERYT: CharacterString
+ waznyOd: DateTime
constraints
{Jednostka miary powierzchni}
{Ważny Do}
{Jednostka administracyjna}
{Przymiotnik nazwy dla miasta}
{Przymiotnik nazwy dla wsi}
«DataType»
AD_EndonimStandaryzowany
+
+
+
jezyk: NG_KodJezyka
nazwa: CharacterString
przymiotnik: CharacterString [0..1]
«voidable»
+ dopelniacz: CharacterString
+jestCzescia
0..1
+czesc
0..*
+NG_NazwaGeografRP
+miejsce
«Union»
BT_ModelPodstawowy::
BT_ReferencjaDoObiektu
+
idIIP: BT_Identyfikator
Model Podstawowy – przykłady
wykorzystania – mapa zasadnicza
class Mapa zasadnicza
«Union»
BT_Referencj aDoObiektu
+
+PRPOG
idIIP: BT_Identyfikator
0..*
0..*
0..*
+PRG
0..*
+EGiB
0..*
+BDOT500
0..*
+GESUT
0..*
+EMUiA
+BDSOG
0..*
0..*
0..*
0..*
0..*
«FeatureType»
MZ_OgolnyObiekt
1
+obiektKarto 1
«FeatureType»
KR_ObiektKarto
0..*
0..*
Katalog obiektów
Konkluzja
•
•
•
Krokiem w stronę dostosowania do wymogów
INSPIRE jest harmonizacja referencyjnych danych z
wykorzystaniem norm ISO-EN serii 19100
Naszym pomysłem na osiągniecie harmonizacji tych
danych jest opracowanie i wdrożenie modelu
podstawowego, który jest modelem ogólnym dla
pozostałych opracowanych schematów: EGiB,
BDOT, PRG, ZSIN i in.
Następnym krokiem ma być spełnienie reguł
implementacyjnych INSPIRE ze szczególnym
uwzględnieniem specyfikacji danych, co jest
warunkiem osiągnięcia przez zbiory danych i usługi
interoperacyjności