Ebben a posztban a nyílt forráskódú térinformatikai projektekről lesz szó, a teljesség igénye nélkül próbáltam összeszedni milyen, a világhlóra is alkalmas térinformatikai megoldások léteznek.

A nyílt forráskód elsőszámú gyűjtőhelye az OSGEO portálja, ahol Web Mapping Solutions néven található fél tucat használható alkalmazás.

OSGEO inkubátor alatt fejlesztett alkalmazások

deegree : Ez a projekt követi leginkább az OGC standardjait, felfoghatatlan számú standardot (WMS, WFS, WCS stb stb)  támogat, adatbázis alapja is lényegében bármi lehet: Esri shape, postgis, oracle spatialdb, ArcSDE, Mapinfo MIF, hogy csak a támogatott vektoros adatbázis kezelőket említsem. Két példa:  deegree1 deegree2

GeoServer: Az egyik leggyorsabban fejlődő web térkép szolgáltatás előállító. Java alapú, nagyon barátságos a kezelőfelülete, támogatja a főbb OGC standardokat (WFS 1.0, WMS 1.1.1, WCS 1.0). Lényegében bármilyen adatbázisból tud adatokat olvasni (Kipróáltam .shp, postgis adatbáziskezelőkkel nagyon jól együtt működik). Windows és unix környezetben is megy. És végül íme egy geoserver alapú megoldás.

Mapbender: Hasonlít a deegree-hez, támogatja a főbb OGC standardokat, csak a postgresql adatbáziskezelőre találtam támogatást, de ez biztos támogat mást is. Elvileg linux és windows alapon is elfut.   Példa

MapBuilder: Egy lassan véget érő projekt. Egy példát azért belinkelek

MapFish:  Ez egy pylon alapú fejlesztő környezet, ami több technológiát olvaszt magába. Ez például egy mapfish alapú fejlesztés. Meg ez is.

MapGuide: Az autodesk által fejlesztett komplex web-gis alkalmazás nyílt forráskódú verziója.  Íme egy példaoldal Nem vagyok meggyőződve, hogy ez a nyílt forráskódú verzió, de mindenesetre magyar fejlesztés, ezért mindenképpen link járt neki.  Linux alatt live cd-vel kipróbálható (az oldal alján találhatóak a linkek).  Támogatja a legtöbb adatbázisformátmot, és a főbb OGC standardokat. Linux és windows alatt is működik.

Mapserver: A legelterjedtebb web mapping megoldás, kiforrott, hatalmas dokumentációja van, támogat mindent, mindenféle standardot, adatbázist, hatalmas közösség áll mögötte. Már készülőben van egy poszt a feltelepítséről, használatáról ezért nem írok itt többet róla.  Egy magyar példa.

OpenLayers: Ez egy javascript könyvtár, a térkép böngészőben való megjelenítéséért felelős. Összeépíthető a MapGuide-al, MapServerrel, GeoServerrel, megjeleníthető vele a Google, a Bing, a Yahoo maps stb.  Fontos, hogy ez az előbbiekkel ellentétben ez egy kliens oldali megoldás (ezért pl ESRI shp, vagy postgis közvetlenül nem kapcsolható össze vele).

Egyéb projektek

Cartoweb:  A MapFishhez is közel álló CampToCamp fejlesztette mapserver alapú alkalmazás, deegree, Mapbender, MapGuide hoz hasonló összetett alkalmazás. Itt egy példa is.

PyWPS:  Ismét egy Osgeohoz közel álló projekt, a GRASS GIS térinformatikai programhoz fejlesztett webes alkalmazás. Azon ritka alkalmazások közé tartozik, ami támogatja az OGC WPS (Web Procress Service) szabványát. Itt egy vagány cseh és itt egy  hasonló szlovák példa.

Mapnik: Ez egy térkép renderelő program elsősorban, de létre lehet vele hozni wms szolgáltatást, ez az elsőszámú renderelő eszköz az OpenStreetMap-hoz. Windows és linux alatt is működik, olvassa az esri shp-t, és a postgist. Nagyon gyorsan fejlődik.

