implementacija web baziranog geografskog … web baziranog geografskog informacionog sistema u...

Unapređ enje upravljanja zemljištem na nivou lokalnih samouprava u Srbiji

IMPLEMENTACIJA WEB BAZIRANOG GEOGRAFSKOG INFORMACIONOG SISTEMA U SRBIJI

City of Čačak

Implementacija WEB baziranog geografskog informacionog sistema u Srbiji

2

mailto:[email protected]

http://www.ambero-icon.rs/


3

Stručno mišljenje

o

implementaciji WEB baziranog geografskog informacionog sistema u Srbiji

Na osnovu iskustva iz pilot projekta u Čačku

Verzija 1.0

Dr. Joachim Benner [email protected]

Dezembar 2014


4

Sadržaj

1 Zadatak i pregled .......................................................................................................................................................... 5

2 Zahtevi iz INSPIRE direktive .......................................................................................................................................... 5

3 Modeli i formati podataka o korišćenju zemljišta ........................................................................................................ 6

3.1 Uopšteni zahtevi za ISO 191xx konformne modele podataka ............................................................................. 6

3.2 INSPIRE kompatibilni modeli podataka o korišćenju zemljišta ............................................................................ 8

4 Model podataka grada Čačka - analiza i predlozi za poboljšanje modela .................................................................... 9

4.1 Model podataka grada Čačaka, verzija 1.0 (mart 2014) ...................................................................................... 9

4.2 Sadržajne i formalne slabosti modela u verziji 1.0 .............................................................................................. 9

4.3 Model podataka Čačak, verzija 2.0 (septembar 2014) ..................................................................................... 11

4.4 Posledice nesprovođenja datih predloga .......................................................................................................... 11

5 Predlozi o daljim aktivnostima ................................................................................................................................... 11

5.1 Revizija i dorada modela podataka ................................................................................................................... 12

5.2 Testiranje primene modela podataka ............................................................................................................... 12

6 Rezime ........................................................................................................................................................................ 14

7 Referenzen ................................................................................................................................................................. 14

PrilogA: Dokumentacija modela podataka i predlozi za njegovo poboljšanje .................................................................... 16

A1: Modelovanje plana kao jedne celine ............................................................................................................................ 16


5

1 Zadatak i pregled

Grad Čačak od 2011.Godine, u okviru GIZ-projekta "Unapređenje upravljanja zemljištem na nivou lokalnih samouprava u Srbiji" zajedno sa AMBERO/ICON, realizuje pilot projekat daljeg razvoja komunalnog informacionog sistema zemljišta. Grad Čačak je u okviru ovog pilot-projekta između ostalog razvio i UML model podataka za konceptualno modelovanje prostornih podataka (model podataka Čačak, verzija 1). Ovaj model je, u okviru jedne radionice spovedene u aprilu 2014., podvrgnut kritičnoj analizi u okviru koje je iznet set konkretnih predloga za formalne i sadržajne izmene. Na osnovu ovih predloga grad Čačak je tokom 2014. godine razvio verziju 2 ovog modela podataka.

Ovo stručno mišljenje se može, u skladu sa projektnim zadatkom, sažeti u nekoliko tačaka:

Kratak rezime o rokovima i sadržaju zahteva koji proizilaze iz implementacije INSPIRE direktive, specijalno za temu prostornog planiranja (poglavlje 2);

Uopšteni uvod u formalne zahteve za ISO 191xx konformni model podataka (poglavlje 3.1);

Kratak uvod u sadržaj INSIPRE modela podataka za "Planirano korišćenje zemljišta" (INSPIRE PLU) (poglavlje 3.2);

Kratak pregled sadržaja i strukture modela podataka u Čačku u verziji 1 (poglavlje 4.1), kao i identifikovane i u ra-dionici navedene slabosti i greške u tom modelu (poglavlje 4.2);

Rezime o stepenu korigovanja identifikovanih slabosti i grešaka korigovanih u verziji 2 (poglavlje 4.3);

Ocena očekivanih posledica u slučaju da model podataka ne bude dalje revidiran (poglavlje 4.4);

Predlozi za moguće metode revizije, testiranja i implementacije modela podataka (poglavlje 5). U prilogu A su detaljno navedene identifikovane slabosti i greške modela podataka u verziji 2 kao i konkretni predlozi za njihovo otklanjanje.

2 Zahtevi iz INSPIRE direktive

INSPIRE (INfrastructure for SPatial InfoRmation in Europe) je stupila na snagu 15 maja 2007 godine kao direktiva Evropske Unije (EU 2007). Cilj ove direktive je da se u Evropi uspostavi jedinstvena infrastruktura prostornih podataka kao podrška zajedničkim odlukama u domenu politike zaštite životne sredine. U praksi INSIRE poziva na jedinstven opis prostornih podataka kao i na njihovu dostupnost na internetu sa mogućnošću pretraživanja, vizualizacije i preuzimanja. Podaci takođe moraju da budu u jedinstvenom formatu. EU direktive moraju biti prenete u nacionalno pravo od strane svih država članica i to u roku od dve godine. EU direktiva pruža pravni okvir za izgradnju infrastrukture prostornih podataka. Ova direktiva definiše profesionalne teme koje su pogođene INSPIRE direktivom u tri aneksa (aneks I - aneks III). Tema "planirano korišćenje zemljišta" pada pod INSPIRE Annex III, tema "Planned Land Use" (INSPIRE PLU). Stručne i tehničke pojedinosti o uspostavljanju i korišćenju infrastrukture prostornih podataka reguliše EU sa 5 pravila implementacije (Implementing Rules (IR)), koja su za države članice obavezujuća. U daljem tekstu sledi kratki pregled IR sadržaja. Metapodaci su podaci koji apstrahovano opisuju geo-podatke i servise geo-podataka jedne prostorne infrastrukture. Oni pomažu pronalaženju potrebnih informacija i daju važne osobine, na primer namenu. INSPIRE pravila implementacije za Metapodatke (EU 2008) su stupila na snagu 24.12.2008. Tehnički detalji o stavljanju ovih podataka na raspolaganje su definisani u pratećem dokumentu (INSPIRE 2013). Metapodaci moraju od 31.12.2014. da se stave na raspolaganje i za zapise iz aneksa III za profesionalne teme. Pravila implementacije vezana za interoperabilnost setova prostornih podataka i njihovih usluga definišu jednake modele podataka za sve 34 INSPIRE geo-teme. Za temu INSPIRE PLU u aneksu III je relevantna uredba (EU 2013). Za implementaciju ove direktive važe sledeći termini:

Novo prikupljeni, odnosno restrukturirani setovi prostornih podataka moraju do 21.10.2015 da budu predati u INSPIRE formatu.

Svi setovi prostornih podataka koji postoje na dan 10.12.2013 moraju do 21.10.2020 da budu predati u INSPIRE formatu.

Deo tehničke arhitekture INSPIRE-a se sastoji iz infrastrukturnih komponenti, čiji je konkretni dizajn definisan pravilima implementacije za mrežni servis (EU 2009, EU 2010). Kod komponenti se radi o servisu geo-podataka "pretraga" i "rezultati pretrage" u setovima geo-podataka (usluge pretrage), o vizualizaciji setova geo-podataka (usluge prikaza) i o preuzimanju setova geo-podataka (usluge download-a). U pripadajućim pratećim dokumentima su definisani tehnički detalji za implementaciju usluga pretrage (INSPIRE 2011), usluge download-a (INSPIRE 2013b) i usluge prikaza (INSPIRE 2013c). Od 03.12.2013. svi relevantni setovi podataka iz aneksa III, vezani za usluge prikaza i usluge download-a (trenutno još nisu u INSPIRE formatu), moraju da budu predavani u INSPIRE format.


6

U INSPIRE pravilniku o implementaciji Data and Service Sharing su definisani konkretni zahtevi za modele licenci u svrsi korišćenja INSPIRE-podataka i usluga. Odgovarajuća direktiva (EU 2010a) je na snazi od 19.04.2010. Države članice su se obavezale da će redovno izveštavati o uspostavljanju i korišćenju svoje infrastrukture prostornih podataka, kao i o statusu sprovođenja INSPIRE direktive. U tu svrhu se svake godine objavljuju rezultati za infrastru-kturne elemente i sadržaje, kao i setovi geo-podataka i mrežnog servisa u kojima se Metapodaci prikupljaju, analiziraju i objavljuju (Monitoring). Odgovarajuća direktiva od strane EU je stupila 5.6.2009. na snagu.

3 Modeli i formati podataka o korišćenju zemljišta

