Geoinformatics FCE CTU
Transkript
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, ¢er) < 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