Geomajas: Java és javascript alapú web framework. Nagyon szép (kattints). Épp ennyit is tudok róla:(

Modest_map: Falsh alapú verziója az OpenLayersnek (hát kb)

Metacarta projektek

Eredetileg az OpenLayers is-t is e cég fejlesztette.

TileCache:  wms-c/tms standardokat használja térképek közzétételére. Például ezen a magyar oldalon, a II. katonai felmérés rétegét tilecache szolgáltatja.

Featureserver: Nem képeket, hanem vektoros állományokat lehet vele megosztani a weben. Nem csak http-n keresztül lehet közzétenni  vele adatokat (ezt jelenti azt hiszem, hogy RESTFUL). Sajnos nem támogatja a WFS standardot (Ha jól tudom).  Ezzel mostanában próbálkozom, szóval valószínű lesz róla majd egy poszt.

Még több projektet itt lehet keresni.

Néhány sor az adatbázisváltásról.

pg_dump -f kulcsdb -U balazs kulcsdb_dump

sudo /etc/init.d/postgresql-8.3 stop

sudo /etc/init.d/postgresql-8.4 start

psql -U balazs -f kulcsdb_dump

Következő történt: 8.3-as adatbáziskezelő kulcsdb adatbázisát dump fájlba tettem mindenféle séma, tulajdonos és egyéb beállításokkal együtt, ezután leállítottam a régebbi verziót, és elindítottam az újat (amin létezik már balazs nevű felhasznaló, be van állítva a postgis és megfelelően hangolva van a pg_hba fájl) és legvégül visszaállítom a régi állapotokat.

SRID az nem más mint a Spatial Reference IDentifier angol szavak mozaikja. Ez egy szám, ami azonosítja a térbeli adatok által használt koordináta rendszert. Van egy honlap ez http://spatialreference.org/ , amin összegyűjtötték az összes ilyen jelölést. A rövidítések haszna, hogy két szám megadásával egy megfelelő program (pl gdalwrap) könnyen átváltja az átalunk megadott térbeli adatállományt, egy a listán szereplő térbeli koordináta rendszerbe. Például HD72 EOV -ban (23700) lévő 45-121 EOTR térképlapot a WGS84 forgási ellipszidon meghatározott földrajzi koordináta rendszerbe (4326), így a HD72 és a WGS84 jelölések bármiféle megértése nélkül használhatóvá válnak a különböző vetületű, dátumozású, forgási ellipszoidú állományok. Ez a számozás jó két évtizede az European Petroleum Survey Group (www.epsg.hu) égisze alatt teljesedett ki egy listává, amin szereplő CRS-ek egymásba megfelelő pontosággal átválthatóak. A hagyomány miatt e kódokat ezért nagyon ritkán használják SRID elöljáróval, inkább mint "EPSG" kódok szerepelnek a hivatkozásokban. A CRS a coordinate reference system szavakból áll össze. A világhálón a CRS, PROJ4 format, SRID, EPSG code szavak alapján lehet hasznos találatokat szerezni e témában.
Több különböző CRS párhuzamos használatára vagy nemzeti sajátosság (például nálunk az EOV), vagy az elterjedt webes térképekhez való alkalmazkodás miatt van általában szükség.

Egy kis kitérő a web és a GOOGLE MAPS fele

A webes térképezés meghatározó szereplője a Google. A 256*256 pixel méretű képek egymás mellé illesztését ők hozták el a mindennapokba, amely technika a világhálón fellelhető térképeket mindmáig alapvetően meghatározza. Azért, hogy nem csupán a Google Maps létezik összeállítottam egy listát azokról az alkalmazásokról, amelyekkel térképeket jelenítenek meg az interneten

Faumaxion térkép, modest_map (flash) segítségével megjelenítve. A leírás itt található.

Openmaps java megjelenítője. turistautak.hu oldalon ugyanezzel (vagy ennek az adatbázisnak az alapjain talán) az adatbázissal még több megjelenítési példa is fellelhető.

Budapesti Műszaki Egyetem Felsőgeodéziai Tanszékének oldalán található gyűjtemény.

A google maps úgynevezett Spherical Mercatort használ () mint alapvetületet. Mivel minden esetben 256*256 pixeles négyzeteken jelenítenek meg térképi tartalmat, és mert az eredeti Mercátor vetület a sarkok felé a végtelenbe tart, így az egész világot átfogó nagyítási szinten (0) az egy darab 256*256 méretű csempe nem fedheti le az egész világot. A koordináta rendszerek kuszasága onnan kezdődik, hogy a Mercator vetület y tengelyének zérusa az egyenlítőnél van (kb az említett csempe kellős közepén), míg a csempéket megjelenítő algoritmus a bal felső sarokból indul ki, onnan ahol a levágás áthalad a képzeletbeli, végtelenbe tartó Mercator térképén. Amelyik térinformatikai alkalmazás igazodni akar ehhez nem használhatja az eredeti EPSG:3395 World Mercator CRS-t. A Google a Google Earth és a Google Maps közötti kompatibilitási okokból a térképein csak földrajzi koordinátákat használ (ami az EPSG:4326). Jelenleg a SRID listán két megoldás létezik arra a problémára, ha valaki egy Spherical Mercatorral megegyező vetületű térinformatikai alkalmazást akar létrehozni, ez az EPSG:3785, és az EPSG:900913 CRS-ek (31300 egységet kell kell az elöbbi északi koordinátájához adni, ennyi az eltérés a 900913-hoz képest) .

PROJ4 formáik:

+proj=merc +lon_0=0 +k=1 +x_0=0 +y_0=0 +ellps=WGS84 +datum=WGS84 +units=m +no_defs              
+proj=merc +lon_0=0 +k=1 +x_0=0 +y_0=0 +a=6378137 +b=6378137 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs

(Érdemes egy pillanatra belegondolni mekkorát kamillázhattak az EPSG listát összeállítók - akik MTA és hasonló komolyságú vonalon jegyezhetőek - hogy jött egy webes cég két kocka programozója, hogy há csináltak egy új koordináta rencert a webes térképeknek és há szeretnék, hogy ennek az legyen a kódja, hogy EPSG:900913. Tudják, mint a hogy a telefonba pötyögi be az ember, hogy google, 900913 ééértik ugye??).

Egy kis kitérés az EOV fele

Néha az SRID-k nem jók. Pl az EOV esetében:) Nem próbálom megérteni, csak jelzem, hogy nem jó. Sajnos elég kismiska vagyok, hogy kijavítsam, vagy, hogy kijavítsák ha szólok:/