Pod modelom podataka se uopšteno podrazumeva jedan formalan opis objekta iz određene grupe sa svojim osobinama (atributima) kao i međusobnim vezama (Relationships). O konceptualnom modelu podataka se govori, ukoliko se ovaj opis uzima nezavisno od konkretne implementacije u neki uopšteni programski jezik poput Unified Modelling Language (UML) (OMG 2014). Prednost konceptualnog modelovanja je ta da se iz ovakvog modela, eventualno sa automatskim softverskim alatima ako ShapeChange (ShapeChange 2014), mogu izvesti različite implementacije kao formati podataka, šeme baza podataka ili katalozi vrste objekata.

Ključni funkcionalni zahtev kod jednog modela podataka je da predviđena oblast može biti prikazana u potpunosti i bez problema. Za ovaj konkretan projekat to znači da model mora da prikaže sadržaj svih relevantnih planova o korišćenju zemljišta u Srbiji tako, da je moguće korišćenje svih aplikacija vezanih za različite digitalne karte. Pod ovim se posebno podrazumeva automatska transformacija digitalnih planova u INSPIRE PLU format.

Model podataka ne sme biti ograničen na samo pojedine planove. Za jedno održivo korišćenje trebaju svi planovi jednog tipa (na primer razvojni planovi ili planovi o korišćenju zemljišta) da budu obuhvaćeni i to na nivou cele zemlje. Ovo se ne odnosi samo na već postojeće, konačne planove, već i na sve u načelu izvodljive i razumne, a u skladu sa pravnim propisima, buduće planove.

3.1 Uopšteni zahtevi za ISO 191xx konformne modele podataka Serija standarda 19100ff od "International Organization for Standardization" (ISO 191xx) se bavi konceptualnim modelom podataka i formatima razmene prostornih podataka. Ovde se posebno ograničava UML-standard (ISO 191xx UML-Profil). Automatski izvod jednog XML baziranog formata podataka iz UML-modela je dozvoljen. Ovako generisana XML-šema je zasnovana na ISO Norm 19136 - Geography Markup Language (GML), verzija 3.2.1. Ona je istovremeno i zvanični standard kod Open Geospatial Consortium (OGC), (OGC 2007). ISO 19136 definiše detaljna pravila za transformacije iz UML na XML-šeme. Najvažnija pravila i ograničenja kod ISO 191xx profila će se u nastavku ukratko objasniti. Za bolje razumevanje služi ilustracija 1, koja pokazuje jedan tipični, ISO-konformni UML-model. 1. pravilo: Model podataka je kreiran kao UML-klasni dijagram. 2. pravilo: UML-paketima i UML-elementima mora da se dodeli jedan Stereotype (na primer featureType UML-elementa FeatureClassA u ilustraciji 1). Pri tome se smeju koristiti samo odeđene oznake koje jedan UML-elemenat dodeljuju samo jednoj određenoj konceptualnoj kategoriji. Detalji se mogu naći u tabeli 1. Kod ilustracije od UML na XML-šemu je svakom Stereotype dodeljena jedna posebna XML-šematska osnova. 3. pravilo: UML-elementi mogu da imaju atribute. Njima se mora dodeliti jedan tip atributa. Tipovi atributa moraju da budu ili definisani u okviru modela podataka (CodeListValue i EnumerationValue u ilustraciji 1), ili se mora koristiti tip atributa koji je definisan u ISO 191xx (GM_Measure, GM_MultiSurface, Integer iCharacterString u ilustraciji 1). U tabeli 1 su prikazani najčešće korišćeni ISO-tipovi. Potpuni model korišćenih tipova podataka je napra-vljen od strane radne grupe ISO TC 211 kao UML-model (ISO TC 211 Harmonized Model) u EnterpriseArchitect-formatu (ISO 2014). 4. pravilo: Relacije između UML-elemenata se modeluju korišćenjem funkcionalnosti veza. Njima se obavezno dodeljuje jedno ime (relationName u ilustraciji 1). Za dozvoljene tipove podataka kod veza važe ista pravila kao i za atribute. Tipovi moraju ili da se definišu u modelu podataka ili da budu usaglašeni sa ISO standardima. 5. pravilo: Atributima i vezama se može opciono dodeliti kardinalnost. Kardinalnost daje informaciju da li jedan atribut / veza postoji samo kao opcija ili je obavezna i da li je zauzeta samo jednom ili više puta. Ako kardinalnost nije određena, onda je atribut / veza definisana kao obavezna i može da bude definisana samo jednom.


7

6. pravilo: Za UML-pakete, UML-elemente, atribute UML-elemenata, kao i za funkcionalne veze, definisan je set parametara (Tagged Values) kojima je detaljno određeno kreiranje XML-šeme iz jednog UML-modela. Najvažniji parametri su dati u Tabeli 3.

Ilustracija 1. Primer jednog ISO 191xx konformnog UML-modela

Stereotype Relevantno za Koncept

applicationSchema UML-pakete Modeluje jednu sveukupnu GML-korisničku šemu koja ima sopstveno prostorno ime i koja se memoriše u formi XML-šema file.

featureType UML-elemente Modeluje jedan nezavisan, event. prostorno referentan objekat prema ISO 19109.

dataType UML-elemente Modeluje jedan kompleksan tip podataka kao agregaciju vrednosti atributa, koji ne reprezentuje nezavisan objekat.

enumeration UML-elemente Modeluje jednu fiksnu listu (Enumeration) od tekstualnih identifikatora, koji su definisani u okviru šeme. Jedan atribut, čiji tip podataka poseduje Stereotype enumeration, može preuzeti samo one vrednosti koje su prikazane u listi.

codeList UML-elemente Modeluje jednu fleksibilnu listu (Codeliste) od tekstualnih identifikatora, koja se po pravilu memoriše eksterno kao GML- Dictionary. UML model može da zada vrednosti Codeliste, i ona može u svakom trenutku da se proširi.

Tabela 1: Najvažniji Stereotype prema ISO 19136

Jednostavni tipovi podataka Izvedeni tipovi podataka Datum i vreme Geometrija

Tip Značenje Tip Značenje Tip Značenje Tip Značenje

Integer Ceo broj Length Dužina Date Datum GM_Object Uopštena geometrija

Decimal Decimalni broj Area Površina Time Vreme GM_Point Tačka

CharacterString Niz znakova Volume Zapremina DateTime

Datum / vreme

GM_MultiPoint Multi-tačka

Boolean Prava vrednost Angle Ugao (stepen) GM_Curve Linija

URI Internet-URN Measure Vrednost sa jedinicom mere

GM_MultiCurve Multi-linija

GM_Surface Površina

GM_MultiSurface Multi-površina Geometrie

Tabela 2: Najčešći tipovi podataka u ISO 191xx normama

«featureType»

FeatureClassA

+ geometryAttribut: GM_MultiSurface

+ intAttribut: Integer

+ textAttribut: CharacterString [0..1]

«featureType»

FeatureClassB

+ codeListAttribut: CodeListValue [0..1]

+ enumAttribut: EnumerationValue [0..*]

«enumeration»

EnumerationValue

enumWert1

enumWert2

«codeList»

CodeListValue

«featureType»

FeatureSuperClass

+ measureAttribut: GM_Measure

+relationName

0..*


8

«featureType»

SpatialPlan

«featureType»

ZoningElement

«featureType»

SupplementaryRegulation

«featureType»

OfficialDocumentation

Tagged Value Relevantno za Značenje

targetNamespace applicationSchema Namespace generisane XML-šeme

xmlns applicationSchema Namespace-skraćenicegenerisane XML-šeme

xsdDocument applicationSchema Ime generisanog XSD-file

asDictionary codeList Ako jeasDictionary == true, onda se Codeliste memoriše kao GML-Dictionary.

inlineOrByReference Atribute veze

inline - Označen objekat mora biti ugrađen u objekat na koji se upućuje. byReference - Referenca može postojati samo preko xlink-a. inlineOrByReference - Moguće su obe vrste referenci.

sequenceNumber Atribute veze

Jedan jasan broj koji određuje redosled elemenata u XML-šemi.

Tabele 3:Važni upravljački parametri (Tagged Values) prema ISO 19136

