Geoinformatics FCE CTU

Geoinformatics
FCE CTU
Geoinformatics
Faculty of Civil
Engineering
Czech
Technical
University
in Prague
Volume 2, 2007
Proceedings of the workshop Geoinformatics FCE CTU 2007, September 19th, Prague, 2007.
Organizing
Chairman:
Members:
Editors:
committee:
Aleš Čepek
Martin Landa
Martin Landa, Aleš Čepek
Geoinformatics, Faculty of Civil Engineering, Czech Technical University in Prague
ISSN 1802-2669
This book was prepared from the input files supplied by the authors. No additional English, Czech or Slovak style
corrections of the included articles were made by the compositor.
Published by Faculty of Civil Engineering, Czech Technical University in Prague.
Contents
1 Svět se měnı́ nenápadně
5
2 Surveying Curriculum from the Point of View of Multidisciplinarity
9
3 Scientia Est Potentia Welcome Words
19
4 Software used for diploma thesis at Geoinformatics VSB-TUO
23
5 GAL Framework
33
6 GUI development for GRASS GIS
43
7 Freeware for GIS and Remote Sensing
53
8 PyWPS 2.0.0: The presence and the future
61
9 NOP
65
10 The International Exchange of Students: Problems and Solutions at the
Riga Technical University
67
11 PostGIS pro vývojáře
71
12 PostgreSQL 8.3
91
13 Optimalizace procesu generovánı́ map pomocı́ XML
101
14 Otevřený katastr - svobodné internetové řešenı́ pro prohlı́ženı́ dat výměnného
formátu katastru nemovitostı́
111
15 Ukázka možnosti využitı́ programu OpenJUMP v SOA
Geinformatics FCE CTU 2007
119
3
Geinformatics FCE CTU 2007
4
Svět se měnı́ nenápadně
Pro titulek úvodnı́ho slova k druhému ročnı́ku semináře Geoinformatika jsem si vypůjčil název
stejnojmenné knihy Jaroslava Žáka. Na našem prvnı́m setkánı́ v červnu 2006 jsme informovali
o otevřenı́ našeho nového oboru Geoinformatika, v rámci studijnı́ho programu Geodézie a
kartografie, o našich plánech a očekávánı́ch.
Jestliže budu dnes opět hovořit v úvodu k semináři o uplynulém roku předevšı́m z našeho
pohledu, pohledu studijnı́ho programu Geodézie a kartografie, pak je to proto, že podobná
setkánı́ jsou pro nás cenným zdrojem inspirace a ponaučenı́ a snad naše zkušenosti mohou
být ve srovnánı́ inspiracı́ i pro naše kolegy.
Za jeden rok se toho přı́liš nezměnilo a pokud ano, pak změny byly nenápadné. Jednak se nám
podařilo vı́ceméně sjednotit prvnı́ ročnı́ky oborů Geodézie a kartografie a Geoinformatika. Pro
nový obor to předevšı́m znamenalo doplněnı́ dvou tradičnı́ch předmětů Aplikovaná optika a
Elektronické metody, do oboru Geodézie a kartografie byl naopak do druhého semestru nově
zařazen úvodnı́ kurz Databázové systémy. Protože kapacita studijnı́ch plánů je omezená, došlo
k redukci jednoho ze společenskovědnı́ch předmětů prvnı́ho ročnı́ku.
V konkurenci nabı́dky různých škol a studijnı́ch oborů je podle mého názoru nezbytné, aby
přı́buzné i stejné obory různých škol byly jasně profilovány, různost je cennějšı́ než uniformita.
Základem oboru Geoinformatika na stavebnı́ fakultě ČVUT je pochopitelně akcent na geodezii, zařazenı́ předmětů Aplikovaná optika a Elektronické metody je plně v souladu s našim
technickým zaměřenı́m.
Zájem o nový obor geoinformatika se ve druhém roce nijak zásadně nezvýšil, opět budeme v
prvnı́m ročnı́ku otevı́rat pouze dva kroužky. V nastávajı́cı́m akademickém roce 2007-2008 ale
zároveň otevı́ráme prvnı́ ročnı́k magisterského studia geoinformatiky, předevšı́m pro bakaláře
našeho tradičnı́ho oboru Geodézie a kartografie. Do prvnı́ho ročnı́ku se přihlásilo 16 studentů,
což je řádově jedna čtvrtina všech absolventů.
V souvislosti s přechodem na strukturované studium pro náš studijnı́ program vyvstává jistá
komplikace v přijı́manı́ bakalářů z jiných škol. Bakalářské studium je totiž na studijnı́m programu Geodézie a kartografie Stavebnı́ fakulty ČVUT akreditováno jako čtyřleté. Je tedy
otázka, jak řešit přijı́mánı́ třı́letých bakalářů do našich navazujı́cı́ch magisterských programů.
Pokud neprokážı́ u přijı́macı́ zkoušky uchazeči znalosti v rozsahu, který vyžadujeme u našich
bakalářů, může jim přijı́macı́ komise navrhnout přijetı́ do bakalářského studia na jeden rok a
po úspěšném splněnı́ individuálnı́ho studijnı́ho plánu pak přijetı́ do magisterského oboru.
Jestliže naše čtyřleté bakalářské obory představujı́ jistou komplikaci pro mobilitu studentů,
pak na druhé straně poskytujı́ významně většı́ prostor pro odbornou přı́pravu bakalářů ve
srovnánı́ třı́letými obory. Konkrétně zı́skávajı́ naši bakaláři ukončené vzdělánı́ v katastru
nemovitostı́. V magisterských oborech se již katastr nevyučuje.
Geinformatics FCE CTU 2007
5
Svět se měnı́ nenápadně
Za jednu z absurdit našı́ doby považuji, že podle zeměměřického zákona (zák. č. 200/1994
Sb. v platném zněnı́) se ale naši bakaláři nemohou ucházet o zı́skánı́ úřednı́ho oprávněnı́ pro
ověřovánı́ výsledků zeměměřických činnostı́ pro správu a vedenı́ katastru nemovitostı́.
Nikdo přitom nezpochybňuje jejich odbornou způsobilost, v zákoně je ale explicitně požadováno vzdělánı́ alespoň magisterského studijnı́ho programu, pětiletá odborná praxe a složenı́
zkoušky odborné způsobilosti. Zjevně naše společnost nenı́ na bakaláře ještě plně připravena.
Věřı́m, že jde o přechodný stav, který nebude mı́t dlouhého trvánı́.
Zmiňuji zde tento přı́pad proto, že jsem si jist, že nejde o jediný přı́klad, kdy je vysokoškolské
bakalářské vzdělánı́ degradováno zákonem, resortnı́mi předpisy či jen pouhou praxı́ a požadavky profesnı́ch komor. Evropská idea mobility pracovnı́ch sil a všeobecného uznávánı́ vzdělánı́
tak narážı́ na lokálnı́ administrativnı́ překážky.
Na struktuře našich studentů se začı́ná projevovat působenı́ státnı́ školské politiky, která
usiluje o zvýšenı́ počtu vysokoškolsky vzdělaných obyvatel v populaci. Jde o celoevropský,
resp. celosvětový, trend a nemá smysl s nı́m polemizovat. Navı́c jde v principu o správný
cı́l. Protože ale nelze rozhodnutı́m ministerstva školstvı́ zároveň zvýšit průměrnou inteligenci
populace, ani zajistit jejı́ vyššı́ pracovitost a pı́li, struktura našich studentů se nenápadně ale
nezadržitelně měnı́.
Tradice a koeficienty ekonomické náročnosti na technických školách vedou k masové produkci
studentů. V zásadě pro náš studijnı́ program nenı́ problém počet zájemců o studium, ale
jejich kvalita. Počty našich přijı́maných studentů se přitom dlouhodobě držı́ řádově na stejné
úrovni [6]. Skutečnostı́ ovšem je, že dnes přijı́máme i studenty, kteřı́ by před necelými deseti
lety neměli nejmenšı́ naději na přijetı́. Stále přitom máme i výjimečné a skvělé studenty,
v poslednı́ době ale pozoruji trend, kdy podprůměrnı́ studenti majı́ tendenci své nadanějšı́
kolegy demotivovat.
At’ již máme jakékoli názory na e-learning a počı́tačem podporovanou výuku, je mimo jakoukoli diskusi, že jde o technologie, bez kterých se dlouhodobě neobejdeme. Zajı́mavý článek
na téma e-learningu v oblasti geoinformatiky přednesli na semináři Scientia est potentia Petr
Soukup a Pavel Žofka [3].
Jak jsem již zmı́nil, jednou z nenápadných změn v našich studijnı́ch plánech bylo sjednocenı́
prvnı́ch dvou semestrů na oborech Geodézie a kartografie a Geoinformatika a v úvodnı́m
kurzu základů informatiky zařazenı́ databázı́ a SQL i pro geodety. Existuje snad bezpočet
internetových kurzů a tutoriálů na dané téma, z nich ale svým způsobem vyniká A Gentle
Introduction to SQL [4].
A Gentle Introduction to SQL nás s Janem Pytlem inspiroval k úvaze o založenı́ vlastnı́ho
podobného projektu SQLtutor, jehož pracovnı́ alfa verze je k nahlédnutı́ na
http://josef.fsv.cvut.cz/cgi-bin/cepek/sqltutor
Implementace je přitom podružná, základnı́ myšlenka projektu je sestavit sadu SQL úloh a
z nich podle potřeby dynamicky generovat testy, resp. kvizy, se závěrečným bodovým hodnocenı́m. Pokud se projekt ukáže jako životaschopný, budou pochopitelně zdrojové kódy
zveřejněny pod GPL licencı́, právě tak jako datové sady a otázky (zde přicházı́ do úvahy
licence GNU FDL).
Geinformatics FCE CTU 2007
6
Svět se měnı́ nenápadně
V úvodnı́m kurzu se naši studenti seznamujı́ s databázı́ PostgreSQL (že šlo o dobrou volbu
dokazuje mimo jiné i to, že pro přı́štı́ verzi ArcGIS připravuje firma ESRI rozšı́řenı́ o podporu
databáze PostgreSQL). Pro praktické procvičovánı́ SQL použı́váme vývojové prostředı́ emacsu. Databáze otázek pro SQLtutora je generována z textových souborů ve formátu, který
lze spouštět v emacsu pomocı́ sql-postgres módu. Veškeré otázky tedy mohou být zveřejněny
jednak přes interaktivnı́ přı́stup k databázi otázek, jednak zcela nezávisle jako jednoduché
textové soubory, na které jsou studenti zvyklý ze cvičenı́.
Ideálnı́m stavem by byla dostatečně rozsáhlá databáze otázek (později k SQL selectům plánujeme doplnit i operace insert, delete a update a otázky typu ”autoškola”, s výběrem odpovědı́
z dané nabı́dky), která by umožnila generovánı́ kvalitnı́ch testů. Pokud se podařı́ správně
nastavit bodové ohodnocenı́ náročnosti otázek, je možné použı́t systém jako formu zápočtové
pı́semky, přı́padně i jako filtr, který u zkoušky oddělı́ studenty, kteřı́ majı́ napřı́klad šanci se
ucházet o výbornou. Při počtu řádově 120 studentů to může být významná úspora času a
úsilı́ spojeného se zkoušenı́m. Takto ušetřený čas lze věnovat individuálnı́ výuce a zkoušenı́
nejlepšı́ch studentů.
SQLtutor předpokládá, že jednotlivé úlohy budou kategorizovány. Zavedenı́ kategoriı́ otázek
přitom bude jednı́m z nejnáročnějšı́ch úkolů. Kvalitnı́ kategorizace by ale byla cestou pro
automatizované zkoušenı́, ve kterém by bylo možné ověřit, zda se napřı́klad student pouze
zmýlil v jedné konkrétnı́ otázce, nebo zda opravdu nerozumı́ jisté standardnı́ úloze.
Při rekapitulaci uplynulého roku nesmı́m zapomenout na oslavy 300 let výročı́ založenı́ ČVUT.
Na oboru geodézie a kartografie jsme v rámci oslav uspořádali ve spolupráci s druhou komisı́
FIG mezinárodnı́ symposium Scientia est potentia. Sbornı́k recenzovaných referátů ze symposia byl vydán tiskem [5] a zároveň i v elektronické podobě. V druhém čı́sle časopisu Geoinformatics FCE CTU uvádı́me tři přı́spěvky, které z časových důvodů nebyly publikovány ve
sbornı́ku [5] (autoři Karel Večeře, Václav Slaboch a Janis Strauhmanis).
Přı́prava a organizace mezinárodnı́ho symposia byla poměrně náročná a do značné mı́ry šla
na úrok přı́pravy druhého ročnı́ku workshopu Geoinformatika, který jsme museli přesunou na
zářı́. Tak jako minulý rok, tak i letos zajistil veškerou přı́pravu workshopu i vydánı́ sbornı́ku
Martin Landa, kterému bych chtěl upřı́mně poděkovat (věřı́m, že nejen za sebe). Pokud se
v organizaci druhého ročnı́ku workshopu vyskytnou nějaké organizačnı́ potı́že či nedostatky,
pak plně padajı́ na moji hlavu a předem se za ně omlouvám.
Aleš Čepek
19. zářı́ 2007, Praha
[1] Jaroslav Žák, Svět se měnı́ nenápadně, Nakladatelstvı́ Olympia, druhé vydánı́, Praha 1971,
132 stran
[2] Martin Landa, Aleš Čepek, eds.: Geoinformatics, Faculty of Civil Engineering, CTU Prague, sbornı́k referátů [5], 183 pages, 2006, ISSN 1802-2669
[3] Petr Soukup and Pavel Žofka: Experience in the Application of E-learning Tools in Teaching, In Scientia est potentia, Czech Technical University, Prague, Czech Republic, 7-9 June,
2007, pp. 123-134. ISBN 978-80-01-03718-8
[4] A Gentle Introduction to SQL
http://www.sqlzoo.net/
Geinformatics FCE CTU 2007
7
Svět se měnı́ nenápadně
[5] Aleš Čepek ed.: Scientia est potentia, Proceedings of the symposium dedicated to the
development of curricula organized jointly by FIG Commission 2 and the Faculty of Civil Engineering CTU in Prague, Prague, 7-9 June 2007, Published by the Czech Technical University
in Prague. Printed by CTU Publishing House, ISBN 978-80-01-03718-8
http://geoinformatics.fsv.cvut.cz/wiki/index.php/Scientia Est Potentia - Download
[6] Aleš Čepek, Leoš Mervart, and Josef Kopejska. Motivace pro studium geoinformatiky. In
Jiřı́ Horák and Pavel Děrgel, editors, Sbornı́k sympozia GIS Ostrava 2007. Hornicko-geologická
fakulta, Institut geoinformatiky, VŠB – Technická univerzita Ostrava, 28.-31.1. 2007
Geinformatics FCE CTU 2007
8
Surveying Curriculum from the Point of
View of Multidisciplinarity
Václav Slaboch
CLGE, Vice President for Professional Education
vaclavs.vaclavs seznam.cz
Keywords: Multidisciplinarity, Modern curriculum for Surveying Education, role of CLGE,
multilateral Agreement of Mutual recognition of qualification. Necessity of a CPD system for
Surveying Profession.
Summary
The multidisciplinarity and globalization makes fade the differences among professions and
surveying is no exception. CLGE – CLGE has a name in two of the many European languages
English and French, namely “The Council of European Geodetic Surveyors” and “Comité de
Liaison des Géomètres Européens”. A “Multilateral Agreement” on mutual recognition of
qualification in surveying was signed in 2005 in Brussels by representatives of Germany,
France, Belgium, Switzerland and Luxembourg. In 2006 also Slovakia joint this Agreement.
The signature by the Czech Republic is recently under discussion.
Multidisciplinarity and globalization and their influence on surveying
The multidisciplinarity in our profession is nothing new. A good example might be the
Famous Italian Surveyor an architect Domenico Martinelli (1650-1718) to whom an European
Research Project financed from ERDF (European Regional Development Fund) has been
dedicated. Martinelli was not a mere surveyor, but also a diplomat, judge, valuer, professor
and architect. By the way his multidisciplinarity is typical even for present Italian surveyors.
Martinelli´s relations to Czechia are represented namely through his diplomatic services for
count Kounic, during his diplomatic mission in as emperor’s ambassador in the Dutch Hague
in 1698. One of the most famous architectonical project of Martineli is the château Slavkov by
Brno (Austerlitz). Partners of this Project are, Universität Wien, Faculty of Philosophy of the
Masaryk University in Brno, Senate of the Czech Republic, Liechtenstein Museum Vienna,
U.S. Embassy in Prague and the Town of Rousı́nov. It might be worth while considering to
launch a similar interregional project dedicated to real estate cadastre covering the countries
of the former Austro-Hungarian Cadastre (Czechia, Slovakia, Hungary, Austria, Croatia,
Slovenia, Italy). In fact this co-operation already exists, but it might be enlarged by France,
Belgium and maybe even Denmark. Why this enlargement e.g. by France? Because the
Geinformatics FCE CTU 2007
9
Surveying Curriculum from the Point of View of Multidisciplinarity
Czech Society of Surveyors and Cartographers is one of the founding members of the FGF
(Federation de Géometrs Francophone) and also because the so called Napoleonian Cadastre
is based on the same principles as the former Austro-Hungarian Cadastre. The new definition
of the functions of the surveyor as adopted by the FIG General Assembly in Athens in May
2004 is a typical example of a multidisciplinary approach to our profession.
Main Points of the New Definition of Surveying Profession as Adopted by FIG
and CLGE:
A surveyor is a professional person with the academic qualifications and technical expertise
to conduct one, or more, of the following activities:
ˆ to determine, measure and represent land, three-dimensional objects, point-fields and
trajectories;
ˆ to assemble and interpret land and geographically related information;
ˆ to use that information for the planning and efficient administration of the land, the
sea and any structures thereon; and,
ˆ to conduct research into the above practices and to develop them.
CLGE and their mission
CLGE has a name in two of the many European languages English and French, namely “The
Council of European Geodetic Surveyors” and “Comité de Liaison des Géomètres Européens”.
This has arisen because the business of the council is conducted in English, and the language
of the European Courts of Justice is French. The accepted abbreviation in all languages is
“CLGE”. CLGE was established at the Féderation Internationale des Géomètres (F.I.G.).
Congress in Wiesbaden in 1972 by the then 9 member States of the EEC to consider the
implementation of the Treaty of Rome in relation to the profession of geodetic surveying.
CLGE represents in Europe the geodetic surveyors in 23 States, which includes 22 member
states and Norway, Switzerland too.
The purpose and objectives of the CLGE
The purpose of CLGE is to represent and to promote the interest of the geodetic surveying profession in the private and public sector in Europe, especially to the Institutions of
the European Union. The aim is to enhance the development of the profession both administratively, educationally and scientifically, to facilitate training, continuous professional
development and mutual recognition and to promote the activities of geodetic surveyors as a
highly qualified profession.
Liaison with the European Commissions
CLGE has nominated a liaison Officer to open and maintain contact with the European
Commission. Links have already been established with DG 12, 15 and 22.
The Executive Board consisting of
ˆ President
Geinformatics FCE CTU 2007
10
Surveying Curriculum from the Point of View of Multidisciplinarity
ˆ The President is chairman of the General Assembly and the Executive Board
ˆ Vice President for professional Education
ˆ Vice President for professional Practice
ˆ Vice President for European Relations
As permanent members:
ˆ Secretary-General
ˆ Treasurer
Multilateral Agreement on mutual recognition of professional qualifications of
public appointed surveyors
On 24th October 2004 representatives of Surveying Profession from Switzerland, Germany,
France, Belgium, Austria, Luxembourg and Denmark signed the following Multilateral Agreement. In 2006 this Agreement was also signed by Slovakia.
Preamble
The basis of all commercial and financial activity is confidence in the security of the legal
system relating to land and property. National constitutions protect ownership of land
and property and subject commercial and financial activity to strict procedures of a formal
nature. In central European countries, comprehensive and legally binding documentation
relating to ownership of land and property is assured traditionally by the technical-legal
system of “the land register – real estate cadaster”. The keeping of ownership and mortgage
registers as well as real estate cadasters is a matter for the State. Codified procedures for
registration and changes to entries therein must be compatible in all three areas in order
to assure the necessary security. The presumed correctness of registers is reflected in the
Real Estate Cadastre in the presumption of correctness of the cadastre entries in terms of
location of the property boundaries and the designation of properties. Furthermore, real
estate cadastre contains much more information which is essential for the functioning of the
State, for the commercial and scientific utilisation of the surface of the earth, for avoidance
of hazards and for nature protection and for safety in planning and civil engineering.
As changes in the registries of State and commercial interests arise in terms of place and
time in a random fashion by their very nature, central European States have made use of
the instrument of delegation of State functions for the past three hundred years. Specially
trained reliable persons such as notary-publics or publicly commissioned geometers have been
selected for this function. The multiplicity of public and private laws and legal effects relating
to land and property calls for impartiality, reliability and comprehensive technical and legal
knowledge on the part of members of the profession.
Protection of ownership as a basis of an economy starts out very simply with confidence in
the publicly commissioned geometer as an individual who, without regard to person, sets out
the boundaries of the property and the rights accruing from the property and thus lays the
foundation for the implementation of constitutional dictates for protection of ownership of
land and property. The complexity of land rights in modern economies calls for thorough
Geinformatics FCE CTU 2007
11
Surveying Curriculum from the Point of View of Multidisciplinarity
command of technical and legal knowledge relating to land and property on the part of the
geometer commissioned with these duties in order to be able to carry out this function. In
central Europe, public registers covering ownership are quite diverse. The complexity of
regulations is increasing in modern economies because land as a resource is coming to play
an ever more important role and is being circumscribed in diverse legal manners. The legal
framework within which the commissioned geometer operates differs from one country to the
next and continues to develop.
A profession for public functions
Geometers commissioned to perform public functions are known in a number of countries:
in
in
in
in
in
in
in
France
Germany
Belgium
Denmark
Austria
Switzerland
Luxembourg
as
as
as
as
as
as
as
Géomètre-Expert,
Öffentlich bestellter Vermessungsingenieur,
Géomètre-Expert / Landmeter-Expert,
Praktiserende Landinspektører,
Ingenieurkonsulent für Vermessungswesen,
patentierter Ingenieurgeometer,/ ingénieur géomètre breveté,
Géomètre-Officiell.
With this delegation of functions, States pursue the aim of opening up public functions to
competition and reducing costs as well as improving the effectiveness of public registers in
the economy. In this context, the appointment of a highly qualified member of the liberal
professions is an advantage for citizens in their function as consumers as they can select their
service provider from the pool of competing, commissioned individuals all of whom are on
an equal footing. It has been proven historically that the organizational form of the liberal
professions, under State supervision in terms of personnel and specialist knowledge, or in selfadministration in conjunction with efficiency-based competition is the form which discharges
public functions for State and for commercial interests most efficiently in the long term. In
the above-mentioned countries, there are roughly 4,500 offices with one or several members
of the profession.
Professional rules govern public appointment
In the respective countries, the professions are based on legislation governing the particular
profession which regulates duties assumed, entry requirements to and ethics of the
profession. In addition, there are procedural laws which set out the professional scope of
work. These relate to areas of real estate, planning and civil engineering. The core of the
profession is to be found in being commissioned to perform surveying work in the respective
property securing system. Moreover, the profession rests on the following pillars:
ˆ cadastral survey and safeguarding property boundaries, privately commissioned
ˆ documentation of property surveying (i.e. keeping registers, measures, computations
and maps, publicly commissioned)
ˆ national geodetic survey
ˆ geomatics / geoinformation / topography / hydrography
ˆ certification of facts relating to land and property
Geinformatics FCE CTU 2007
12
Surveying Curriculum from the Point of View of Multidisciplinarity
ˆ work as technical expert reflecting the whole range of the professional formation
ˆ application of laws relating to land and property
ˆ real estate valuation
These are public functions, referred to as “sovereign” in some countries; as a rule, a member
of the profession is permitted to take on assignments in the context of private law, if such do
not give rise to a conflict of interest with the legal independence of the said member. Commissioning a member of the profession to carry out public work (delegation) is by government
bodies or professional boards. In France, Belgium and Luxembourg, the géomètre-expert is
the link from the property tax cadastre to ownership. In the German Federal states, members
of the profession also issue administrative acts in their own right, in Austria, they issue official documents, in Switzerland, they carry out surveying and administer the comprehensive
official Swiss surveying activities. In all countries the consultation of the consumer concerning the limitations of the real estate property due to the legal contents and geometry of the
boundaries is the first duty of the profession. In no country are the numbers of members of
the profession restricted by Government or self-administration; on the contrary, once members of the profession have provided proof of the necessary qualification, they have a right to
admission. In that way, newcomers can always enter the profession. In all signatory states,
there is a general trend towards an increase in delegating State functions to commissioned
free-lance geometers.
Entry to the profession and its European dimensions
Regulations relating to entry to the profession vary from one country to another, however
they are very similar and are in terms of their nature essentially of the same kind.
Demonstration of attainment of the necessary qualification involves, apart from an academic
course of study for surveyors (Bac + 5U) the following general fields of study
ˆ Administrative law,
ˆ Land law,
ˆ Building and planning law.
University education provides a widely available and comparatively equivalent, defined knowledge base. Thus, it has not been problematic to-date to perform straight-forward surveying
techniques in a cross-border context (for a non-commissioned geometer or surveying technician). This happens very often. The education set out below thus relates to practice and
legal issues arising in the particular national legal system. There is, however, no possibility
of exercising the public functions of a commissioned geometer on a cross-border basis. The
regulatory situation on the one hand and the de facto impossibility of mastering two legal
systems in sufficient professional depth have precluded this to-date, not to speak of other
formal obstacles. Otherwise the right of public certification of facts is used in cross border
service already now.
Nonetheless, the situation in the sector is in a constant state of flux, the legal systems are
being investigated mutually and knowledge is disseminated transnationally over borders, not
least by international associations such as GEOMETER EUROPAS. In addition, the EU is
Geinformatics FCE CTU 2007
13
Surveying Curriculum from the Point of View of Multidisciplinarity
moving slowly in the direction of a harmonization of laws which also presupposes mutual
understanding as a prerequisite.
As this is of major importance economically, this initiative of the signatory states also has
the objective of making knowledge of practice of the profession more transparent in a legal
and technical context and of drawing up common European positions in this sector. The
larger this block of common European knowledge is, the sooner universities and training
institutions can take account of it. This makes it easier for those entering the profession to
avail of the possibility of working in the European country of choice, with all well-known
associated economic advantages. This likewise serves to achieve a stepwise harmonization of
systems and their use to the benefit of the European population.
Illustration of the hitherto existing prerequisites for admission
Differences between countries having publicly commissioned geometers are, when seen in
isolation, multifold and, in addition, vary between French and German speaking areas but, in
summary, they produce geometers who can function well within the respective legal system.
For the individual countries, the following regulations apply:
Country
Master
Professional
practice (after
BAC+5)
Exam
France:
BAC1 + 5U2
2P
Germany:
BAC + 5U
Belgium:
Denmark:
BAC
+
4U
(in
future:
BAC+5U)
BAC + 5U
1 P after State
examination
0 P (2P)
Appraisal
of
work
certificates: D.P.L.G.
(in case of basic
education at a
State school)
State examination
without
Austria:
BAC + 5U
3P
Switzerland:
BAC + 5U
min. 18 months
Luxembourg:
BAC + 5U
2 P (min 6
months
in
cadaster administration)
3P
Selection based
on work certificates
External examination
External examination
Examination
Other
Right
to being
admitted
yes
2R
yes
Con”
vention“
yes
yes
yes
Legend:
Geinformatics FCE CTU 2007
14
Surveying Curriculum from the Point of View of Multidisciplinarity
BAC + 5U: Baccalaureat + 5-year study at a university / technical university
P: On-the-job training in law and work practice in the respective country after university
study
R: compulsory monitored experience prior to the Great state examination (two years)
In various countries, legal professional regulations also allow holders of a degree from a technical university to enter, if they can provide evidence of relevant technical and legal knowledge
(and a longer practical training). This is regulated by national law.
Current admission and examination institutions
The current examination and admission institutions are state institutions or legally established
boards
Country
France:
Germany:
Belgium:
Denmark:
Austria:
Switzerland:
Luxembourg:
Examination authority
Ministry of Education (for DPLG)
principally the Oberprüfungsamt
(Higher
Examination
Office)
Frankfurt
Communautés (VL+ W) Assermente Tribunal de 1ere Instance
Supreme Land Surveying Authority
Federal Ministry of Economics and
Labour
Swiss examination commission
EPIG
Examination
commission
appointed by the Minister
Admission authority
Ordre des Géomètres Experts
Ministries of the Federal laender
Conseils Federaux des GeometresExperts
Supreme Land Surveying Authority
Federal Ministry of Economics and
Labour
Executive Federal Council
Ministry of Finance
Mutual recognition of qualifications for admission to the profession
The signatory states mutually recognize the qualifications for admission to the profession of
a European Geometer and agree on a procedural modus for ensuring unimpeded migration
of members of the profession – irrespective of the directive 89/48 – on the following basis:
Training as a graduate engineer (Bac + 5) in surveying or Master (if compatible) is recognized automatically as an educational foundation. In additional, each candidate must acquire
necessary country-specific extra qualifications in the area of
ˆ administrative law,
ˆ land law,
ˆ building and planning law.
Qualifications for admission to the profession shall then be based on a common, general
platform
Diploma-engineer / European Master (BAC + 5U) + 2R/P + E
Geinformatics FCE CTU 2007
15
Surveying Curriculum from the Point of View of Multidisciplinarity
Treatment of migrants after obtaining qualification in a signatory state
The signatory associations support such migrants to provide them with the opportunity of
evidencing the required knowledge in
ˆ administrative law,
ˆ land law,
ˆ building and planning law.
of the respective country and of fulfilling the European platform requirements in terms of
legal admission regulations. The admitting member states might value the elements of the
formation and experience of the migrant and give him the choice between training seminar
and an examination to prove his acceptability.
References webliography and bibliography
1. Internet homesite of the CLGE – www.clge.eu
2. Internet homesite of the FIG – the International Federation of Surveyors – www.fig.net
3. FIG Definition of Functions of the Surveyor1 as adopted by the FIG General Assembly
on 24 May 2004
4. EU Interreg Project Domenico Martinelli2 (1650-1718) Italian surveyor and architect
5. ZEMĚMĚŘIČ a Czech Monthly for surveying, Cadastre and Cartography3 . The new
definition of Surveying profession – illustrated
6. Internet home site of the VUGTK – www.vugtk.cz – the Research Institute of Geodesy,
Topography and Cartography at Zdiby, with the Land Surveying Library where the
originals and the Czech translations of majority of the cited documents are now available.
7. Otmar SCHUSTER: Multilateral Agreement. Proceedings from the International CLGE
Conference at the RM in Brussels, 1-2 December 2005. VÚGTK, Volume 52, Publication
No. 39, ISBN 80-85881-14-4
8. Stig ENEMARK, tom KENNIE: CPD – Continuig Professional Development and its
future promotion within FIG- in Surveying. FIG Publication No. 15.
9. Vaclav SLABOCH, Frantisek KRPATA, Josef WEIGEL: Surveying education in the
Czech Republic
10. Otmar SCHUSTER: Surveying Market in Europe. CLGE publication, 2004
11. Vaclav SLABOCH, Jean-Yves PIRLOT(edts): European Professional Qualifications In
Geodetic Surveying, Proceedings of the CLGE International Conference 2005, Brus1
http://www.fig.net/general/definition.htm
http://www.domenico-martinelli.com/index en.html
3
http://www.geos.cz/resort/definice.htm
2
Geinformatics FCE CTU 2007
16
Surveying Curriculum from the Point of View of Multidisciplinarity
sels/Belgium, 1-2 December 2005, VÚGTK, Volume 52, Publication No. 39, ISBN
80-85881-14-4
12. Vaclav SLABOCH: Impacts and Challenges of the EU Membership on Surveying Profession in the Czech Republic. In: 1st International Trade Fair of Geodesy, Cartography,
Navigation and Geoinformatics, GEOS 2006, Conference Proceedings, Milan Talich
(Ed), VÚGTK, Volume 52, Publication No. 40, ISBN 80-85881-25-X.
Geinformatics FCE CTU 2007
17
Geinformatics FCE CTU 2007
18
Scientia Est Potentia Welcome Words
Karel Večeře
president of the Czech Office for Surveying, Mapping and Cadastre
karel.vecere cuzk.cz
Ladies and gentlemen, distinguished guests,
It is a great honour for me to cordially greet you here in Prague on the occasion of the Knowledge is Power conference. The Symposium has been organised by the FIG Commission for
professional education, and the Faculty of Civil Engineering of the Czech Technical University
in Prague, and is being to mark the occasion of the 300th anniversary of its foundation. I am
really pleased, that this Symposium is taking place right here in Prague and I hope that it will
be a source of inspiration for the development of education in land surveying and geomatics.
Allow me now to say a couple of words from the position of the man who is responsible not
only for the nation-wide land surveying activities and products (maps etc.) but also for the
administration of the cadastre of real estates.
Land surveying has changed dramatically over the last 20 years. We had barely got used to
electronic surveying devices, which replaced the previous optical equipment, when satellitepositioning methods arrived. Built-in computers in measuring devices process the surveying
results and therefore written records of surveyed data are hardly used at all. Computer processing and presentation of the results of land surveying activities have undergone radical
changes. Only the people with excellent basic knowledge acquired in the educational process
can respond to these changes and can be actively engage to them. Previous technical development has brought many incentives into the educational system, the content of Surveyors´
studies has been changing, and the additional education for land surveyors has been growing.
New study specializations such as geomatics, which reflects this development, have appeared.
We can also recognize other aspects of this progress. We do not need so much time for
surveying itself and the processing of results is also much faster. Could this be a cause for the
decline in the number of surveyors? I personally don’t think so. The point is, however, that
surveyors should evolve into further areas. The range is really wide. We are traditionally very
closely connected to informatics, and Universities have also had to revise their educational
programmes as a result of this. I dare say that GIS can be studied at all Universities with
the land surveying specialization.
However, GIS is not the only field for surveyors and for their potential value. The real
estate market has been growing rapidly in the Czech Republic – it represents more than 10%
annual growth. It is a huge sphere for our profession. Due to our history the orientation in
cadastral documentation is still very complicated and surveyors are able to assist in this, it
means not only in executions of surveying sketches for partioning of parcels or surveying of
Geinformatics FCE CTU 2007
19
Scientia Est Potentia Welcome Words
new buildings. Despite this fact the combination of a land surveying company with a real
estate agency is still rather exceptional. It might be an area for some changes in the content
of educational programmes, which should enable to acquire wider knowledge in the field of
evaluation of real estates or even in economy with focus on the real estate market. I think
that our universities are able to prepare highly skilled graduates even in the field of land
consolidation, and possibly in further fields important for cooperation on projects focused on
better use of both urban and rural areas. That is the reason why surveyors often take part
in teams preparing and launching such projects.
I could go on listing fields suitable for surveyors for many hours, the point is, however, whether
they will get a sufficient base for these specializations during their study and whether we will
be able to motivate them enough for these interdisciplinary fields.
By the end of 2006 a total of 720 graduates from technical universities focused on surveying
had worked in our offices but beside them also 432 graduates from faculties of law and 343
graduates from other universities, particularly IT specialists and economists. In addition to
that we employ more than 3 000 alumni of secondary schools, half of them being surveyors.
The great number of lawyers is a result of the fact, that we are responsible for the registration
of rights to real estates. We execute legal examination of deeds about real estates and on
this base we decide about the registration of the right in the cadastre of real estates or
its refusal. The experts in informatics support not only everyday operation of IT but also
further development of cadastral information system and other GI systems. As I have already
mentioned, the cadastre of real estates in the Czech Republic includes and connects at present
3 main professions:
1. Surveyors, particularly responsible for the mapping part of the cadastre, but also supporting other technical activities,
2. Lawyers, supporting the registration of rights and supervising other administrative activities,
3. Experts in informatics, taking care of the complex databases of the territory and supporting a wide range of services for customers and employees.
The graduates of different universities have to cooperate really closely. Without such cooperation we could not achieve satisfactory results. General overview of each other’s work and a
certain overlap into the specialization of their colleagues gained already at university are very
useful for cooperation of experts from different specializations. It seems to me, that there is
no problem to provide enough education in informatics for surveyors. Universities produce
graduates in surveying field who are more than just skilled users of IT and who are competent
even in areas requiring deeper knowledge of informatics. It is interesting that nowadays even
graduates of faculties of law have not serious problems with informatics and are able to make
use of information technologies on a high level.
More complicated situations occur in the cases that require certain knowledge of law. The
surveyor working in the cadastre also needs knowledge of Civil Code, Land Law, Administrative Procedures Law, Urban Planning Law and others. It is rare to find a graduate of both
branches – surveying and law, but from my point of view it isn’t so important. The important
thing is to improve the legal awareness of surveyors during their education – at least in land,
building and administrative laws. And that is not only the problem of surveyors in the state
Geinformatics FCE CTU 2007
20
Scientia Est Potentia Welcome Words
administration. The surveyor should be able to act as a complete advisor at least regarding
the technique of real estates business. To do so, they have to have knowledge of further
processes provided usually by experts from other branches such as urban planning, building
proceeding, water proceeding or they need skills of some important aspects of the nature and
landscape protection. Unfortunately, surveyors often acquire this necessary knowledge from
their working experience, and often in a very complicated way.
It is necessary to mention, that the graduates of faculties of law face the same problem of
insufficient awareness in some technical fields. It is difficult in many cases to provide them
with sufficient basic technical knowledge to simplify their orientation in surveying sketches.
They do not get such skills at the faculty. Nevertheless, this knowledge is the essential for
correct registration of the proprietary rights, of mortgages or easements, apart from correct
making a deed about the real estate. That is why we organize further education in this basic
field of cadastre for our lawyers.
Ladies and Gentlemen, I have tried to address the problems faced by state administration
responsible for cadastre of real estates and surveying in connection with university education.
We realize more than 1,5 mil. registrations of changes into the cadastre, introduce 130
thousand survey sketches into maps and update other geographical documentation of the CZ
territory each year.
This is, however, significant part of land surveying in this country, but it does not cover
everything. There exist both great land-surveying companies with a wide offer of services
and products acting on the whole state territory and small land surveying companies specialized – for instance – on survey sketches and acting only on a limited territory. There
are construction companies with their special needs for high accuracy while laying out and
monitoring buildings. There are utility companies with their specific needs for documentation in technical maps, today on the base of GIS, for professionals as well as for common
users. There is public administration demanding updated and precise information about the
territory for its decisions. All these diverse ideas and professional needs should be satisfied.
Universities ought to strive to offer skilled graduates equipped with the necessary knowledge
and skills and above all with the ability to proceed further in their personal development.
This task is definitely not simple, because the educational process cannot omit other even
more important aspects and universities have to develop also the language skills or economic
awareness of students and last, but not least, to address the general personal development
including the ability to present the results of their work.
Well, I hope this conference will inspire many new ideas which will enrich the education of
graduates of land surveying and geomatics and even influence lifelong learning. We all –
employers and employees as well as our customers, business partners and universities – will
benefit from such a development in the future. I hope, that you find the Prague atmosphere
hospitable and inspiring. At the Czech Technical University in Prague – such discussions
have been held for 300 years and without such debates no University would be able to fulfill
its mission.
I wish your conference success once again.
Thank you for your attention.
Geinformatics FCE CTU 2007
21
Scientia Est Potentia Welcome Words
Karel Večeře, Scientia Est Potentia1 – FIG Commission 2 Symposium, Prague, Czech Republic, 7-9 June 2007
1
http://geoinformatics.fsv.cvut.cz/wiki/index.php/Scientia Est Potentia
Geinformatics FCE CTU 2007
22
Software used for diploma thesis at
Geoinformatics VSB-TUO
Jan Růžička
Institute of Geoinformatics
Faculty of Mining and Geology, VSB-TUO
E-mail: [email protected]
Keywords: Software, GIS, open source, freeware, commercial, diploma thesis
Abstract
The paper describes software usage for diploma thesis presented by VSB-TUO students during
students conference GISáček. A prepared statistics was build from papers available at web
pages of the conference. The prepared statistics is not complete clear view on this area, but I
do not have any other simple way how to prepare such statistics.
The statistics was build just from the text of the papers. If a student mentioned any software
than it is included in the statistics. Summarized results are presented at the following figures
with some general comments, that can be useful.
The statistics is prepared only for years 2000 – 2006. A last year of the conference was not
included, because of problems with availability of the proceedings.
Software is categorized to three categories. A category fee contains only software that must
be payed. This category includes software that can be obtained by students free of charge, but
for firm usage must be payed. A category without fee includes software that can be used free
of charge even for firm purposes, but is not available as an open source software. The last
category open source includes open source software and in a case of this statistics, all open
source software mentioned by students is free of charge as well.
GIS and CAD software
Category GIS and CAD software includes all software that can be directly used for spatial data
manipulation. There are not included systems such as MySQL, Oracle, GIMP, Statgraphics
that can be used for spatial data manipulation, but they were not used as GIS or CAD
software for the thesis.
Complete list of the GIS and CAD software that were mentioned by students follows: ArcIMS,
ArcView IMS, MapGuide, JShape, PMS, Deegree, MapServer, ArcInfo (ArcGIS), Surfer ArGeinformatics FCE CTU 2007
23
Software used for diploma thesis at Geoinformatics VSB-TUO
cPad, TopoL, ArcSDE, ERDAS Imagine, Infomapa, MapObjects, KOKEŠ, Patch Analyst,
ArcInfo (7.x), PC ARC/INFO, FlowMap, ArcView, AutoCAD, Microstation, IRAS-C, GeoMedia, Pathfinder Office, Cadfusion, Kristýna GIS, OCAD, Terra Explorer, GDAL, Thuban,
MapWindow, uDIG, OGR, QGIS, gvSIG, GeoTools, PostGIS, GPSsim, OpenMAP, JUMP,
JgraphT, Transform, NVIZ, Vis5D+, Trand’ák, FWTools, GRASS.
OGR, GDAL or other libraries were used as an individual software pieces not as a part of
MapServer or GRASS software.
Figure 1: GIS and CAD software
The figure 1 shows number of GIS and CAD software used during 2000 – 2006 period by
students. We can see high increase of the number of open source and software without fee
in the last two years. To be correct we must mention that for several tasks user in the open
source area usually uses not only one software, but a set of software. In the area of commercial
software this is not so common. For this purpose you can find figure 4 that shows software
used by individual student.
Figure 2 shows number of Web Mapping software used during 2000 – 2006 period. We can
see that there was free or open source software used every year when Web Mapping software
was used. A complete list of the used web mapping software follows: ArcIMS, ArcView IMS,
MapGuide, Jshape, PMS, Deegree, MapServer.
Figure 4 shows how is GIS and CAD software used by individual student. There are three
categories of students: students that use only fee software, students that use only free ware
software (including open source) and students that use both kind of software.
Very interesting is popularity of ESRI software between students. Although we use different
software for teaching during the study, the first one software that is used is ESRI software
(ArcView in the past and ArcGIS nowadays). This is described at the figures 5, 6 and 7.
Figure 5 shows that other than ESRI commercial software for GIS and CAD is not generally
used by our students. Situation will not probably be better in the next years, because our
university paid for site licence of the ESRI products. This license will be available for all
Geinformatics FCE CTU 2007
24
Software used for diploma thesis at Geoinformatics VSB-TUO
Figure 2: Web Mapping software
Figure 3: GIS and CAD software without Web Mapping software
students that are connected via VPN to the campus intranet. I feel this as a problem, that
can be solved only by other GIS and CAD software vendors action via companies that can
prepare diploma thesis for our students.
Figure 6 and 7 shows that our students are usually in face of decision: Use ESRI or open
source software. Diploma thesis that are written by our students are usually prepared for
some company (commercial, non-commercial). Does it mean that for the practice are only
these two options? I believe that not, and that the reason is a structure of our company
partners specialization.
Very intersting is usage of individual software during whole period. At figure 8 you can
see that more than 40% are ArcInfo (from ArcGIS edition) and ArcView 3.x, about 38% is
Geinformatics FCE CTU 2007
25
Software used for diploma thesis at Geoinformatics VSB-TUO
Figure 4: GIS and CAD software by individual student
Figure 5: ESRI and other GIS and CAD fee software
distributed between software with usage less than 2%. About 18% is divided between open
source software MapServer, PostGIS, GRASS, JUMP and commercial software MapGuide
(before it has been open source), ArcIMS.
You can compare this individual software usage for 2000 – 2006 period with single year
2006 that is described at figure 9. ArcInfo and ArcView are still quite strong, but there is
remarkable increase of other open source software. OGR and GDAL in this case were used
as an individual software pieces not as a part of MapServer or GRASS software.
Geinformatics FCE CTU 2007
26
Software used for diploma thesis at Geoinformatics VSB-TUO
Figure 6: ESRI and other GIS and CAD open source and without fee software
Figure 7: ESRI and other GIS and CAD software
DBMS software
Students during the 2000 – 2006 period used following DBMS (DataBase Management Systems) software: Oracle, MS Access, MS Excel, MySQL, eXist, PostgreSQL, MS SQL Server
(free edition). MS Access and MS Excel are not exactly the DBMS, but they are generally
used for data storage and manipulation.
MS Access that was mentioned 31 times (generally more than 80% of fee DBMS) during
whole period. This software is used for teaching in database systems subject. PostgreSQL
was mentioned only in a connection to PostGIS software. MySQL was mentioned mainly in
a connection with Web Mapping software.
Other software
Students during the 2000 – 2006 period used following other software: Statgraphics, SPSS,
TRANSCAT, Jı́znı́ řády, Malovánı́, HYDROG, DOK, HEC-HMS, AEOLIUS, WebCastle,
CASC2D, MODFLOW, LiveCD, JGAP, PHPGraph, GIPSY OASIS, Sarovar, GIMP, VirtualDub, Apache, Plone, Zope, Axis, Tomcat, JBOSS.
This is probably quite common that users of the open source software mention any software
Geinformatics FCE CTU 2007
27
Software used for diploma thesis at Geoinformatics VSB-TUO
Figure 8: GIS and CAD software 2000 – 2006
Figure 9: GIS and CAD software 2006
that they used. They usually mean this as an acknowledgements to open source software
developers. Users of the commercial software thank by payment. Other software is mentioned
Geinformatics FCE CTU 2007
28
Software used for diploma thesis at Geoinformatics VSB-TUO
Figure 10: DBMS software
Figure 11: Other software
mainly in the last years, this can be cause of better preciseness of the participants.
Operating systems
Very interesting is usage of operating systems. There are only a few students that were
completely satisfied with GNU/Linux (UNIX – there was used only one UNIX system named
Irix) OS only. Most common are students satisfied with OS MS Windows only, but in a last
years is quite common combining OS MS Windows with OS Linux.
Geinformatics FCE CTU 2007
29
Software used for diploma thesis at Geoinformatics VSB-TUO
Figure 12: Operating systems
All software
There are prepared figures 13, 14 and 15 for complete view on the statistics.
Figure 13: All software (without operating systems)
Programming languages
Students mentioned programming languages used for their diploma thesis. There are not so
big surprises at the following figure. Students can learn PHP, Java and Visual Basic during the
study. Usage of the Avenue language is only a reflection of ArcView usage. VRML was (maybe
still is) favorite modeling language of the former head of the Institute of Geoinformatics.
Geinformatics FCE CTU 2007
30
Software used for diploma thesis at Geoinformatics VSB-TUO
Figure 14: All software (without OS) by individual student
Figure 15: All software (without OS) 2000 – 2006
Few words at the end
The statistic prepared for this paper is not representative, but shows some trends. Students
did not mention all software that they used for their diploma thesis and some of them did not
mention any software. For the paper were checked 129 papers form students’ conference, 122
students did mention any software. This is the best that we can have for our statistics. We
can read all thesis to get better statistic, but this will not be probably efficient. I can make
a mistake and did not found all software mentioned during the statistics preparation, but I
Geinformatics FCE CTU 2007
31
Software used for diploma thesis at Geoinformatics VSB-TUO
Figure 16: Programming languages 2000 – 2006
believe that I got at least 95% of mentioned software.
Geinformatics FCE CTU 2007
32
GAL Framework
Radek Bartoň, Martin Hrubý
Faculty of Information Technology
Brno University of Technology
E-mail: [email protected], [email protected]
Keywords: design, GIS, GRASS, open source, library
Abstract
GAL (GIS or GRASS? Abstraction Layer) Framework is meant to be multiplatform OpenSource library with certain tools and subsidiary daemons for easy implementation of distributed
modules for GIS GRASS1 in static or dynamic programming languages. This article aims to
present some ideas behind this library and bait a fresh meat for this project since its complexity
needs more spread development team not just single person. Project homepage can be found
at http://gal-framework.no-ip.org.
Motivation
A year ago I was trying to implement some feature to nviz module and I got acquainted with
GRASS’s core libraries. Accustomed to well-designed and well-documented APIs like Qt2 ,
Coin3 or wxWidgets4 it was shocking to me to meet such old-styled API with underestimated
state of documentation, so I gave up that job in few days in anger. But because I like GRASS
style from user’s point of view and its complexity and scalability of provided modules, I wanted
1
http://grass.itc.it/
http://doc.trolltech.com/
3
http://doc.coin3d.org/Coin/
4
http://www.wxwidgets.org/manuals/stable/wx contents.html
2
Geinformatics FCE CTU 2007
33
GAL Framework
to provide an easy and modern approach to module development along with current ones for
those that are not satisfied with present possibilities as me. So I decided to work on GAL
Framework as my diploma work and thesis. As actual advancement of common information
technology in hardware domain heads to multiprocessored devices and usage expansion of
dynamic languages such as Python, Java, C# or Ruby is here, there is need to consider these
factors in GRASS development too. GAL Framework should be answer to these trends.
Principles
GAL Framework should be alternative to current way of creating new modules for GRASS and
some current modules can be reimplemented in GAL Framework too if some weight reasons
occurs. Illustration of future GAL Framework role in GRASS module development can be
seen on Figure 1. Current GRASS code is displayed yellow and it is formed by GRASSlib and
code of each of GRASS modules. Green GAL Framework code is formed by core GAL library
and code of new GRASS modules which can be implemented with it or code of reimplemented
modules (v.proj for example). GAL Framework then may depend on GRASSlib itself and
other possible libraries such as D-Bus5 for distributive execution of functions or TerraLib6 for
faster implementation of GIS related functionality (red block).
Figure 1: Role of GAL Framework in module development.
GAL Framework internally uses component architecture which means that whole system is
formed by bunch of components which communicate which each other by interfaces. Some
components declare interfaces, some of them implement interfaces and some of them use
interfaces. Using UML syntax this can be displayed as on Figure 2.
There are four components and one interface on a figure. Component 1 declares an interface
Interface which indicates stereotype <<reside>>. Component 1 and Component 2 uses in5
6
http://www.freedesktop.org/wiki/Software/dbus
http://www.dpi.inpe.br/terralib/
Geinformatics FCE CTU 2007
34
GAL Framework
Figure 2: Component architecture in UML syntax.
terface (symbolized by dashed line with arrow). That means that they are calling interface’s
functions. Component 3 and Component 4 implement interface functions which is symbolized by solid line. There is an abstraction over interface functions called slots which may be
configured some ways to specify which implementation will be executed when interface slot is
called. Sometimes you may want to execute just lastly registered implementation, sometimes
you may want to call each of them, etc.
To allow public access to all available components and interfaces in the system, a common
access point must be introduced. In this case, it is called component manager and it serves
for new component or interface registration as long as registration of interface implementations. Figure 3 shows simplified class diagram for relationships between component manager,
components, interfaces and slots:
Figure 3: Class diagram of component architecture.
Let’s see on Figure 4 how can be this component architecture applied in practice:
There is a ModuleComponent component implementing a GRASS module at the top which
uses three different (and imaginary for now) interfaces:
ˆ IVectorLayerProvider,
ˆ IRasterLayerProvider,
ˆ IMessageHandler for retrieving of vector or raster data and for message display and
logging.
IVectorLayerProvider interface is implemented by two different components registered in
system. One of them shelters vector layer data in PostgreSQL database, the second shelters
for example data in MySQL database. Raster related interface IRasterLayerInterface is
Geinformatics FCE CTU 2007
35
GAL Framework
Figure 4: Component architecture practically.
then implemented by two components too. First offers raster data from PostgreSQL and
second enwraps raster data in ordinary data files. This diagram should demonstrate that
using this approach module component can obtain GIS data and it don’t need to care where
and how are these data stored.
When module does what it wants with retrieved data it needs to output some informations
to console, logs or GUI, it sends messages through IMessageHandler interface. In discussed
example is this interface implemented by two components which forwards messages to CLI,
GUI or writes them to log files. This again demonstrates presentation of outputed data
independence.
Usage and Examples
Although bindings to most of commonly used dynamic languages are planned, at least for
Python and Java, all of following code examples are written in C++ because it will be main
language used during GAL Framework development. Get known that all of this example
usages reflect current state of design and may change in future.
The simplest interface usage example which doesn’t create component and can be used only
as a client module is listed here:
#include <iostream>
#include
#include
#include
#include
<core/GAL.h>
<core/ComponentManager.h>
<core/Interface.h>
<exceptions/Basic.h>
int main(int argc, char * argv[])
{
try
{
01:
GAL::initialize();
// Obtain slots of IExampleInterface functions.
Geinformatics FCE CTU 2007
36
GAL Framework
02:
03:
04:
05:
ComponentManager & component_manager = GAL::getComponentManager();
Interface & interface = component_manager.getInterface("IExampleInterface");
Function1Slot & function1 = dynamic_cast<Function1Slot &>(interface.getSlot("function1"));
Function2Slot & function2 = dynamic_cast<Function2Slot &>(interface.getSlot("function2"));
06:
07:
// Call functions’ implementation.
std::cout << "Function 1 returned: " << function1() << std::endl;
std::cout << "Function 1 returned: " << function2("Example", 10) << std::endl;
08:
GAL::finalize();
}
catch (Exception exception)
{
std::cout << exception.getMessage() << std::endl;
return EXIT_FAILURE;
}
return EXIT_SUCCESS;
}
Code is enclosed between initialization and deinitialization functions: GAL::initialize()
and GAL::finalize(). First we obtain reference to publicly available component manager
at line 02. Then we get interface object at line 03. At line 04 and 05, we get slot objects
which can be remembered during whole program run time for interface’s functions execution.
This can minimalize needed overhead. Lines 06 and 07 do this execution. In this example
we used only imaginary interface IExampleInterface but in real case it can be for example
interface which provides access to raster layer and we will compute some statistical values
over returned data. Note, that from this point of view it doesn’t matter if interface’s slots
are implemented in statically linked C++ code, loaded and executed from plug-in in shared
library or they are executed distributively in Python code or on distant machine via RPC
call. All of this is only up to slot implementations and its configuration.
The second example shows how can be certain interfaces implemented by components:
#include <iostream>
#include <string>
#include
#include
#include
#include
#include
<core/GAL.h>
<core/ComponentManager.h>
<core/Component.h>
<core/Interface.h>
<exceptions/Basic.h>
// ExampleComponent class definition.
01: class ExampleComponent: public Component
{
public:
02:
virtual void initialize();
03:
virtual void finalize();
04:
virtual void * getFunction(const char * name);
05:
static const char * function1();
06:
static const char * function2(const char * first, cont int second);
private:
Interface * interface;
07:
};
// Component initialization. Gets instance of interface and registers it
// in component manager.
08: void ExampleComponent::initialize()
{
09:
ComponentManager & component_manager = GAL::getComponentManager();
10:
this->interface = &(component_manager.getInterface("IExampleInterface"));
Geinformatics FCE CTU 2007
37
GAL Framework
11:
component_manager.registerImplementation(*(this->interface), *this);
}
// Component deinitialization. Unregisters interface.
12: void ExampleComponent::finalize()
{
13:
ComponentManager & component_manager = GAL::getComponentManager();
14:
component_manager.unregisterImplementation(*(this->interface), *this);
15:
this->interface = NULL;
}
// Implementation of first interface function.
16: const char * ExampleComponent::function1()
{
17:
std::cout << "IExampleInterface::function1" << std::endl;
18:
return "Example";
}
// Implementation of second interface function.
19: const char * ExampleComponent::function2(const char * first, const int second)
{
20:
std::cout << "IExampleInterface::function2" << std::endl;
21:
return "Example";
}
22:
23:
24:
25:
26:
27:
28:
29:
// Overriden virtual function which returns function pointer to requested
// implementation of interface function.
void * ExampleComponent::getFunction(const char * _name)
{
std::string name = std::string(_name);
if (name == "function1")
{
return (void *) &(this->function1);
}
else if (name == "function2")
{
return (void *) &(this->function1);
}
else
{
return NULL;
}
}
int main(int argc, char * argv[])
{
try
{
30:
GAL::initialize();
31:
32:
// Create component instance.
Component * component = new ExampleComponent();
component->initialize();
33:
GAL::daemonize();
34:
34:
// Destroy component instance.
component->finalize();
delete component;
36:
GAL::finalize();
}
catch (Exception exception)
{
std::cout << exception.getMessage() << std::endl;
return EXIT_FAILURE;
Geinformatics FCE CTU 2007
38
GAL Framework
}
return EXIT_SUCCESS;
}
There is defined ExampleComponent first at lines 01-07 in this example. Each component
needs to override three virtual methods: Component::initialize() at lines 08-11 for component initialization and registration of interface implementation, Component::finalize()
at lines 12-15 for component deinitialization and interface implementation unregistration and
Component::getFunction() at lines 22-29 for access to interface functions implementations.
Main program block (lines 30-36) then contains code which creates instance of component
and then turns program to daemon with GAL::daemonize() method. Interface implementation can be then called by external modules. In case where implemented interface is used
only internally as in this example, no daemonization is needed and program would just use
interface as in first example.
The third example is just code snippet showing how to define a new interface with its slots:
// Definition of CallbackSlot derived slot.
01: class Function1Slot: public CallbackSlot
{
public:
02:
Function1Slot();
03:
char * execute();
04:
char * operator()();
};
// Definition of DBusSlot derived slot.
05: class Function2Slot: public DBusSlot
{
public:
06:
Function2Slot();
07:
char * execute(char * first, int second);
08:
char * operator()(char * first, int second);
};
// Slot signature initialization.
09: Function1Slot::Function1Slot():
10:
CallbackSlot()
{
11:
this->addReturnValue(STRING);
}
// Slot signature initialization.
12: Function2Slot::Function2Slot():
13:
DBusSlot()
{
14:
this->addArgument(STRING);
15:
this->addArgument(INT32);
16:
this->addReturnValue(STRING);
}
// Arguments and return values packing and unpacking for D-Bus call.
17: char * Function2Slot::execute(char * first, int second)
{
18:
char * result = NULL;
19:
20:
21:
this->setArgument(0, (void *) first);
this->setArgument(1, (void *) second);
this->setReturnValue(0, (void *) &result);
Geinformatics FCE CTU 2007
39
GAL Framework
22:
this->callFunction();
23:
return result;
}
// Syntax sugar for use of slot as a functor.
24: char * Function1Slot::operator()()
{
25:
return this->execute();
}
// Syntax sugar for use of slot as a functor.
26: char * Function2Slot::operator()(char * first, int second)
{
27:
return this->execute(first, second);
}
// Definitions of example interface with two function slots.
28: class IExampleInterface: public Interface
{
public:
29:
IExampleInterface();
30:
~IExampleInterface();
private:
Slot * function1Slot;
Slot * function2Slot;
31:
32:
};
33:
34:
35:
36:
// Interface initialization. Instances of two slots are created and added
// to interface.
IExampleInterface::IExampleInterface():
Interface(),
function1Slot(NULL), function2Slot(NULL)
{
this->setId("IExampleInterface");
37:
38:
this->function1Slot = new Function1Slot();
this->function2Slot = new Function2Slot();
39:
40:
this->addSlot("function1", *(this->function1Slot));
this->addSlot("function1", *(this->function2Slot));
}
// Interface deinitialization. Instances of two slots are removed and
// destroyed.
41: IExampleInterface::~IExampleInterface()
{
42:
this->removeSlot("function1");
43:
this->removeSlot("function2");
44:
45:
delete this->function1Slot;
delete this->function2Slot;
}
First of all, two slots are defined at lines 01-04 and 05-08. One of them is derived from
CallbackSlot which is simple static implementation of slot mechanism and second is derived
from DBusSlot which implements slot mechanism via D-Bus calls. Slot constructors at lines
09-11 and 12-16 specify their signature by addition of input and output arguments. For
DBusSlot derived slots is needed to define way of argument packing and unpacking which does
Function2Slot::execute() method at lines 17-23. IExampleInterface is then defined at
lines 28-32 and slots are created or destroyed in its constructor at lines 33-40 and destructor
at lines 41-45. Finally, to be able to use this interface in whole system, its instance has to be
Geinformatics FCE CTU 2007
40
GAL Framework
registered in component manager using ComponentManager::registerInterface() method.
Current State
At the time of this article creation, GAL Framework is in early stage of design with work on
test implementation of designed ideas in progress. Test component management, client-side
and partially a server-side of D-Bus slot implementation is finished. Pieces of knowledge
gained from test implementation will be fed back to update the current design lately. When
all parts of component management and slot mechanisms will be designed and proved by
implementation, GAL Framework may proceed to design of appropriate GIS related interfaces
which will serve for further implementation of GRASS modules.
Currently GAL Framework uses SCons as a build tool, Subversion as a source management
system, Trac as a project management system, wiki and discussion forum, Umbrello for UML
modeling, SWIG for bindings generation and libffi and D-Bus as a libraries.
Anyone interested in this approach, who wants to contribute to GAL Framework at least with
comments or new ideas, may contact me at [email protected] or create account
at http://gal-framework.no-ip.org to get edit rights for wiki and discussion forum.
References
1. Christopher Lenz, Dave Abrahams and Christian Boos: Trac Component Architecture,
web-page7
2. Trac – http://trac.edgewall.org/
3. SCons – http://www.scons.org/
4. Subversion – http://subversion.tigris.org/
5. Umbrello – http://uml.sourceforge.net/index.php
6. SWIG – http://www.swig.org/
7. libffi – http://sourceware.org/libffi/
8. D-Bus – http://www.freedesktop.org/wiki/Software/dbus/
7
http://trac.edgewall.org/wiki/TracDev/ComponentArchitecture
Geinformatics FCE CTU 2007
41
Geinformatics FCE CTU 2007
42
GUI development for GRASS GIS
Martin Landa
Department of Geodesy and Cartography
Faculty of Civil Engineering, Czech Technical University in Prague
and
FBK-irst, Trento, Italy
landa.martin gmail.com
Keywords: GIS, GRASS, GUI, wxPython, development
Abstract
This article discusses GUI development for GRASS GIS. Sophisticated native GUI for GRASS
is one of the key points (besides the new 2D/3D raster library, vector architecture improvements, etc.) for the future development of GRASS. In 2006 the GRASS development team
decided to start working on the new generation of GUI instead of improving the current GUI
based on Tcl/Tk.
Motivation and background
GRASS GIS has been under continuous development since 1982 especially by the U.S. Army
Construction Engineering Research Laboratories (USA-CERL) a branch of the US Army Corp
of Engineers, as a tool for land management and environmental planning by the military. In
1995 USA-CERL decided to leave GRASS project, the first GPL’ed GRASS GIS has been
released in 1999 as GRASS 5. In the result GRASS GIS is actively developed for more than 25
years. GRASS as a piece of software with long tradition is closely linked to Unix environment.
Almost all GRASS modules are originally CLI-oriented (Command Line Interface). This can
be advantage for developers or power users. The real capabilities of GRASS are basically
connected to the power of CLI. The GRASS users request intuitive, simple graphical user
interface. In GRASS world, GUI is an alternative way how to use the system, the main
advantage for the users is powerful CLI. Anyway GUI is very important point for the most
of GRASS users, requested especially by newcomers. Beside of that, there are tools like
Georectifier, Digitization tool, etc. which are basically mouse-driven. These tools should be
fully integrated into GUI structure.
Geinformatics FCE CTU 2007
43
GUI development for GRASS GIS
The GRASS GUI History
The first native GUI for GRASS was originally developed by Jacques Bouchard in 1999 (based
on Tcl/Tk) and became part of GRASS 5, so called TCLTKGRASS (fig. 1).
Fig. 1: TCLTKGRASS available in GRASS 5.0
Later has been developed still Tcl/Tk-based replacement of TCLTKGRASS called d.m (”Display Manager”) by Michael Barton, Radim Blazek and others (fig. 2). This component allowed the users to run GRASS modules from menu and graphically manage the (old) GRASS
monitors (based on X11 driver).
Fig. 2: Display Manager (d.m) in GRASS 6.0
In 2006 Michael Barton decided to develop gis.m (”GIS Manager”) as a replacement of old
d.m. In the result, gis.m has been released for GRASS 6.2 (fig. 3). Display architecture, module menu, graphical module dialogs (which are generated on-the-fly by the GRASS parser)
have been completely rewritten, new output window and layer management introduced. Moreover new external tools have been integrated, e.g. georeferencing tool (replacement of X11
driver based on i.points module). Also new map display window with integrated basic tools
like zooming, panning, data querying has been implemented (as a replacement of X11 driverbased GRASS monitors).
Similarly the digitization tool (module v.digit) has been originally CLI-based. GRASS 6
Geinformatics FCE CTU 2007
44
GUI development for GRASS GIS
Fig. 3: GIS Manager (gis.m) in GRASS 6.3
brought GUI-based completely rewritten v.digit (fig. 4).
Fig 4.: Digitization tool v.digit from CLI-driven to GUI-driven user interface
The last major part represents NVIZ, a tool for 3D visualization also written in Tcl/Tk
Geinformatics FCE CTU 2007
45
GUI development for GRASS GIS
(fig. 5).
Fig 5.: NVIZ as a tool for 3D visualization
Discussion about future development
The native GUI for GRASS was originally developed using Tcl programming language and Tk
graphical toolkit (including first version called TCLTKGRASS or the latest GIS Manager,
NVIZ or user interface for v.digit module). Besides the native GUI also a few alternative
GUIs for GRASS are available, mainly JGRASS written in Java or QTGRASS (QT library).
During the time, the limitations of Tcl/Tk toolkit appeared to be fundamental for the future
development. This issue has been several times discussed in the GRASS developer mailing
list. At the end has been decided to leave Tcl/Tk and to design new native GRASS GUI
from the scratch using another graphical toolkit.
There was question which graphical toolkit to choose. The major players are QT, GTK and
wxWidgets. The main requirements:
ˆ portability,
ˆ native look and feel,
ˆ OpenGL widget available,
ˆ powerful Python binding,
ˆ performance and flexibility.
At the end wxWidgets toolkit has been chosen, the major reasons:
ˆ Python binding (know as wxPython).
Geinformatics FCE CTU 2007
46
GUI development for GRASS GIS
ˆ Uses native platform SDK (native look and feel), it means that a program compiled on
Windows will have the look and feel of a Windows program, and when compiled on a
Linux machine, it will get the look and feel of a Linux program.
ˆ Free OpenGL widget (in contrast to QT) which is requested for the future development
(NVIZ replacement).
For real development has been chosen Python binding of wxWidgets which is known as wxPython. The main reason is more or less simple, Python as ”easy-to-learn”, object oriented,
currently ”very popular” language should enable more people actively contribute on the development in contrast to wxWidgets which works for C++ (or Tcl/Tk used for the old GUI).
Moreover wxPython is currently actively developed and maintained. The decision is strategic
for the future development.
Development of wxPython-based GUI
Development of GUI using wxPython started in the end of 2006.
Basic information
The newly developed GUI follows more or less design of the latest Tcl/Tk-based GUI which is
available in GRASS 6. The GUI is composed by Layer Manager (fig. 6) which enables the user
to run different GRASS modules (generated on-the-fly based on XML output of the GRASS
parser) from menu, layer management for map display windows, integrated command-line,
etc.
Fig. 6: wxPython-based Layer Manager
Geinformatics FCE CTU 2007
47
GUI development for GRASS GIS
The second main component is Map display window which integrates basic tools for zooming,
panning, data querying, decorations (north arrows, barscale, etc.). This component replaces
the old X11-based GRASS monitors. The user is allowed to start various map display windows during one session. Layer Manager registers the all started map display windows using
different tabs.
Fig. 7: Layer Manager and several Map display windows in one session
Each map display window has different toolbars, by default only ”Main” toolbar is enabled.
Currently is available special toolbar for Digitization tool, under active development is also
Georectifier tool.
The future development
One of the key components of GUI – Digitization tool – is currently under active development.
This tool is fully integrated into GUI structure and should replace current Tcl/Tk-based
v.digit module. Almost all features available in v.digit has been implemented in the new
Digitization tool. Some additional features are planned to be implemented, e.g. marking
isolines (available in old CLI-oriented v.digit in GRASS 5.0, never re-implemented in v.digit),
snapping to vertex, background vector map layer objects, etc. This requires also modification
of vector library especially to enable partial (based on the bounding box) building of topology
for modified vector map layer.
Another important component – Georectifier tool – is currently being developed by Michael
Barton. Many other components or sub-components have to implemented or improved including interactive command-line, module search engine (to find given GRASS module according
Geinformatics FCE CTU 2007
48
GUI development for GRASS GIS
Fig. 8: Map display window with integrated different toolbars
Fig. 9: Digitization tool in action / Uno
key words for a given user’s task), message handling, etc.
Very complex and integral part is NVIZ re-implementation in wxPython. Functionality of
NVIZ (3D visualization tool written in Tcl/Tk) is planned to integrated into the current
components of wxPython GRASS GUI. Map display window currently enables only 2D visuGeinformatics FCE CTU 2007
49
GUI development for GRASS GIS
Fig. 10: Digitization tool in action / Due
Fig. 11: Digitization tool in action / Tre
alization, in the future it will be extended towards 3D visualization skills. This fundamental
feature will be implemented using OpenGL widget which is available in wxPython.
Geinformatics FCE CTU 2007
50
GUI development for GRASS GIS
Conclusion
The decision to replace currently used Tcl/Tk with wxPython is crucial for the future GRASS
GUI development. The experience with wxPython is mostly positive. wxPython is one of the
most active and maintained bindings for wxWidgets toolkit. Moreover it supports more or less
all features which are needed for the current development (including fundamental OpenGL
widget) of GUI for GRASS.
WxPython-based GUI for GRASS is actively developed by several people, it seems that
Python as a ”easy-to-learn” programming language enables more people to actively contribute
on the development process.
The GRASS development team is currently preparing new development branch for GRASS 7,
wxPython-based GUI will be part of GRASS 7 as the default graphical user interface. Current
speed of development is promising for the future.
Sophisticated GUI is crucial for GRASS user politics especially connected to the newcomers
or non-power users who essentially request GUI. The GUI need to reflect the specific needs
of GRASS users, need to be intuitive, simple and in the certain point ”minimal”.
References
1. Markus Neteler and Helena Mitasova: Open Source GIS: A GRASS GIS Approach.Third
Edition., Springer, New York, ISBN 978-0-387-35767-6, http://www.grassbook.org
2. Noel Rappin and Robin Dunn: wxPython in Action, Manning Publications, ISBN 9781932394627
3. Julian Smart, Kevin Hock and Stefan Csomor: Cross-Platform GUI Programming with
wxWidgets, Prentice Hall PTR, ISBN 978-0131473812
4. GRASS GIS – http://grass.itc.it
5. wxPython – http://wxpython.org
6. wxWidgets – http://www.wxwidgets.org
7. PyOpenGL project – http://PyOpenGL.sourceforge.net
Geinformatics FCE CTU 2007
51
Geinformatics FCE CTU 2007
52
Freeware for GIS and Remote Sensing
Lena Halounová
Department of Mapping and Cartography, Faculty of Civil Engineering
Czech Technical University in Prague
halounova fsv.cvut.cz
Keywords: GIS, Freeware
Abstract
Education in remote sensing and GIS is based on software utilization. The software needs to
be installed in computer rooms with a certain number of licenses. The commercial software
equipment is therefore financially demanding and not only for universities, but especially for
students. Internet research brings a long list of free software of various capabilities. The paper
shows a present state of GIS, image processing and remote sensing free software.
Introduction
GIS and remote sensing tasks are mutually interlinked and division of software to GIS software
and remote sensing software means that GIS software is able to work with remote sensing
data and to perform simple tasks with them. On the contrary, GIS functions are embedded
in remote sensing software. This duality is a result of close relation between these regions.
Looking for the GIS free software, three groups of them can be found
ˆ Viewers of commercial software – ArcReader 91 , ArcExplorer 4.02 of ESRI, GeoMedia®
Viewer of INTERGRAPH, FreeLook 3.13 for ENVI, etc.
ˆ Software tools for certain tasks as GDAL 1.1.5 [11], libgeotiff, MB-System4 for bathymetry and backscatter imagery data derived from multibeam, interferometry, and sidescan sonars, MITAB5 MITAB a C++ library for reading and writing MapInfo .TAB
(binary) and .MIF/MID files.
ˆ Complete GIS software – GRASS, ILWIS, FMaps covering GIS together with remote
sensing.
1
http://www.arcdata.cz/download/ArcReader/ArcReaderWebSetup.exe
http://www.arcdata.cz/download/ArcExplorer/AE4JavaSetup.exe
3
http://www.envi-sw.com/
4
http://www.ldeo.columbia.edu/MB-System/
5
http://mitab.maptools.org/
2
Geinformatics FCE CTU 2007
53
Freeware for GIS and Remote Sensing
ˆ Software for image processing – Intel, Image Analyzer 1.27
The Open Source GIS [7] brings a list of more than 150 free GIS software available for users.
The web page remotesensing.org [15] is a source of many free software for remote sensing
including the link to Remote Sensing Tutorial prepared by William J. Campbell from NASA
[10].
Viewers of commercial software
Following examples shows limits of viewers for common users.
GeoMedia extregistered Viewer [13]. Key Features of the software are data access providing read-only access to geospatial data in Microsoft Access, MapInfo and Shapefile formats.
With GeoMedia Viewer new connections to the above formats can be also created if you have
other data sets you want to access. GeoMedia Viewer let us create new geoworkspaces and
save any changes made to existing geoworkspaces. GeoMedia Viewer includes a powerful set
of navigation commands for moving around and exploring your data as Pan, Zooming, etc.
and supports multiple windows including map and data windows.
ArcExplorer [9]. As a complete data explorer, ArcExplorer – Java lets display and query
a wide variety of standard data sources. Using ArcExplorer as a stand-alone desktop application, it is possible to consume shapefiles, a variety of images, ArcSDE layers, and more,
allows to also pan and zoom through these map layers and identify, locate, and query their
spatial and attribute information. You can buffer a selected set of features and view their
attributes. ArcExplorer also provides the ability to thematically map your data, symbolizing various features based upon information found in the data’s attribute table, displaying
graduated symbology, or classbreaks rendering for instance.
Software tools for certain tasks
There are many software packages for large number of different tasks and questions for GIS
purposes [6]. Project conversion software form an important group of them.
GDAL 1.1.5 [11] is a translator library for raster geospatial data formats. As a library, it
presents a single abstract data model to the calling application for all supported formats. A
initial skeleton of GDAL has formed, and operates for a few formats [11].
Geotiff libs [16] – GeoTIFF represents an effort by over 160 different remote sensing, GIS,
cartographic, and surveying related companies and organizations to establish a TIFF6 based
interchange format for georeferenced raster imagery [16].
PROJ 4.4.3 [8] – This package offers command line tools and a library for performing respective forward and inverse transformation of cartographic data to or from cartesian data with
a wide range of selectable projection functions. O.S. GNU/Linux and other Unices Windows
[8].
6
http://www.awaresystems.be/imaging/tiff/faq.html
Geinformatics FCE CTU 2007
54
Freeware for GIS and Remote Sensing
Virtual Terrain Project [17] – The goal of VTP is to foster the creation of tools for easily
constructing any part of the real world in interactive, 3D digital form. This goal will require
a synergetic convergence of the fields of CAD, GIS, visual simulation, surveying and remote
sensing. VTP gathers information and tracks progress in areas such as procedural scene
construction, feature extraction, and rendering algorithms. VTP writes and supports a set of
software tools, including an interactive runtime environment (VTP Enviro). The tools and
their source code are freely shared7 to help accelerate the adoption and development of the
necessary technologies [15].
Complete GIS/remote sensing software
There are four useful GIS and remote sensing free software packages – GRASS, ILWIS, OSSIM
and FMaps.
GRASS – Geographic Resources Analysis Support System commonly referred to as GRASS,
this is a Geographic Information System (GIS) used for geospatial data management and
analysis, image processing, graphics/maps production, spatial modeling, and visualization.
GRASS is currently used in academic and commercial settings around the world, as well
as by many governmental agencies and environmental consulting companies. GRASS is a
raster GIS. There are a large range of applications of GRASS: geography, landscape ecology,
epidemiology, remote sensing8 , urban planning, biology, geophysics, hydrology, groundwater
Flow Modeling (GRASS and MODFLOW9 ), vector network analysis (in part of GRASS 610 ),
geostatistics11 , raster 3D Volume12 (voxel) [5].
ILWIS [1] version 3.4. is a software created for Windows platform and the following list
shows the product tools:
ˆ Integrated raster and vector design
ˆ Import and export of widely used data formats
ˆ On-screen and tablet digitizing
ˆ Comprehensive set of image processing tools
ˆ Orthophoto, image georeferencing, transformation and mosaicing
ˆ Advanced modeling and spatial data analysis
ˆ 3D visualization with interactive editing for optimal view findings
ˆ Rich projection and coordinate system library
ˆ Geo-statistical analyses, with Kriging for improved interpolation
ˆ Production and visualization of stereo image pairs
7
http://www.vterrain.org/Site/privacy.html#License
http://mpa.itc.it/rs/
9
http://www.valledemexico.ambitiouslemon.com/gwmodelling.html
10
http://grass.itc.it/grass61/screenshots/network.php
11
http://grass.itc.it/statsgrass/index.php
12
http://grass.itc.it/grid3d/
8
Geinformatics FCE CTU 2007
55
Freeware for GIS and Remote Sensing
ˆ Spatial Multiple Criteria Evaluation
52°North Initiative for Geospatial Open Source Software GmbH is an international research
and development company whose mission is to promote the conception, development and
application of free open source geo-software for research, education, training and practical
use. 52°North backs an open initiative, which is driven by leading research organizations and
individuals in the international GIS field. The work of all partners results in a collection of
Java based web services implementations [1].
FMaps [5] is an open source GIS/RS (Geographic Information System/ Remote Sensing)
application on the Linux13 and Gnome14 compatible platforms. The database engine is PostgreSQL15 . PostgreSQL is an opensource SQL server.
OSSIM (Open Source Software Image Map) [14] is a high performance software system for
remote sensing, image processing, geographical information systems and photogrammetry. It
is an open source software project maintained at http://www.ossim.org and has been under
active development since 1996. The lead developers for the project have years of experience
in commercial and government remote sensing systems and applications. OSSIM has been
funded by several US government agencies in the intelligence and defense community and
the technology is currently deployed in research and operational sites. The name OSSIM is
a contrived acronym (Open Source Software Image Map) that is pronounced “awesome” –
the acronym was established by our first government customer. Designed as a series of high
performance software libraries it is written in C++ employing the latest techniques in object
oriented software design. A number of command line utilities, GUI tools and applications,
and integrated systems have been implemented with the baseline. Many of those tools and
applications are included with the software releases.
MultiSpec is a freeware multispectral image data analysis system (latest release: 5-12-2007)
MultiSpec is being developed at Purdue University16 , West Lafayette17 , IN18 , by David Landgrebe19 and Larry Biehl20 from the School of Electrical and Computer Engineering21 , ITaP22
and LARS23 . It results from an on-going multiyear research effort which is intended to define
robust and fundamentally based technology for analyzing multispectral and hyperspectral
image data, and to transfer this technology to the user community in as rapid a manner as
possible. The results of the research are implemented into MultiSpec and made available
to the user community via the download pages. MultiSpec© with its documentation© is
distributed without charge.
13
http://www.linux.org/
http://www.gnome.org/
15
http://www.postgresql.org/
16
http://www.purdue.edu/
17
http://www.wintek.com/wlaf/
18
http://www.state.in.us/
19
http://dynamo.ecn.purdue.edu/~landgreb/
20
http://dynamo.ecn.purdue.edu/~biehl/
21
http://www.purdue.edu/ECE
22
http://www.itap.purdue.edu/
23
http://www.lars.purdue.edu/
14
Geinformatics FCE CTU 2007
56
Freeware for GIS and Remote Sensing
Radar interferometry
Interferometry is a separate part of remote sensing working with radar image pairs for determination of DEM on one side, and small surface movements – subsidences, e.g., on the
other side. It is a separate software and branch as well because its processing method differs
significantly from other remote sensing image data evaluation. There is one freeware called
DORIS [11].
DORIS (Delft object-oriented radar interferometric software) The Delft Institute of Earth
Observation and Space Systems24 of Delft University of Technology25 developed processor
for interferometric SAR. It is a freeware for non-commercial usage. The software works with
European ERS and ENVISAT data, Japanese JERS, and Canadian RADARSAT.
Image processing software
Intel offers Open Source Computer Vision Library with following
Library areas [12]:
ˆ Image functions: Creation, allocation, destruction of images. Fast pixel access macros.
ˆ Data Structures: Static types and dynamic storage
ˆ Contour Processing: Finding, displaying, manipulation, and simplification of image
contours
ˆ Geometry: Line and ellipse fitting. Convex hull. Contour analysis
ˆ Features: 1st & 2nd Image Derivatives. Lines: Canny, Hough. Corners: Finding,
tracking.
ˆ Image Statistics: In region of interest: Count, Mean, STD, Min, Max, Norm, Moments,
Hu Moments
ˆ Image Pyramids: Power of 2. Color/texture segmentation
ˆ Morphology: Erode, dilate, open, close. Gradient, top-hat, black-hat
ˆ and many others
Intel extregistered Image Processing Library (included in OpenCV WinOS download)
comprises [12]:
ˆ Image creation and access
ˆ Image arithmetic and logic operations
ˆ Image filtering
ˆ Linear image transformation
ˆ Image morphology
24
25
http://www.deos.tudelft.nl/
http://www.tudelft.nl/live/pagina.jsp?id=b226846d-f19f-4c34-97ed-165fecc5ad8f&lang=nl
Geinformatics FCE CTU 2007
57
Freeware for GIS and Remote Sensing
ˆ Color space conversion
ˆ Image histogram and thresholding
ˆ Geometric transformation (zoom-decimate, rotate, mirror, shear, warp, perspective
transform, affine transform
The Intel software covers wide range of image processing methods applicable in remote sensing
and other branches. The largest user group can be found among digital photographs users.
Image Analyzer 1.27. [6] is a freeware for Windows 98/ME/2000/XP/Vista. Advanced
image editing, enhancement and analysis software. The program contains both most image
enhancement features found in conventional image editors plus a number of advanced features
not even available in professional photo suites as:
ˆ Automatic brightness, contrast, gamma and saturation adjustment
ˆ Build-in conventional and adaptive filters for noise reduction, edge extraction etc.
ˆ Retouch tools
ˆ Deconvolution for out-of-focus and motion blur compensation (see below)
ˆ Easy red-eye removal
ˆ User specified filters in spatial and frequency domain
ˆ Resize, rotate, crop and warping of images
ˆ Scanner, camera and printer support
ˆ File format support: Read/write BMP, ICO, CUR, WMF, EMF, PNG, MNG, GIF,
PCX, JPEG and JPEG 2000 images
ˆ Morphological operations
ˆ Color model conversion: RGB, CMY, HSI, Lab, YCbCr, YIQ and PCA
ˆ Distance, Fourier and discrete cosine transformation
ˆ Math expression module for creating and transforming images and advanced ”pocket”
calculator with equation solver
ˆ Plugin system for adding more specialized features. See below for available plugins
Conclusion
There are more viewers belonging to the software group. Viewers are tools for ready data
and users with low level of demands and are prepared for large society of users and created
by commercial GIS/remote sensing companies. They are in fact useless for most processing
of advanced users and students. The software packages focused on certain tasks are useful for
solution of individual problems which cannot be processed in other software on one side or
for solution of stand alone tasks. Their application for education of GIS or remote sensing as
a whole is not suitable. The university education of GIS and remote sensing can be based on
complete software like GRASS and others. The open software allows to use existing modules
Geinformatics FCE CTU 2007
58
Freeware for GIS and Remote Sensing
on one side, and are a place for development of new tools on the other side. Therefore,
whenever the education is focused on advanced experienced students, these software packages
are the best solution for education.
References
All web pages cited on 18 September 2007
1. http://52north.org/index.php?option=com projects&task=showProject&id=30
2. http://cobweb.ecn.purdue.edu/˜biehl/MultiSpec/
3. http://enterprise.lr.tudelft.nl/doris/
4. http://fmaps.sourceforge.net/
5. http://grass.itc.it/
6. http://meesoft.logicnet.dk/Analyzer/
7. http://opensourcegis.org/
8. http://proj.maptools.org/
9. http://www.esri.com/software/arcexplorer/about/overview.html
10. http://www.fas.org/irp/imint/docs/rst/Front/tofc.html
11. http://www.gdal.org/index.html
12. http://www.intel.com/technology/computing/opencv/overview.htm
13. http://www.intergraph.com/gviewer/Key Features.asp
14. http://www.ossim.org/OSSIM/OSSIMHome.html
15. http://www.remotesensing.org/Home.html
16. http://www.remotesensing.org/geotiff/geotiff.html
17. http://www.vterrain.org/
The paper was prepared in the framework of the project of the Czech Grant Agency GA ČR
205/06/1037 Application of Geoinformation Technologies for Improvement of Rainfall-Runoff
Relationships
Geinformatics FCE CTU 2007
59
Geinformatics FCE CTU 2007
60
PyWPS 2.0.0: The presence and the future
Jachym Cepicky
Help Service – Remote Sensing s.r.o
Černoleská 1600
256 01 Benešov u Prahy
jachym at bnhelp dot cz
Keywords: OGC, Web Processing Service, WPS, PyWPS, GIS, GRASS, FOSS4G
Abstract
This paper presents current status of PyWPS1 program, which implements OGC Web Processing Service standard. PyWPS 0.2.0, which was released only recently, implements OGC
WPS 0.4.0. Nowadays, OGC is preparing the WPS 1.0.0 standard, with slightly different
characteristics. Next versions of PyWPS should implement this version too.
OGC Web Processing Service
The Open Geospatial Consortium, Inc.® (OGC) is a non-profit, international, voluntary
consensus standards organization that is leading the development of standards for geospatial
and location based services. OGC specifications are technical documents that detail interfaces
or encodings. Software developers use these documents to build support for the interfaces
or encodings into their products and services. One of this document OGC Web Processing
Service (WPS). It is relatively new standard (compared to other, more used standards, like
OGC Web Mapping Service (WMS) or Web Feature Service). The document number 05007r4 describes version 0.4.0 of the WPS standard. Request for comments to this standard
was published February 2006. In June 2007, version 1.0.0 of this standard was released.
The standard describes the way, how geospatial operations (referred as “processes”) are distributed across networks. WPS server can be configured to offer any sort of GIS functionality
to clients across network. Process can be simple calculation, like adding to raster maps together or making buffer around vector feature, as well as complicated models, as for example
climate change model.
The main goal of WPS is, that computational high-demanded operations are moved from
client stations (general desktop PC) to server.
1
http://pywps.wald.intevation.org
Geinformatics FCE CTU 2007
61
PyWPS 2.0.0: The presence and the future
WPS request types
Three types of request-response pairs are defined. Request can be in Key-Value-Pairs (KVP)
encoding, as well as XML document. Server response is always formatted as XML document.
ˆ GetCapabilities – Server returns Capabilities document. First part of the document
includes metadata about server provider and other server features. Second part of the
document includes list of on server available processes.
ˆ DescribeProcess – Server returns ProcessDescription document. Apart from process
identifier, title and abstract, process in- and outputs are defined.
ˆ Execute – Client overhands necessary inputs for partial process, the server provides
geospatial calculations and returns document with all process outputs.
Data Types
Three basic types of in- and output data are defined:
ˆ LiteralData – Character strings as well as integer or double numbers.
ˆ BoundingBoxData – Two pairs of coordinates
ˆ ComplexValue and ComplexValueReference – Input and output vector and/or raster
data. Vector data (e.g. GML files) can be directly part of request/response execute
document (than they the input is of type ComplexValue). Client can specify only URL
to input data (e.g. address to Web Coveradge Server (WCS)). In this case, the data are
of type ComplexValueReference.
PyWPS
The PyWPS program implements OGC Web Processing Service (WPS) standard in it’s 0.4.0
version. It can be understand as proxy, between common GIS command-line-oriented programs, like GRASS GIS, GDAL/OGR tools as well as R statistic package and Internet.
PyWPS is Free Software, published under GNU/GPL.
Currently, PyWPS has three developers, and about 40 people registered in mailing list. From
beginning, it has been developed with direct support for GRASS GIS.
PyWPS Homepage can be found at http://pywps.wald.intevation.org.
PyWPS usage examples
Several examples are provided, which are demonstrating usage of OGC WPS. All examples
are web browser oriented.
WPS Demos Two demo applications are provided, with same functionality. Help Service –
Remote Sensing demo running at
http://www.bnhelp.cz/mapserv/wpsdemo/
Geinformatics FCE CTU 2007
62
PyWPS 2.0.0: The presence and the future
http://www.bnhelp.cz/mapserv/pokusy/openlayers/wpsdemo
Prefarm As part of the Premathmod project, which is an statistical and mathematical
modeling, data analysis simulation and optimization methodologies for precision farming,
PyWPS was used. On the server, GRASS GIS is used, to calculate optimal fertilization over
fields.
Embrio interface Lorenzo Becchi made WPS interface for his map viewer ka-Map. It works
together with PyWPS and till now, only basic functions are implemented, like shortest path
calculation, vector buffers and lines of sight.
OpenLayers WPS plugin WPS can be also used together with OpenLayers map viewer.
New OpenLayers.Control class was written, which serves like WPS client. It communicates
with the server directly and can be used for any kind process.
What’s new in WPS 1.0.0
In July 2007, new version of WPS standard was launched. This version implements some
missing functionality of previous version of the standard, mainly:
ˆ SOAP/WSDL API
ˆ New and more rich KVP request encoding definition
ˆ Better input specification, including e.g. maximal file size
ˆ Basic support for WPS server internationalization
Future of PyWPS
Current version of PyWPS supports only the 0.4.0 version of named standard. In the summer
2008, PyWPS development team would like to release new version, which would implement
current version of the standard.
Another field of development are the clients, suitable for WPS. Currently, apart from proprietary client-server solutions, there are WPS plugins for uDig and Open Jump programs, both
provided by 52north, and OpenLayers WPS plugin. Other GIS (viewers) are now lacking for
suitable WPS plugin, so they could enjoy advantages of remote geoprocessing.
Conclusion
PyWPS (Python Web Processing Service) implements OGC Web Processing Service standard
in it’s 0.4.0 version. Several applications, which are using PyWPS are available on Internet
as well as intranet applications.
In the future, new version of WPS standard should be implemented, as well as new WPS
client plugins should be developed.
Geinformatics FCE CTU 2007
63
PyWPS 2.0.0: The presence and the future
References
1. OGC Web Processing Service 0.4.0, Editors: Peter Schut, Arliss Whiteside, Ref. number: OGC 05-007r4, Open Geospatial Consortium Inc. 2005
2. PyWPS2 – Implementation of OGC WPS specification
3. OpenLayers3 – JavaScript library for dynamic maps provided by MetaCarta
4. ka-Map!4 – JavaScript API for developing interactive web-mapping applications
2
http://pywps.wald.intevation.org
http://openlayers.org
4
http://ka-map.maptools.org/
3
Geinformatics FCE CTU 2007
64
NOP
Jan Pytel
Department of Geodesy and Cartography
Faculty of Civil Engineering, Czech Technical University in Prague
jan.pytel fsv.cvut.cz
Key words: No Operation
Reviewed by Aleš Čepek.
Geinformatics FCE CTU 2007
65
Geinformatics FCE CTU 2007
66
The International Exchange of Students:
Problems and Solutions at the Riga
Technical University
Janis Strauhmanis
Riga Technical University, Latvia
strauhmanis bf.rtu.lv
Keywords: exchange of students, foreign languages, coursebooks
Summary
The international exchange of students plays an important role in acquisition of new knowledge
and skills. However, it was possible to start implementing such exchange programmes at the
Riga Technical University only in 1991 after the reestablishment of the Department of Geodesy.
Currently, the Riga Technical University cooperates with several countries in implementing
exchange programmes of students. The main problems encountered in this process are similar:
inadequate foreign language skills, a lack of internationally recognized coursebooks and other
study materials, insufficient cooperation between the universities that implement exchange
programmes. These problems should be addressed by creating a working group and expanding
cooperation, as well as enhancing requirements for students who participate in the exchange
programmes.
The present situation
The first foreign students who came to study geodesy at the Riga Technical University (RTU)
in 1994 were from Lebanon, however, their basic field of study was civil engineering. A year
later the students of RTU went to Finland and Sweden to study at the Technical University
of Helsinki and the Higher Technical School of Stockholm. From 1998 to 2004, several citizens
of Lebanon mastered the study programme in geodesy and cartography at the Riga Technical
University and defended their engineering projects.
The students of RTU went to study (mostly for one semester) to the following countries:
ˆ Denmark: University of Aalborg, Technical University of Denmark,
ˆ Finland: Mikkeli Politechnic,
ˆ Germany: High Technical School of Karlsruhe, High Technical School of Stuttgart,
Geinformatics FCE CTU 2007
67
The International Exchange of Students: Problems and Solutions at the
Riga Technical University
ˆ Spain: University of Valencia.
The following figures characterize the exchange programme of students in geodesy and cartography:
ˆ in 1995/96 and 1996/97 four students from RTU studied abroad;
ˆ in 1998/99 and 1999/2000 four students from Lebanon studied at RTU and five students
of the Department of Geomatics studied abroad;
ˆ in 2000/01 and 2001/02 the Lebanese students continued their studies at RTU and three
students of the Department of Geomatics studied abroad;
ˆ in 2003/04 the Lebanese students completed their studies at RTU and three students
of the our Department went to study in Germany and Finland.
During the following year a comparatively small number of students from the Department of
Geomatics, RTU studied abroad. In 2006/07 four our students went to Finland to study at
the Mikkeli Politechnic (Finland), one student went to Germany – High Technical School of
Stuttgart and one to University of Valencia (Spain). 4 students from Spain (University of
Valencia), two from Germany and France studied at the Department of Geomatics, RTU.
It should be noted that the number of foreign students studying in Latvia and also at the Riga
Technical University has recently increased: in the academic year 2006/2007 1425 students
from 57 countries studied at Latvian higher educational establishments, but at RTU – 76
students from 30 countries. 829 students from 25 Latvian higher educational establishments
are now studying abroad; 67 students of the Riga Technical University are now studying in
20 foreign countries.
Problems and solutions
Having been involved in the international exchange of students for more than ten years, we
can identify the main problems; some of them, in our opinion, are the following:
ˆ inadequate English language skills;
ˆ a lack of internationally recognized coursebooks and other studies materials in geodesy,
surveying and cartography;
ˆ some higher educational establishments that offer exchange programmes do not provide
instruction in English for foreign students.
In our opinion, the above-mentioned problems could be solved in the following way:
ˆ the students who want to go to study in another country should pass a foreign language
test that proves their ability to master courses in their speciality in the required foreign
language;
ˆ before implementing an exchange of students, the relevant universities should exchange
information about the previously acquired knowledge and the required subjects, as it
Geinformatics FCE CTU 2007
68
The International Exchange of Students: Problems and Solutions at the
Riga Technical University
was already pointed out in the plan drawn up by the FIG 2nd commission and, in our
opinion, it should be dealt with immediately;
ˆ it is necessary to hold a seminar at international level to discuss the issues of implementing student exchange programmes. Proposals about a new coursebook in cartography
were made at FIG Congress.
It should be noted that we closely cooperate with our Finnish colleagues in exchanging information, which makes it possible for us to improve the training of foreign students. The
International Institute for Geo-Information Science and Earth Observation (ITC) has great
experience in training foreign students and they consider that one of the main problems
in working with groups of foreign students is their different level of basic knowledge. This
problem is encountered quite often.
The Department of Geomatics of Riga Technical University is ready to participate in finding
solutions to the above-mentioned problems.
References
1. Balodis J., Strauhmanis J., Tarasenko M. System of cartographic and GIS study subjects at the Department of Geomatics, Riga Technical University. Proceedings: 1st
International conference on Cartography & GIS. Borovetz, 2006.
2. Bruijn de S.. Knowledge Economy for Whom? Task for Europe in Internationalisation
of Education. GEO Informatics, July/August, 2006., p.32 – 35.
3. FIG Commission 2. Draft Work Plan 2007 – 2010. Munich, 2006.
4. Dasse G. Enhancing the Representation of Under-Represented Groups in FIG. FIG
publication No.35, Copenhagen 2006.
5. Magel H. 2005, New Challenges to Education in Geodesy and Geoinformation. GEOinformatics, April/May 2005., p. 12 – 13.
6. Quality Assurance in Surveying Education. (1999) FIG Publication No.19.
7. Strauhmanis J. Geomatics Education in Latvia. GIM International, March 2007.,
8. Strauhmanis J. Activities of the state and private cartography in Latvia. East and
Central Europe experience in cartography of new economy and political systems.Legal
and organizational problems. Abstracts. Wroclaw-Polanica Zdroj, 2006. p. 56-57.
9. Quality Assurance in Surveying Education. (1999) FIG Publication No.19.
Geinformatics FCE CTU 2007
69
Geinformatics FCE CTU 2007
70
PostGIS pro vývojáře
Pavel Stěhule
Department of Mapping and Cartography, Faculty of Civil Engineering
Czech Technical University in Prague
stehule kix.fsv.cvut.cz
Klı́čová slova: Database systems, GIS, development
Abstrakt
Systémy GIS prvnı́ generace ukládaly svá data do souborů v proprietárnı́ch formátech. Dalšı́
generace těchto systémů dokázaly spolupracovat s databázemi (zejména čerpat data s databázı́).
Soudobé GIS systémy se již zcela spoléhajı́ na databáze. Tyto požadavky GIS systémů musely
reflektovat databázové systémy. Nejstaršı́ SQL systémy vůbec s prostorovými daty nepočı́taly.
Úvod
Až standard ANSI SQL2000 v části věnované podpoře multimediálnı́ch dat obsahuje popis
prostorových (spatial) dat. Z komerčnı́ch databázı́ je na prvnı́m mı́stě, co se týče podpory
prostorových dat, databázový systém fy. Oracle. Počı́naje verzı́ Oracle 7 existuje rozšı́řenı́
Oracle, samostatně distribuované, řešı́cı́ podporu prostorových dat. Toto rozšı́řenı́ se nazývá
Oracle spatial. Odpovědı́ o.s. světa byla implementace podpory prostorových dat pro RDBMS
PostgreSQL a to tak, jak předpokládá standard OpenGIS.
Jednou z charakteristik PostgreSQL je právě jeho rozšiřitelnost. V PostgreSQL lze relativně
jednoduše navrhnout vlastnı́ datové typy, vlastnı́ operace a operandy nad těmito typy. Touto
vlastnostı́ byl systém PostgreSQL mezi o.s. databázovými systémy výjimečný. Proto celkem logicky byl PostgreSQL použit pro o.s. implementaci standardu OpenGIS. Část standardu OpenGIS (chronologicky předcházı́ SQL2000) je zaměřena na SQL databáze, které
by měly sloužit jako uložiště prostorových dat. Vycházı́ z SQL92 rozšı́řeného o geometrické
typy (SQL92 with Geometry Types), definuje metadata popisujı́cı́ funkcionalitu systému co
se týká geometrických dat, a definuje datové schéma. Databáze, jejichž datový model respektuje normu OpenGIS, může sloužit jako datový server libovolné GIS aplikaci, která vycházı́
z tohoto standardu. Dı́ky tomu může, v celé řadě přı́padů, PostgreSQL zastoupit komerčnı́
db systémy. Implementace standardu OpenGIS pro PostgreSQL se nazývá PostGIS. PostgreSQL základnı́ geometrické typy má, úkolem PostGISu je hlavně jejich obalenı́ do specifického
(určeného normou) datového modelu. SQL/MM-Spatial sice vycházı́ z OpenGIS nicméně nenı́
kompatibilnı́. PostGIS je certifikován pro OpenGIS, částečně také implementuje SQL/MM.
Geinformatics FCE CTU 2007
71
PostGIS pro vývojáře
PostGIS obsahuje:
ˆ nové datové typy (geometry),
ˆ nové operátory (&& průnik, @kompletně obsažen),
ˆ nové funkce (distance, transform),
ˆ nové tabulky (Geometry columns, Spatial ref sys) sloužı́ jako systémové tabulky, poskytujı́ prostor pro metadata.
Standard OpenGIS je množina dokumentů detailně popisujı́cı́ aplikačnı́ rozhranı́ a datové
formáty v oblasti GIS systémů. Tato dokumentace je určena vývojářům a jejı́m cı́lem je
dosaženı́ interoperability aplikacı́ vyvı́jených členy konsorcia Open Geospatial Consortium
(www stránky OGC). Oblast, kterou pokrývá PostGIS je popsána v dokumentu ”OpenGIS®
Simple Features Specification For SQL”
Názvy datových typů v SQL/MM odvozených z OpenGISu vznikly spojenı́m prefixu ST
(spatial type) a názvu datového typu v OpenGISu. OpenGIS je obecnějšı́, počı́tá s minimálně dvěma variantami implementace geometrických typů, a k tomu potřebnému zázemı́.
SQL/MM-Spatial se dá s jistou mı́rou tolerance chápat jako podmnožina OpenGISu.
Implementace vlastnı́ch funkcı́ v PostgreSQL
Vzhledem k faktu, že vlastnı́ datové typy lze implementovat pouze v prg. jazyce C a že
PostGIS je implementován v C, bude popsán návrh modulu pouze s využitı́m jazyka C.
Při návrhu funkcı́ v C se prakticky všude použı́vajı́ makra z PostgreSQL knihovny. Důvodů
je několik:
ˆ použı́vánı́ univerzálnı́ho typu Varlena pro typy s variabilnı́ délkou, který je v přı́padě,
že je delšı́ než 2K transparentně (jak pro uživatele, tak pro vývojáře) komprimován.
ˆ odlišný způsob předávánı́ parametrům (v PostgreSQL nepřı́mo prostřednictvı́m určené
hodnoty typu struct obsahujı́cı́ ukazatel na pole parametrů, pole s informacı́, který
parametr je NULL, a počtem parametrů).
ˆ tento způsob volánı́ nenı́ závislý na programovacı́m jazyku C
Ukázka implementace funkce concat text spojujı́cı́ dva řetězce dohromady:
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
PG_FUNCTION_INFO_V1(concat_text);
Datum
concat_text(PG_FUNCTION_ARGS)
{
text *arg1 = PG_GETARG_TEXT_P(0);
text *arg2 = PG_GETARG_TEXT_P(1);
int32 new_text_size = VARSIZE(arg1) + VARSIZE(arg2) - VARHDRSZ;
text *new_text = (text *) palloc(new_text_size);
VARATT_SIZEP(new_text) = new_text_size;
memcpy(VARDATA(new_text), VARDATA(arg1), VARSIZE(arg1) - VARHDRSZ);
memcpy(VARDATA(new_text) + (VARSIZE(arg1) - VARHDRSZ),
VARDATA(arg2), VARSIZE(arg2) - VARHDRSZ);
PG_RETURN_TEXT_P(new_text);
}
Geinformatics FCE CTU 2007
72
PostGIS pro vývojáře
Komentáře:
01 Registrace funkce s volacı́ konvencı́ 1.
03 Každá funkce dosažitelná z SQL musı́ vracet univerzálnı́ datový typ Datum (společný
typ pro datové typy s fixnı́ velikostı́ (menšı́ než 64bite) a datový typ varlena).
06 Zı́skánı́ prvnı́ho parametru (resp. ukazatele na něj a korektnı́ přetypovánı́, přı́padně dekomprimace).
07 Zı́skánı́ prvnı́ho parametru (resp. ukazatele na něj a korektnı́ přetypovánı́, přı́padně dekomprimace).
08 Datový typ varlena je podobný stringu v Pascalu, prvnı́ čtyři byte obsahujı́ údaj o délce
s rozdı́lem, že údaj obsahuje velikost celé hodnoty včetně záhlavı́. Velikost hlavičky je
uložena v konst. VARHDRSZ. Výpočet velikosti vrácené hodnoty typu datum (součet
velikostı́ obou řetězců + velikost hlavičky).
09 PostgreSQL má vlastnı́ správu paměti, tudı́ž se pamět’ nealokuje volánı́m funkce malloc,
ale palloc. PostgreSQL přiděluje pamět’ z tzv. pamět’ových kontextů (persistentnı́, transakce, volánı́ funkce). Při dokončenı́ operace se uvolňuje odpovı́dajı́cı́ pamět’ový kontext.
Explicitnı́ volánı́ pfree má smysl jen u funkcı́, které by bez explicitnı́ho uvolněnı́ paměti
si nárokovali přı́liš paměti. Použitı́ pamět’ových kontextů snižuje riziko tzv. memory leaku, tj. že vývojář zapomene vrátit alokovanou pamět’. Také snižujı́ náročnost vrácenı́
paměti. Mı́sto několikanásobného uvolněnı́ malých bloků paměti se volá jednorázová
operace. Dalšı́m přı́jemným efektem je nižšı́ fragmentace paměti.
15 Přetypovánı́ z typu text na datum (přı́padná komprimace).
Každá internı́ funkce se musı́ před vlastnı́m použitı́m zaregistrovat pro jejı́ použitı́ v SQL.
01 CREATE FUNCTION concat_text(text, text) RETURNS text
02
AS ’DIRECTORY/funcs’, ’concat_text’
03
LANGUAGE C STRICT;
Komentáře:
01 Funkce concat text má dva parametry typu text a vracı́ text.
02 Tuto funkci PostgreSQL nalezne v knihovně (souboru) ’DIRECTORY/funcs’ pod názvem
’concat text’.
03 Jedná se o binárnı́ knihovnu. V přı́padě, že jeden parametr je NULL, výsledkem volánı́
funkce je hodnota NULL (atribut STRICT).
Pro volánı́ existujı́cı́ch PostgreSQL funkcı́ (pod volajı́cı́ konvencı́ 1) musı́me použı́t specifický
způsob jejich volánı́, resp. předánı́ parametrů. Často použı́vanou funkcı́ je textin, což je funkce,
která sloužı́ pro převod z-řetězce (klasického řetězce v jazyce C ukončeného nulou) na řetězec
typu varlena. Následujı́cı́ funkce vrátı́ konstantnı́ řetězec ”Hello World!”.
01
02
03
04
05
06
07
PG_FUNCTION_INFO_V1(hello_world);
Datum
hello_word(PG_FUNCTION_ARGS)
{
PG_RETURN_DATUM(DirectFunctionCall1(textin, CStringGetDatum("Hello World!")));
}
Geinformatics FCE CTU 2007
73
PostGIS pro vývojáře
Komentáře:
06 CStringGetDatum provádı́ pouze přetypovánı́
Bez použitı́ funkce DirectFunctionCall1(1 na konci názvu funkce má význam jeden argument.
Tato funkce existuje ve variantách pro jeden až devět argumentů.) by výše zmı́něná funkce
vypadala následovně (z ukázky je vidět předávánı́ parametrů v V1 volajı́cı́ konvenci):
01
02
03
04
05
06
07
08
09
10
11
12
13
14
PG_FUNCTION_INFO_V1(hello_world);
Datum
hello_word(PG_FUNCTION_ARGS)
{
FunctionCallInfoData locfcinfo;
InitFunctionCallInfoData(locfcinfo, fcinfo->flinfo, 1, NULL, NULL);
locfcinfo.arg[0] = CStringGetDatum("Hello World!")
locfcinfo.argnull[0] = false;
PG_RETURN_DATUM(textin(&locfinfo));
}
Komentáře:
08 Datová struktura locfcinfo je inicializována pro jeden argument.
13 Přı́mé volánı́ funkce textin. Jelikož tato funkce vracı́ typ Datum, který je výsledný typ
funkce hello world, nedocházı́ k přetypovánı́.
Implementace vlastnı́ch datových typů v PostgreSQL
V PostgreSQL je každý datový typ určen svojı́ vstupnı́ a výstupnı́, a sadou operátorů a funkcı́,
které tento typ podporujı́. Vstupnı́ funkce je funkce, která převádı́ řetězec na binárnı́ hodnotu.
Výstupnı́ funkce inverzně převádı́ binárnı́ hodnotu na řetězec. Podporované operátory a funkce
pak pracujı́ s binárnı́ hodnotou. V přı́padě vkládánı́ nových záznamů se vstupnı́ funkce volajı́
automaticky, v přı́padě výrazů je nutné v některých přı́padech volat explicitnı́ konverzi.
Explicitnı́ konverze se v PostgreSQL provede třemi různými způsoby:
ˆ zápisem typu následovaný řetězcem
ˆ použitı́m ANSI SQL operátoru CAST
ˆ použitı́m binárnı́ho operátoru pro přetypovánı́ ’::’ (nenı́ standardem)
Ukázka:
SELECT rodne_cislo ’7307150xxx’;
SELECT CAST(’730715xxx’ AS rodne_cislo);
SELECT ’730715xxx’::rodne_cislo;
OpenGIS, coby nezávislý standard, přidává vlastnı́ způsob zápisu. V OpenGISu je počı́táno
i s variantou, že data jsou uložená textově, v přı́padě že databázový systém nelze rozšı́řit
o geometrické typy (což nenı́ přı́pad PostgreSQL). Nicméně PostGIS nepoužı́vá geometrické
typy PostgreSQL. Typ se zapisuje přı́mo do řetězce následovaný vlastnı́mi daty, které jsou
uzavřené v závorkách. Tento zápis se označuje jako ’Well-Known Text (WKT)’. Pro přečtenı́
hodnoty tohoto typu se použı́vá funkce GeometryFromText.
Geinformatics FCE CTU 2007
74
PostGIS pro vývojáře
Ukázka:
INSERT INTO SPATIALTABLE ( THE_GEOM, THE_NAME ) VALUES
( GeomFromText(’POINT(-126.4 45.32)’, 312), ’A Place’);
Kromě textového formátu je v OpenGISu ještě definován binárnı́ formát ’Well-Know Binary
(WKB)’. Konverzi z binárnı́ho formátu do textového (čitelná podoba) formátu provádı́ funkce
asewkt (astext). Interně PostGIS ukládá data v binárnı́m formátu WKB.
Pokud máme vstupnı́ a výstupnı́ funkci k dispozici, můžeme zaregistrovat nový datový typ
přı́kazem CREATE TYPE.
01
02
03
04
05
06
07
08
09
10
11
CREATE OR REPLACE FUNCTION rodne_cislo_in (cstring)
RETURNS rodne_cislo AS ’rc.so’,’rodne_cislo_in’ LANGUAGE ’C’;
CREATE OR REPLACE FUNCTION rc_out (rodne_cislo)
RETURNS cstring AS ’rc.so’, ’rodne_cislo_out’ LANGUAGE ’C’;
CREATE TYPE rodne_cislo (
internallength = 8,
input
= rc_in,
output
= rc_out
);
Komentáře:
08 Jedná se o datový typ s pevnou délkou osmi bajtů.
Pokud chceme datovým typ použı́t v databázi, musı́me implementaci datového typu rozšı́řit
o implementaci základnı́ch binárnı́ch operátorů. Poté bude možné použı́t vlastnı́ datový typ
v klauzuli WHERE a ORDER BY.
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
CREATE OR REPLACE FUNCTION rodne_cislo_eq (rodne_cislo, rodne_cislo)
RETURNS bool AS ’rc.so’,’rodne_cislo_eq’ LANGUAGE ’C’ STRICT;
CREATE OR REPLACE FUNCTION rodne_cislo_ne (rodne_cislo, rodne_cislo)
RETURNS bool AS ’rc.so’, ’rodne_cislo_ne’ LANGUAGE ’C’ STRICT;
CREATE OR REPLACE FUNCTION rodne_cislo_lt (rodne_cislo, rodne_cislo)
RETURNS bool AS ’rc.so’,’rodne_cislo_lt’ LANGUAGE ’C’ STRICT;
CREATE OR REPLACE FUNCTION rodne_cislo_le (rodne_cislo, rodne_cislo)
RETURNS bool AS ’rc.so’, ’rodne_cislo_le’ LANGUAGE ’C’ STRICT;
CREATE OPERATOR = (
leftarg
= rodne_cislo,
rightarg = rodne_cislo,
procedure = rodne_cislo_eq
commutator = =,
negator
= <>,
restrict
= eqsel,
join
= eqjoinsel
);
CREATE OPERATOR <> (
leftarg
= rodne_cislo,
rightarg = rodne_cislo,
procedure = rodne_cislo_ne
);
CREATE OPERATOR <(
leftarg
= rodne_cislo,
rightarg = rodne_cislo,
procedure = rodne_cislo_le
);
Geinformatics FCE CTU 2007
75
PostGIS pro vývojáře
35 CREATE OPERATOR <= (
36
leftarg
= rodne_cislo,
37
rightarg = rodne_cislo,
38
procedure = rodne_cislo_le
39 );
Komentáře:
13 Registrace binárnı́ho operátoru rovno.
14 Levý argument je typu rodné čı́slo.
15 Pravý argument je typu rodné čı́slo.
16 Název funkce, která zajišt’uje operaci porovnánı́ pro datový typ rodne cislo.
17 Rovná se je komutátorem sama sebe, nebot’ platı́ že x = y <=> y = x.
18 Platı́, že x = y <=> N OT (x <> y).
19 Operátor je silně restriktivnı́ v přı́padě, že jednı́m argumentem je konstanta, tj. výsledkem
je malá podmnožina tabulky.
20 Operátoru se přiřazuje funkce odhadu selektivity.
Výše uvedené operátory stále nestačı́ k tomu, aby se nad sloupcem s vlastnı́m typem mohl
vytvořit index. Každý datový typ musı́ mı́t definovanou alespoň jednu třı́du operátorů, což
je v podstatě seznam operátorů doplněný o jejich sémantický význam. Kromě operátorů je
potřeba určit tzv. podpůrnou funkci F (a, b), jejı́ž parametry jsou klı́če a výsledkem celé čı́slo
(a > b => F (a, b) = 1; a = b => F (a, b) = 0; a < b => F (a, b) = −1).
01 CREATE OR REPLACE FUNCTION rodne_cislo_cmp (rodne_cislo, rodne_cislo)
02
RETURNS int AS ’rc.so’, ’rodne_cislo__cmp’ LANGUAGE ’C’ STRICT;
03
04 CREATE OPERATOR CLASS rodne_cislo_ops
05
DEFAULT FOR TYPE rodne_cislo USING btree AS
06
OPERATOR 1
<,
07
OPERATOR 2
<=,
08
OPERATOR 3
= ,
09
OPERATOR 4
>=,
10
OPERATOR 5
>,
11
FUNCTION 1
rodne_cislo_cmp (rodne_cislo, rodne_cislo);
Komentáře:
06 Strategie 1 má význam menšı́ než.
07 Strategie 2 má význam menšı́ rovno než.
08 Strategie 3 má význam rovno.
09 Strategie 4 má význam vetšı́ rovno než.
10 Strategie 5 má význam většı́ než.
11 Určenı́ podpůrné funkce.
Geinformatics FCE CTU 2007
76
PostGIS pro vývojáře
Ukázka použitı́ PostGISu
OpenGIS předpokládá uloženı́ dat do klasických databázových tabulek. Nicméně k tomu,
aby tyto tabulky dokázali přečı́st GIS aplikace je nutné do datového schématu přidat dvě
systémové (z pohledu OpenGIS) tabulky.
geometry columns obsahuje informace o sloupcı́ch geometrii geoprvků,
spatial ref sys obsahuje informace o souřadnicových systémech použı́vaných systémem.
01 create table user_locations (gid int4, user_name varchar);
02 select AddGeometryColumn (’db_mapbender’,’user_locations’,’the_geom’,’4326’,’POINT’,2);
03 insert into user_locations values (’1’,’Morissette’,GeometryFromText(’POINT(-71.060316 48.432044)’,
4326));
Komentáře:
01 vytvořenı́ tabulky faktů (feature table)
02 do tabulky user location přidá sloupec s názvem the geom (následně přidá do tabulky
geometry columns nový řádek s metadaty o sloupci the geom)
03 Plněnı́ tabulky daty
Kromě plněnı́ datových tabulek pomocı́ SQL přı́kazů PostGIS obsahuje nástroj pro import
datových (shape) souborů, tzv. shape loader. Dı́ky němu je možné importovat data v několika
formátech. Namátkou podporované formáty jsou Shape, MapInfo, DGN, GML.
K urychlenı́ operacı́ prováděných nad prostorovými daty lze použı́t prostorový index. PostgreSQL podporuje několik typů indexů, pro GIS lze použı́t (ve verzi 8.2) formáty GIST a
GIN.
01 CREATE INDEX <indexname>
02 ON <tablename>
03 USING GIST ( <geometrycolumn> [ GIST_GEOMETRY_OPS ] );
Komentáře:
03 GIST GEOMETRY OPS určuje výše zmı́něnou třı́du operátorů.
Analýza obsahu distribuce PostGIS 1.2.1
Struktura adresáře:
ˆ ./ – Sestavovacı́ a instalačnı́ skripty
ˆ ./lwgeom – Zdrojový kód knihoven
ˆ ./java/ejb – Podpora EJB Java
ˆ ./java/jdbc – JDBC ovladač pro PostgreSQL rozšı́řený o podporu GIS objektů
ˆ ./java/pljava – PostgreSQL PL/Java rozšı́řená o prostorové objekty
ˆ ./doc – Dokumentace
ˆ ./loader – Programy zajišt’ujı́cı́ konverzi ESRI Shape souborů do SQL (resp. PostGIS)
a inverznı́ transformaci PostGIS dat do Shape souborů (pgsql2shp a shp2pgsql)
Geinformatics FCE CTU 2007
77
PostGIS pro vývojáře
ˆ ./topology – Počátečnı́ implementace modelu topology
ˆ ./utils – Pomocné skripty (aktualizace, profilace)
ˆ ./extras – Kód, který se nedostal do hlavnı́ho stromu (WFS locks, ukázka wkb parseru)
ˆ ./regress – Regresnı́ testy
Závislosti:
ˆ proj4 - knihovna realizujı́cı́ transformace mezi projekcemi
ˆ geos – knihovna implementujı́cı́ topologické testy (PostgreSQL je třeba překládat s
podporou C++)
Typ LWGEOM nahrazuje původnı́ typ GEOMETRY PostGISu. Oproti němu je menšı́ (data
jsou uložená binárně – pro POINT(0,0) je to úspora z 140 bajtů na 21 bajtů), podporuje 1D,
2D, 3D a 4D souřadnice, interně vycházı́ z OGC WKB typu a také jeho textová prezentace je
OGC WKB. Typ LWGEOM nahradil předchozı́ typ GEOMETRY ve verzi 1.0. LW znamená
Light Weight (vylehčený). Interně v PostgreSQL se použı́vá identifikátor PG LWGEOM.
Hodnoty se serializujı́ rekurzivně, za hlavičkou specifikujı́cı́ typ a atributy se serializujı́ vlastnı́
data.
Jádro PostGISu je schované v implementaci typu LWGEOM. Jako parser je, v prostředı́
UNIX obvyklý, použitý generátor překladačů Lex a yacc (konkrétně jejich implementace Bison). Syntaxe je určena v souborech wktparse.lex (lexikálnı́ elementy, klı́čová slova, čı́sla) a
wktparse.y (syntaktické elementy)
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
/* MULTIPOINT */
geom_multipoint :
MULTIPOINT { alloc_multipoint(); } multipoint { pop(); }
|
MULTIPOINTM { set_zm(0, 1); alloc_multipoint(); } multipoint {pop(); }
multipoint :
empty
|
{ alloc_counter(); } LPAREN multipoint_int RPAREN { pop(); }
multipoint_int :
mpoint_element
|
multipoint_int COMMA mpoint_element
mpoint_element :
nonempty_point
|
/* this is to allow MULTIPOINT(0 0, 1 1) */
{ alloc_point(); } a_point { pop(); }
Komentáře:
03 Povoleným zápisem je MULTIPOINT seznam nebo MULTIPOINTM seznam.
08 Seznam může být prázdný nebo je posloupnostı́ čı́sel uzavřený v závorkách.
13 Seznam je bud’to o jednom prvku nebo seznam a čárkou oddělený element.
16 Rekurzivnı́ definice seznamu.
Geinformatics FCE CTU 2007
78
PostGIS pro vývojáře
22 a point je 2D 3D 4D hodnota zapsaná jako posloupnost n čı́sel oddělených mezerou.
Serializace a deserializace načteného syntaktického stromu je řešena v souboru lwgeom inout.c.
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
CREATE FUNCTION geometry_in(cstring)
RETURNS geometry
AS ’@MODULE_FILENAME@’,’LWGEOM_in’
LANGUAGE ’C’ _IMMUTABLE_STRICT; -- WITH (isstrict,iscachable);
CREATE FUNCTION geometry_out(geometry)
RETURNS cstring
AS ’@MODULE_FILENAME@’,’LWGEOM_out’
LANGUAGE ’C’ _IMMUTABLE_STRICT; -- WITH (isstrict,iscachable);
CREATE TYPE geometry (
internallength = variable,
input = geometry_in,
output = geometry_out,
);
Definice typu geometry je v souboru lwpostgis.sql.in spolu s definicemi dalšı́ch desı́tek databázových objektů. Zcela zásadnı́ jsou tabulky spatial ref sys a geometry columns.
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
-------------------------------------------------------------------- SPATIAL_REF_SYS
------------------------------------------------------------------CREATE TABLE spatial_ref_sys (
srid integer not null primary key,
auth_name varchar(256),
auth_srid integer,
srtext varchar(2048),
proj4text varchar(2048)
);
-------------------------------------------------------------------- GEOMETRY_COLUMNS
------------------------------------------------------------------CREATE TABLE geometry_columns (
f_table_catalog varchar(256) not null,
f_table_schema varchar(256) not null,
f_table_name varchar(256) not null,
f_geometry_column varchar(256) not null,
coord_dimension integer not null,
srid integer not null,
type varchar(30) not null,
CONSTRAINT geometry_columns_pk primary key (
f_table_catalog,
f_table_schema,
f_table_name,
f_geometry_column )
) WITH OIDS;
Řada funkcı́ PostGISu jsou realizována v jazyce PL/pgSQL. Což je jazyk SQL procedur v
prostředı́ PostgreSQL vycházejı́cı́ z PL/SQL fy. Oracle (který vycházı́ z prg. jazyka ADA). Je
to celkem logické, dı́ky integraci SQL jsou SQL přı́kazy zapsány úsporně a čitelně.
001
002
003
004
005
006
007
008
009
010
011
------------------------------------------------------------------------ ADDGEOMETRYCOLUMN
-<catalogue>, <schema>, <table>, <column>, <srid>, <type>, <dim>
------------------------------------------------------------------------- Type can be one of geometry, GEOMETRYCOLLECTION, POINT, MULTIPOINT, POLYGON,
-- MULTIPOLYGON, LINESTRING, or MULTILINESTRING.
--- Types (except geometry) are checked for consistency using a CHECK constraint
-- uses SQL ALTER TABLE command to add the geometry column to the table.
-- Addes a row to geometry_columns.
Geinformatics FCE CTU 2007
79
PostGIS pro vývojáře
012
013
014
015
016
017
018
019
020
021
-- Addes a constraint on the table that all the geometries MUST have the same
-- SRID. Checks the coord_dimension to make sure its between 0 and 3.
-- Should also check the precision grid (future expansion).
-- Calls fix_geometry_columns() at the end.
-----------------------------------------------------------------------CREATEFUNCTION AddGeometryColumn(varchar,varchar,varchar,varchar,integer,varchar,integer)
RETURNS text
AS
’
Komentáře:
018 Tento zdrojový kód se v PostGISu zpracovává ještě preprocesorem, takže na prvnı́ pohled
neplatné klı́čové slovo CREATEFUNCTION je správné. Důvodem je potřeba jedné
verze zdrojových kódů použitelných pro různé verze PostgreSQL, kdy mezi nejstaršı́
verzı́ 7.4 a nejnovějšı́ 8.2 je zřetelný rozdı́l v možnostech a i v zápisu uložených procedur.
Jinak tyto verze od sebe dělı́ tři roky. Přestože oficiálně nejstaršı́ podporovaná verze je
7.4, v kodu je řada odkazů na verzi 7.2.
022 DECLARE
023 catalog_name alias for $1;
024 schema_name alias for $2;
025 table_name alias for $3;
026 column_name alias for $4;
027 new_srid alias for $5;
028 new_type alias for $6;
029 new_dim alias for $7;
030 rec RECORD;
031 schema_ok bool;
032 real_schema name;
033 BEGIN
034
035 IF ( not ( (new_type =’’GEOMETRY’’) or
036
(new_type =’’GEOMETRYCOLLECTION’’) or
037
(new_type =’’POINT’’) or
038
(new_type =’’MULTIPOINT’’) or
039
(new_type =’’POLYGON’’) or
040
(new_type =’’MULTIPOLYGON’’) or
041
(new_type =’’LINESTRING’’) or
042
(new_type =’’MULTILINESTRING’’) or
043
(new_type =’’GEOMETRYCOLLECTIONM’’) or
044
(new_type =’’POINTM’’) or
045
(new_type =’’MULTIPOINTM’’) or
046
(new_type =’’POLYGONM’’) or
047
(new_type =’’MULTIPOLYGONM’’) or
048
(new_type =’’LINESTRINGM’’) or
049
(new_type =’’MULTILINESTRINGM’’) or
050
(new_type = ’’CIRCULARSTRING’’) or
051
(new_type = ’’CIRCULARSTRINGM’’) or
052
(new_type = ’’COMPOUNDCURVE’’) or
053
(new_type = ’’COMPOUNDCURVEM’’) or
054
(new_type = ’’CURVEPOLYGON’’) or
055
(new_type = ’’CURVEPOLYGONM’’) or
056
(new_type = ’’MULTICURVE’’) or
057
(new_type = ’’MULTICURVEM’’) or
058
(new_type = ’’MULTISURFACE’’) or
059
(new_type = ’’MULTISURFACEM’’)) )
060 THEN
061 RAISE EXCEPTION ’’Invalid type name - valid ones are:
062 GEOMETRY, GEOMETRYCOLLECTION, POINT,
063 MULTIPOINT, POLYGON, MULTIPOLYGON,
064 LINESTRING, MULTILINESTRING,
065
CIRCULARSTRING, COMPOUNDCURVE,
Geinformatics FCE CTU 2007
80
PostGIS pro vývojáře
066
067
068
069
070
071
072
073
074
075
076
077
078
079
080
081
082
083
084
085
086
087
088
089
090
091
092
093
094
095
096
097
098
099
100
101
102
103
104
105
106
107
108
109
CURVEPOLYGON, MULTICURVE, MULTISURFACE,
GEOMETRYCOLLECTIONM, POINTM,
MULTIPOINTM, POLYGONM, MULTIPOLYGONM,
LINESTRINGM, MULTILINESTRINGM
CIRCULARSTRINGM, COMPOUNDCURVEM,
CURVEPOLYGONM, MULTICURVEM or MULTISURFACEM’’;
return ’’fail’’;
END IF;
IF ( (new_dim >4) or (new_dim <0) ) THEN
RAISE EXCEPTION ’’invalid dimension’’;
return ’’fail’’;
END IF;
IF ( (new_type LIKE ’’%M’’) and (new_dim!=3) ) THEN
RAISE EXCEPTION ’’TypeM needs 3 dimensions’’;
return ’’fail’’;
END IF;
IF ( schema_name != ’’’’ ) THEN
schema_ok = ’’f’’;
FOR rec IN SELECT nspname FROM pg_namespace WHERE text(nspname) = schema_name LOOP
schema_ok := ’’t’’;
END LOOP;
if ( schema_ok <> ’’t’’ ) THEN
RAISE NOTICE ’’Invalid schema name - using current_schema()’’;
SELECT current_schema() into real_schema;
ELSE
real_schema = schema_name;
END IF;
ELSE
SELECT current_schema() into real_schema;
END IF;
-- Add geometry column
EXECUTE ’’ALTER TABLE ’’ ||
quote_ident(real_schema) || ’’.’’ || quote_ident(table_name)
|| ’’ ADD COLUMN ’’ || quote_ident(column_name) ||
’’ geometry ’’;
Komentáře:
105 Prostřednictvı́m dynamického SQL přidává sloupec do cı́lové tabulky faktů.
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
-- Delete stale record in geometry_column (if any)
EXECUTE ’’DELETE FROM geometry_columns WHERE
f_table_catalog = ’’ || quote_literal(’’’’) ||
’’ AND f_table_schema = ’’ ||
quote_literal(real_schema) ||
’’ AND f_table_name = ’’ || quote_literal(table_name) ||
’’ AND f_geometry_column = ’’ || quote_literal(column_name);
-- Add record in geometry_column
EXECUTE ’’INSERT INTO geometry_columns VALUES (’’ ||
quote_literal(’’’’) || ’’,’’ ||
quote_literal(real_schema) || ’’,’’ ||
quote_literal(table_name) || ’’,’’ ||
quote_literal(column_name) || ’’,’’ ||
new_dim || ’’,’’ || new_srid || ’’,’’ ||
Geinformatics FCE CTU 2007
81
PostGIS pro vývojáře
127
128
quote_literal(new_type) || ’’)’’;
Komentáře:
112 Prostřednictvı́m dynamického SQL rušı́ sloupec, pokud byl takový, v tabulce metadat
geometry columns.
121 Prostřednictvı́m dynamického SQL vkládá metadata o sloupci do tabulky
geometry columns.
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
-- Add table checks
EXECUTE ’’ALTER TABLE ’’ ||
quote_ident(real_schema) || ’’.’’ || quote_ident(table_name)
|| ’’ ADD CONSTRAINT ’’
|| quote_ident(’’enforce_srid_’’ || column_name)
|| ’’ CHECK (SRID(’’ || quote_ident(column_name) ||
’’) = ’’ || new_srid || ’’)’’ ;
EXECUTE ’’ALTER TABLE ’’ ||
quote_ident(real_schema) || ’’.’’ || quote_ident(table_name)
|| ’’ ADD CONSTRAINT ’’
|| quote_ident(’’enforce_dims_’’ || column_name)
|| ’’ CHECK (ndims(’’ || quote_ident(column_name) ||
’’) = ’’ || new_dim || ’’)’’ ;
IF (not(new_type = ’’GEOMETRY’’)) THEN
EXECUTE ’’ALTER TABLE ’’ ||
quote_ident(real_schema) || ’’.’’ || quote_ident(table_name)
|| ’’ ADD CONSTRAINT ’’
|| quote_ident(’’enforce_geotype_’’ || column_name)
|| ’’ CHECK (geometrytype(’’ ||
quote_ident(column_name) || ’’)=’’ ||
quote_literal(new_type) || ’’ OR (’’ ||
quote_ident(column_name) || ’’) is null)’’;
END IF;
return
real_schema || ’’.’’ ||
table_name || ’’.’’ || column_name ||
’’ SRID:’’ || new_srid ||
’’ TYPE:’’ || new_type ||
’’ DIMS:’’ || new_dim || chr(10) || ’’ ’’;
END;
’
LANGUAGE ’plpgsql’ _VOLATILE_STRICT; -- WITH (isstrict);
----------------------------------------------------------------------------- ADDGEOMETRYCOLUMN ( <schema>, <table>, <column>, <srid>, <type>, <dim> )
------------------------------------------------------------------------------ This is a wrapper to the real AddGeometryColumn, for use
-- when catalogue is undefined
----------------------------------------------------------------------------CREATEFUNCTION AddGeometryColumn(varchar,varchar,varchar,integer,varchar,integer) RETURNS text AS ’
DECLARE
ret text;
BEGIN
SELECT AddGeometryColumn(’’’’,$1,$2,$3,$4,$5,$6) into ret;
RETURN ret;
END;
’
LANGUAGE ’plpgsql’ _STABLE_STRICT; -- WITH (isstrict);
Geinformatics FCE CTU 2007
82
PostGIS pro vývojáře
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
----------------------------------------------------------------------------- ADDGEOMETRYCOLUMN ( <table>, <column>, <srid>, <type>, <dim> )
------------------------------------------------------------------------------ This is a wrapper to the real AddGeometryColumn, for use
-- when catalogue and schema are undefined
----------------------------------------------------------------------------CREATEFUNCTION AddGeometryColumn(varchar,varchar,integer,varchar,integer) RETURNS text AS ’
DECLARE
ret text;
BEGIN
SELECT AddGeometryColumn(’’’’,’’’’,$1,$2,$3,$4,$5) into ret;
RETURN ret;
END;
’
LANGUAGE ’plpgsql’ _VOLATILE_STRICT; -- WITH (isstrict);
Komentáře:
174 Přetı́ženı́ funkcı́ (tj. existuje vı́ce funkcı́ stejného jména s různými parametry) se v
PostgreSQL (dle standardu ANSI) použı́vá také k náhradě nepodporovaných volitelných
parametrů. Funkce definované na řádcı́ch 174 a 192 se použı́vajı́ v přı́padě, že chybı́
hodnoty parametrů katalog a schéma. V ANSI SQL se nepoužı́vá termı́n databáze, ale
katalog, který obsahuje jemnějšı́ dělenı́ na jednotlivá schémata.
Zdrojový kód ESRI ArcSDE podporovaná podmnožiny SQL/MM funkcı́ je v souboru
sqlmm.sql.
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
-- PostGIS equivalent function: ndims(geometry)
CREATEFUNCTION ST_CoordDim(geometry)
RETURNS smallint
AS ’@MODULE_FILENAME@’, ’LWGEOM_ndims’
LANGUAGE ’C’ _IMMUTABLE_STRICT; -- WITH (iscachable,isstrict);
-- PostGIS equivalent function: GeometryType(geometry)
CREATEFUNCTION ST_GeometryType(geometry)
RETURNS text
AS ’
DECLARE
gtype text := geometrytype($1);
BEGIN
IF (gtype IN (’’POINT’’, ’’POINTM’’)) THEN
gtype := ’’Point’’;
ELSIF (gtype IN (’’LINESTRING’’, ’’LINESTRINGM’’)) THEN
gtype := ’’LineString’’;
ELSIF (gtype IN (’’POLYGON’’, ’’POLYGONM’’)) THEN
gtype := ’’Polygon’’;
ELSIF (gtype IN (’’MULTIPOINT’’, ’’MULTIPOINTM’’)) THEN
gtype := ’’MultiPoint’’;
ELSIF (gtype IN (’’MULTILINESTRING’’, ’’MULTILINESTRINGM’’)) THEN
gtype := ’’MultiLineString’’;
ELSIF (gtype IN (’’MULTIPOLYGON’’, ’’MULTIPOLYGONM’’)) THEN
gtype := ’’MultiPolygon’’;
ELSE
gtype := ’’Geometry’’;
END IF;
RETURN ’’ST_’’ || gtype;
END
’
LANGUAGE ’plpgsql’ _IMMUTABLE_STRICT; -- WITH (isstrict,iscachable);
Komentáře:
Geinformatics FCE CTU 2007
83
PostGIS pro vývojáře
02 Vytvořenı́ synonyma pro PostGIS funkci.
08 Zapouzdřenı́ PostGIS funkce kódem v plpgsql. V tomto přı́padě se stı́rá rozdı́l mezi typy
MULTIPOINT a MULTIPOINTM (analogicky u dalšı́ch typů).
Řešenı́ výkonných funkcı́ v PostGISu
Kromě vlastnı́ implementace datových typů PostGIS obsahuje implementaci pomocných funkcı́
nad prostorovými daty. Následujı́cı́ přı́klady jsou funkce z lwgeom functions basic.c, které mohou sloužit jako vzor pro vytvářenı́ vlastnı́ch funkcı́.
Funkce LWGEOM makepoint se použı́vá pro vytvořenı́ 2D bodu na základě zadaných souřadnic.
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
PG_FUNCTION_INFO_V1(LWGEOM_makepoint);
Datum LWGEOM_makepoint(PG_FUNCTION_ARGS)
{
double x,y,z,m;
LWPOINT *point;
PG_LWGEOM *result;
x = PG_GETARG_FLOAT8(0);
y = PG_GETARG_FLOAT8(1);
if ( PG_NARGS() == 2 ) point = make_lwpoint2d(-1, x, y);
else if ( PG_NARGS() == 3 ) {
z = PG_GETARG_FLOAT8(2);
point = make_lwpoint3dz(-1, x, y, z);
}
else if ( PG_NARGS() == 4 ) {
z = PG_GETARG_FLOAT8(2);
m = PG_GETARG_FLOAT8(3);
point = make_lwpoint4d(-1, x, y, z, m);
}
else {
elog(ERROR, "LWGEOM_makepoint: unsupported number of args: %d",
PG_NARGS());
PG_RETURN_NULL();
}
result = pglwgeom_serialize((LWGEOM *)point);
PG_RETURN_POINTER(result);
}
Komentáře:
01, 02 Standardnı́ záhlavı́ funkce pro v1 volajı́cı́ konvenci
08, 09 Zı́skánı́ prvnı́ch dvou argumentů typu float8
11 Pokud počet argumentů funkce je roven dvěma, volá se externı́ funkce make lwpoint2d,
jinak se zjišt’uje počet argumentů a podle něj se volá odpovı́dajı́cı́ verze externı́ funkce.
22 Funkce elog se použı́vá pro vyvolánı́ výjimky, pokud je level ERROR. V přı́padě, že level
je NOTICE, zobrazı́ ladı́cı́ hlášenı́.
24 Kód za elog(ERROR,...) se již neprovádı́. V tomto přı́padě PG RETURN NULL() sloužı́
k utišenı́ překladače ohledně zobrazenı́ varovánı́.
27 Serializace objektu do typu PG LWGEOM.
Geinformatics FCE CTU 2007
84
PostGIS pro vývojáře
29 Výstupem z funkce je ukazatel na serializovanou hodnotu objektu, provede se konverze
na typ Datum.
SQL registrace této funkce vypadá následovně:
01 CREATEFUNCTION makePoint(float8, float8)
02
RETURNS geometry
03
AS ’@MODULE_FILENAME@’, ’LWGEOM_makepoint’
04
LANGUAGE ’C’ _IMMUTABLE_STRICT; -- WITH (iscachable,isstrict);
05
06 CREATEFUNCTION makePoint(float8, float8, float8)
07
RETURNS geometry
08
AS ’@MODULE_FILENAME@’, ’LWGEOM_makepoint’
09
LANGUAGE ’C’ _IMMUTABLE_STRICT; -- WITH (iscachable,isstrict);
10
11 CREATEFUNCTION makePoint(float8, float8, float8, float8)
12
RETURNS geometry
13
AS ’@MODULE_FILENAME@’, ’LWGEOM_makepoint’
14
LANGUAGE ’C’ _IMMUTABLE_STRICT; -- WITH (iscachable,isstrict);
Komentáře:
01, 06, 11 Tato implementace je ukázkou přetı́žené funkce (s různým počtem parametrů),
kdy všechny varianty této přetı́žené funkce sdı́lı́ jednu funkci implementovanou v jazyce
C.
Funkce LWGEOM inside circle point sloužı́ k určenı́, zda-li je bod uvnitř nebo vně kruhu.
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
PG_FUNCTION_INFO_V1(LWGEOM_inside_circle_point);
Datum LWGEOM_inside_circle_point(PG_FUNCTION_ARGS)
{
PG_LWGEOM *geom;
double cx = PG_GETARG_FLOAT8(1);
double cy = PG_GETARG_FLOAT8(2);
double rr = PG_GETARG_FLOAT8(3);
LWPOINT *point;
POINT2D pt;
geom = (PG_LWGEOM *)PG_DETOAST_DATUM(PG_GETARG_DATUM(0));
point = lwpoint_deserialize(SERIALIZED_FORM(geom));
if ( point == NULL ) {
PG_FREE_IF_COPY(geom, 0);
PG_RETURN_NULL(); /* not a point */
}
getPoint2d_p(point->point, 0, &pt);
PG_FREE_IF_COPY(geom, 0);
PG_RETURN_BOOL(lwgeom_pt_inside_circle(&pt, cx, cy, rr));
}
Komentáře:
11 Z TOAST hodnoty musı́me zı́skat serializovanou hodnotu typu PG LWGEOM. TOAST
je pro uživatele databáze (nikoliv pro vývojáře) transparentnı́ mechanismus zajišt’ujı́cı́
kompresi a uloženı́ serializovaných řetězců delšı́ch než 2KB. PostgreSQL interně použı́vá
datové stránky o 8KB a žádná do databáze uložená hodnota (vyjma tzv. BLOBu)
nemůže tuto velikost přesáhnout. Toto omezenı́ se obcházı́ právě metodou nazvanou
TOAST, kdy se delšı́ hodnoty dělı́ a ukládajı́ do speciálnı́ tabulky do vı́ce řádků po
maximálně 2KB).
12 Deserializace typu point.
Geinformatics FCE CTU 2007
85
PostGIS pro vývojáře
14 Bezpečné uvolněnı́ paměti (celá řada typů se přenášı́ hodnotou, a tudı́ž je nelze chápat
jako ukazatele a nelze dealokovat pamět’ na kterou by se odkazovaly).
18 Konverze typu LWPOINT na typ POINT2D.
22 Vrácenı́ návratové hodnoty jako výsledku volánı́ funkce lwgeom pt inside circle.
Definice funkce lwgeom pt inside circle (measures.c):
01 lwgeom_pt_inside_circle(POINT2D *p, double cx, double cy, double rad)
02 {
03
POINT2D center;
04
05
center.x = cx;
06
center.y = cy;
07
08
if ( distance2d_pt_pt(p, &center) < rad ) return 1;
09
else return 0;
10 }
Funkce LWGEOM inside circle point je registrována SQL přı́kazem:
01 CREATEFUNCTION point_inside_circle(geometry,float8,float8,float8)
02
RETURNS bool
03
AS ’@MODULE_FILENAME@’, ’LWGEOM_inside_circle_point’
04
LANGUAGE ’C’ _IMMUTABLE_STRICT; -- WITH (isstrict);
Podpora indexu typu GiST v PostGISu
Indexy typu R-tree jsou specifické právě pro prostorová vı́cedimenzionálnı́ data (a pro ně
byly navrženy). Aktuálnı́ verze PostgreSQL nabı́zı́ již dalšı́ generaci této třı́dy databázových
indexů a to tzv. GiST (Generalized Search Tree) indexy. Jejich princip je stejný, širšı́ je ale
jejich uplatněnı́. GiST indexy se v PostgreSQL použı́vajı́ pro fulltext, indexovánı́ obsahu polı́,
vlastnı́ podporu hierarchických dat a také samozřejmě pro geometrické typy.
Jak již bylo zmı́něno, R-tree index předpokládá, že indexovaná data budou mı́t minimálně
dvě dimenze. Index má stromovou strukturu, a každý nekoncový uzel obsahuje jednak odkaz
na své potomky a hlavně geometrii nejmenšı́ho pravoúhlého n-rozměrného tělese obsahujı́cı́ho
všechny potomky.
GiST je aplikačnı́ rozhranı́, které umožňuje implementaci libovolného typu indexu: B-tree, Rtree. Výhodou GiST indexů je možnost vytvořenı́ doménově specifických indexů vázaných na
vlastnı́ typy vývojářům znalým doménové oblasti bez toho, aby se nutně staly databázovými
specialisty (Rozhodně ale implementace GiST indexu nepatřı́ mezi triviálnı́ programovánı́).
Ukázkovým přı́kladem je použitı́ GiST indexu v PostGISu. Kritériem, které se použije pro
rozhodovánı́, zda-li použı́t B-tree index nebo GiST index jsou operace, které chceme urychlit
indexem. Pokud nám postačuje množina binárnı́ch operátorů <, =, >, pak je na mı́stě uvažovat
o B-tree indexu. V opačném přı́padě nezbývá než použı́t GiST index, který je obecnějšı́ než
B-tree index.
Prostorové indexy se dajı́ použı́t i pro klasická data. Jednodimenzionálnı́ data se ale musı́
předtı́m převést na vı́cedimenzionálnı́. Ukázkovým přı́padem selhánı́ jednodimenzionálnı́ho
přı́padu je následujı́cı́ přı́klad. Mějme databázi událostı́ popsanou časem zahájenı́ (start time)
a časem ukončenı́ (end time). Pokud budeme chtı́t vypsat události, které probı́haly v určitém
čase napı́šeme dotaz s podmı́nkou
01 WHERE star_time < t AND end_time > (t + n)
Geinformatics FCE CTU 2007
86
PostGIS pro vývojáře
Indexace sloupců start time a end time zcela jistě pomůže, nicméně v tomto přı́padě majı́ indexy malou selektivitu (v průměru oba vracı́ polovinu řádků z tabulky). start time a end time
jsou dvě jednodimenzionálnı́ řady, takže se celkem přirozeně nabı́zı́ chápat je jako jednu dvou
dimenzionálnı́ řadu a předchozı́ podmı́nku transformovat do tvaru postaveného nad geometrickými operátory.
01 WHERE box(point(start_time - t, start_time - t),
02
point(end_time - (t + n), end_time - (t + n)) @
03 box(point(start_time, start_time),
04
point(end_time, end_time))
Komentáře:
01 Zápis nenı́ validnı́. Z důvodu čitelnosti neobsahuje nezbytnou konverzi z typu Date na
celá čı́sla.
02 Operátor @ má význam kompletně obsažen.
Popis a použitı́ GiST indexu
GiST index je vyvážený strom obsahujı́cı́ vždy dvojice klı́č (predikát), ukazatel na data na
hraničnı́ch uzlech stromu (listech) a dvojice tvrzenı́, ukazatel na potomky ve vnitřnı́ch uzlech
stromu. Dvojice tvrzenı́, ukazatel se označuje jako záznam indexu. Každý uzel může obsahovat vı́ce záznamů indexu. Tvrzenı́ (predicates) je vždy platné pro všechny klı́če dostupné z
daného uzlu. To je koncept, který se objevuje ve všech na stromech založených indexech. U již
zmı́něného R-tree indexu je tvrzenı́m ohraničujı́cı́ obdélnı́k obsahujı́cı́ všechny body (R-tree
je index navržený pro prostorová data), které jsou dostupné z vnitřnı́ho uzlu.
Každý GiST index je definován následujı́cı́mi operacemi:
Operace nad klı́či – tyto metody jsou specifické pro danou třı́du objektů a defacto určujı́
konfiguraci GiST indexu (Key Methods): Consistent, Union, Compress, Decompress, Penalty,
PickSplit
Operace nad stromem – obecné operace, které volajı́ operace nad klı́či (Tree Methods): Search
(Consistent), Insert (Penalty, PickSplit), Delete (Consistent).
Operace nad klı́či (v závorce smysl operace v přı́padě prostorových dat):
Základnı́ datovou strukturou použı́vanou ve funkcı́ch implementujı́cı́ch GiST index je GISTENTRY:
01
02
03
04
05
06
07
08
09
10
11
12
13
/*
* An entry on a GiST node. Contains the key, as well as its own
* location (rel,page,offset) which can supply the matching pointer.
* leafkey is a flag to tell us if the entry is in a leaf node.
*/
typedef struct GISTENTRY
{
Datum
key;
Relation
rel;
Page
page;
OffsetNumber offset;
bool
leafkey;
} GISTENTRY;
Komentáře:
Geinformatics FCE CTU 2007
87
PostGIS pro vývojáře
consistent
union
compress
decompress
penalty
picksplit
same
Pokud v záznamu indexu je zaručeno, že tvrzenı́ nevyhovuje dotazu s danou hodnotou, pak vracı́ logickou hodnotu nepravda. Jinak vracı́ logickou
hodnotu pravda. Pokud operace nesprávně vrátı́ log. hodnotu pravda, pak
tato chyba nemá vliv na výsledek, pouze ovlivnı́ efektivitu algoritmu (true,
pokud docházı́ k překryvu, jinak false).
Pro danou množinu záznamů indexu vracı́ takové tvrzenı́, které je platné
pro všechny záznamy v množině.
Převádı́ data do vhodného formátu pro fyzické uloženı́ na stránce indexu
(V přı́padě prostorových dat se určı́ hraničnı́ obdélnı́k).
Opak metody compress. Převádı́ binárnı́ reprezentaci indexu tak, aby s nı́
mohlo API manipulovat (načte se hraničnı́ obdélnı́k).
Vracı́ hodnotu ve významu ceny za vloženı́ nové položky do konkrétnı́ části
stromu. Položka je vložena do té části stromu, kde je tato hodnota (penalty)
nejnižšı́ (Zjišt’uje se, o kolik by se zvětšila plocha hraničnı́ho obdélnı́ku).
Ve chvı́li, kdy je nutné rozdělit stránku indexu, tato funkce určuje, které
položky zůstanou na původnı́ stránce, a které se přesunou na novou stranu
indexu.
Vracı́ logickou hodnotu pravda pokud jsou dvě položky identické.
09 Identifikátor tabulky
10 Identifikace datové stránky
11 Pozice na datové stránce
a
GistEntryVector
01
02
03
04
05
06
07
08
09
10
11
/*
* Vector of GISTENTRY structs; user-defined methods union and pick
* split takes it as one of their arguments
*/
typedef struct
{
int32
n;
/* number of elements */
GISTENTRY
vector[1];
} GistEntryVector;
#define GEVHDRSZ
(offsetof(GistEntryVector, vector))
Následujı́cı́ přı́klad je ukázkou metody union, která vracı́ nejmenšı́ možný obdélnı́k pro všechny
zadané body:
01 PG_FUNCTION_INFO_V1(LWGEOM_gist_union);
02 Datum LWGEOM_gist_union(PG_FUNCTION_ARGS)
03 {
04
GistEntryVector *entryvec = (GistEntryVector *) PG_GETARG_POINTER(0);
05
int
*sizep = (int *) PG_GETARG_POINTER(1);
06
int
numranges,
07
i;
08
BOX2DFLOAT4 *cur,
09
*pageunion;
10
11
numranges = entryvec->n;
12
cur = (BOX2DFLOAT4 *) DatumGetPointer(entryvec->vector[0].key);
13
14
pageunion = (BOX2DFLOAT4 *) palloc(sizeof(BOX2DFLOAT4));
Geinformatics FCE CTU 2007
88
PostGIS pro vývojáře
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34 }
memcpy((void *) pageunion, (void *) cur, sizeof(BOX2DFLOAT4));
for (i = 1; i < numranges; i++)
{
cur = (BOX2DFLOAT4*) DatumGetPointer(entryvec->vector[i].key);
if (pageunion->xmax < cur->xmax)
pageunion->xmax = cur->xmax;
if (pageunion->xmin > cur->xmin)
pageunion->xmin = cur->xmin;
if (pageunion->ymax < cur->ymax)
pageunion->ymax = cur->ymax;
if (pageunion->ymin > cur->ymin)
pageunion->ymin = cur->ymin;
}
*sizep = sizeof(BOX2DFLOAT4);
PG_RETURN_POINTER(pageunion);
Komentáře:
04 Prvnı́ argument obsahuje ukazatel na GistEntryVector
05 Druhý argument obsahuje ukazatel na velikost vrácené datové struktury
14, 15 Vytvořenı́ prostoru pro výstupnı́ strukturu pageunion a jejı́ naplněnı́ prvnı́m prvkem
vektoru.
12, 19 Naplněnı́ struktury cur (iterace po prvcı́ch GiST vektoru, který obsahuje prvky typu
Datum (v tomto přı́padě ukazatele na typ BOX2DFLOAT4)
21-28 Hledánı́ nejmenšı́ho možného obdélnı́ka obsahujı́cı́ho všechny zadané body
33 Předánı́ ukazatele na výstupnı́ strukturu
Každá funkce podporujı́cı́ GiST index se musı́ nejdřı́ve zaregistrovat jako PostgreSQL funkce
a potom všechny relevantnı́ funkce ještě jednou objevı́ v registraci GiST indexu:
CREATEFUNCTION LWGEOM_gist_union(bytea, OPAQUE_TYPE)
RETURNS OPAQUE_TYPE
AS ’@MODULE_FILENAME@’ ,’LWGEOM_gist_union’
LANGUAGE ’C’;
01 CREATE OPERATOR CLASS gist_geometry_ops
02
DEFAULT FOR TYPE geometry USING gist AS
03
OPERATOR
1
<<
RECHECK,
04
OPERATOR
2
&<
RECHECK,
05
OPERATOR
3
&&
RECHECK,
06
OPERATOR
4
&>
RECHECK,
07
OPERATOR
5
>>
RECHECK,
08
OPERATOR
6
~=
RECHECK,
09
OPERATOR
7
~
RECHECK,
10
OPERATOR
8
@
RECHECK,
11
OPERATOR
9
&<|
RECHECK,
12
OPERATOR
10
<<|
RECHECK,
13
OPERATOR
11
|>>
RECHECK,
14
OPERATOR
12
|&>
RECHECK,
15
FUNCTION
1
LWGEOM_gist_consistent (internal, geometry, int4),
16
FUNCTION
2
LWGEOM_gist_union (bytea, internal),
17
FUNCTION
3
LWGEOM_gist_compress (internal),
18
FUNCTION
4
LWGEOM_gist_decompress (internal),
19
FUNCTION
5
LWGEOM_gist_penalty (internal, internal, internal),
20
FUNCTION
6
LWGEOM_gist_picksplit (internal, internal),
Geinformatics FCE CTU 2007
89
PostGIS pro vývojáře
21
FUNCTION
7
LWGEOM_gist_same (box2d, box2d, internal); \
01 CREATE OPERATOR CLASS gist_geometry_ops
Závěr
Cı́lem této práce bylo připravit podklady umožňujı́cı́ snažšı́ orientaci v implementaci standardu OpenGIS v prostředı́ o.s. databázového systémy PostgreSQL – PostGIS. Nejdůležitějšı́
komponenty systému PostGIS byly popsány, zbytek nikoliv. Což ani nebylo cı́lem práce.
Ačkoliv nenı́ pravděpodobné, že by někdo mohl navrhnout vlastnı́ rozšı́řenı́ PostGISu bez
předchozı́ch znalostı́ PostgreSQL, C a vlastnı́ch GIS aplikacı́, doufám, že dı́ky této práci mohou vznikat dalšı́ rozšı́řenı́ postavené nad tı́mto, poměrně velice úspěšným produktem.
Literatura
ˆ Správa časoprostorových dat v prostředı́ PostgreSQL/PostGIS, Antonı́n ORLÍK
ˆ http://postgis.refractions.net/docs/
ˆ Návrh a realizace UDF v C pro PostgreSQL1
ˆ Access Methods for Next-Generation Database Systems2
ˆ Spatial Data Management3
1
http://www.pgsql.cz/index.php/N%C3%A1vrh a realizace UDF v c pro PostgreSQL#N \
.C3.A1vrh vlastn.C3.ADch datov.C3.BDch typ.C5.AF
2
http://citeseer.ist.psu.edu/rd/0%2C448594%2C1%2C0.25%2CDownload/http://citeseer.ist \
.psu.edu/cache/papers/cs/22615/http:zSzzSzs2k-ftp.cs.berkeley.edu:8000zSz%7Emar \
celzSzdisszSzdiss.pdf/access-methods-for-next.pdf
3
http://www.mapbender.org/presentations/Spatial Data Management Arnulf Christl/Spati \
al Data Management Arnulf Christl.pdf
Geinformatics FCE CTU 2007
90
PostgreSQL 8.3
Pavel Stěhule
Department of Mapping and Cartography, Faculty of Civil Engineering
Czech Technical University in Prague
stehule kix.fsv.cvut.cz
Klı́čová slova: Database systems, Open Source
Abstrakt
Práce na Open Source databázı́ch pokračujı́ nezadržitelným tempem. Vývojáři se musı́ vyrovnat s rostoucı́mi požadavky uživatelů na objem dat ukládaných do databázı́, na náročnějšı́
požadavky na odezvu atd. Zatı́m nedostižnou metou je implementace celého standardu ANSI
SQL 200x. Všechny databáze z velké trojky (Firebird, MySQL a PostgreSQL) použı́vajı́ multigeneračnı́ architekturu, cenově orientované hledánı́ optimálnı́ho prováděcı́ho plánu, write
ahead log atd. MySQL se profiluje jako SQL databáze schopná použı́vat specializované databázové backendy schopné maximálnı́ efektivity pro určité konkrétnı́ prostředı́. PostgreSQL
je široce použitelná databáze, těžı́cı́ z vynikajı́cı́ stability, s perfektnı́ rozšiřitelnostı́ a komfortnı́m prostředı́m. Konečně Firebird je vynikajı́cı́ embeded databáze, která se osvědčuje v
tisı́cı́ch instalacı́ch na desktopech.
Podle původnı́ho plánu mělo dojı́t k uvolněnı́ verze 8.3 koncem léta – mělo jı́t o verzi obsahujı́cı́
patche dokončené pro 8.2, ale v té době nedostatečně otestované. Nakonec se ukázalo, že ty
nejdůležitějšı́ patche je třeba dopracovat. Jednalo se o tak atraktivnı́ vlastnosti, že se rozhodlo
s vydánı́m nové verze počkat. 8.3 obsahuje integrovaný fulltext, podporu opožděného potvrzovánı́ (asynchronnı́ commit), synchronizované sekvenčnı́ čtenı́ datových souborů, úspornějšı́
ukládánı́ dynamických datových typů (kratšı́ch 256byte), HOT updates a sofistikovanějšı́ aktualizaci indexů (hot indexes). Z patchů připravených pro 8.2 se v 8.3 neobjevı́ podpora bitmapových indexů a podpora aktualizovatelných pohledů. Původnı́ řešenı́ založené na pravidlech
(rules) bylo přı́liš komplikované. 8.3 obsahuje podporu aktualizovatelných kurzorů, a je docela
dobře možné, že aktualizovatelné pohledy budou ve verzi 8.4 implementovány právě s pomocı́
této třı́dy kurzorů.
Vývoj pokračuje implementacı́ dalšı́ch modulů SQL. Ve verzi 8.3 je to konkrétně SQL/XML
(rozšı́řenı́ ANSI SQL), která umožňuje operace s XML dokumenty přı́mo v databázi a zjednodušuje generovánı́ XML dokumentů. Zásadnı́ (internı́) změnou je zkrácenı́ hlavičky řádku z
28 bajtů na 24 bajtů. Dalšı́ změnou, která by měla vést k minimalizaci velikosti uložených dat
je diverzifikace typu varlena. Tento typ se v PostgreSQL použı́vá pro serializaci hodnot všech
typů s variabilnı́ délkou. Trochu připomı́ná string v Pascalu. Prvnı́ byty nesou informaci o
délce, dalšı́ nesou obsah. Staršı́ verze PostgreSQL znaly jen typ varlena s 4byte informacı́ o
Geinformatics FCE CTU 2007
91
PostgreSQL 8.3
délce. 8.3 podporuje také typ varlena s 1byte záhlavı́m. Úspora by se měla projevit hlavně u
typu NUMERIC a krátkých řetězců. K překladu PostgreSQL lze počı́naje touto verzı́ použı́t
jak gcc, MINGW tak Microsoft Visual C++ (na platformě Microsoft Windows).
Integrace TSearch2
Integrace TSearch2 do jádra PostgreSQL je výsledkem dlouholetého úsilı́ Olega Bartunova a
Teodora Sigaeva. Dı́ky integraci se zjednodušı́ konfigurace fulltextu a pro určité jazyky (pro
které existuje podpora v projektu Snowball) lze fulltext použı́vat hned po instalaci databáze.
Čeština bohužel mezi tyto jazyky nepatřı́ – je potřeba provést několik dalšı́ch operacı́. Předně
převést Open Office slovnı́ky do kódovánı́ UTF8 a zkopı́rovat je do přı́slušného podadresáře
PostgreSQL. Dále zaregistrovat slovnı́k a provést tzv. konfiguraci. Kromě konfigurace jsou
rozdı́ly mezi integrovaným fulltextem a TSearch2 (z verze 8.2) spı́še kosmetické.
CREATE TEXT SEARCH DICTIONARY cspell1(
template=ispell,
dictfile = czech, afffile=czech, stopwords=czech);
CREATE TEXT SEARCH CONFIGURATION cs (copy=english);
ALTER TEXT SEARCH CONFIGURATION cs
ALTER MAPPING FOR word, lword WITH cspell, simple;
postgres=# select * from ts_debug(’cs’,’Přı́liš žlut’oučký kůň se napil žluté vody’);
Alias | Description |
Token
| Dictionaries
|
Lexized token
-------+---------------+-----------+-----------------+--------------------word | Word
| Přı́liš
| {cspell,simple} | cspell: {přı́liš}
blank | Space symbols |
| {}
|
word | Word
| žlut’oučký | {cspell,simple} | cspell: {žlut’oučký}
blank | Space symbols |
| {}
|
word | Word
| kůň
| {cspell,simple} | cspell: {kůň}
blank | Space symbols |
| {}
|
lword | Latin word
| se
| {cspell,simple} | cspell: {}
blank | Space symbols |
| {}
|
lword | Latin word
| napil
| {cspell,simple} | cspell: {napı́t}
blank | Space symbols |
| {}
|
word | Word
| žluté
| {cspell,simple} | cspell: {žlutý}
blank | Space symbols |
| {}
|
lword | Latin word
| vody
| {cspell,simple} | cspell: {voda}
(13 rows)
Podporu fulltextu nad konkrétnı́m sloupcem můžeme aktivovat např. vytvořenı́m funkcionálnı́ho GIN indexu.
CREATE INDEX data_poznamka_ftx ON data
USING gin(to_tsvector(’cs’, poznamka))
a vyhledávat operátorem @@ (fulltextové vyhledávánı́)
SELECT * FROM data
WHERE to_tsvector(’cs’,poznamka) @@ to_tsquery(’žlutá & voda’)
Podpora SQL/XML
Zásadně se změnila podpora XML. To co v předchozı́ch verzı́ch se neohrabaně řešilo přes
doplňky se nynı́ dostalo přı́mo do jádra. Jednak jsou k dispozici funkce generujı́cı́ XML
(xmlelement, xmlforest, ...) jednak jsou tu funkce mapujı́cı́ obsah tabulky do XML. Výsledkem
může být XML schéma (použitelné pro validaci nebo pro přenos definice tabulky), XML
dokument s integrovaným schématem, nebo samotný XML dokument. Jelikož je výstupnı́
Geinformatics FCE CTU 2007
92
PostgreSQL 8.3
formát standardizován v SQL/XML, neměl by být přenos těchto tabulek problémem (mezi
těmi databázemi, které SQL/XML podporujı́).
pavel=# create table a(a date, b varchar(10));
CREATE TABLE
pavel=# insert into a values(current_date, ’něco’),(current_date+1, NULL);
INSERT 0 2
pavel=# select table_to_xml_and_xmlschema(’a’, true, false, ’’);
table_to_xml_and_xmlschema
-----------------------------------------------------------------------------------------------<a xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="#">
<xsd:schema
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:simpleType name="DATE">
<xsd:restriction base="xsd:date">
<xsd:pattern value="\p{Nd}{4}-\p{Nd}{2}-\p{Nd}{2}"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="VARCHAR">
</xsd:simpleType>
<xsd:complexType name="RowType.root.public.a">
<xsd:sequence>
<xsd:element name="a" type="DATE" nillable="true"></xsd:element>
<xsd:element name="b" type="VARCHAR" nillable="true"></xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="TableType.root.public.a">
<xsd:sequence>
<xsd:element name="row" type="RowType.root.public.a" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
<xsd:element name="a" type="TableType.root.public.a"/>
</xsd:schema>
<row>
<a>2007-02-19</a>
<b>něco</b>
</row>
<row>
<a>2007-02-20</a>
<b xsi:nil=’true’/>
</row>
</a>
Stejného výsledku dosáhneme pomocı́ funkcı́ generujı́cı́ch XML. Jejich použitı́ je univerzálnějšı́,
a o trochu komplikovanějšı́:
pavel=# SELECT xmlelement(name a,
xmlagg(
xmlelement(name row,
xmlforest(a,b))))
FROM a;
xmlelement
---------------------------------------------------------------------------<a><row><a>2007-02-19</a><b>něco</b></row><row><a>2007-02-20</a></row></a>
(1 řádka)
V PostgreSQL stále chybı́ COLLATE. Podařilo se alespoň rozšı́řit klauzuli ORDER a to
Geinformatics FCE CTU 2007
93
PostgreSQL 8.3
v pozicovánı́ řádků s hodnotou NULL (ORDER BY .. NULLS FIRST/LAST). Adekvátně
tomu se rozšı́řili parametry u btree indexů. Refaktorizacı́ kódu se docı́lila podpora NULL v
indexech. Staršı́ verze nedokázaly indexovat hodnotu NULL.
postgres=# explain SELECT count(*) FROM fx WHERE a IS NULL;
QUERY PLAN
------------------------------------------------------------------Aggregate (cost=8.28..8.29 rows=1 width=0)
-> Index Scan using bb on fx (cost=0.00..8.28 rows=1 width=0)
Index Cond: (a IS NULL)
(3 rows)
Nové datové typy a rozšı́řenı́ možnostı́ stávajı́cı́ch datových typů
Ve verzi 8.2 PostgreSQL podporuje několik nových datových typů: XML zajišt’ujı́cı́ validitu
obsahu, UUID (universal unique identifier) dle RFC 4122. Vlastnı́ generátor je v contribu
uuid-ossp (je potřeba doinstalovat package uuid a uuid-devel). K dispozici je deset různých
způsobů generovánı́ jednoznačných univerzálnı́ch identifikátorů. Dále je tu možnost použı́vat
vlastnı́ výčtové typy (zjevně inspirováno MySQL). Na rozdı́l od MySQL v PostgreSQL je
nutné před použitı́m vytvořit pro určitý seznam hodnot vlastnı́ typ. Jeho použitı́ je ovšem
podstatně širšı́ než v MySQL.
-- klasické řešenı́ výčtu
CREATE TABLE foo(varianta char(2) CHECK (varianta IN (’a1’,’a2’,’a3’)));
-- pouziti typu enum
CREATE TYPE vycet_variant AS ENUM(’a1’,’a2’,’a3’,’a4’,’a5’);
CREATE TABLE foo(varianta vycet_variant);
-- enum lze pouzit i v poli
SELECT ’{a1,a3}’::vycet_variant[] as pripustne_varianty;
Rozsah hodnot zı́skáme volánı́m funkce enum range. Pokud funkci předáme parametr NULL,
zı́skáme úplný výčet hodnot.
postgres=# SELECT enum_range(’a2’::va, ’a4’::vycet_variant);
enum_range
-----------{a2,a3,a4}
(1 row)
postgres=# SELECT enum_range(null::vycet_variant);
enum_range
-----------------{a1,a2,a3,a4,a5}
(1 row)
Kromě opravy několika chyb v PL/pgSQL (chyběla kontrola NOT NULL domén), došlo již k
nı́že zmı́něnému rozšı́řenı́ přı́kazu RETURN o tabulkový výraz, a konečně lze i v PL/pgSQL
použı́vat scrollable kurzory. Ty PostgreSQL podporuje delšı́ dobu, z PL/pgSQL je však nebylo
možné použı́vat. Kromě scrollable kurzorů lze v PL/pgSQL (ale i vně) použı́vat updatable
kurzory podle ANSI SQL 92 (oproti ANSI SQL 2003 přı́snějšı́ omezenı́). U SRF funkcı́ můžeme
upřesnit jejich náročnost a předpoklad počtu vrácených řádků (atributy COST a ROWS). V
předchozı́ch verzı́ch se při hledánı́ optimálnı́ho prováděcı́ho plánu předpokládalo, že SRF
funkce vrátı́ vždy 1000 řádků, což nebyla pokaždé být pravda (výsledkem byl neoptimálnı́
prováděcı́ plán).
Vedlejšı́m efektem implementace subsystému pro kešovánı́ prováděcı́ch plánů bylo odstraněnı́
problémů s neplatnými prováděcı́mi plány v PL/pgSQL. Tyto problémy se projevovaly hlavně
při použitı́ dočasných tabulek, které se nesměly odstraňovat. Jinak docházelo, při použitı́ SQL
Geinformatics FCE CTU 2007
94
PostgreSQL 8.3
přı́kazu vázaného na zrušenou a opětovně vytvořenou tabulku, k chybě. Nynı́ se cache čistı́
v závislosti na rušenı́ databázových objektů. Samozřejmě, že funkce volané v cyklu budou
prováděny efektivně jen tehdy, pokud nebude docházet k regenerovánı́ prováděcı́ch plánů.
V 8.3 můžeme pole vytvářet i ze složených typů – v podstatě můžeme uložit tabulku jako
jednu hodnotu). Stále však chybı́ podpora domén (a vkládaný záznam je nutné explicitně
typovat):
postgres=# CREATE TYPE at AS (a integer, b integer);
CREATE TYPE
postgres=# CREATE TABLE foo(a at[]);
CREATE TABLE
postgres=# INSERT INTO foo VALUES(ARRAY[(10,20)::at]);
INSERT 0 1
postgres=# INSERT INTO foo VALUES(ARRAY[(10,20)::at, (20,30)::at]);
INSERT 0 1
postgres=# SELECT * FROM foo;
a
----------------------{"(10,20)"}
{"(10,20)","(20,30)"}
(2 rows)
postgres=# SELECT a[1] FROM foo;
a
--------(10,20)
(10,20)
(2 rows)
postgres=# SELECT a[1].a FROM foo;
a
---10
10
(2 rows)
Optimalizace
Ve verzi 8.3 došlo k celé řada změn a úprav, které by měly vést k rychlejšı́mu zpracovánı́ SQL
přı́kazů. Zrychlit by mělo načı́tánı́ dat přı́kazem COPY. U tohoto přı́kazu nenı́ žádný důvod,
proč by mělo docházet k zápisu do write ahead logu (ten je základem procesu obnovy po
pádu PostgreSQL) a tato verze dokáže u tohoto přı́kazu obcházet zápis so WAL (COPY musı́
být v transakci). Nově PostgreSQL efektivněji provádı́ dotazy s ORDER BY c LIMIT n, kdy
znatelně zrychlı́ výběr prvnı́ch n řádků řazených podle sloupce c, pokud nad sloupcem c nenı́
index (nedocházı́ k seřazenı́ celé tabulky). Přı́kaz EXPLAIN ANALYZE nynı́ poskytuje dalšı́
informace o řazenı́ (typ, spotřeba paměti):
t=# explain analyze SELECT * FROM foo ORDER BY a LIMIT 12;
QUERY PLAN
---------------------------------------------------------------------------------------------Limit (cost=3685.48..3685.51 rows=12 width=4) (actual time=290.549..290.588 rows=12 loops=1)
-> Sort (cost=3685.48..3935.48 rows=100000 width=4) (actual time=290.544..290.557 rows=12
loops=1)
Sort Key: a
Sort Method: top-N heapsort Memory: 17kB
-> Seq Scan on foo (cost=0.00..1393.00 rows=100000 width=4) (actual
time=0.036..153.526 rows=100000 loops=1)
Total runtime: 290.658 ms
(6 rows)
t=# explain analyze SELECT * from foo order by a;
Geinformatics FCE CTU 2007
95
PostgreSQL 8.3
QUERY PLAN
--------------------------------------------------------------------------------------------Sort (cost=10894.82..11144.82 rows=100000 width=4) (actual time=520.528..683.190
rows=100000 loops=1)
Sort Key: a
Sort Method: external merge Disk: 1552kB
-> Seq Scan on foo (cost=0.00..1393.00 rows=100000 width=4) (actual time=0.022..159.028
rows=100000 loops=1)
Total runtime: 800.065 ms
(5 rows)
V předchozı́ch verzı́ch neexistovala hash funkce pro typ NUMERIC. Proto se pro spojovánı́
tabulek skrz sloupce typu NUMERIC nedala použı́t metoda HASHJOIN, která patřı́ k nejrychlejšı́m.
Zrychlit by měla i operace LIKE, zvlášt’ když se použije vı́ce bajtové kódovánı́ – použil se jiný
algoritmus na porovnánı́ řetězců. Nynı́ se již neporovnávajı́ znaky, ale bajty, což ušetřı́ jednu
konverzi z UTF8 do UTF16. Na zkušebnı́ tabulce o sta tisı́cı́ch žlutých konı́ch sekvenčnı́ čtenı́
tabulky se zrychlilo z 169ms na 105ms.
Pokud se zjistı́, že docházı́ k souběžnému sekvenčnı́mu čtenı́ jedné tabulky z vı́ce obslužných
procesů, tak se systém pokusı́ tyto procesy sesynchronizovat (pokud dojde k sekvenčnı́mu
čtenı́, tak se ve velké většině přı́padů čte celý datový soubor). Sekvenčnı́ čtenı́ všech procesů
je přibližně stejně rychlé, a tak je šance, že všechny procesy budou chtı́t v jednu chvı́li stejnou
datovou stránku, a je mnohem vyššı́ pravděpodobnost, že ji najdou ve vyrovnávacı́ paměti.
Pokud nedocházı́ k synchronizaci procesu, tak pravděpodobnost, že požadovaná stránka je
ve vyrovnávacı́ paměti je mnohem menšı́, čı́mž se zvyšuje pravděpodobnost požadavku na
fyzické čtenı́ datové stránky se souboru. Tato optimalizace má smysl při většı́m počtu současně
pracujı́cı́ch uživatelů, kdy je vyššı́ pravděpodobnost, že dojde k synchronizaci, a také kdy je
většı́ tlak na vyrovnávacı́ pamět’.
Podpora asynchronnı́ho commitu je méně nebezpečnou obdobou nedoporučované konfigurace
fsync=off. Při asynchronnı́m commitu je zaručena konzistence databáze, nicméně při havárii
hrozı́ riziko ztráty několika poslednı́ch transakcı́. Parametr synchronous commit je vázán na
session, takže vývojář může na základě své úvahy zvolit méně bezpečný, nicméně rychlejšı́
způsob řešenı́ transakcı́. Testy ukazujı́, že má smysl uvažovat o tomto parametru v přı́padě
málo zatı́žené databáze, kdy nedocházı́ ke sdı́lenı́ zápisu do transakčnı́ho logu – typicky při
administraci databáze, kdy ostatnı́ uživatelé nemajı́ přı́stup k databázi a s databázı́ pracuje
pouze DBA.
8.3 obsahuje sofistikovanějšı́ metodu pro vytvářenı́ nových verzı́ označovanou jako HOT (Heap
Only Tuples). Staršı́ verze při jakékoliv operaci UPDATE modifikovaly relevantnı́ indexy, a to
i přesto, že nedošlo k modifikaci oindexovaných sloupců. Tzv. horký UPDATE je podmı́něný
dostatkem volného prostoru na datové stránce a změnou pouze neoindexovaných sloupců. Pokud tyto podmı́nky nejsou splněny, provede se klasický ”studený” UPDATE. HOT UPDATE
je vůči klasické implementaci operace mnohem úspornějšı́ a tudı́ž i rychlejšı́. Navı́c tato nová
metoda dokáže využı́t prostor na datové stránce obsazený nedostupnými verzemi (které byly
vytvořeny také touto metodou) bez potřeby spuštěnı́ operace VACUUM.
Geinformatics FCE CTU 2007
96
PostgreSQL 8.3
Spuštěnı́ operace VACUUM ve vı́ce procesech
V 8.3 je automatické vacuovánı́ implementováno s podporou vı́ce procesů, tj. pokud trvá
vacuum jedné databáze přı́liš dlouho, vytvořı́ se nový pracovnı́ proces (worker), který zajišt’uje
vacuovánı́ dalšı́ch databázı́ (smyslem nenı́ urychlit dı́ky paralelizaci operaci VACUUM, ale
zajistit, že v daném časovém okně se provede spravedlivě VACUUM všech databázı́). Úkolem
pracovnı́ho procesu je projet provoznı́ statistiky všech tabulek v databázi a vybrat tabulky
určené k vacuovánı́. Pracovnı́ proces je na úrovni databáze sekvenčnı́, paralelizace je na úrovni
clusteru. Nově vacuum také zajišt’uje samočinné volánı́ VACUUM FREEZE coby ochrany před
přetečenı́m rozsahu identifikátorů verzı́ řádků.
Rozšı́řenı́ PL/pgSQL – RETURN QUERY, lokálnı́ systémové proměnné
Předchozı́ verze neumožňovaly vrátit množinu záznamů jako výsledek SRF funkce. Jediným
řešenı́m bylo volánı́ přı́kazu RETURN NEXT pro každý řádek výsledku dotazu. V podstatě
totéž (ale na nižšı́ úrovni, tudı́ž efektivněji) provádı́ přı́kaz RETURN QUERY. Jeho parametrem je SQL dotaz, jehož výsledek se připojı́ k výstupu. Podobně jako RETURN NEXT
neukončuje prováděnı́ funkce.
CREATE OR REPLACE FUNCTION dirty_series(m integer, n integer)
RETURNS SETOF integer AS $$
BEGIN
RETURN QUERY SELECT * FROM generate_series(1,m) g(i)
WHERE i % n = 0;
RETURN;
END; $$ LANGUAGE plpgsq;
Dalšı́ novou vlastnostı́ je možnost modifikovat systémové proměnné lokálně pro určitou funkci.
Podobně se chová T-SQL nebo MySQL, kde se ukládá aktuálnı́ nastavenı́ systémových proměnných v čase registrace funkce. V PostgreSQL žádný podobný mechanismus nebyl. Tato
vlastnost řešı́ zabezpečenı́ SECURITY DEFINER funkcı́, kterým bylo možné podvrhnout
útočnı́kův kód změnou systémové proměnné search path. Zápis je zřejmý z následujı́cı́ho
přı́kladu:
CREATE FUNCTION report_guc(text) RETURNS TEXT AS
$$ SELECT current_setting($1) $$ LANGUAGE sql
SET regex_flavor = basic;
ALTER FUNCTION report_guc(text)
RESET search_path
SET regex_flavor = extended;
Podpora režimu Warm Standby, prototyp replikace založené na transakčnı́m
logu
PostgreSQL 8.3 umožňuje nakonfigurovat a použı́vat dva PostgreSQL servery tak, že prvnı́
sloužı́ jako výkonný server a druhý jako záložnı́, kdy změny v datech na prvnı́m serveru jsou
na druhý server replikovány exportem transakčnı́ho logu. Tato konfigurace se použı́vá pouze
v náročných aplikacı́, kde časté klasické zálohovánı́ z důvodu objemu nenı́ možné a kde ztráta
dat nenı́ akceptovatelná – kde zákaznı́k vyžaduje průběžné zálohovánı́. Nejde o multi-master
replikaci jako v přı́padě MySQL. Druhý systém je až do signálu nedostupný, tudı́ž tı́mto
způsobem replikace nelze rozložit zátěž serveru. Pro usnadněnı́ konfigurace verze 8.3 obsahuje
přı́kaz pg standby (ve stejnojmenném contrib adresáři), který zajistı́ udrženı́ druhé instance
PostgreSQL v režimu Warm Standby.
Geinformatics FCE CTU 2007
97
PostgreSQL 8.3
Master (postgresql.conf):
archive_command = ’cp %p ../archive/%f’
archive_timeout = 20
Warm Standby (recovery.conf)
restore_command = ’pg_standby -l -d -k 255 -r 2 -s 2 -w 0 -t /tmp/stop /usr/local/pgsql/archive %f %p \
2>> standby.log’
Po modifikaci konfiguračnı́ch souborů stačı́ spustit oba servery. Záložnı́ server zůstane v recovery režimu, kdy pg standby postupně podvrhuje segmenty transakčnı́ho logu (sleduje exportované segmenty) a nedovolı́ dokončit obnovu záložnı́ databáze. Teprve po signalizaci,
pg standby (existencı́ předem určeného souboru (v přı́kladu /tmp/stop)) oznámı́ serveru, že
se jednalo o poslednı́ segment transakčnı́ho logu a dovolı́ dokončenı́ obnovy a tı́m i přepnutı́
do stavu, kdy záložnı́ server je schopen přijı́mat požadavky. Signálnı́ soubor musı́ vygenerovat
uživatel postgres, tak aby jej pg standby mohlo odstranit. Pokud tento soubor nelze odstranit, replikace zhavaruje. V praxi toto řešenı́ nenı́ přı́liš použitelné, nebot’ pg standby nedokáže
zachytit výjimku a tudı́ž ji ani nedokáže korektně obsloužit (aniž by nebyl nevratně přerušen
proces replikace spojený se ztrátou dat na záložnı́m serveru).
4916 ?
S
0:00 /usr/local/pgsql/bin/postmaster -D /usr/local/pgsql2/data
4918 ?
Ss
0:00 postgres: startup process
5226 ?
S
0:00 sh -c pg_standby -l -d -t
/tmp/aaa /usr/local/pgsql/archive 000000010000000000000018 pg_xlog/RECOVERYXLOG 2>> standby.log
5227 ?
S
0:00 pg_standby -l -d -t
/tmp/aaa /usr/local/pgsql/archive 000000010000000000000018 pg_xlog/RECOVERYXLOG
Záložnı́ cluster musı́ být klonem zálohovaného clusteru. Musı́ být vytvořen zkopı́rovánı́m
adresáře databázového clusteru – nevytvářı́ se přı́kazem initdb.
Regulárnı́ výrazy
Podpora reg. výrazů nenı́ v PostgreSQL novinkou. V 8.3 se objevily nové funkce regexp matches a dvojice regexp split to array a regexp split to table. Pro řadu úloh nynı́ nemusı́me použı́vat plperl. V následujı́cı́m přı́kladu je z XML dokumentu separován seznam identifikačnı́ch
čı́sel, který je následně indexován a použit k vyhledávánı́. Ke stejnému účelu by bylo možné
použı́t i funkce podporujı́cı́ XPath výrazy. Toto řešenı́ je řádově rychlejšı́ než intuitivnı́ (a
velice pomalé) řešenı́ s LIKE.
objednava_v_xml LIKE ’%<id>hledane_id</id>%’
Pole NEW.objednavka id produktu je aktualizované v triggeru:
NEW.objednavka_id_produktu := ARRAY(SELECT i[1] FROM
regexp_matches(NEW.objednavka_v_xml,’<id>(\\d+)</id>’,’g’ r(i));
Funkčně srovnatelný predikát výše uvedenému LIKE je:
objednavka_id_produktu @> ARRAY[hledane_id]
Ostatnı́ změny
Nezanedbatelného rozšı́řenı́ se dočkalo prostředı́ ecpg. Vylepšuje podporu prepared statements, nabı́zı́ auto prepare mód, pozicované proměnné. Jedná o zásadnı́ změny – došlo
ke změně verze z 4.4 na 6.0. Jednou z prvnı́ch backportů z EnterpriseDB je debugger a
profiler PL/pgSQL. Nová verze pgAdminIII obsahuje grafické rozhranı́ debuggeru, které je
zpřı́stupněno, pokud je v PostgreSQL nainstalován plugin s debuggerem (ke staženı́ na pgfoundry). Ve srovnánı́ s modernı́mi debuggery obsahuje PL/pgSQL pouze základnı́ funkce.
Geinformatics FCE CTU 2007
98
PostgreSQL 8.3
pavel=# LOAD ’$libdir/plugins/plugin_profiler’;
LOAD
pavel=# SET plpgsql.profiler_tablename = ’profilerstats’;
SET
pavel=# SELECT line_number, sourcecode, time_total, exec_count, func_oid::regproc
FROM profilerstats
ORDER BY 1;
line_number |
sourcecode
| time_total | exec_count | func_oid
-------------+-----------------------+------------+------------+---------0 |
|
0 |
0 | x
1 | begin
|
0 |
0 | x
2 |
for i in 1..4 loop |
0.000315 |
1 | x
3 |
return next i;
|
9.8e-05 |
4 | x
4 |
end loop;
|
0 |
0 | x
5 |
return;
|
3e-06 |
1 | x
(6 rows)
Index advisor
Index advisor je plugin plánovače dotazů. Jedná se o prototyp navržený Tomem Lanem za
účelem demonstrace monitorovacı́ho rozhranı́ návrhu a optimalizace prováděcı́ch plánů. Pokud
se aktivuje, tak optimalizátor bere v úvahu, kromě existujı́cı́ch indexů, hypotetické indexy
vytvořené nad každým sloupcem:
regression=# load ’/home/tgl/pgsql/advisor’;
LOAD
regression=# explain select * from fooey order by unique2,unique1;
QUERY PLAN
---------------------------------------------------------------------------------------Sort (cost=809.39..834.39 rows=10000 width=8)
Sort Key: unique2, unique1
-> Seq Scan on fooey (cost=0.00..145.00 rows=10000 width=8)
Plan with hypothetical indexes:
Index Scan using <hypothetical index> on fooey
(6 rows)
(cost=0.00..376.00 rows=10000 width=8)
regression=# explain select * from fooey where unique2 in (1,2,3);
QUERY PLAN
-----------------------------------------------------------------------------------Seq Scan on fooey (cost=0.00..182.50 rows=3 width=8)
Filter: (unique2 = ANY (’{1,2,3}’::integer[]))
Plan with hypothetical indexes:
Bitmap Heap Scan on fooey (cost=12.78..22.49 rows=3 width=8)
Recheck Cond: (unique2 = ANY (’{1,2,3}’::integer[]))
-> Bitmap Index Scan on <hypothetical index> (cost=0.00..12.77 rows=3 width=0)
Index Cond: (unique2 = ANY (’{1,2,3}’::integer[]))
(8 rows)
Vývoj v následujı́cı́ch letech
Největšı́ slabinou PostgreSQL je chybějı́cı́ podpora replikaci. V této oblasti nikoliv nezaslouženě dominujı́ komerčnı́ systémy. Dále PostgreSQL nemá dořešenou internacionalizaci,
tzv. COLLATES, které nabı́zı́ jak MySQL, tak Firebird. Konečně třetı́ oblastı́, kterou je nynı́
třeba intenzivně se zabývat je podpora OLAP databázı́. Nelze předpokládat, že by PostgreSQL v brzké době podporoval OLAP databáze, nicméně existujı́ určité indicie, že hlavnı́m
tématem následujı́cı́ verze (8.4) bude podpora analytických a rekurzivnı́ch dotazů. V delšı́m
Geinformatics FCE CTU 2007
99
PostgreSQL 8.3
časovém horizontu je možné očekávat zařazenı́ podpory zpracovánı́ tzv. proudových dat, jelikož platforma PostgreSQL byla použita k vytvořenı́ experimentálnı́ch prototypů proudových
databázı́ a kromě toho, část týmu vývojářů se touto problematikou aktivně zabývá.
Odkazy
1. Přehled vlastnostı́ jednotlivých verzı́1
2. Přehled plánovaných rozšı́řenı́ v přı́štı́ verzi2
1
2
http://developer.postgresql.org/index.php/Feature Matrix
http://developer.postgresql.org/index.php/Todo:WishlistFor84
Geinformatics FCE CTU 2007
100
Optimalizace procesu generovánı́ map
pomocı́ XML
Otakar Čerba
Oddělenı́ geomatiky, Katedra matematiky,
Fakulta aplikovaných věd, Západočeská univerzita v Plzni
[email protected]
Klı́čová slova: kartografické procesy, XML, Atlas mezinárodnı́ch vztahů, optimalizace
Abstrakt
Přı́spěvek je zaměřený na optimalizaci procesů použitých při tvorbě Atlasu mezinárodnı́ch
vztahů [Wai2007]. Tento atlasový projekt vznikl v létech 2006-2007 na půdě Západočeské univerzity v Plzni. Jednotlivé mapy tohoto tištěného atlasu byly generovány metodami webové
kartografie, přičemž šlo o prvnı́ rozsáhlý projekt, kdy byly použity XML (eXtensible Markup
Language) technologie pro generovánı́ tematických map ve formě klasického atlasu. Proto se
během tvorby atlasu a po jejı́m ukončenı́ objevily nedostatky, které by měly být v přı́padě dalšı́ho
využı́vánı́ vytvořených postupů odstraněny nebo alespoň částečně eliminovány. Přı́spěvek se
skládá ze třı́ částı́, které popisujı́ vytvořenou publikaci, princip generovánı́ map atlasu a navrhovaná zlepšenı́ použı́vaných postupů.
Úvod – Atlas mezinárodnı́ch vztahů
Atlas mezinárodnı́ch vztahů [Wai2007] je publikace, která byla vytvořena desetičlenným autorským kolektivem pod vedenı́m PhDr. Šárky Waisové, PhD. Součástı́ autorského kolektivu
byli zástupci Katedry politologie a mezinárodnı́ch vztahů Filosofické fakulty Západočeské
univerzity v Plzni (ZČU), kteřı́ zajišt’ovali textovou část a sběr dat. Tvorba kartografických
výstupů byla úkolem členů oddělenı́ geomatiky, které spadá pod Katedru matematiky Fakulty
aplikovaných věd ZČU. Tvorbu kartografické části zajišt’ovali Ing. Magdaléna Baranová, Doc.
Ing. Václav Čada, CSc., Ing. et Mgr. Otakar Čerba a Ing. Karel Jedlička. Důvodem vzniku atlasu byla předevšı́m absence podobné publikace na českém trhu. Atlas by mohl být využı́vaný
širokým spektrem odbornı́ků z nejrůznějšı́ch oborů (politologie, politická geografie, studium
mezinárodnı́ch vztahů, zahraničnı́ obchod apod.) a studenty přı́slušných vědnı́ch na univerzitách i na střednı́ch školách. Své mı́sto by tato publikace mohla nalézt i v knihovnách laiků,
předevšı́m v souvislosti s rasantnı́mi změnami, které na politické mapě světa odehrávajı́ a
také se stále rostoucı́m významem politiky a globálnı́ch vztahů v životě běžného člověka.
Geinformatics FCE CTU 2007
101
Optimalizace procesu generovánı́ map pomocı́ XML
Finálnı́ verze atlasu obsahuje 72 map (viz následujı́cı́ tabulka) a doprovodných textů na
vı́ce než 150 stránkách. Atlas je dále doplněn dalšı́mi obrázky, tabulkami a grafy [Čer2007a],
[Bar2007].
Druh map
Politická mapa světa
Fyzicko-geografická mapa světa
Tematické mapy
Atypické mapy
Mapy politicko-geografických regionů
Detailnı́ mapy
Celkem
Počet map
1
1
47
4
4
15
72
Table 1 – Struktura Atlasu mezinárodnı́ch vztahů
Princip generovánı́ map
Kromě obsahu, grafické úpravy a rozměrů byl základnı́m limitnı́m faktorem pro tvorbu tematických map Atlasu mezinárodnı́ch vztahů výstupnı́ formát. Veškeré kartografické výstupy
bylo potřeba vytvořit ve formátu PDF (Portable Document Format), který požadovala tiskárna
vydavatelstvı́ Aleš Čeněk.
Postup tvorby map:
1. Navrženı́ základnı́ho rámce map (měřı́tková řada, grafický design, umı́stěnı́ a tvar základnı́ch kompozičnı́ch prvků apod.; vı́ce viz [Čer2007a]).
2. Volba kartografického zobrazenı́ (autorský kolektiv vybral modifikované vyrovnávacı́
zobrazenı́ Times; vı́ce viz [Bar2007]).
3. Volba interpretačnı́ch metod (viz Tab 2 [Čer2007a], [Bar2007]).
4. Generovánı́ map.
5. Kontrolnı́ a validačnı́ procedury.
Ačkoli finálnı́m produktem měla být tištěná verze atlasu, jednotlivé mapy byly generovány
technikami webové kartografie. Hlavnı́m důvodem byla předevšı́m předpokládaná aktualizace
map, kterou si bezpochyby vyžádá překotný vývoj na poli mezinárodnı́ch vztahů. Vytvořené
šablony je možné využı́vat i pro dalšı́ zpracovánı́ prostorových dat. Výstupem námi použité
metody byly mapy ve formátu SVG (Scalable Vector Graphics), které byly pomocı́ programů Inkscape (grafická editace a transformace do formátu Postscript) a GSVIEW32.EXE,
A Ghostscript graphical interface převedeny do formátu PDF určeného pro výsledný tisk.
Pro generovánı́ map byly použity formáty založené na bázi značkovacı́ho jazyka XML (eXtensible Markup Language) a přı́buzné technologie. Konkrétně se jednalo o formáty ([Čer2007a],
[Bar2007]):
1. Vlastnı́ XML schéma (soubor atlas.xml) popisujı́cı́ jednotlivé mapy atlasu, mapové
Geinformatics FCE CTU 2007
102
Optimalizace procesu generovánı́ map pomocı́ XML
symboly, barevné stupnice (barevné stupnice většinou pocházı́ z webových stránek Cynthie A. Brewer1 ) a formáty výsledných map.
2. XML Namespaces (jmenné prostory) umožňujı́cı́ použı́vat v jednom dokumentu vı́ce
typů značenı́ neboli vı́ce značek (tagů) pro elementy a atributy. Napřı́klad dokument
atlas.xml obsahuje elementy definované ve vlastnı́m značenı́ a také prvky ze schématu
SVG. Podobně i transformačnı́ styl se skládá z prvků jazyků XSLT, XLink a SVG.
3. JML neboli JUMP GML (Geography Markup Language) představujı́cı́ specifickou podmnožinu jazyka GML, který je primárně určený pro popis geografických dat. Formát
JML sloužil ke kódovánı́ geoprostorových i atributových dat.
4. XSLT (eXtensible Stylesheet Language Transformation), který je součástı́ komplexnı́ho
stylového a transformačnı́ho jazyka XSL (eXtensible Stylesheet Language). XSLT se
použı́vá pro transformaci XML do jiných, nejen XML formátů. Transformačnı́ styl sloužı́
k převodu datových souborů (formáty JML a XML) na vlastnı́ mapu (formát SVG). Pro
tvorbu atlasu byly nejprve použı́vány šablony (soubor atlas.xsl) zapsané v kombinaci
prvnı́ verze jazyka XSLT a jejı́ho rozšı́řenı́ EXSLT. V červnu 2006 došlo k přepsánı́
šablon nové verze XSLT 2.0.
5. XPath (XML Path Language) představuje dotazovacı́ jazyk určený pro výběr jednotlivých částı́ XML dokumentu. Při tvorbě atlasu byl jazyk XPath použı́vaný pro výběr
jednotlivých částı́ mapy (např. zeměpisná sı́t’, popisky, diagramy apod.), které byly
následně zpracovávány transformačnı́m procesorem podle zásad transformačnı́ho stylu.
V průběhu tvorby atlasu došlo podobně jako v přı́padě XSLT ke změně verze XPath –
nynı́ je v souboru atlas.xsl použı́ván XPath 2.0.
6. XLink (XML Linking Language) umožňuje odkazy mezi XML dokumenty i mezi jeho
částmi. Oproti odkazům známým z HTML umožňuje i dvousměrné nebo dokonce vı́cesměrné odkazy. V jednotlivých mapách se XLink 1.0 použı́vá pro odkazy na přı́slušné
barevné přechody, přičemž původně měl sloužit také k vytvořenı́ vazeb mezi popisem
symbolu a jeho lokalizacı́.
7. SVG (Scalable Vector Graphics) je otevřený vektorový formát určený předevšı́m pro
popis a distribuci dvourozměrných vektorových dat v prostředı́ internetu (vı́ce viz
[Čer2006b]). Mapy byly generovány ve formátu SVG 1.1.
8. XHTML (eXtensible HyperText Markup Language) je jazyk určený pro popis obsahu
www stránek. Jedná se o přı́mého následnı́ka velice populárnı́ho jazyka HTML (HyperText Markup Language), resp. o propojenı́ HTML a XML. V projektu Atlas mezinárodnı́ch vztahů se jazyk XHTML 1.0 Strict společně s kaskádovými styly použil pro
definovánı́ webových stránek s jednotlivými mapami, které sloužily pro jejich prohlı́ženı́
a přı́padné revize.
9. CSS (Cascading StyleSheet, kaskádové styly) je jednoduchý stylový jazyk užı́vaný předevšı́m ve spojenı́ s HTML k definovánı́ vizualizačnı́ch pravidel. V našem přı́padě kaskádové
styly (verze 2.1) posloužily jednak pro popis vizualizačnı́ch pravidel pro webovou stránku
s ukázkami map a předevšı́m pro určenı́ vizualizačnı́ch pravidel jednotlivých map. K
1
http://www.personal.psu.edu/cab38/ColorBrewer/ColorBrewer intro.html
Geinformatics FCE CTU 2007
103
Optimalizace procesu generovánı́ map pomocı́ XML
mapám jsou kaskádové styly připojeny dvěma způsoby – společné vizualizačnı́ vlastnosti jsou k mapám připojeny pomocı́ externı́ho stylu (zakladni styl.css) a některé specifické vlastnosti jsou popsány pomocı́ inline stylů a XML prezentačnı́ch atributů – oba
způsoby jsou zapsány jako atributy přı́slušných elementů.
Vlastnı́ generovánı́ map probı́halo na principu přiřazenı́ vizualizačnı́ho stylu jednotlivým datovým souborů. Přı́slušný styl a vstupnı́ data byly zpracovány pomocı́ XSLT procesoru – v
přı́padě Atlasu mezinárodnı́ch vztahů byl použitý volně šiřitelný produkt Saxon 8.8 verze
B, který implementuje jazyky XSLT 2.0, XPath 2.0 (staršı́ verze XSLT a XPath jsou také
podporovány), XQuery 1.0 a XML Schema 1.0. Vı́ce o generovánı́ map prostřednictvı́m XSLT
stylů viz [Ten2003], [Čer2006a], [Čer2007b].
Optimalizace procesu generovánı́ map
Zvolený postup – generovánı́ map ve formátu XML z XML dat pomocı́ stylů zapsaných v
XML s sebou přinášı́ následujı́cı́ výhody [Bar2007]:
ˆ Aplikace je sestavena výhradně z nekomerčnı́ho software. Uživatel může téměř všechny
finančnı́ prostředky použı́t na nákup kvalitnı́ch datových sad.
ˆ S XML soubory lze pracovat bez ohledu na použı́vané technologie, operačnı́ systém
nebo softwarové vybavenı́. Uživatelé XML majı́ k dispozici velké množstvı́ nejrůznějšı́ho
software – editory, parsery (programy pro kontrolu XML syntaxe), validátory, prohlı́žeče,
XSLT procesory (prostředky pro práci se stylovými jazyky), konvertory a dalšı́. Velký
podı́l mezi XML software majı́ programy šı́řené pomocı́ nějaké otevřené licence.
ˆ XML je velice rozšı́řenou technologiı́ – na internetu se nacházı́ obrovské množstvı́ informacı́ ve formě článků, přı́spěvků z odborných konferencı́, tutoriálů, mailových konferencı́ apod. Napřı́klad téměř jedna čtvrtina všech přı́spěvků na konferenci SVG Open
2005 v nizozemském Eshende byla věnována geografickým informačnı́m technologiı́m,
předevšı́m tvorbě map.
ˆ Pomocı́ stylových a transformačnı́ch jazyků docházı́ k oddělenı́ obsahu dokumentu
od vizualizačnı́ch pravidel. Proto lze XML dokumenty velice snadno přizpůsobovat
konkrétnı́m potřebám uživatele. Na druhou stranu použı́vánı́ stylů s sebou přinášı́ jednotný vzhled všech dokumentů s možnostı́ jednoduché a předevšı́m rychlé aktualizace.
ˆ Za celou aplikacı́ stojı́ pouze jediná technologie. Navı́c technologie, která se velice rychle
vyvı́jı́, ale je podporovaná (v různé mı́ře) většinou světových výrobců software.
Při vlastnı́ tvorbě map docházelo k řadě chyb, které byly způsobeny předevšı́m nezkušenostı́
s projekty obdobného rozsahu a tématického zaměřenı́ (za upozorněnı́ na chyby a postřehy v
Geinformatics FCE CTU 2007
104
Optimalizace procesu generovánı́ map pomocı́ XML
průběhu tvorby map i po vydánı́ publikace je zapotřebı́ poděkovat celému autorskému kolektivu, dále předevšı́m Ing. Jánu Pravdovi, DrSc. a také Prof. RNDr. Vı́tu Voženı́lekovi, CSc.,
Doc. RNDr. Jaromı́ru Kaňokovi, CSc. a Mgr. Monice Čechurové, PhD.). Navrhované změny,
které částečně eliminujı́ zjištěné nedostatky, můžeme rozdělit do pěti základnı́ch skupin:
1. Popis generovaných map.
2. Optimalizace vstupnı́ch dat.
3. Optimalizace transformačnı́ch šablon.
4. Odstraněnı́ kartografických nedostatků.
5. Zlepšenı́ datového a komunikačnı́ho toku.
Popis generovaných map
V současné době prudce narůstá počet geoprostorových dat, včetně kartografických výstupů.
Proto je nutné vytvářet podrobné a standardizované popisy veškerých datových souborů.
Tentýž problém řešı́ také směrnice INSPIRE (INfrastructure for SPatial InfoRmation in Europe), jejı́mž jednı́m úkolem je prosazenı́ použı́vánı́ metadat. Metadatový popis je důležitý
nejen z legislativnı́ho hlediska, ale také z pohledu sémantického webu, kdy metadatové záznamy
umožnı́ efektivnějšı́ vyhledávánı́ a použı́vánı́ nejrůznějšı́ch katalogových služeb.
Pro přı́pad vytvořenı́ elektronické verze atlasu nebo aktualizacı́ tištěné verze atlasu v digitálnı́ formě bude nutné doplnit generované mapy metadatovými záznamy. Obsah metadat
by se měl řı́dit mezinárodnı́ normou ISO 19115 a směrnicı́ INSPIRE. Z hlediska formátu je
důležitá jeho otevřenost a standardizace – jako nejvhodnějšı́ se jevı́ formát na bázi XML
DCMI (Dublin Core Metadata Initiative). Zařazenı́ XML metadatového formátu umožnı́ generovánı́ některých metadatových záznamů pomocı́ XSLT přı́mo z popisu map (např. název
mapy). Dalšı́ možnostı́ je vloženı́ metadatových záznamů ve formátu DCMI přı́mo do popisu
mapy (soubor atlas.xml) pomocı́ XML Namespaces.
Metadatový popis by měl být připojen nejen k jednotlivým mapám, ale také k vytvořeným
šablonám, popisným souborům, schématům, stylům nebo webovým stránkám, které jsou
nedı́lnou součástı́ celého projektu.
Optimalizace vstupnı́ch dat
Vstupnı́ datové vrstvy byly převzaty z datových sad distribuovaných společnostı́ ESRI. Data
obsahovala drobné chyby z hlediska obsahu, napřı́klad Španělsko přiřazené do Afriky nebo
chybějı́cı́ zakreslenı́ státu Vatikán. Vzhledem ke stářı́ dat bylo zapotřebı́ také doplněnı́ nového
státnı́ho celku – Východnı́ Timor, a změn atributů u některých zemı́ (napřı́klad přejmenovánı́
státu Zair na Kongo).
Vzhledem k rozsahu dat a redundantnı́ podrobnosti by bylo vhodné před vlastnı́m zpracovánı́m data generalizovat. Jedná se předevšı́m o zjednodušenı́ obrysů kontinentů (pro potřeby
Geinformatics FCE CTU 2007
105
Optimalizace procesu generovánı́ map pomocı́ XML
atlasu byla data velice podrobná) a spojenı́ některých jednoduchých liniı́ do řetězce liniı́. Jedinou formou generalizace aplikovanou na vstupnı́ data bylo odstraněnı́ nadbytečných atributů
(např. kódy měn apod.).
Dalšı́ změnou, která byla nezbytná z pohledu procesu transformace dat do kartografického
výstupu, bylo převedenı́ původnı́ch dat z formátu Shapefile do formátu JUMP GML. Tato
změna znamenala nárůst objemu dat o vı́ce než 400%.
Mezi vstupnı́ data se také zdrojový dokument atlas.xml, který obsahuje popis jednotlivých
map a dalšı́ch použitých nástrojů, napřı́klad kartografických barevných stupnic. Základnı́m
vylepšenı́m tohoto souboru je vytvořenı́ schématu, které bude popisovat jednotlivé prvky
dokumentu, jejich vzájemné vazby a přı́padná omezenı́ nebo tzv. business rules“. Schéma
”
by mělo sloužit také ke kontrole a validaci zdrojového souboru a zároveň by mělo zajistit
přenositelnost tohoto základnı́ho stavebnı́ho prvku aplikace do jiných projektů a přı́padná
rozšı́řenı́. Tento schémový soubor by mohl být součástı́ širšı́ho schématu jazyka popisujı́cı́
mapy a jiné kartografické produkty. Součástı́ schématu by mohly být vazby na již existujı́cı́
XML deriváty zabývajı́cı́ se geografickými daty (metadatový popis, jazyk definujı́ diagramové
prvky mapy apod.). Jako v současnosti nejvhodnějšı́ schémový jazyk se jevı́ RELAX NG
doplněný o datové typy použı́vané v jazyku W3C XML Schema a některé konstrukce jazyka
Schematron.
Optimalizace transformačnı́ch šablon
Dalšı́ vylepšenı́ se týká také transformačnı́ch šablon, které sloužily k převáděnı́ vstupnı́ch souborů prostorových dat na digitálnı́ mapy publikované v Atlasu mezinárodnı́ch vztahů. Optimalizace šablon spočı́vá jednak ve zkrácenı́ kódu (odstraněnı́ nadbytečných prvků, modularizace,
sestavovánı́ jednotlivých interpretačnı́ch kartografických metod jako sekvenci základnı́ch modulů) a také v implementaci všech nových prvků jazyků XSLT 2.0 a XPath 2.0. Z pohledu
aplikace transformačnı́ch a dotazovacı́ch jazyků založených na bázi XML do kartografie jsou
důležité zejména následujı́cı́ vlastnosti obou výše uvedených jazyků:
ˆ Pro digitálnı́ kartografii (předevšı́m pro generovánı́ map) je výhodná práce sekvencemi
a textovými řetězci, které mohou představovat seznamy souřadnic (např. ve formátu
GML nebo SVG). Otázkou je rychlost transformačnı́ch procesorů, které jsou většinou
napsány v Javě, při zpracovánı́ takového objemu dat, který je v oblasti geoinformačnı́ch
technologiı́ běžný.
ˆ Prohledávánı́ a rozřazovánı́ rozsáhlých dokumentů obsahujı́cı́ prostorová data s velkým
počtem atributů zjednodušı́ a zřejmě také zrychlı́ použı́vánı́ klı́čů a možnost seskupovánı́
dat na základě zadaného výrazu (velice jednoduše se budou napřı́klad řadit obce na
základě přı́slušnosti k obci s rozšı́řenou působnostı́).
ˆ XSLT 2.0 integrovala řadu funkcı́ EXSLT, které jsou při tvorbě digitálnı́ch map nezbytné. Napřı́klad se jedná o matematické funkce (součet, průměr, maximum, minimum) použı́vané při tvorbě grafů a diagramů při generovánı́ kartodiagramů nebo při
generovánı́ intervalů stupnic při generovánı́ kartogramů.
ˆ Práce s datovými typy XML Schema, které jsou přebı́rány i do dalšı́ch aplikacı́ (např.
jazyky RELAX NG, OWL) je důležitá z hlediska tvorby obecného sémantického doku-
Geinformatics FCE CTU 2007
106
Optimalizace procesu generovánı́ map pomocı́ XML
mentu a také snažšı́ kontrole správnosti dokumentu (zabránı́ se tak napřı́klad použı́vanı́
textových řetězů mı́sto čı́sel apod.).
ˆ Práce s regulárnı́mi výrazy patřı́ mezi dalšı́ výhody druhé verze XSLT. Napřı́klad v SVG
souborech půjde odstranit vysoké hodnoty jednotlivých souřadnic (dojde ke zmenšenı́
velikosti souborů), odřı́znutá“ hodnota bude do souboru vrácena pouze jednou ve formě
”
translačnı́ transformace.
ˆ XSLT zásadně změnilo charakter. Od stylového jazyku (jakési dokonalejšı́ verze kaskádových stylů) se posouvá spı́še do oblasti programovacı́ch jazyků, o čemž svědčı́ doplněnı́
a zdokonalenı́ práce s funkcemi, podmı́něné výrazy apod. [Nič2005]
Vyššı́ úrovni optimalizace bránı́ nı́zká úroveň implementace XSLT 2.0 a XPath 2.0 (stejný
problém majı́ i jiné XML technologie jako napřı́klad SVG) v různých nástrojı́ch. Výjimku
tvořı́ XSLT procesor Saxon použı́vaný pro generovánı́ map atlasu.
V budoucnosti (v přı́padě dalšı́ho využı́vánı́ transformačnı́ch stylů) by měly být do transformačnı́ho stylu doplněny dalšı́ šablony pro generovánı́ dalšı́ch kartografických interpretačnı́ch
metod (různé typy kartogramů nebo kartodiagramů) a pro analýzu dat (tvorba stupnic, grafy
četnosti...). V souvislosti s rozšı́řenı́m transformačnı́ho stylu bude dokument atlas.xsl modularizován (rozdělen na několik menšı́ch vzájemně propojených souborů).
Odstraněnı́ kartografických nedostatků
Kartografické nedostatky se projevujı́ předevšı́m dı́ky tzv. autorské slepotě“, dı́ky nı́ž tvůrcům
”
map uniknou některé dı́lčı́ nedostatky ve využı́vánı́ kartografických interpretačnı́ch metod. V
přı́padě Atlasu mezinárodnı́ch vztahů se jedná o
ˆ Volbu kartografického zobrazenı́, která byla determinována geodetickým pohledem“
”
na zobrazovanou problematiku. Jinými slovy při volbě kartografického zobrazenı́ byla
důležitá minimalizace zkreslenı́ a výsledná kompozice mapy před zvýrazněnı́m oblastı́,
které jsou z pohledu mezinárodnı́ch vztahů potřebné (např. rovnı́ková Afrika) – geo”
grafický pohled“.
ˆ Různé velikosti pı́sma použité na Politické mapě světa evokujı́ různý význam popisovaných objektů (států).
ˆ Otázky vyvolala také použitá terminologie. Vzhledem k poměru map a doprovodného
textu by mohla být publikace označena nikoli jako atlas, ale spı́še jako mapová encyklopedie.
Zlepšenı́ datového a komunikačnı́ho toku
Zlepšenı́ datového a komunikačnı́ho toku (např. Komunikace mezi členy autorského kolektivu,
verzovánı́ jednotlivých fázı́, forma, způsob a četnost zálohovánı́ apod.) patřı́ v současnosti
mezi aktuálnı́ problémy kartografie. Činnost kartografa by měla spočı́vat v řı́zenı́ a vedenı́
celého atlasového projektu a také v korigovánı́ autorské slepoty“ spolupracovnı́ků (tvůrců
”
dat, marketingových specialistů, designérů apod.).
Geinformatics FCE CTU 2007
107
Optimalizace procesu generovánı́ map pomocı́ XML
V našem konkrétnı́m přı́padě se ukázala jako velice problematická komunikace mezi jednotlivými členy rozsáhlého kolektivu autorů. Řešenı́m by mohlo být napřı́klad použitı́ softwaru
pro vedenı́ projektů (pro přı́klad uved’me produkt Microsoft Office Project 2007). V průběhu
pracı́ jsme se pokusili zavést alespoň online tvorbu a sdı́lenı́ dokumentů (docs.google.com),
což se však nakonec nesetkalo s patřičným ohlasem. Data byla předávána v různých formátech
(často se jednalo o texty ve formátu DOC nebo tabulky ve formátu XLS), které nemohly být
automaticky převáděny do formátu zpracovatelných prostřednictvı́m geoinformačnı́ch technologiı́.
V procesu generovánı́ map se vyskytujı́ i dalšı́ riziková mı́sta, která ovšem nejdou eliminovat změnou pracovnı́ho postupu. Změnu musı́ vyvolat předevšı́m výrobci podpůrného software. Mezi nejvýraznějšı́ nedostatky patřı́ slabšı́ podpora formátu SVG a rychlost zpracovánı́
velkého množstvı́ dat interpretačnı́m jazykem Java.
V atlasu nejsou využity veškeré možnosti vektorového formátu SVG. SVG napřı́klad umožňuje
velice elegantnı́ a jednoduché definovanı́ symbolů. Ty je možné zapsat pouze jednou a dalšı́
použitı́ těchto symbolů lze zajistit pomocı́ odkazů, který je zapsaný v jazyku XLink. U takového symbolu je možné nejen zadat souřadnice nového umı́stěnı́, ale novému” symbolu
”
lze přidat nové” atributy, napřı́klad transformaci (SVG umožňuje použı́vánı́ změny měřı́tka,
”
zkosenı́, posun a rotace) nebo jiný vizualizačnı́ styl. Bohužel ne každý software umožňuje regulérnı́ předávánı́ symbolů pomocı́ XLink odkazů (stejné typ odkazů ovšem funguje v přı́padě
barevných přechodů – gradientů). Proto bylo nutné veškeré symboly pomocı́ stylu a transformačnı́ho procesu do výsledné mapy kopı́rovat, čı́mž se zvláště v přı́padě složitých symbolů
zvětšila velikost výsledného souboru. Slabšı́ podporu ze strany výrobců software majı́ i dalšı́
vlastnosti formátu SVG jako napřı́klad animace, vzorky, ořezové cesty nebo podpora multimédiı́.
Jednı́m z dalšı́ch problémů byla rychlost aplikacı́ založených na interpretačnı́m jazyku Java.
V jazyce Java byly vytvořeny stěžejnı́ aplikace použı́vané pro zpracovánı́ map atlasu, jako
napřı́klad transformačnı́ procesor Saxon, GIS software pro zpracovánı́ dat OpenJUMP a grafický editor Inkscape – důvodem pro výběr těchto aplikacı́ byly předevšı́m multiplatformnost
a otevřenost. Tyto aplikace velice obtı́žně a pomalu zpracovávaly rozsáhlá data (průměrný
JML soubor – 14,5 MB, průměrný SVG soubor – 8,5 MB, průměrný PS soubor – 14 MB,
výsledná mapa ve formátu PDF – 1,9 MB).
Závěr
V České republice byla kartografická atlasová tvorba v nedávné minulosti poměrně opomı́jena.
Tento přı́spěvek shrnuje zkušenosti zı́skané během vı́ce než ročnı́ práce na Atlasu mezinárodnı́ch
vztahů. Navrhovaná zlepšenı́ lze rozdělit do dvou skupin:
1. Optimalizace týkajı́cı́ se použité technologie, která je svým způsobem specifická a navı́c
je stále ve vývoji.
2. Optimalizace standardnı́ch kartografických procesů (zı́skávánı́, hodnocenı́ a modifikace
vstupnı́ch dat, kartografické postupy, metody a použité prvky).
3. Zkvalitněnı́ komunikačnı́ch procesů v rámci autorského kolektivu.
Geinformatics FCE CTU 2007
108
Optimalizace procesu generovánı́ map pomocı́ XML
Použı́vánı́ webových technologiı́ při tvorbě atlasů je velice zajı́mavou technologiı́, která odpovı́dá současným aktuálnı́m trendům světové kartografie (ICA Research Agenda [Vir2007]).
Z tohoto důvodu by mohly navrhované optimalizačnı́ procesy sloužit jako podklad pro dalšı́
projekty podobného charakteru.
Seznam použitých zdrojů
1. [Bar2007] Baranová, M., Čada, V., Čerba, O. Kartografická část Atlasu mezinárodnı́ch
vztahů. In Kartografické listy 15. Bratislava: Kartografická spol’očnost’ Slovenskej republiky, Geografický ústav Slovenskej Akadémie vied, 2007, str. 5-12. ISBN 80-89060-10-8.
ISSN 1336-5274.
2. [Čer2006a] Čerba, O. Cartographic e-documents & SGML/XML. In International Symposium GIS. Ostrava 2006. Ostrava: Vysoká škola báňská – Technická univerzita, 2006.
Dostupné z:
3. [Čer2006b] Čerba, O. SVG v kartografii [online]. In Geoinformatics FCE CTU 2006.
Praha: 2006. ISSN 1802-2669. Dostupné z:
4. [Čer2007a] Čerba, O. Tvorba map pro Atlas mezinárodnı́ch vztahů. In 9. odborná
konference doktorského studia Juniorstav 2007. Brno: 2007. ISBN 978-80-214-3337-3.
5. [Čer2007b] Čerba, O. XML Technologies for Cartographers. In XXIII International
Cartographic Conference. Moskva : International Cartographic Association, 2007.
6. [Nič2005] Nič, M. XSLT 2.0 Tutorial [online]. 13.12.2005. Dostupné z:
7. [Ten2003] Tennakoon, W.T.M.S.B. Visualization of GML data using XSLT [online].
2003. Dostupné z:
8. [Vir2007] Virrantaus, Kirsi, Fairbairn, David. ICA Research Agenda in Cartography
and GI science [online]. In ICA News, Number 48, June 2007. International Cartographic
Association, 2007. Dostupné z:
9. [Wai2007] Waisová, Š.; Baranová, M.; Čada, V.; Čerba, O.; Jedlička, K.; Šanc, D.;
Weger, K.; Cabada, L.; Romancov, M. Atlas mezinárodnı́ch vztahů: prostor a politika
po skončenı́ studené války. 1. vyd. Plzeň: Aleš Čeněk, 2007. 158 s. ISBN 978-80-7380015-4.
Geinformatics FCE CTU 2007
109
Geinformatics FCE CTU 2007
110
Otevřený katastr - svobodné internetové
řešenı́ pro prohlı́ženı́ dat výměnného
formátu katastru nemovitostı́
Karel Jedlička
Department of Mathematics, Geomatics section,
Faculty of Applied sciences, University of West Bohemia,
smrcekZkma.zcu.cz,
Autor je podporován Výzkumným záměrem MŠM 4977751301.
Jan Ježek
Department of Mathematics, Geomatics section,
Faculty of Applied sciences, University of West Bohemia,
h.jezekZcentrum.cz.
Jiřı́ Petrák
jiripetrakZseznam.cz.
Klı́čová slova: Otevřený katastr, informace o parcele, list vlastnictvı́, VF ISKN, SPI, SGI,
PostGIS, UMN Map Server, Subversion.
Abstrakt
Otevřený katastr je projekt s cı́lem vytvořenı́ svobodného rozhranı́ pro přı́stup k datům katastru nemovitostı́. Jeho realizace spočı́vá v tvorbě několika nástrojů, které jsou šı́řeny pod
licencı́ GNU/GPL. Prvnı́ sada nástrojů umožňuje importovat data z Výměnného formátu katastru nemovitostı́ ČR (VF ISKN) do prostorové databáze PostGIS. Dalšı́ nástroje sloužı́ pro
publikaci dat katastru nemovitostı́ v prostředı́ internetu pomocı́ UMN MapServeru. Pro dalšı́
podporu vývoje nástrojů je připravováno nasazenı́ nástroje Subversion.
Úvod
Současná situace na ZČU
Oddělenı́ geomatiky na Západočeské univerzitě se dlouhodobě zabývá základnı́mi datovými
sadami, mezi které data katastru nemovitostı́ nepochybně patřı́. Kromě zde představovaného
Geinformatics FCE CTU 2007
111
Otevřený katastr - svobodné internetové řešenı́ pro prohlı́ženı́ dat
výměnného formátu katastru nemovitostı́
projektu pro Otevřený katastr též spolupracujeme s firmou ARCDATA Praha, s. r. o.1 na
testovánı́ jejich nástrojů po prohlı́ženı́ dat VF ISKN. Dále pracujeme na rozšı́řenı́ těchto
nástrojů o možnost spojenı́ importu SPI z VF ISKN a připojenı́ SGI z jiného externı́ho
zdroje.
Projekt Otevřený katastr
Otevřený katastr je projekt, který vycházı́ z bakalářské práce Novotného 2005 [4] a diplomových pracı́ Orálka 2006 [6] a Petráka 2007 [7] obhájených na Západočeské univerzitě, katedře matematiky, oddělenı́ geomatiky. Tento přı́spěvek navazuje na článek Jedličky a Orálka
2006 [2], který popisuje již realizovanou tvorbu nástrojů pro import dat výměnného formátu
katastru nemovitostı́ (VF ISKN – je popsán v ČÚZK 2007 [1] do prostorové databáze PostGIS
[8].
Vlastnı́ přı́spěvek je zaměřen na představenı́ nástrojů (vyvinutých pro UMN MapServer [9]),
které po grafické identifikaci parcely v souboru geodetických informacı́ (SGI) umožňujı́ vypsat
popisné informace ze souboru popisných informacı́ (SPI), konkrétně základnı́ informace o
parcele a list vlastnictvı́. Následně představuje nástroj pro správu zdrojových kódů Subversion
(SVN) [10], pod kterým je plánován dalšı́ vývoj obou výše zmiňovaných aplikacı́.
Výměnný formát ISKN – zdroj dat
Výměnný formát ISKN (VF ISKN, někdy též VFK) je stručně popsán v Petrákovi 2007 [7],
přı́padně v Jedlinském 2006 [3], který se danou problematikou, byt’ z jiného úhlu pohledu a v
jiném software také zabýval. Oficiálnı́ dokumentace VF ISKN je samozřejmě popsána v ČÚZK
2007 [1]. Důvodem, proč jsou uvedeny dalšı́ zdroje je to, že jsou bohatšı́ o názorné a vysvětlujı́cı́
modely stěžejnı́ch částı́ databáze. V této kapitole bude představena pouze nejnutnějšı́ část VF
ISKN, nutná k vysvětlenı́ datového pozadı́ vyvı́jených nástrojů (viz dalšı́ kapitoly).
VF ISKN je textový soubor, který se skládá z úvodnı́ch informacı́ obsažených v hlavičce
(obsah, rozsah a aktuálnost dat) a následně z datových bloků. Pojem datový blok odpovı́dá
pojmu tabulka v relačnı́ databázi. Dále pracuje s pojmem skupina datových bloků (či blok
(datových) bloků), což je již čistě virtuálnı́ seskupenı́ datových bloků (tabulek) majı́cı́ mezi
sebou nějaký vztah. Detailnı́ část dokumentace VF ISKN popisovaná v ČÚZK 2007 [1] je
členěná právě po těchto skupinách. V textovém souboru s daty VF ISKN (data.vfk) však
nejsou nijak obsaženy. Pro vybudovánı́ struktury prostorové databáze s informacemi o vlastnictvı́ v daném územı́ jsou důležité zejména skupiny datových bloků zobrazené na obr. 1.
Poznámka: ISKN a potažmo i výměnný formát obsahuje dalšı́ informace zejména o průbězı́ch
řı́zenı́ v katastru nemovitostı́, jejichž zpřı́stupňovánı́ nenı́ v současné době předmětem projektu
Otevřeného katastru, proto nejsou zmiňovány.
1
http://www.arcdata.cz
Geinformatics FCE CTU 2007
112
Otevřený katastr - svobodné internetové řešenı́ pro prohlı́ženı́ dat
výměnného formátu katastru nemovitostı́
Obr. 1: Skupiny datových bloků obsahujı́cı́ch data o geometrii digitálnı́ katastrálnı́ mapy
(SGI) a vlastnických vztazı́ch (SPI).
Nástroje pro Otevřený katastr
Import VF ISKN do PostGIS
V roce 2006 byl vyvinut nástroj pro import VF ISKN do PostGIS, který z importuje datové
bloky z VF ISKN do tabulek v prostorové databázi PostgreSQL a podle dokumentace ČÚZK
2007 [1] znovu buduje vybrané relačnı́ vztahy (obr. 2). Nástroj buduje pouze relace potřebné
k vybudovánı́ prostorové (konkrétně geometrické, nikoli topologické) reprezentace parcel a
budov.
Obr. 2: Vytvořené relace. Převzato z Orálka 2006 [6].
Dále z datových bloků obsažených ve skupině PKMP (konkrétně SOBR, SBP, SBM, HP, OB,
OP a DPM, vysvětlenı́ zkratek viz. předchozı́ kapitola) vytvářı́ prostorovou reprezentaci a
ukládá ji do prostorového rozšı́řenı́ PostGIS (viz obr. 3) podle specifikacı́ OGC2 .
”VF ISKN obsahuje bodová a liniová prostorová data. Souřadnice všech bodů polohopisu
(včetně lomových bodů liniových prvků) jsou uloženy v jediné tabulce – SOBR a s vlastnı́mi
2
http://www.opengeospatial.org
Geinformatics FCE CTU 2007
113
Otevřený katastr - svobodné internetové řešenı́ pro prohlı́ženı́ dat
výměnného formátu katastru nemovitostı́
Obr. 3: Budovánı́ prostorové reprezentace z datových bloků VF ISKN. Převzato z
Jedlinského 2006 [3].
prvky jsou svázány přes propojovacı́ tabulku SBP. Z obrázku 3 je patrné, že VF ISKN nepoužı́vá pro uloženı́ prostorových dat prostorové datové typy, ale jednoduché čı́selné datové
typy. Struktura jeho prostorové části je kvůli tomu složitějšı́, než v přı́padě způsobů běžných
v GIS. Souřadnice každého bodu polohopisných prvků ve VF ISKN jsou uloženy jen jednou.
Naproti tomu, souřadnice bodů nepolohopisných liniových prvků se v tabulce SBM opakujı́
tolikrát, na kolika liniı́ch bod ležı́. Stejně tak je v GIS obvyklé, že geometrie každého prvku je
uložena odděleně, tzn. souřadnice jednoho bodu jsou v databázi uloženy tolikrát, kolik prvků
na něm (svým lomovým bodem) ležı́, na přı́klad shoduje-li se obvod budovy s hranicemi stavebnı́ parcely. Když je potřeba přiřadit lomovým bodům polygonových nebo liniových prvků
atributy, tak jako v tabulce SOBR, musı́ se tyto body zkopı́rovat do samostatné bodové vrstvy
a atributy uložit tam, Jedlinský 2006 [3].”
Je nutno upozornit na to, že existujı́ různé verze VF ISKN, popisované pomocı́ dodatků v
dokumentu ČÚZK 2007 [1]. Popisovaný nástroj ve verzi z roku 2006 umožňuje importovat
data z VF ISKN verze 2.8.
Vizualizace katastrálnı́ch dat prostřednictvı́m mapového serveru
V roce 2007 pokračovaly práce na projektu zejména vývojem nástrojů pro výpis údajů ze souboru popisných informacı́ v návaznosti na objekt vybraný v souboru geodetických informacı́,
tedy vizualizovaný v mapovém okně. Nástroj nejdřı́ve poskytuje základnı́ popisné informace o
parcele (budově): Katastrálnı́ územı́, čı́slo parcely, čı́slo budovy, výměra, druh pozemku a čı́slo
listu vlastnictvı́. V dalšı́m kroku vypı́še informace v rozsahu veřejné části konkrétnı́ho listu
vlastnictvı́. Detailnı́ dokumentace vývoje této části projektu je podrobně popsána v Petrákovi
2007 [7], v tomto přı́spěvku budou dále nastı́něny hlavnı́ body.
Nejdřı́ve bylo nutné provést aktualizaci nástroje pro import dat z VF ISKN tak, aby dokázal
Geinformatics FCE CTU 2007
114
Otevřený katastr - svobodné internetové řešenı́ pro prohlı́ženı́ dat
výměnného formátu katastru nemovitostı́
importovat verzi 3 VFK, která byla mezitı́m vydána a popsána dodatkem v ČÚZK 2007 [1].
Hlavně ale bylo nutné importnı́ nástroj výrazně rozšı́řit tak, aby vybudoval i relace týkajı́cı́
se vlastnických vztahů. To se ukázalo jako klı́čová část práce, protože právě dokumentace
relacı́ je výraznou slabinou dokumentu (ČÚZK 2007 [1]), který VF ISKN popisuje. Za velký
přı́nos projektu lze považovat, že v rámci práce Petráka 2007 [7] vznikla dokumentace formou
ERA modelů, která jinak veřejně k dispozici nenı́ (firmy, které vyvı́jejı́ importnı́ nástroje pro
VFK ERA modely nepublikujı́, i když je nepochybně pro své účely také musely prozkoumat).
Jedná se zejména o podrobné datové modely skupin bloků NEMO (Nemovitosti), VLST
(Vlastnictvı́), Jiných právnı́ch vztahů (JPVZ), ale i vybraných tabulek skupiny Řı́zenı́ (RIZE)
a skupiny Bonitnı́ dı́ly parcel (BDPA). Dalšı́ datové modely potom zobrazujı́ přı́mo vztahy
mezi jednotlivými tabulkami nutné pro zı́skánı́ kompletnı́ch popisných informacı́ o konkrétnı́
parcele/budově – tj. pro výpis listu vlastnictvı́.
Na základě zmiňovaných ERA modelů byly následně napsány PHP skripty, které popisné
informace po prostorové identifikaci parcely (v SGI) vypisujı́ souvisejı́cı́ atributové informace
(SPI).
Poznámka: Jako technologické pozadı́ je využı́váno databáze PostgreSQL s prostorovým
rozšı́řenı́m PostGIS, UMN MapServeru pro serverovánı́ prostorových dat a jazyka PHP a
do něj vnořeného dotazovacı́ho jazyka SQL pro zı́skávánı́ a výpis atributových informacı́.
Jednotlivé technologie jsou podrobněji popsány v článku Jedličky a Orálka 2006 [2].
Otevřený vývoj
Jednı́m z důležitých aspektů obdobných projektů realizovaných na oddělenı́ Geomatiky je
také možnost jejich dalšı́ho vývoje v budoucnu a návaznost a spolupráce s dalšı́mi pracemi.
Cı́lem oddělenı́ je postupně budovat infrastrukturu zaměřenou na možnost kontinuálnı́ho a
otevřeného vývoje software od semestrálnı́ch projektů až po diplomové a disertačnı́ práce.
Nejvhodnějšı́ přı́stup pro naplněnı́ této skutečnosti představuje standardnı́ model většiny
Open Source projektů a použı́vánı́ s tı́m spojených nástrojů softwarového inženýrstvı́.
Základnı́ nástroje
ˆ Správa zdrojového kódu – Klı́čový nástroj pro vývoj každého software jsou produkty umožňujı́cı́ systematicky spravovat zdrojový kód. Pro tento účel existuje řada
komplexnı́ch systémů které umožňujı́ spravovat přı́stupová práva pro editaci, vytvářenı́
větvı́, sledovánı́ a historii změn v čase, ale předevšı́m přinášı́ možnost efektivnı́ spolupráce vı́ce programátorů na jednom projektu. Zdrojový kód popisovaného projektu
(stejně jako řada dalšı́ch pracı́) je spravován pomocı́ nástroje Subversion [10]. Tento
přı́stup jednak zjednodušuje samotný vývoj (pomocı́ verzovánı́), ale předevšı́m představuje platformu pro spolupráci širšı́ho kolektivu autorů.
ˆ WIKI – V blı́zké budoucnosti je plánováno také vytvořenı́ portálu (pomocı́ technologie
wiki), který bude určen pro rozvoj dokumentace k obdobným projektům řešeným na
oddělenı́ geomatiky, katedry matematiky, Západočeské univerzity v Plzni.
Úložiště zdrojového kódu popisovaného produktu je k dispozici na adrese:
http://mapserver.zcu.cz/svn/OtevrenyKatastr/
Geinformatics FCE CTU 2007
115
Otevřený katastr - svobodné internetové řešenı́ pro prohlı́ženı́ dat
výměnného formátu katastru nemovitostı́
Kód je publikován pod licencı́ GPL3 .
Závěr
Otevřený katastr je vyústěnı́m řady navazujı́cı́ch závěrečných pracı́, obhajovaných na oddělenı́
geomatiky, katedry matematiky, Západočeské univerzity v Plzni. V poslednı́m roce byl impulsem k dalšı́mu vývoji projektu zájem komerčnı́ firmy o nasazenı́ v praxi. Jeden z autorů
uvažuje o realizaci dodávek informačnı́ch systémů malým obcı́m tzv. na klı́č. Klı́čovou komponentou takových systémů se ukazuje právě aplikace, poskytujı́cı́ informace o datech katastru
nemovitostı́. Autoři uvı́tajı́, pokud i dalšı́ zájemci budou stavět na myšlence otevřeného katastru dál.
Použité zdroje
1. ČÚZK. Výměnný formát ISKN v textovém tvaru4 . [Cit. 18. 9. 2007].
2. JEDLIČKA, K.; ORÁLEK, J. Prostorové rozhranı́ informačnı́ho systému malé obce
řešené v Open Source Software5 . In Geoinformatics FCE CTU . Praha : ČVUT, 2006.
s. 129-143. ISSN 1802-2669.
3. JEDLINSKÝ, J. Způsoby uloženı́ prostorových dat v databázi pro účely pozemkového
datového modelu6 [diplomová práce]; ved. práce Karel Jedlička. – Plzeň : Západočeská
univerzita. Fakulta aplikovaných věd, 2006. – 58 s.
4. NOVOTNÝ, J. Informačnı́ systém malé obce7 [bakalářská práce]; ved. práce Otakar
Čerba. – Plzeň : Západočeská univerzita. Fakulta aplikovaných věd, 2005. – 56 s.
5. OGC. Open Geospatial Consortium, Inc8 . [Cit. 10. 10. 2007].
6. ORÁLEK, J. Možnosti využitı́ nekomerčnı́ho geografického software pro tvorbu prostorového rozhranı́ informačnı́ho systému malé obce9 [diplomová práce]; ved. práce Karel
Jedlička. – Plzeň : Západočeská univerzita. Fakulta aplikovaných věd, 2006. – 60 s.
7. PETRÁK, J. Open source mapový server pro data katastru nemovitostı́10 [diplomová
práce]; ved. práce Karel Jedlička. – Plzeň : Západočeská univerzita. Fakulta aplikovaných
věd, 2007. – 57 s.
3
http://www.gnu.org/copyleft/gpl.html
http://www.cuzk.cz/Dokument.aspx?PRARESKOD=10&MENUID=10283&AKCE=DOC:10-VF ISKNTEXT
5
http://geoinformatics.fsv.cvut.cz/wiki/index.php/Prostorov%C3%A9 rozhran%C3%AD in \
forma%C4%8Dn%C3%ADho syst%C3%A9mu mal%C3%A9 obce %C5%99e%C5%A1en \
%C3%A9 v Open Source Software
6
http://gis.zcu.cz/studium/dp/2006/Jedlinsky Zpusoby ulozeni prostorovych dat v \
databazi pro ucely pozemkoveho datoveho modelu DP.pdf
7
http://gis.zcu.cz/studium/ZaverecnePrace/2005/Novotny InformacniSystemMaleObce BP.pdf
8
http://www.opengeospatial.org
9
http://gis.zcu.cz/studium/ZaverecnePrace/2006/Oralek Moznosti vyuziti nekomercniho \
geografickeho software pro tvorbu prostoroveho rozhrani informacniho sy \
stemu male obce DP.pdf
10
http://gis.zcu.cz/studium/ZaverecnePrace/2007/Petrak Open source mapovy server p \
ro data KN DP.pdf
4
Geinformatics FCE CTU 2007
116
Otevřený katastr - svobodné internetové řešenı́ pro prohlı́ženı́ dat
výměnného formátu katastru nemovitostı́
8. PostGIS. PostGIS documentation11 . [Cit. 18. 9. 2007].
9. UMN MapServer. UMN MapServer documentation12 . [Cit. 18. 9. 2007].
10. Subversion. Subversion project home page13 . Open Source Software Engineering Tools.
[Cit. 18. 9. 2007].
11
http://postgis.refractions.net/documentation/
http://mapserver.gis.umn.edu/docs
13
http://subversion.tigris.org/
12
Geinformatics FCE CTU 2007
117
Geinformatics FCE CTU 2007
118
Ukázka možnosti využitı́ programu
OpenJUMP v SOA
Martin Prager
Institute of Geoinformatics
Faculty of Mining and Geology, VSB-TUO
E-mail: [email protected]
Klı́čová slova: Orechestration, chainging, web services, GeoWeb, JUMP, SOA
Abstrakt
Tento krátký článek by měl poukázat prostřednictvı́m vytvořené extenze na možnost širokého
uplatněnı́ open-source produktu OpenJUMP (dřı́ve JUMP) a jeho modularitu. A to konkrétně
v oblasti servisně orientované architektury (SOA) se zaměřenı́m na řetězenı́ webových služeb.
Úvod
Servisně orientovaná architektura (SOA) přitahuje zájem všech oblastı́ IT průmyslu. Poháněná
standardy jako XML, webové služby a SOAP, SOA rychle proniká do hlavnı́ch chodů aplikacı́
zásadnı́ch pro plněnı́ business operacı́. S rostoucı́m počtem dostupných služeb a nároky na
efektivnost a obtı́žnost řešených úloh si už mnohdy nevystačı́me pouze s výsledky (zdroji)
jednotlivých služeb, přı́padně s jejich statickým propojenı́m. Jsme nuceni začı́t služby řetězit
dynamicky. Spojovat je dle aktuálnı́ch potřeb, možnostı́ uživatele (finance, přesnost výsledků,
rychlost ap.). Existujı́ dvě úrovně řetězenı́ služeb, známé pod názvy orchestrace a choreografie
(zaměřena vı́ce globálně). Orchestrace a choreografie je spojena s některými standardy (BPEL,
WS-CDL, XLANG atd.) a organizacemi (OASIS, W3C, BPMI apod.) [4].
Extenze pro OpenJUMP
OpenJUMP API poskytuje programátorům přı́stup ke všem funkcı́m včetně I/O rozhranı́,
datovým sadám, vizualizaci a prostorovým operacı́m. Tato možnost z něj dělá vysoce modulárnı́ a rozšiřitelný produkt. Rozšı́řenı́ jsou zde realizována prostřednictvı́m zásuvných modulů. Tyto moduly, které jsou po startu Workbench“ nahrány, můžou mı́t podobu plu”
”
gin“ (položky menu), cursor tools“ (nástrojové tlačı́tka), renderers“ (způsoby vykreslovánı́
”
”
dat) a datasources“ (způsoby nahrávánı́ a ukládánı́ různých datových formátů) [3]. Ex”
tenze, kterou jsem nazval WSPlugin“ poskytuje uživateli GUI pro vytvářenı́ jednoduchých
”
Geinformatics FCE CTU 2007
119
Ukázka možnosti využitı́ programu OpenJUMP v SOA
sekvenčnı́ch řetězů webových služeb. Umožňuje přidávat služby typu WSDL, WMS (WMS
pouze na konec řetězu) jednotlivě, nebo hromadně s podporou vyhledávánı́ v katalogu WSCO
(http://gisak.vsb.cz/wsco/intranet/). Samotný řetěz poté vytvořı́ uživatel přesunutı́m jednotlivých metod (operacı́ Drag-and-Drop“) na pracovnı́ plochu. Obrázek 1 znázorňuje grafické
”
rozhranı́ pro propojovánı́ parametrů jednotlivých metod (aktivováno kliknutı́m na konkrétnı́
metodu). Parametry lze propojovat přı́mo, nebo je transformovat s využitı́m jazyka XSL, či
za pomocı́ XPath výrazů. Využitı́ XPath (viz http://www.w3.org) výrazů lze je patrné jak
na následujı́cı́m obrázku, tak v přiloženém ukázkovém BPEL procesu.
Obrázek 1: Grafické rozhranı́ pro nastavenı́ relacı́ mezi metodami [4]
Na obrázku 2 lze vpravo vidět spuštěnou extenzi s již vykonaným řetězem služeb, který vracı́
jako odpověd’ GML vrstvu. Tato vrstva je automaticky vizualizována v mapovém okně OpenJUMP. V přı́padě, že na konci řetězu stojı́ WMS služba, je zobrazena s následnou možnostı́
modifikace jejı́ch parametrů.
Obrázek 2: Spuštěná extenze v prostředı́ OpenJUMP [4]
Jak již bylo zmı́něno v úvodu, řetězenı́ služeb je spojeno se spoustou specifikacı́. Jazyk BPEL
se stal v poslednı́ch dvou letech významným standardem, vyzdvihujı́cı́m využitı́ SOA z IT
úrovně na obchodnı́ úroveň. Umožňuje organizacı́m automatizovánı́ jejich obchodnı́ch procesů,
prostřednictvı́m orchestrace služeb uvnitř i vně dané organizace [1]. Vyvinut firmami Microsoft a IBM, standardizován neprofitujı́cı́m konsorciem OASIS (http://docs.oasis-open.org).
Geinformatics FCE CTU 2007
120
Ukázka možnosti využitı́ programu OpenJUMP v SOA
Z toho důvodu byla do extenze zabudovaná podpora BPEL jazyka. V přı́padě, že by chtěl
uživatel daný řetěz služeb poskytovat širšı́ veřejnosti, má možnost ho exportovat (importovat pouze soubory exportované z extenze) jako proces do tohoto jazyka. Sloužı́ zde k tomu
jednoduchý průvodce, který umožňuje nastavit některé základnı́ parametry (název procesu,
metodu procesu, výběr relevantnı́ch vstupnı́ch parametrů ap.). Kromě těchto základnı́ch parametrů lze nastavit export přı́mo do formátu ActiveBPEL engine“ stroje (http://www.active”
endpoints.com/open-source-active-bpel-Intro.htm). BPEL proces se jevı́ navenek jako standardnı́ webová služba, kterou bychom mohli opětovně načı́st do extenze a propojit s dalšı́mi
službami, přı́padně procesy. Dále v extenzi lze nastavit některé vlastnosti prostředı́, pracovat s
projektem ap. Extenze v současnosti umožňuje grafický návrh sekvenčnı́ho řetězenı́ webových
služeb s podporou přı́mého zobrazovánı́ mapových výstupů. Na rozdı́l od všech ostatnı́ch produktů určených k řetězenı́ webových služeb, umožňuje do řetězu zařazovat kromě WSDL
služeb i služby WMS. BPEL jazyk je sice standard, ovšem s přenositelnostı́ procesu mezi
různými BPEL stroji je problém. Většinou každý z těchto strojů potřebuje k interpretaci
kromě standardnı́ch souborů BPEL jazyka ještě dalšı́ podpůrné soubory, které jsou bohužel
typické pro jednotlivé stroje. Jak je vidět prostředı́ OpenJUMP lze asi rozšı́řit o cokoliv. K
tomuto faktu značně přispı́vá velmi dobrá dokumentace programu a jeho široká komunita.
Základnı́ struktura BPEL procesu
<process...>
<partnerLinks.../>
<variables.../>
<correlationSets.../>
<faultHandlers.../>
<compensationHandler.../>
<eventHandlers.../>
activities
</process>
Význam jednotlivých elementů je následujı́cı́ [2]:
ˆ partnerLinks – zde jsou definovány služby, které proces využı́vá a poskytuje. Uvnitř
každého partnerLink musı́ být vymezena aspoň jedna z dvou možných rolı́. Roli samotného procesu určuje atribut myRole a naopak roli partnera atribut partnerRole;
ˆ variables – tato část specifikuje proměnné, které proces využı́vá. BPEL umožňuje deklarovat proměnné třemi způsoby: jako typ WSDL zprávy, jako typ XML Schema (jednoduchý nebo složený) a jako XML Schema element;
ˆ correlationSets – ještě před spuštěnı́m daného procesu docházı́ k vytvořenı́ jeho instance.
Význam tohoto elementu spočı́vá v tom, že zabezpečuje doručovánı́ přicházejı́cı́ch zpráv
odpovı́dajı́cı́m instancı́m procesů;
ˆ faultHandlers – jak už název sám o sobě řı́ká, tento element sloužı́ ke zpracovánı́
chyb, které nastanou při běhu procesu. Chyby mohou být vyvolány explicitně (pomocı́
elementu < throw >), nebo implicitně (jako např. výsledek chyby při volánı́ nějaké
partnerské služby). Naopak pro zachytávánı́ chyb je využı́ván element s odpovı́dajı́cı́m
jménem < catch >;
ˆ compensationHandler – tento element poskytuje možnost zpětného zotavenı́ z chyby v
specifikované oblasti. Jinými slovy pokusit se o jakési vyčistěnı́ a navrácenı́ se do stavu,
Geinformatics FCE CTU 2007
121
Ukázka možnosti využitı́ programu OpenJUMP v SOA
kde může proces po chybě pokračovat;
ˆ eventHandlers – sloužı́ k zachycenı́ událostı́. V BPEL jsou dva typy: přı́chozı́ zprávy
(korespondujı́ s WSDL operacemi) a alarmy (aktivovány po uživatelem zadaném čase).
V každém tomto elementu musı́ být obsažen aspoň jeden zmı́něny typ;
ˆ activities – struktura procesu pokračuje tzv. aktivitami (elementy), které už implementujı́ jeho samotný tok. Každý proces má jednu hlavnı́ aktivitu. BPEL obsahuje sadu
jednoduchých aktivit, které můžeme skládat a vytvářet tak aktivity složené (viz [2]).
Ukázkový BPEL proces
<?xml version="1.0" encoding="UTF-8"?>
<process xmlns:ns1="http://tonda.vsb.cz/gazeteer" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:ns2="http://postgis.vsb.cz/transform" xmlns:ns0="cz.vsb.jump.wsplugin"
xmlns="http://docs.oasis-open.org/wsbpel/2.0/process/executable"
targetNamespace="cz.vsb.jump.wsplugin.VodniPlochy"
exitOnStandardFault="yes" suppressJoinFailure="yes" name="VodniPlochy" >
<partnerLinks >
<partnerLink myRole="VodniPlochyRole" partnerLinkType="ns0:VodniPlochyPLT" name="VodniPlochyLink" />
<partnerLink partnerRole="gazeteerRole" partnerLinkType="ns0:gazeteerPLT" name="gazeteerLink" />
<partnerLink partnerRole="transformRole" partnerLinkType="ns0:transformPLT" name="transformLink" />
</partnerLinks>
<variables >
<variable name="getAreasRequest" messageType="ns0:getAreasRequest" />
<variable name="getAreasResponse" messageType="ns0:getAreasResponse" />
<variable name="getXY_0Request" messageType="ns1:getXYRequest" />
<variable name="getXY_0Response" messageType="ns1:getXYResponse" />
<variable name="xy2xy_1Request" messageType="ns2:xy2xyRequest" />
<variable name="xy2xy_1Response" messageType="ns2:xy2xyResponse" />
<variable name="getFeaturesGML_2Request" messageType="ns1:getFeaturesGMLRequest" />
<variable name="getFeaturesGML_2Response" messageType="ns1:getFeaturesGMLResponse" />
</variables>
<faultHandlers >
<catchAll >
<sequence >
<compensate name="ReverseCompletedTransactions" />
<assign name="GenerateFaultMessage" >
<copy >
<from >
<literal >An error occurred while submitting the order. All transactions have been canceled.</literal>
</from>
<to part="countries" variable="getAreasResponse" />
</copy>
</assign>
<reply variable="getAreasResponse" portType="ns0:VodniPlochyPT" name="SendError"
operation="getAreas" partnerLink="VodniPlochyLink" />
</sequence>
</catchAll>
</faultHandlers>
<sequence >
<receive createInstance="yes" variable="getAreasRequest" portType="ns0:VodniPlochyPT"
operation="getAreas" partnerLink="VodniPlochyLink" />
<assign >
<copy > <from >’obce32633’</from><to part="layer" variable="getXY_0Request" /> </copy>
<copy > <from >’nazob_a’</from> <to part="field" variable="getXY_0Request" /> </copy>
<copy > <from >$getAreasRequest.Obec</from> <to part="name" variable="getXY_0Request" /></copy>
</assign>
<invoke outputVariable="getXY_0Response" inputVariable="getXY_0Request" portType="ns1:gazeteerPort"
name="InvokegetXY" operation="getXY" partnerLink="gazeteerLink" />
<assign >
<copy > <from >substring-after(substring-before($getXY_0Response.xy,’ ’),’(’)</from>
Geinformatics FCE CTU 2007
122
Ukázka možnosti využitı́ programu OpenJUMP v SOA
<to part="x_coord" variable="xy2xy_1Request" /> </copy>
<copy > <from >substring-after(substring-before($getXY_0Response.xy,’)’),’ ’)</from>
<to part="y_coord" variable="xy2xy_1Request" /> </copy>
<copy ><from >’epsg:32633’</from> <to part="sourceCoordSys" variable="xy2xy_1Request" /> </copy>
<copy > <from >’esri:102065’</from> <to part="targetCoordSys" variable="xy2xy_1Request" /> </copy>
</assign>
<invoke outputVariable="xy2xy_1Response" inputVariable="xy2xy_1Request" portType="ns2:transformPort"
name="Invokexy2xy" operation="xy2xy" partnerLink="transformLink" />
<assign >
<copy > <from >substring-before($xy2xy_1Response.xy,’,’)</from>
<to part="longitude" variable="getFeaturesGML_2Request" /> </copy>
<copy ><from >substring-after($xy2xy_1Response.xy,’,’)</from>
<to part="latitude" variable="getFeaturesGML_2Request" /> </copy>
<copy > <from >$getAreasRequest.Vzdalenost</from>
<to part="distance" variable="getFeaturesGML_2Request" /> </copy>
<copy ><from >’voda’</from> <to part="layer" variable="getFeaturesGML_2Request" /> </copy>
<copy ><from >’nazev’</from> <to part="field" variable="getFeaturesGML_2Request" /> </copy>
</assign>
<invoke outputVariable="getFeaturesGML_2Response" inputVariable="getFeaturesGML_2Request"
portType="ns1:gazeteerPort" name="InvokegetFeaturesGML" operation="getFeaturesGML"
partnerLink="gazeteerLink" />
<assign >
<copy ><from >$getFeaturesGML_2Response.countries</from> <to part="countries"
variable="getAreasResponse" />
</copy>
</assign>
<reply variable="getAreasResponse" portType="ns0:VodniPlochyPT"
operation="getAreas" partnerLink="VodniPlochyLink" />
</sequence>
</process>
Použité zdroje
1. BLANVALVET, S; BOLIE, J; CARDELLA, M; CAREY, S; CHANDRAN, P; COENE,
Y; GEMINIUC, K; JURIČ, M; NGUYEN, H; PODUVAL, A; PRAVIN, L; THOMAS, J;
TODD, D. BPEL Cookbook: Best Practivec for SOA-based integration and composite
applications development. Birmingham: Packt Publishing Ltd., 2006. ISBN 1-90481133-7
2. OASIS. [online]. 2007. Dostupný na WWW: http://www.oasis-open.org
3. OpenJUMP. [online]. 2007. Dostupný na WWW: http://openjump.org
4. PRAGER, M. Řetězenı́ webových služeb v prostředı́ open source GIS. Diplomová práce.
2007. Ostrava. Dostupný na WWW:
http://gisak.vsb.cz/˜pra089/texty/DP pra089 v1 0.pdf
Geinformatics FCE CTU 2007
123