gdalwarp -s_srs "+proj=somerc +lat_0=47.14439372222 +lon_0=19.048571778 +k_0=0.99993 +x_0=650000 +y_0=200000 +ellps=GRS67 +units=m +towgs84=52.684,-71.194,-13.975,-0.312,-0.1063,-0.3729,1.0191  +no_defs" -t_srs "+proj=longlat +datum=WGS84 +no_defs" 45-121.tiff 45-121_latlng.tiff

Ezt hasznaltam, ez átváltja földrajzi koordináta rendszerbe, és onnantól az EOV felejtős számomra.

Na még egy kis földrajzi koordináta

A földrajzi koordináta azért hasznos, mert Michal Migurski ezt írta, hogy ebből könnyű átváltani a programoknak, és mert a Google, a Bing, a  Yahoo maps és az OpenStreet Map is ezt küldi a szemünk elé.

Áttérve a POSTGIS-re

Az SRID beállítására eddig három esetben voltam rászorulva
-Új tábla létrehozásánál
-shp2psql használatánál
-És amikor nem álítottam be az shp2psql használatakor az SRID-t

Az SRID  lista alapvetően benne van a POSTGIS spatial_ref_sys táblájában, de az is előfordúlhat, hogy nincs, ilyenkor egy recordot kell beszúrni a táblába, az előbb már említett spatialreference.org oldalról átmásolva (van egy ilyen sora, hogy Postgis). SRID listát szerkeszthetjük is, illetve saját számot, saját koordináta rendszerrel is hozzáadhatunk megfelelő hozzáértéssel.