3.2 INSPIRE kompatibilni modeli podataka o korišćenju zemljišta Razvijeni model podataka o korišćenju zemljišta u gradu Čačku, ne samo da treba u potpunosti da reprodukuje sadržaje nacionalnih planova, već on mora da omogući i njihovu transformaciju u INSPIRE PLU format. Iz ovog razloga struktura srpskog modela mora da bude kompatibilna sa INSPIRE strukturom. Sadržajno mora biti moguće, da se u najmanju ruku mogu generisati svi obavezni atributi i asocijacije iz INSPIRE klase objekata. Da bi se mogao oceniti trenutno postojeći nacrt, biće ukratko opisan INSPIRE PLU model podataka. Kompletna tehnička specifikacija modela podataka se nalazi u (INSPIRE 2013d), a kompaktne karakteristike u (Richter & Krause 2013). Ilustracija 2 pokazuje strukturu INSPIRE modela podataka bez atributa. Sadržaji prostornih planova se modeluju kroz četiri objektne klase:

Klasa SpatialPlan modeluje jedan prostorni plan kao celinu. Obavezni atributi u klasi su geografski obim plana (geometrija površine plana), zvanična oznaka plana (kao slobodan tekst), nivo administracije koji je odgovoran za sadržaj plana i to po jednoj jedinstvenoj evropskoj klasifikacionoj šemi, kao i jedna nacionalna klasifikacija tipa plana. Opcionalno mogu da se, između ostalog, daju informacije o vremenskoj pravosnažnosti plana, upućivanje na plansku osnovu, kao i da se specificiraju informacije o nastanku plana. SpatialPlan sumira preko asocijacija sve

objekte koji modeluju konkretne sadržaje plana.

Klasa ZoningElement modeluje prostorne sadržaje plana. Ovi objekti definišu primarno dozvoljeno korišćenje zemljišta u oblasti planiranja. Oni moraju u potpunosti preklopiti sveukupan prostor plana. Obavezni atributi klase ZoningElement su oblast (geometrija prostora), klasifikacija postojećih kultura zemljišta i to po jednoj jedinstvenoj klasifikacionoj šemi (HIerarchical Land Use Classification System - HILUCS), kao i jedna klasifikacija pravne odgovornosti za sadržaj. Opcionalno mogu da se definišu i dalji atributi, na primer klasifikacija dodatnih, za tu zemlju specifičnih kultura zemljišta, vremenska ograničenost važnosti plana kao i dalja brojčano i tekstualno formulisana ograničenja.

Klasa SupplementaryRegulation modeluje dodatna, za prostor vezana, ograničenja dozvoljenih kultura zemljišta. Ova ograničenja mogu imati proizvoljnu geometriju (obavezan atribut). Ona moraju biti klasifikovana po jednoj jedinstvenoj evropskoj šemi (Hierarchical Supplementary Regulation Code List - HSRCL). Lista opcionalnih atributa je ista kao kod ZoningElement.

Klasa OfficialDocumentation modeluje sve ne-prostorne sadržaje plana. Ovi sadržaji mogu da se pojave u tri varijante: kao slobodan tekst, kao upućivanje na jedan eksterni dokument i kao pozivanje na zakonsku odredbu. Za zadnja dva slučaja mora da se navede ime referentnog dokumenta, odnosno naziv zakona, kao i da se specificira jedan Internet-URL.

Ilustracija 1: Struktura INSPIRE PLU Modells


9

4 Model podataka grada Čačka - analiza i predlozi za poboljšanje modela

4.1 Model podataka grada Čačaka, verzija 1.0 (mart 2014) Prva verzija modela podataka, koja je bila na raspolaganju na radionici aprila 2014 godine, je imala ukupno 46 UML-elemenata. Od toga je 15 njih imalo Stereotype featureType, koji konkretno modeluju prostorne i ne-prostorne sadržaje plana o korišćenju zemljišta. Ostali UML-elementi reprezentuju kompleksne tipove podataka, numeracije i liste kodova u kojima su korišćeni atributi. FeatureTypes mogu da se strukturiraju i da se opišu:

Klase za modelovanje plana kao celine (AdministrativeInformation i PlanObject). Ovde se kod atributa obe klase očigledno orijentisalo na INSPIRE PLU model podataka.

Klase za modelovanje ne-prostornog sadržaja plana: GraphicalInformation, TextualInformation, TextualRegulation i Raster.

Klase za modelovanje prostornog sadržaja plana. Kao bazna klasa služi apstraktna klasa PlanFeature koja referira od PlanObject. Atributiranje PlanFeature je konformno sa INSPIRE PLU modelom podataka. Ono omogućava posebno jasan prikaz dodatnih ograničenja u zoniranim objektima.

Konkretni, prostorni sadržaji plana su opisani kroz jedan broj klasa, koji direktno ili indirektno proizilaze iz PlanFeature: UrbanRegulationLine, UrbanRegulationArea, ConditionsAndConstraints, FunctionIndications, DimensioningIndications, ConstructionIndications, IndirectExecution.

Klasa DevelopmentApplication treba (najverovatnije) da upravlja aplikacijama Metapodataka koje imaju pristup digitalnoj prezentaciji plana.

4.2 Sadržajne i formalne slabosti modela u verziji 1.0

Formalne i sadržajne slabosti prvog modela podataka, kao i pregled otvorenih pitanja vezanih za značenje pojedinih delova modela podataka, su kratko sažeti u daljem tekstu. Formalne slabosti/greške

F1 Nisu se koristile korektne ISO 191xx oznake tipova podataka (izuzetak su geometrijski atributi). Posebno često se koristio tip char (jedan Character) za tekst-atribut.

F2 Kod relacija svuda nedostaju imena krajeva upravljačkih asocijacija.

F3 Kod automatske transformacije iz UML na XML-šemu nedostaju neophodni upravljački parametri.

F4 Gereralno nedostaje dokumentacija UML-elemenata i atributa u okviru UML dijagrama. Iz tog razloga je značenje mnogih delova modela podataka nejasno.

F5 U nekim slučajevima je korišćen Stereotype CodeList, iako se sadržajno ne radi o DataTypes (OtherTerritorialClassification, SurfaceIndication, VolumeIndication, Index, UnitIndication, OtherDimensioningIndication, HeightIndication). U pomenutim UML-elementima se javlja sintaksna greška u specifikaciji atributa. Sadržajne slabosti/greške/otvorena pitanja

I1 Neizvesno je da li ovaj model podataka može adekvatno podržavati planove o korišćenju zemljišta u Srbiji i istovremeno omogućiti jednu jednostavnu i jasnu transformaciju u INSPIRE model. Model je očigledno preuzet od jednog evropskog projekta Plan4All (Salvemini et al. 2011), i malo dorađen. Plan4All-model je razvijen bez uzimanja u obzir zakona o planiranju i izgradnji, kao i bez iskustva o planiranju u Srbiji. Ovaj model nije nikada isproban niti objavljen. On isključivo služi kao pomoć razvoju INSPIRE PLU modela podataka. Različiti, paralelno korišćeni koncepti za klasifikaciju kulture zemljišta (GeneralLandUseType, SpecificLandUseType, MacroClassificationOfLand, LUCAS_Code, Property) se ne nalaze u tom obliku u INSPIRE modelu podataka, i najverovatnije ni u srpskim planovima o korišćenju zemljišta. Isto važi i za korišćene klasifikacione šeme za dodatna ograničenja (EasementType, ZoneTypeCode, ProtectionClassificationValue, HazardCategorieValue, InterventionCategorie), kao i za CodeListe tipa planova (PlanType). Zato je tokom radionice preporučano da se proveri kompatibilnost klasifikacione šeme sa nacionalnom praksom planiranja i da se ista koriguje. Alternativno može da se razmisli o korišćenju INSPIRE-klasifikacione šeme (HILUCS, HSRCL).


10

I2 Postoji previše obaveznih atributa u modelu podataka, koji u pojedinačnim slučajevima treba da se prebace u opcionalne atribute. Isto tako, postoje u pojedinim slučajevima opcionalni atributi za koje bi bilo bolje da se definišu kao obavezni. Osim toga su atributi višestruko zauzeti, što u pojedinim slučajevima izgleda čudno.

I3 Razlika između klasaTextualRegulation i TextualInformation je nejasna. Nedostaje mogućnost da se tekst

dokumenta određuje korišćenjem URL-a. I4 Značenje klasaRaster i GraphicalInformation je nejasno. Nedostaju atributi za sadržajni prikaz (na primer URL za

jedan rasterski file). I5 KlasuPlanObject treba izvesti iz AdministrativeInformation, a ne obrnuto. I6 Definicija hijerarhije klasa za prostorne podatke izgleda zaista veoma proizvoljno. Pojedini FeatureTypes objedinjuju

samo ne-geometrijske atribute (DimensioningIndications, FunctionIndications, ConstructionIndications, IndirectExecution) i trebaju biti konceptualno pretvoreni u DataTypes. Sve konkretne klase prostornih podataka (UrbanRegulationArea, UrbanRegulationLine, ConditionsAndConstraints) mogu onda da koriste taj DataTypes.

I7 KlasaUrbanRegulationArea kroz atributtype (UrbanRegulationAreaType) daje utisak, da se korišćenje zemljišta može

definisati preko tri različite nivoa komunalne strukture ("parcela", "blok" i "zona"). Ovde nije jasno, da li su parcele u planskom dokumentu iste sa parcelama u zemljišnim knjigama. Parcele su posebno modelovane u katastarskom planu i one ne smeju bite još jednom modelovane u planskom dokumentu. Takođe nije jasno, da li je moguće u jednom određenom planskom dokumentu istovremeno postaviti definicije na različitim nivoima, koje se preklapaju. I nije jasno koju vezu ima ova struktura sa različitim šemama klasifikacije koršćenja zemljišta (vidi ilutraciju 3). Ako je moguća mešavina nivoa parcele, bloka i zone, onda moraju biti jasno definisana pravila prioriteta kod njihovog pre-klapanja. Da bi se omogućio jedan jasan prelaz na INSPIRE PLU format mora se specificirati da li jedan UrbanRegulationArea u propratnom planskom dokumentu pripada zoniranom sloju (isOverlayArea == false) ili predstavlja jedno dodatno ograničenje (isOverlayArea == true).

Ilustracija 2: Komentar u modelu podataka Čačak

buildingParcel(0...1): SpecificLandUseType

urbanZone(1...*): buildingParcel

urbanBlock(1...*): buildingParcel

urbanZone(1): GeneralLandUseType

urbanBlock(1): SpecificLandUseType


11

4.3 Model podataka Čačak, verzija 2.0 (septembar 2014)

Model podataka grada Čačka je redividran u periodu između aprila i avgusta 2014 godine. U daljem tekstu je ukratko opisano u kojoj meri su otklonjene slabosti opisane u poglavlju 4.1. Detaljna dokumentacija o još postojećim slabostima i greškama u verziji 2.0 modela podataka, kao i predlozi za njihovo otklanjanje, se nalaze u prilogu A. Formalne slabosti/greške

F1 Korektura je nepotpuna i čini se kao da je svedena samo na pojedine klase (PlanObject, TextualInformation, TextualRegulation, Raster).

F2 Korekture nisu sprovedene F3 Korekture nisu sprovedene F4 Korekture nisu sprovedene F5 Korekture nisu sprovedene Sadržajne slabosti/greške/otvorena pitanja

I1 Kod atributa i kod korišćene Codeliste nisu utvrđene nikakave promene u odnosu na prethodnu verziju. I2 Promene kod kardinalnosti atributa su uočene samo kod manjeg broja klasa (PlanObject, PlanFeature, Raster,

TextualRegulation, TextualInformation). I3 TextualInformationje dodat u pojedinim atributima, tako da je njihovo sveukupno značenje sada jasnije. I4 Raster-u je dodat jedan atribut (Referenz za raster-file). Ali značenje i primena GraphicalInformation je još uvek

nejasna. I5 Ovo je korigovano. I6 Hijerarhija nasleđivanja i Stereotype su promenjeni u tri slučaja (FunctionIndications, DimensioningIndications,

UrbanRegulationArea). Pri tome su nastale nove, još veće greške. Navedene klase sada više uopšte nemaju vezu ka PlanObject iPlanFeature i one praktično ne mogu više da se koriste.

I7 Nisu utvrđene nikakve promene.

4.4 Posledice nesprovođenja datih predloga

Formalne greške onemogućavaju u najmanju ruku kreiranje jedne GML-kompatibilne XML-šeme iz UML-modela.Ovo nije moguće odraditi ni automatski, ni manuelno. Manuelno izvođenje jedne šeme baze podataka bi principijelno bilo moguće. Zbog nedostatka dokumentacije je eksperimentisanje i praktično izvođenje modela, kao i razvoj softvera za te svrhe, veoma problematično.

Problem kod I1 je veoma kompleksan i ozbiljan. Ovde nije jasno da li model podataka može u potpunosti da prikaže sadržaje srpskih planova o korišćenju zemljišta. Izgleda da u modelu postoje konstrukcije koje su neupotrebljive kako za nacionalne planove tako i za INSPIRE. Ovo dovodi do toga da je ceo model nepotrebno iskomplikovan i uveliko otežava njegov prenos u INSPIRE. Zbog velikog broja paralelno korišćenih šema klasifikacije zemljišta je trenutno gotovo nemoguće definisati jedno pravilo prenosa nacionalnog modela u INSPIRE model.

Nepovoljno definisana kardinalnost atributa (I2) može se različito odraziti na korišćenje modela podataka. Kada jedna klasa ima obavezan atribut, a vrednost tog atributa na osnovu postojećih informacija nije poznata, onda ova situacija dovodi to toga da nije moguće šematski konformno prikazati plan korišćenja zemljišta. S druge strane, nepopunjeni ili veoma često popunjeni atributi mogu da dovedu do toga da određene aplikacije nemaju dovoljno informacija ili da imaju nejasne informacije.

Već navedeni problemi klasa u I6 imaju centralnu ulogu u modeliranju sadržaja prostornog plana. Bez promena u modeliranju verzije 2 modela podataka, ne može se ni jedan plan prikazati. Principijelno može da se koristi stara verzija 1, ali ona ima velika funkcionalna ograničenja.

5 Predlozi o daljim aktivnostima

Jedan mogući budući projekat bi trebao biti fokusiran na sledeće dve teme:

Na reviziju i dopunu modela podataka koji je razvijen za grad Čačak

Na praktično testiranje implementacije modela podataka Za svaki ovaj deo će biti dati predlozi za sadržaj prikaza i za mogući postupak.


12

5.1 Revizija i dorada modela podataka Pre nego što se počne sa izradom verzije 3.0 modela podataka, trebalo bi kao prvo da se na nacionalnom nivou u Srbiji ustanovi, koji su to konkretni ciljevi koji se žele pratiti kroz razvoj ovog modela. Kada se uzme u obzir obim posla, onda se dolazi do zaključka da nema mnogo smisla razvijati model podataka samo kao podršku INSPIRE direktivi, i to samo za jednu opštinu kao Čačak i samo za jedan tip planova o korišćenju zemljišta. Umesto toga trebalo bi težiti da se na svim nivoima javne uprave planovi o korišćenju zemljišta izrade u jednom standardnom, objektno orijentisanom formatu. I da se kao takvi arhiviraju i stave na korišćenje. Dalje bi trebalo razjasniti da li i u kom obimu će se ovi podaci u budućnosti koristiti u administrativnim procedurama (na primer javni uvid ili dobijanje različitih dozvola).

Pre jedne nove revizije modela podataka treba razjasniti kompleksna pitanja vezana za strukturu i sadržaj postojećih planova. U jednoj detaljnoj studiji trebaju da se daju odgovori na sledeća pitanja:

Koje sadržajne specifikacije (obavezni sadržaji, opcionalni sadržaji, klasifikacione šeme, indikatori koji se koriste) se nalaze u zakonu o prostornom planiranju u Srbiji.

Koji sadržaji se zapravo koriste u postojećim planovima? U ovu svrhu je neophodno uzeti u obzir primere planova iz više opština različitih regiona.

Na koji način (analogno ili digitalno) se trenutno čuvaju pravosnažni planovi? Za praktično testiranje treba biti dostupan jedan broj uzoraka digitalnih planova.

Koji tipični softverski alati se koriste u Srbiji za izradu i ažuriranje digitalnih planova? U kojim formatima se arhiviraju izrađeni planovi?

Da li se može u bliskoj budućnosti računati sa time da će planovi biti postavljeni na drugačijoj platformi ili da će biti izmena u postojećim planovima?

Koja se sve pravila prikaza koriste u različitim opštinama? Tim koji radi na projektu, odnosno prati ovu studiju, treba da se sastoji od stručnjaka iz oblasti prostornog planiranja i to iz različitih opština, odnosno regiona, zatim od stručnjaka iz oblasti prava na nacionalnom nivou, kao i od IT-eksperata. Na osnovu ovakve studije bi trebalo u novom postupku model podataka revidirati i proširiti. Na kraju bi, u idealnom slučaju, trebalo da postoje sledeći dokumenti:

Jedan formalno ispravan i potpuno dokumentovan UML-model, koji pricipijelno podržava zakonske uslove / obavezne sadržaje i koji može da prikaže sve uzorke planova koji su korišćeni u studiji.

Broj Codeliste za specifikaciju dozvoljenih kultura zemljišta kao i za specifikaciju dodatnih propisa i ograničenja.