a) Létre kell hozni egy akármilyen postgresql táblát pl [ CREATE TABLE (nev var); ], majd 
AddGeometryColumn(<schema_name>,<table_name>,<column_name>,<srid>,<type>,<dimension>)
Mivel a séma név opcionális, és el is hagyható (ilyenkor a jelenleg használt séma kerül alkalmazásra), így a tábla név,  az oszlop név (általában 'the_geom') után kell megadni az SRID-t. Azok a térbeli adatok amelyek az egyes rekordokhoz tartoznak és a the_geom oszlopba kerülnek, azontúl a megadott SRID szerint lesznek értelmezve.

b) shp2psql esetében egy -s kapcsolót kell használni pl #shp2psql -s 4326 uthalozat.shp uthalozattable kulcsdb > uthalozat.sql (Ebben a példában egy olyan leíró fájlt hoz létre a shp2psql, ami egy adott adatbázisban (itt kulcsdb) fogja létrehozni az uthalozat táblát a megadott SRID szerinti CRS-ben.

c) Amikor kézzel, utólag kell beállítani az SRID-t az némileg problémásabb.
Lényegében ennek az oldalnak használom a leírását a megoldáshoz. Abban az esetben, amikor nincs beállítva az SRID, az a -1 értéket kapja alapból. Ezt az
SELECT SRID(the_geom) FROM uthalozat;
sql lekérdezéssel lehet ellenőrizni.
\d uthalozat parancs begépelése után alul található egy ilyen sor "enforce_srid_the_geom" , ami szerint az SRID "kényszerített" közvetlenül nem megváltoztatható. Tehát fel kell oldani ezt a kényszert, ezután be kell állítani az új SRID-t, majd visszaállítani a kényszert, és végül a postgis geometry_column táblájában is frissíteni kell a táblához tartozó SRID-t:

ALTER TABLE uthalozat DROP CONSTRAINT enforce_srid_the_geom RESTRICT;
UPDATE uthalozat SET the_geom = ST_SetSRID(the_geom, 4326);
ALTER TABLE uthalozat ADD CONSTRAINT enforce_srid_the_geom CHECK (SRID(the_geom)=4326);
UPDATE geometry_columns SET SRID=4326 WHERE f_table_name=’uthalozat’;

Ma voltam Székesfehérváron a levéltárban, úgyhogy végre megvannak Kulcs régi térképei is. Üröm az ürömben, hogy egy levéltárnak nem alapfelszereltsége a fénymásoló vagy a szkenner és hát digitalizálásról sem nagyon  hallani arrafelé. A fényképezés az egyetlen járható út ezért a digitalizálásra. Azért az szívfájdító, hogy egyes helyeken milliókat költenek a nyomtatók fénymásolók összeszámolására, míközben lassan elporladnak, vagy elkopnak a levéltári emlékeink:(

Következőek vannak meg:

T 249
Rácalmás (Fejér vármegye)
Jeszeniczei Jankovich Béla ráczalmási birtokának térképe
Müller János Gáspár mérnök, – (1861)
100 bécsi öl = 26 mm
89 x 145 cm
restaurált


U 38
Rácalmás (Fejér vármegye)
– (útvonalterv)
Rieder József, 1846
100 bécsi öl = 6,5 mm
64 x 55 cm
restaurálandó

U 48
Rácalmás (Fejér vármegye)
– (úrbéri térkép)
Potemkin Eugén, – (XIX. század közepe)
I–VI. szelvény (Tabelle 3.: 40 x 53 cm, Tabelle 5.: 58 x 79 cm, Tabelle 6.: 41 x 55 cm, Tabelle 9.: 40 x 54 cm, Tabelle 10.: 56 x 110 cm, Tabelle 11.: 43 x 60 cm)
restaurálandó