XML-šema za razmenu podataka, kao i GML-Dictionaries za XML-reprezentaciju Code-liste. Oboje može automatski da se generiše iz UML-modela.

Jedan neformalan skup pravila po kojim bi srpski format podataka za planove o korišćenju zemljišta bio prikazan u INSPIRE PLU formatu.

Jedan neformalan skup pravila o prikazu klasa i atributa u srpskom formatu podataka.

5.2 Testiranje primene modela podataka Centralni deo budućih aktivnosti treba da budu pilot-projekti za praktično testiranje modela podataka. Ti pilot-projekti treba da se sprovode na bazi postojećih, pravno obavezujućih ili onih planova za korišćenje zemljišta koji su u fazi izrade. Projekti treba da slede sledeće ciljeve:

Da daju odgovor na pitanje da li postojeći digitalni planovi korišćenja zemljišta uopšte mogu da se prenesu na objektno orijentisan format, kao i na pitanje u kojoj meri moraju planovi da se prerade ili da se krieiraju novi. Ako se utvrdi da su u najvećem broju slučajeva neophodne velike revizije planova, onda treba razviti preporuke o softve rskim alatima koji bi se koristili za kreiranje planova, kao i o tome kako ih koristiti. U tom slučaju treba inicirati i određene obuke.

Praktične dokaze da razvijeni format podataka može u potpunosti reprodukovati postojeće planove, kao i da je principijelno moguća jedna jasna transformacija u INSPIRE PLU format. U suprotnom, potrebno je format podataka dodatno revidirati i pravila mapiranja za izradu INSPIRE PLU promeniti, odnosno doraditi.

Razvoj jednog broja softverskih modula za podržavanje procesa mapiranja. U okviru projekta mogu verovatno da se generišu samo prototipska rešenja, koja bi za dalju upotrebu u javnim upravama trebala da se revidiraju i da se dorade.


13

Ilustracija 3 šematski pokazuje sistemsku arhitekturu koja bi mogla da se kreira u nekom sledećem projektu. Ona podržava različite delove procesa koji bi eventualno mogli da se realizuju u posebnom pilot-projektu:

Primer eksporta postojećih planova u format ESRI Shapefile. Upotreba ovog formata je korisna, jer ga podržavaju skoro svi sistemi iz oblasti prostornog planiranja i zato što poseduje jednu objektno orijentisanu strukturu. Ako se jedan postojeći set podataka, bez velikih gubitaka, može eksportirati u Shapefile-format,onda se on može principijelno prikazati i u GML-baziranom, objektno orijentisanom formatu.

Primer transformacije Shapefile planova u novo razvijeni nacionalni format podataka. U okviru pilot-projekta su primeri planova bazirani na različitim Shapefile-strukturama, što zahteva jedan fleksibilniji softver za transformaciju. Za ove svrhe postoje različiti, principijelno pogodni softverski alati, između ostalih i komercijalni System Feature Manipulation Engine (FME) (SAFE 2014), slobodan HUMBOLDT Alignment Editor (HALE) (HALE 2014), ili specijalni razvoj GML-Toolbox (KIT 2014), koji se koristio u jednoj specijalnoj varijanti testiranja formata podataka (Benner et al. 2008) u Crnoj Gori.

Integracija primer-planova u jednu nacionalnu infrastrukturu prostornih podataka. U ovom kontekstu moraju da se reše različiti problemi: izbor i instalacija odgovarajućeg WebGIS sistema; kreiranje šeme baze podataka na osnovu novog modela podataka, automatsko prebacivanje jednog XML-baziranog plana u banku podataka kao i stavljanje plana na uvid preko Web-Services. Pored usluge prikaza plana, kao što je za jedan specijalni plan i realizovano (Čačak 2014), potrebno je razviti i usluge Download-a i Web Feature Services-a.

Automatska transformacija primer-planova u format INSPIRE PLU. Za ovo trebaju da se formulišu pravila prikaza koja moraju da se implementiraju pomoću odgovarajućeg softvera. Ovo poslednje može principijelno da se odradi sa prikazanim alatima za transformaciju Shapefile nacionalni format.

Integracija primer-planova u INSPIRE PLU formatuu evropski GDI. Ovde se principijelno radi o istoj tehnologiji kao i kod nacionalne strukture prostornih podataka. Ali, moraju da se zadovolje smernice vezane za usluge podrške i zahteve perfomanse (poglavlje 2).

Ilustracija 3: Sistemska arhitektura za prototipski prenos postojećih planova u novo razvijeni format podataka

ESRIShapefilePlan

Plan

Plan

Plan

Export

Export

Export

Export

Transfor-mation

NationalesDatenformat

NationaleGDI

Transfor-mation

INSPIRE PLU

EuropäischeGDI

ESRIShapefile

ESRIShapefile

ESRIShapefile


14

6 Rezime

Grad Čačak je zajedno sa AMBERO/ICON u okviru GIZ-projekta "Unapređenje upravljanja zemljištem na nivou lokalnih samouprava u Srbiji" razvio jedan UML-bazirani model podataka za planove o korišćenju zemljišta. Kod ove realizacije je u prvom planu stajala podrška EU direktive INPIRE sa temom prostorno planiranje. U okviru ove studije je ocenjen model podataka i navedeni su suštinski predlozi za buduće projekte.

U tom cilju su najpre definisani formalni i sadržajni zahtevi za model podataka, koji su proizašli kako iz INSPIRE direktive tako i iz ISO 191xx normi. Uočene formalne greške i sadržajne slabosti u obe verzije su dokumentovane i ocenjene. Na osnovu toga su napravljeni predlozi za poboljšanja u sledećim projektima koji se mogu sažeti na sledeći način:

Pojašnjenje, koje dalje ciljeve - pored podrške INSPIRE - treba da prati razvoj modela podataka na nacionalnom nivou.

Izrada studije o pravnom okviru i ustaljenoj praksi u oblasti prostornog planiranja u Srbiji.

Revizija razvijenog modela podataka na bazi predloga koji su navedeni u ovoj studiji.

Praktično testiranje modela podataka na osnovu jednog broja reprezentativnih primer-planova. Za ovu svrhu moraju posebno da se razviju prototipski softverski alati kojima je moguće prebacivanje postojećih digitalnih planova o korišćenju zemljišta (iz različitih opština/regiona) u jedan standardni nacionalni format kao i u evropski format INSPIRE PLU. Osim toga potrebno je stvoriti jednu platformu za distribuciju podataka (u nacionalnom i evropskom formatu) preko standardnog Web Services.

7 Referenzen

Benner, J., Eichhorn, T., Krause, K.-U., Müller, Y. 2008: MonPlanGML - GML-based Data Model for Muncipal Land Management in Montenegro. In: Schrenk/Popovich/Engelke/Elisei (Eds.) "Proc. REAL CORP 2008", Wien, 19. - 21.5.2008., pp. 325 - 333. Čačak 2014: GUP Grada Čačka. http://serbia.gdi.net/gupCacak/.Poslednja poseta 29.12.2014. EU 2007: Direktiva 2007/2/EG Evropskog parlamenta i Saveta od 14. marta 2007. za uspostavljanje jedne infrastrukture prostornih podataka u evropskoj zajednici (INSPIRE). http://eur-lex.europa.eu/legal-content/DE/TXT/PDF/?uri=CELEX:32007L0002&from=EN. Poslednja poseta 29.12.2014. EU 2008: Uredba (EG) br. 1205/2008 Komisije od 3. decembra 2008. o implementaciji direktive 2007/2/EG Evropskog parlamenta i Savetau vezi Metadata.http://eurlex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2008:326:0012:0030:DE:PDF. Poslednja poseta 4.12.2014. EU 2009: Uredba(EG) br. 976/2009 Komisije od 19. oktobra 2009. o implemetaciji direktive 2007/2/EG Evropskog parlamenta i Saveta u vezi mrežnog servisa http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2009:274:0009:0018:DE:PDF. Poslednja poseta 4.12.2014. EU 2009a: Odluka Komisije od 5. juna 2009. o implementaciji direktive 2007/2/EG Evropskog parlamenta i Saveta u vezi praćenja i izveštavanja.http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2009:148:0018:0026:DE:PDF.Poslednja poseta 4.12.2014. EU 2010: Uredba (EU) br. 1088/2010 Komisije od 23. novembra 2010. o izmeni uredbe (EG) br. 976/2009 u vezi Download- usluga i usluga transformacije. http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2010:323:0001:0010:DE:PDF. Poslednja poseta 4.12.2014. EU 2010a: Uredba(EU) br. 268/2010 Komisije od 29. marta 2010.o sprovođenju direktive 2007/2/EG Evropskog parlamenra i Saveta u vezi pristupa setovima geo-podataka od strane različitih institucija. http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2010:083:0008:0009:DE:PDF. Poslednja poseta 4.12.2014. EU 2013: Uredba(EU) br. 1253/2013 Komisije od 21. oktobra 2013. o izmeni uredbe (EU) br. 1089/2010 o sprovođenju direktive 2007/2/EG vezano za interoperabilnost setova prostornih podataka i usluga. http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2013:331:0001:0267:DE:PDF. Poslednja poseta 4.12.2014.

http://serbia.gdi.net/gupCacak/

http://eur-lex.europa.eu/legal-content/DE/TXT/PDF/?uri=CELEX:32007L0002&from=EN

http://eur-lex.europa.eu/legal-content/DE/TXT/PDF/?uri=CELEX:32007L0002&from=EN

http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2008:326:0012:0030:DE:PDF












15

HALE 2014: HUMBOLDT Alignment Editor. http://www.esdi-community.eu/projects/hale.Poslednja poseta 27.12.2014. INSPIRE 2011: Technical Guidance for theimplementation of INSPIRE DiscoveryServices, Version 3.1. http://inspire.jrc.ec.europa.eu/documents/Network_Services/TechnicalGuidance_DiscoveryServices_v3.1.pdf. Poslednja poseta 4.12.2014. INSPIRE 2013: INSPIRE Metadata Implementing Rules: Technical Guidelines based on EN ISO 19115 and EN ISO 19119, Version 1.3, 2013-10-29. http://inspire.jrc.ec.europa.eu/documents/Metadata/MD_IR_and_ISO_20131029.pdf. Poslednja poseta 4.12.2014

INSPIRE 2013a:D2.8.III.4 Data Specification on Land Use – Technical Guidelines, Version 3.0.

http://inspire.jrc.ec.europa.eu/documents/Data_Specifications/INSPIRE_DataSpecification_LU_v3.0.pdf. Poslednja poseta 4.12.2014. INSPIRE 2013b: Technical Guidance for the implementation of INSPIRE Download Services, Version 3.1. http://inspire.jrc.ec.europa.eu/documents/Network_Services/Technical_Guidance_Download_Services_v3.1.pdf.Poslednja poseta 4.12.2014. INSPIRE 2013c:Technical Guidance for theimplementation of INSPIRE ViewServices, Version 3.11. http://inspire.jrc.ec.europa.eu/documents/Network_Services/TechnicalGuidance_ViewServices_v3.11.pdf. Poslednja poseta 4.12.2014. INSPIRE2013d: D2.8.III.4 Data Specification on Land Use – Technical Guidelines, Version 3.0. http://inspire.jrc.ec.europa.eu/documents/Data_Specifications/INSPIRE_DataSpecification_LU_v3.0.pdf. Poslednja poseta 4.12.2014. ISO 2014: ISO/TC 211 Harmonized Model. http://www.isotc211.org/.Poslednja poseta 4.12.2014. KIT 2014: GML-Toolbox. http://www.iai.kit.edu/www-extern/index.php?id=683&L=1. Poslednja poseta 29.12.2014. OGC 2007: OpenGIS® Geography Markup Language (GML) Encoding Standard, Version 3.2.1, OGC 07-036. http://portal.opengeospatial.org/files/?artifact_id=20509. Poslednja poseta 4.12.2014. OMG 2014: Object Management Group - Unified Modeling Language™ (UML

®).

http://www.omg.org/spec/UML/.Poslednja poseta 4.12.2014. Richter, W., Krause, K.-U. 2013: Karakteristike INSPIRE priloga III Nr. 4 tema kulture zemljišta, verzija 1.0. http://www.geoportal.de/SharedDocs/Downloads/DE/GDI-DE/Steckbrie_Bodennutzung_Version1_0.html. Poslednja poseta 4.12.2014. Safe 2014: Internet prezentacija firme SAFE SOFTWARE. http://www.safe.com/fme/.Poslednja poseta 27.12.2014. Salvemini, M., Vico, F., Iannucci, C. (Editors) 2011: Plan4all Project Interoperability for Spatial Planning. http://www.eurogi.org/eurogi-downloads/category/55-plan4all-book?download=138:plan4all-book. Poslednja poseta 5.12.2014. ShapeChange 2014: ShapeChange - Processing application schemas for geographic information. http://shapechange.net/.Poslednja poseta 29.12.2014.

http://www.esdi-community.eu/projects/hale.

http://inspire.jrc.ec.europa.eu/documents/Network_Services/TechnicalGuidance_DiscoveryServices_v3.1.pdf

http://inspire.jrc.ec.europa.eu/documents/Metadata/MD_IR_and_ISO_20131029.pdf

http://inspire.jrc.ec.europa.eu/documents/Data_Specifications/INSPIRE_DataSpecification_LU_v3.0.pdf

http://inspire.jrc.ec.europa.eu/documents/Network_Services/Technical_Guidance_Download_Services_v3.1.pdf

http://inspire.jrc.ec.europa.eu/documents/Network_Services/TechnicalGuidance_ViewServices_v3.11.pdf

http://inspire.jrc.ec.europa.eu/documents/Data_Specifications/INSPIRE_DataSpecification_LU_v3.0.pdf

http://www.isotc211.org/

http://www.iai.kit.edu/www-extern/index.php?id=683&L=1

http://portal.opengeospatial.org/files/?artifact_id=20509

http://www.omg.org/spec/UML/

http://www.geoportal.de/SharedDocs/Downloads/DE/GDI-DE/Steckbrie_Bodennutzung_Version1_0.html

http://www.safe.com/fme/

http://www.eurogi.org/eurogi-downloads/category/55-plan4all-book?download=138:plan4all-book

http://shapechange.net/


16

PrilogA: Dokumentacija modela podataka i predlozi za njegovo poboljšanje

A1: Modelovanje plana kao jedne celine

Ilustracija 4: Model podataka Čačak, verzija 2

Predlozi za poboljšanje

Oba kraja veze kodPlanObject "sa samim sobom" moraju imati jedno ime

AdministrativeInformation: tip podataka stringCharacterString

AdministrativeInformation: tip podataka char CharacterString

PlanObject: tip podataka GM_AggregateGM_MultiSurface

PlanType: Redukcija unosa na specifične tipove planova u Srbiji kao i otklon skraćenice "=srp". To vodi kod automatskog kreiranja jednog GML-Dictionaries do greške.

Proveriti da li su navedeni koraci u ProcessStepSpecific u skladu sa nacionalnom praksom i eventualno eliminisati nepotrebne unose.

«featureType»

Administrativ eInformation

+ hierarchyLevelName: HierarchyLevelName

+ organisationName: char

+ planDescription: string [0..1]

+ planType: PlanType

+ processStepGeneral: ProcessStepGeneral

+ temporalExtentTo: Date [0..1]

«voidable»

+ ordinanceDate: Date [1..*]

+ ordinanceRef: string [1..*]

+ processStepSpecific: ProcessStepSpecific

+ temporalExtentFrom: Date

«featureType»

PlanObject

+ geometry: GM_Aggregate

+ ID: Identifier

+ title: CharacterString

«voidable»

+ legislationReference: CharacterString

«enumeration»

ProcessStepGeneral

elaboration

adoption

legalForce

obsolete

«codelist»

ProcessStepSpecific

+ adopted

+ approved

+ counterDeducations

+ draft

+ earlyInvolvementPublicAuthorities

+ earlyPublicParticipation

+ involvementPublicAuthorities

+ municipalStatute

+ planPreparationDecision

+ publicObservations

+ revision

«codelist»

PlanType

+ bindingLandUsePlan

+ detailedRegulationPlan = srp

+ executiveDevelopmentPlan

+ generalRegulationPlan = srp

+ generalUrbanPlan = srp

+ landscapePlan

+ municipalitySpatialPlan = srp

+ municipalOperationPlan

+ municipalStructurePlan

+ parcellationProject = srp

+ preparatoryLandUsePlan

+ regionalSpatialPlan = srp

+ republicSerbiaSpatialPlan = srp

+ specialPurposeAreaPlan = srp

+ stateDevelopmentPlan

+ structureVisionPlan

+ urbanProject = srp

+ zoningPlan

«enumeration»

CoreMetadata - Plan::

HierarchyLev elName

spatialPlan.country

spatialPlan.state

spatialPlan.regional

spatialPlan.subRegional

spatialPlan.supraLocal

spatialPlan.local

spatialPlan.subLocal

spatialPlan.other

0..1

+replaces 0..1


17

Ilustracija 5: Moguća alternativa modelovanja

«featureType»

PlanObject

+ geometry: GM_MultiSurface

+ ID: Identifier

+ legislationReference: CharacterString [0..1]


«featureType»

AdministrativeInformation

+ hierarchyLevelName: HierarchyLevelName


+ ordinanceRef: CharacterString [0..*]

+ organisationName: CharacterString

+ planDescription: CharacterString [0..1]

+ planType: PlanType

+ processStepGeneral: ProcessStepGeneral

+ processStepSpecific: ProcessStepSpecific [0..1]

+ temporalExtentFrom: Date [0..1]

+ temporalExtentTo: Date [0..1]

+isReplacedBy 0..*

+replaces 0..1


18

A2 Modeliranje ne-prostornog sadržaja plana



Svi upravljački krajevi kod veze moraju da imaju jedno ime

Codeliste DocumentFileType mora biti definisana

Raster: atribut refDocument treba da ima kardinalitet 1..*

GraphicalInformation: ova klasa treba da se eliminiše


«featureType»

PlanObject


+ ID: Identifier


«voidable»


«featureType»

TextualInformation

+ date: Date [0..1]

- fi leType: DokumentFileType [0..1]

+ ID: Identifier

+ language: LanguageCode [0..1] = srp

+ name: CharacterString

+ refDocument: URI [0..*]

«featureType»

TextualRegulation

+ ID: Identifier



«codelist»

CoreMetadata - Plan::

LanguageCode

+ eng

+ srp

«featureType»

Raster

+ fileType: RasterFileType [0..1]

+ ID: Identifier

+ name: CharacterString [0..1]

+ refDocument: URI [0..1]

«featureType»

GraphicalInformation

+ ID: Identifier

+ language: LanguageCode = srp

+ title: char

«codelist»

RasterFileType

+ bitmap

+ ecw

+ geotiff

+ jpg

+ pdf

+ png

+ tiff

0..1

+replaces 0..1

1

0..*

1

0..*

0..* 1

0..*

1


19


A3: Viša klasa PlanFeature za prostorni sadržaj plana



Svi upravljački krajevi kod veza moraju da imaju jedno ime

PlanFeature treba da ima jednu Relation i sa TextualInformation

Atributi geometry i isOverlayArea treba da se definišu u izvedenim klasama

«featureType»

TextualInformation

+ date: Date [0..1]

+ fi leType: DocumentFileType [0..1]

+ ID: Identifier




«featureType»

TextualRegulation

+ ID: Identifier



«featureType»

Raster

+ fi leType: RasterFileType [0..1]

+ ID: Identifier

+ name: CharacterString [0..1]



«featureType»

PlanObject


+ ID: Identifier

+ legislationReference: CharacterString [0..1]


«codelist»

RasterFileType

+ bitmap

+ ecw

+ geotiff

+ jpg

+ pdf

+ png

+ tiff

«codelist»

DocumentFileType

+ doc

+ pdf

+ txt

«codelist»

CoreMetadata - Plan::LanguageCode

+ eng

+ srp

+refPlan

1

+refText0..*

+refPlan 1

+refDocument 0..*

+isReplacedBy 0..*+replaces 0..1

+refRasterfi le0..*

+refPlan

1

«featureType»

PlanFeature


+ ID: Identifier

+ isOverlayArea: boolean

+ regulationNature: RegulationNature

«voidable»

+ regulationReference: char [1..*]

+ status: PlanFeatureStatus


«featureType»

PlanObject


+ ID: Identifier


«voidable»


«featureType»

TextualRegulation

+ ID: Identifier



«codelist»

PlanFeatureStatus

+ existing

+ planned

+ removal

«enumeration»

RegulationNature

generallyBinding

bindingForDevelopers

bindingOnlyForAuthorities

nonBinding

1

0..*

0..1

+replaces 0..1

1

0..*

1

0..*


20

Tip podataka charCharacterString


A4: Klase za modelovanje prostornog sadržaja plana A4.1 Struktura modela


«featureType»

PlanFeature

+ ID: Identifier

+ regulationNature: RegulationNature

+ regulationReference: CharacterString [0..1]

+ status: PlanFeatureStatus [0..1] = planned

«enumeration»

RegulationNature

generallyBinding

bindingForDevelopers

bindingOnlyForAuthorities

nonBinding

«codelist»

PlanFeatureStatus

+ existing

+ planned

+ removal

«featureType»

TextualInformation

+ date: Date [0..1]

+ fi leType: DocumentFileType [0..1]

+ ID: Identifier




«featureType»

TextualRegulation

+ ID: Identifier



«codelist»

DocumentFileType

+ doc

+ pdf

+ txt

+refPlanFeature 1

+refText 0..*

+refPlanFeature 1

+refDocument 0..*

«featureType»

PlanFeature

«featureType»

ConditionsAndConstraints

«featureType»

ConstructionIndications

«dataType»

FunctionIndications

«dataType»

DimensioningIndications

«featureType»

IndirectExecution

«featureType»

UrbanRegulationArea

«featureType»

UrbanRegulationLine


21


Klase UrbanRegulationArea, FunctionIndications, ConstructionIndications, DimensioningIndications i IndirectExecution moraju ili da se (direktno ili indirektno) izvedu iz PlanFeature ili da se preko njegovih atributa, odnosno veza povezuju. Kod ovakvog modeliranja je upotreba klasa nemoguća.

I klase IndirectExecution i ConstructionIndications su konceptualno DataTypes i treba da poseduju ovaj Stereotype.

Da bi se u jednoj međusobnoj nezavisnosti moglo definisati korišćenje zemljišta (FunctionIndications) kao i da bi se mogla ograničiti gradnja (ConstructionIndications), potrebno je da ConstructionIndications ne bude izvedena iz FunctionIndications.


A4.2FeatureType UrbanRegulationArea

«featureType»

PlanFeature

«featureType»


«featureType»

UrbanRegulationLine

«featureType»

UrbanRegulationArea

«dataType»

IndirectExecution

«dataType»

FunctionIndications

«dataType»


«dataType»

DimensioningIndication



«featureType»

UrbanRegulationArea

+ description: string [0..1] = URL, text,...

+ label: char [0..*]

+ type: UrbanRegulationAreaType [0..*]

«codelist»

UrbanRegulationAreaType

+ buildingParcel

+ urbanBlock

+ urbanZone

«featureType»

UrbanRegulationArea


+ type: UrbanRegulationAreaType

+ description: CharacterString [0..1]

+ label: CharacterString [0..*]

+ functionalIndications: FunctionIndications

+ constructionIndications: ConstructionIndications [0..1]

+ dimensionalIndications: DimensioningIndication [0..*]

+ indirectExecution: IndirectExecution [0..1]

+ isOverlayArea: Boolean

«codelist»

UrbanRegulationAreaType

+ buildingParcel

+ urbanBlock

+ urbanZone


22

Predlozi za poboljšanje UrbanRegulationArea trebaju konceptualno da reprezentuju definicije i ograničenja kod korišćenja zemljišta i to u obliku površina. Shodno tome preporučujemo sledeće promene u modelu podataka:

Transfer atributa geometrije (geometry) iz više klase PlanFeature u klasu UrbanRegulationArea, i ograničenje na površinsku geometriju (GM_MultiSuface).

Specifikacije komunalne regulacije (atributtype) da bude jednostavan obavezan atribut.

Transfer iz isOverlayArea u klasu UrbanRegulationArea, i specifikacije kao jedan obavezan atribut, da bi se osigurao INSPIRE PLU prikaz.

Dodavanje atributa za specifikaciju funkcionalnih ograničenja kod korišćenja zemljišta (functionIndications, jednostavan obavezan atribut), kod ograničenja vrste i stepena gradnje (dimensionalIndications, opcionalno, višestruko), i za specifikacije ograničenja načina gradnje (constructionIndications, opcionalno, jednostavno).

Proveriti da li postoji potreba za atributima label i indirectExecution pošto je njihovo značenje nejasno. A4.3 FeatureType UrbanRegulationLine




Specifikacija atributa type (UrbanRegulationLineType) kao jednostavan obavezan atribut

Dodavanje atributa za ograničenja vrste i stepena gradnje (dimensionalIndications, opcionalno, višestruko).

Treba ispitati potrebu za atributom indirectExecution, pošto je njegovo značenje nejasno.

PlanFeature

«featureType»

UrbanRegulationLine

+ description: CaharacterString [0..1]

- geometry: GM_MultiCurve


+ type: UrbanRegulationLineType [0..*]

«codelist»

UrbanRegulationLineType

+ constructionLine

+ constructionLine.ground

+ constructionLine.storey

+ constructionLine.underground

+ parcellationLine

+ regulationLine

PlanFeature

«featureType»

UrbanRegulationLine

+ geometry: GM_MultiCurve

+ type: UrbanRegulationLineType

+ description: CharacterString [0..1]


+ dimensioningIndications: DimensioningIndications [0..1]

«codelist»

UrbanRegulationLineType

+ constructionLine

+ constructionLine.ground

+ constructionLine.storey

+ constructionLine.underground

+ parcellationLine

+ regulationLine


23

A4.4 FeatureType ConditionsAndConstraints

Ilustracija 16:Model podataka Čačak, verzija 2


Klasa ConditionsAndConstraints konceptualno reprezentuje dodatna ograničenja korišćenja zemljišta koja mogu imati proizvoljnu prostornu referencu. Ova ograničenja mogu doći iz 5 različitih tematskih oblasti:

Specijalna ograničenja korišćenja zemljišta ili prava na korišćenje zemljišta (easementType, Enumeration EasementTypes);

Zaštićena područja ili zaštićeni objekti (protectedSite, Enumeration ProtectionClassificationValue);

Specijalne mere gradnje u gradovima ili intervencije (interventionType, Codeliste InteventionCategory);

Područja sa posebnim rizicima ili propisima o bezbednosti (naturalRiskSafetyArea, Codeliste HazardCategoryValue);

Područja sa posebnim propisima (restrictionZone, Codeliste ZoneTypeCode). Jedan konkretan objekat ConditionsAndConstraints može imati samo jedno ograničenje iz jednog od 5 gore opisanih tematskih oblasti. Kardinalnost odgovarajućih atributa treba u svakom slučaju redukovati sa 0..* na 0..1. Bilo bi još bolje, za svaki tip ograničenja definisati jednu specijalnu, od ConditionsAndConstraints izvedenu klasu (Stereotype featureType).

A5 Kompleksni tipovi podataka Klase za prostorne sadržaje plana, koje su diskutovane u poglavlju A4, se koriste za kompleksne atribute složenih tipova podataka koji će biti prikazani u ovom poglavlju. Pri tome će se ići uglavnom na sintaksnu ispravnost specifikacije, a manje na sadržajne aspekte. Generalno se preporučuje da se proveri da li su korišćene klasifikacije i indikatori neophodni u okviru prostornog planiranja u Srbiji i da li se mogu koristiti još neki drugi indikatori. A5.1 FunctionIndications



PlanFeature

«featureType»


+ constraintDescription: string [0..*]

+ constraintName: char [0..*]

+ easementType: EasementTypes [0..*]

+ interventionType: InterventionCategory [0..*]

+ naturalRiskSafetyArea: HazardCategoryValue [0..*]

+ protectedSite: ProtectionClassificationValue [0..*]

+ restrictionZone: ZoneTypeCode [0..*]

PlanFeature

«featureType»


+ geometry: GM_Object

+ constraintName: CharacterString [0..1]

+ constraintDescription: CharacterString [0..*]

+ dimensioningIndications: DimensioningIndications [0..1]


+ protectedSite: ProtectionClassificationValue [0..1]

+ naturalRiskSafetyArea: HazardCategoryValue [0..1]

+ restrictionZone: ZoneTypeCode [0..1]

+ easementType: EasementTypes [0..1]

+ interventionType: InterventionCategory [0..1]

«dataType»

FunctionIndications

+ generalLandUseType: GeneralLandUseType [0..*]

+ indirectExecution: boolean


+ LUCAS_code: char [0..1]

+ macroClassificationOfLand: MacroClassificationOfLand [0..1]

+ otherTerritorialClassification: OtherTerritorialClassification [0..*]

+ property: Property [0..1]

+ specificLandUseType: SpecificLandUseType [0..*]

«dataType»

FunctionIndications

+ specificLandUseType: SpecificLandUseType [0..*]

+ generalLandUseType: GeneralLandUseType [1..*]

+ property: Property [0..1]

+ LUCAS_code: CharacterString [0..1]

+ macroClassificationOfLand: MacroClassificationOfLand [0..1]

+ otherTerritorialClassification: CharacterString [0..1]


+ indirectExecution: Boolean


24


Klasifikacija generalLandUse treba da bude obavezna, radi obezbeđivanja jasnog prikaza u INSPIRE klasi HILUCS.

LUCAS_Code (ako je uopšte obavezan) i otherTerritorialClassification trebaju da budu tipa CharacterString, ili da budu definisani jednom specijalnom Codeliste.

Značenje Boolean atributa indirectExecution je nejasno. A5.2 DimensioningIndications


«dataType»

DimensioningIndications

+ heightIndications: HeightIndication [0..*]

+ indexes: Index [0..*]

+ otherIndications: OtherDimensioningIndication [0..*]

+ surfaceIndications: SurfaceIndication [0..*]

+ unitIndications: UnitIndication [0..*]

+ volumeIndications: VolumeIndication [0..*]

«codelist»

HeightIndication

+ ...(freeText)(m): float

+ maxHeight: float

«codelist»

OtherDimensioningIndication

+ ...(freeText): float

+ landUsageDegree: float

«codelist»

SurfaceIndication

+ ...(freeText)(m2): float

+ grossConstructionArea: float

+ grossStoreyArea: float

«codelist»

UnitIndication


+ grossHousingDensity: float

+ maxNumberOfApartments: float

+ maxNumberOfStoreys: float

+ netHousingDensity: float

«codelist»

VolumeIndication

+ ...(freeText)(m3): float

+ cubicCapacity: float

«codelist»

Index


+ constructionIndex: float

+ occupancyIndex: float


25


Codeliste (Stereotype codelist) koje su korišćene kao tipovi atributa, su u stvari kompleksni tipovi podataka (Stereotype dataType).

U ovim tipovima podataka se pojavljuju i atributi tipa Integer (maxNumberOfAppartments, maxNumberOfStoreys) kao i atributi sa fizičkim jedinicama (na pr. maxHeight, grossConstructionArea).

Generalno se preporučuje jedna struktura podataka koja se oslanja na INSPIRE PLU (Ilustracija 22).


A5.3 ConstructionIndications



«dataType»

DimensioningIndication

+ indicationReference: DimensioningIndicationValue

«codelist»

DimensioningIndicationValue

+ ConstructionIndex

+ OccupancyIndex

+ GrossConstructionArea

+ GrossStoreyArea

+ CubicCapacity

+ NetHousingDensity

+ GrossHousingensity

+ MaxNumberOfAppartments

+ MaxNumberOfStoreys

+ LandUsageDegree

+ MaxHeight

«dataType»

DimensioningIndicationRealValue

+ value: Decimal

«dataType»

DimensioningIndicationIntegerValue

+ value: Integer

«dataType»

DimensioningIndicationMeasureValue

+ value: Measure

DimensioningIndicationTextValue

+ value: CharacterString

FunctionIndications

«featureType»


+ otherConstructionIndications: OtherConstructionIndications [0..*]

+ roofShape: RoofShape [0..*]

+ typeOfBuilding: TypeOfBuilding [0..*]

«dataType»


+ typeOfBuilding: TypeOfBuilding [0..*]

+ roofShape: RoofShape [0..*]

+ otherConstructionIndications: OtherConstructionIndication [0..*]


26


Dodeljivanje atributa kod ConstructionIndications je formalno korektno, konceptualno je potrebno da se UML-element modeluje kao dataType.

A 5.4 IndirectExecution




Preporučuje se modeliranje kao dataType umesto featureType.

Treba koristiti tip podataka CharacterString umesto string i char.

Klase modeluju očigledno informacije o procesu izrade plana na nivou pojedinih sadržaja plana. Nije jasno da li su na ovom nivou atributi title, ordinanceDate i ordinanceReference uopšte relevantni. U INSPIRE PLU formatu postoje ovi podaci samo na nivou celog plana. U modelu podataka Čačak su na nivou plana (AdministrativeInformation, PlanObject) atributi od IndirectExecution korišćeni pojedinačno, što je sa tačke modelovanja nedosledno.

Nije jasno zašto je klasa nazvana "IndirectExecution". Bolje ime za ovu klasu bi bilo na primer "OrdinanceInformation".

«featureType»

IndirectExecution


+ ordinanceRef: string [0..*]

+ processStepGeneral: ProcessStepGeneral [0..1]

+ title: char [0..1]

«dataType»

IndirectExecution

+ title: CharacterString [0..1]

+ processStepGeneral: ProcessStepGeneral [0..1]

+ ordinanceRef: CharacterString [0..*]


implementacija web baziranog geografskog … web baziranog geografskog informacionog sistema u...

Documents