adatbázisok? Nem túl érdekes.
így gondolhatja egy átlagos személy, aki GIS-sel vagy adatvizualizációval dolgozik. Be kell vallanom, hogy az adatbázisok nem a legszexisebb dolog a világon (sajnálom a DBA-t), de ha azt állítja (vagy célozza), hogy komolyabb módon végezzen elemzéseket vagy vizualizációt (térbeli) adatokkal, akkor biztosan nem szabad figyelmen kívül hagynia őket. Remélem, hogy ez a blogbejegyzés képet ad arról, hogy milyen előnyökkel járhat a térbeli adatbázisok hatékony használata.
Hype kifejezések jönnek és mennek benne, és volt egy nagy hype körül big data még csak néhány évvel ezelőtt, de ez most lassan elhalványul. Nos, az adatok még mindig nagyok, és valójában nagyobbak, mint valaha. A fájlméretek növekednek, és az “adattudományban” és a földtudományokban az embereknek olyan adatokkal kell foglalkozniuk, amelyek könnyen gigabájt tartományban lehetnek. Minél nagyobb az adat, annál nagyobb figyelmet kell fordítanunk az adatok tárolására és elemzésére.
ez az, ahol egy adatbázis jön a képbe.
a szoftverfejlesztésben az adatbázisokkal való munka kötelező. De a számítástechnika más alterületein (például a GIS-ben) élő emberek számára az adatbázis előnyei nem mindig nyilvánvalóak. Természetesen az emberek hajlamosak a számukra legismertebb eszközöket használni, bár ez nem lenne a leghatékonyabb módszer a célok elérésére. De néha kilépve a kényelmi zónából valóban nagy előnyökkel járhat. Magam is lassan felismertem a térbeli SQL-ben rejlő lehetőségeket.
ez a blogbejegyzés elsősorban azoknak szól, akik térinformatikai adatokkal dolgoznak, de még nem érintették meg a PostGIS-t, vagy talán még nem is hallottak róla. Nem fogok átmenni a PostgreSQL/PostGIS telepítésén, hanem megpróbálok áttekintést adni arról, hogy mi az, és mire jó.
a munkafolyamat és a példák elsősorban a QGIS + PostGIS kombinációra összpontosítanak, de vegye figyelembe, hogy csak PostGIS-szel, saját kóddal vagy más GIS-kliensekkel is dolgozhat.
hozzászólás … mi?
már a GIS tanulmányaim során többször hallottam a ‘PostGIS a Postgres térbeli kiterjesztése’ kifejezést. Nem azt jelentette, hogy fogalmam sem volt, hogy ez mit jelent. Fogalmam sem volt, mi a Postgres, nemhogy egy térbeli kiterjesztés.
próbáljuk meg a lehető legegyszerűbben lefékezni.
néhányan utálhatnak engem ezért az összehasonlításért, de vállalom a kockázatot: ha még soha nem dolgozott adatbázisokkal, akkor az adatbázis-táblákat hatalmas Excel-lapoknak tekintheti. De egy hatalmas intelligens Excel lap, ahonnan egy milliszekundum alatt megtudhatja, hogy mi az érték a 433 285 sor harmadik oszlopában. Ahelyett, hogy a munkalapon belüli funkciókat egyetlen cellába írná, az SQL parancsablakba írja őket. Tehát egy hely az adatok tárolására és ahonnan hatékonyan ki lehet venni.
PostGIS egy nyílt forráskódú, szabadon elérhető térbeli adatbázis extender a PostgreSQL adatbázis-kezelő rendszer (más néven DBMS). Tehát a PostgreSQL (más néven Postgres) az adatbázis, a PostGIS pedig olyan, mint egy kiegészítő az adatbázishoz. A PostGIS legújabb verziója most a PostgreSQL-hez van csomagolva.
dióhéjban a PostGIS olyan térbeli függvényeket ad hozzá a PostgreSQL-hez, mint a távolság, terület, Unió, metszéspont és speciális geometriai adattípusok.A térbeli adatbázisok az adatbázis bármely más objektumához hasonlóan tárolják és manipulálják a térbeli objektumokat.
tehát egy normál adatbázisban különböző típusú adatokat tárol (numerikus, szöveges, időbélyegek, képek…), és szükség esetén lekérdezheti (lekérheti), hogy válaszoljon az adatokkal kapcsolatos kérdésekre. A kérdések lehetnek ‘ hány ember jelentkezett be a webhelyére ‘vagy’hány tranzakció történt egy online áruházban’. A térbeli függvények ehelyett olyan kérdésekre válaszolhatnak, mint ‘milyen közel van a legközelebbi bolt’, ‘ez a pont ezen a területen belül’ vagy ‘mekkora ez az ország’.
tehát az adatokat sorokban és oszlopokban tárolja. Mivel a PostGIS egy térbeli adatbázis, az adatoknak van egy geometriai oszlopa is, amely egy adott koordinátarendszer adatait tartalmazza, amelyet a térbeli referencia-azonosító (srid) határoz meg. De ne feledje, hogy bár a PostGIS-t elsősorban téradatokhoz használná, ott nem térbeli adatokat is tárolhat, mivel még mindig rendelkezik egy normál PostgreSQL adatbázis összes funkciójával!
a kiváló határtalan PostGIS intro három alapvető fogalmat vezet be, amelyek a téradatokat egy adatbázishoz társítják. Ezek kombinációja rugalmas struktúrát biztosít az optimalizált teljesítmény és elemzés érdekében.
- Téradattípusok, például pont, vonal és sokszög. A legtöbb téradattal dolgozó ismerős;
- a többdimenziós térbeli indexelést a térbeli műveletek hatékony feldolgozására használják;
- az SQL-ben feltett térbeli függvények a térbeli tulajdonságok és kapcsolatok lekérdezésére szolgálnak.
az SQL vagy “strukturált lekérdezési nyelv” a relációs adatbázisok kérdéseinek és adatainak frissítésének eszköze. A select lekérdezés (amelyet a kérdések feltevésére használ) általában a következő formátumú parancs
SELECT some_columns FROM some_data_source WHERE some_condition;
a PostGIS-specifikus függvények általában ST_functionName formában vannak.
ezeket a parancsokat az adatbázisba vagy az adatbázis GUI eszközébe (például pgAdmin vagy QGIS DB Manager) való bejelentkezés után írja be a parancssorba. Tehát igen, az SQL megköveteli, hogy valóban írjon valamit. A jobb egérgombbal való kattintás általában alulértékelt lehet, de annak, aki nem ír kódot, az SQL jó első lépés a saját parancsok, esetleg későbbi kód megírásához.
a PostGIS mellett más térbeli adatbázisok is vannak. Az SQL Server Spatial, az ESRI ArcSDE, az Oracle Spatial és a GeoMesa néhány további lehetőség a térbeli adatok kezelésére és elemzésére. De a PostGIS állítólag több funkcióval és általában jobb teljesítménnyel rendelkezik. A többi említett (a GeoMesa kivételével) nem nyílt forráskódú.
ha még nem ismeri ezt, most összezavarodhat: tehát ez egy olyan hely, ahol adatokat tárolhat, és összetett módon kell információt kapnia azáltal, hogy furcsa dolgokat ír a parancssorba? Várd ki. Vannak olyan valódi előnyök is, amelyeket a PostGIS kínálhat Önnek, ha valóban elkötelezi magát.
megkérdeztem néhány ötletet a Twitter blogbejegyzéséhez, és sok jó visszajelzést kaptam. Innen jött az ötlet, hogy ezt két részre osztom. Az első részben megvizsgálom azokat az előnyöket, amelyeket a PostGIS hozhat a mindennapi munkájában. A második részben inkább a térbeli SQL-re fogok összpontosítani.
a PostGIS lehetővé teszi, hogy új munkamódszert fogadjon el. Ez az új módszer könnyebben reprodukálható, könnyebben elkezdheti használni a verziókezelést, és lehetővé teszi a többfelhasználós munkafolyamatokat.
a fájlok olvasásához és írásához gyakran speciális szoftverre van szükség. Az SQL egy absztrakció a véletlenszerű adatokhoz való hozzáféréshez és elemzéshez. Az absztrakció nélkül vagy egy speciális szoftverre lesz szüksége a műveletek elvégzéséhez, vagy magának kell megírnia az összes hozzáférési és elemzési kódot.
ha az elemzést SQL-ben végzi, ahelyett, hogy véletlenszerű műveleteket végezne a fájlokhoz véletlenszerű eszközökkel, véletlenszerű paraméterekkel, lehetővé teszi az eredmények könnyebb megosztását és reprodukálását. Lehet, hogy van egy” master Shapefile ” jelenleg valahol, ahol több térbeli illesztést és klip műveletet hajtott végre egy Shapefile-hez, hogy ez olyan legyen, mint amilyennek lennie kell. Mi van, ha ez eltűnik?
Johnnie jó példát írt a Twitteren arról, hogy véletlenül törölte az összes adatait, de minimális erőfeszítéssel képes volt reprodukálni őket a GIT-be mentett SQL szkriptekkel.
a szoftverfejlesztéssel foglalkozó emberek valószínűleg (vagy remélhetőleg) ismerik a verziókezelést. Nem fogok mélyebben belemenni ebbe a blogbejegyzésbe, de képes (és kell) az SQL szkripteket egy verziókezelő rendszerben, mint például a GIT. Gondolj rá úgy, mint egy szakácskönyvre, amelyet a könyvespolcon tartasz, és folyamatosan frissítesz, hogy mindig megtaláld a legjobb recepteket az ízletes adatelemzéshez. Csak azt, hogy újra megvásárolhatja ennek a pontos szakácskönyvnek az új példányát az Amazon-tól, ha háza leég.
az adatbázis segíthet a téradatok jobb rendben tartásában is. Egyikünk sem igazán tökéletes, és valószínűleg továbbra is olyan táblákat hoz létre, mint a temp_1, a final_final, de az adatbázis még mindig jobb lehetőséget kínál az adatstruktúra szabványosítására, mint a fájlok (például a táblázatok adattípusainak szabványosításával).
és mi a helyzet azokkal a nagy adatkészletekkel? A nagy adatkészletekkel rendelkező térbeli adatbázis lehetővé válik. Nem csak könnyebb, de néha szinte lehetetlen nagyobb adatkészleteken dolgozni adatbázis nélkül. Próbáltál már megnyitni 2 gb csv fájlt? Vagy megpróbált némi geoprocessing egy 800 mb GeoJSON? Tudta egyáltalán, hogy a Shapefiles-nek van méretkorlátja? Természetesen kezelheti ezeket a problémákat Geopackage vagy más fájlformátumok használatával, de általában a PostGIS az optimális eszköz a nagy (térinformatikai) adatok kezelésére.
az adatbázisok egyik nagyon szép tulajdonsága, hogy könnyebben automatizálhatja azokat a folyamatokat, amelyeket általában manuálisan végez. Például a PostgreSQL NOTIFY funkció használatával automatikusan frissítheti a QGIS térképeket. Akkor is, ha dolgozik ETL eszközök (például FME), hogy automatizálják a munkát, olvasás/írás/a PostGIS táblák sokkal könnyebb, mint a fájlokat.
ha nem vagy olyan, mint én (jelenleg ezt a dolgot egyedül és szórakozásból csinálom), akkor lehet, hogy van egy dolog, amit csapatnak hívnak. Más néven munkatársak. Lehet, hogy ugyanazokhoz az adatokhoz kell hozzáférniük, mint te. Az adatbázis használata a munkafolyamatban lehetővé teszi a párhuzamos munkát teljesen más szinten, mint a megosztott meghajtón lévő fájlok.
ennek egyik fő oka az, hogy az egyidejű felhasználók korrupciót okozhatnak. Bár lehetséges, hogy írjon extra kódot annak biztosítására, hogy több írást ugyanabba a fájlba nem korrupt az adatokat, mire megoldotta a problémát, és megoldotta a kapcsolódó teljesítmény probléma, akkor már írt a jobb része egy adatbázis-rendszer.
természetesen mind az előnyök, mind a hátrányok vannak az új munkafolyamat elfogadásában. Csakúgy, mint a fájlok rendben tartása, a nap végén az adatbázis fenntartása is sok munka lehet. Például a PostGIS frissítése új verzióra valódi fájdalom lehet, amint arra a Twitteren rámutattak. A nagy hatalom nagy felelősséggel jár.
de beszéljünk többet arról a hatalmi részről.
2.rész: a spatial SQL varázslatos világa
A Spatial SQL valóban felgyorsíthatja a feldolgozást (ha okosan használják). Az alábbiakban összehasonlítjuk ugyanazt a folyamatot a Shapefile és a QGIS feldolgozással, majd a PostGIS-ben a ST_GeneratePoints segítségével.
ehhez az összehasonlításhoz Finnországból származó irányítószám-adatokat és az egyes irányítószám-területek sokaságát találtam. Ez volt mind a Shapefile, mind a táblázat a helyi adatbázisban. Minden sokszögen belül véletlenszerű pontokat hoztam létre a populáció ábrázolására. A QGIS feldolgozást (véletlenszerű pontok a sokszög belsejében a Vektorfeldolgozásból) használtam a Shapefile-hez, a PostGIS-ben pedig az SQL valóban ilyen egyszerű volt:
SELECT ST_GeneratePoints(geom, he_vakiy) from paavo.paavo
mint látható a grafikonon korábban, tartott PostGIS kevesebb, mint 10% – a az idő, hogy ugyanazt az elemzést, mint a QGIS és a Shapefile. Ha GIS elemző vagy, és minden nap ilyen folyamatokat végez, ez egy év alatt elég sok időt takaríthat meg.
a gyorsabb feldolgozás mellett élvezheti a PostGIS által kínált térbeli funkciók széles választékát. Az, hogy mely funkciók a leghasznosabbak az Ön számára, teljesen a használati esettől függ. A Voronoi analízis és a hagyományosabb térinformatikai analízis mellett (puffer, overlay, intersect, clip stb..) meg tudod csinálni fejlettebb dolgokat:
- útvonal. A pgRouting és az útadatok segítségével megtalálhatja az optimális útvonalakat és különböző hálózati elemzéseket végezhet;
- sokszög skeletonizálás. Ez a funkció lehetővé teszi a sokszög mediális tengelyének felépítését menet közben;
- Geometriai felosztás. A geometriák további feldolgozásra való felosztása jelentősen felgyorsíthatja a folyamatokat;
- klaszterezés. Keressen fürtöket és mintákat az adataiból. Az AI hype csúcsán, a k-means egyesek számára még érdekesebb lehet, mint korábban…
mire van szüksége olyan dolgoknak, mint a sokszög skeletonizálása? Lehet, hogy érvényes kérdés a legtöbb számára, de egyszer, amikor a térbeli elemzésnek szüksége van rá, rendkívül örülni fog, hogy valaki elvégezte helyetted a kemény munkát (=matematikát). A különböző térbeli funkciók kombinálása és a Postgres beépített funkcióinak használata lehetővé teszi, hogy fejlett térbeli elemzést végezzen az adatbázisban.
a bonyolult és érdekes kérdések (térbeli illesztések, aggregációk stb.), amelyek az SQL egy sorában kifejezhetők az adatbázisban, sok számítási teljesítményt igényelnek, és ez az, amit a PostGIS kínál. Ugyanazon kérdések megválaszolása saját kóddal, több száz sor speciális kódot igényelhet a fájlok elleni programozás során.
PostGIS a dataviz számára
a portfóliómban szereplő vizualizációk közül a PostGIS valamilyen szerepet játszott a vizualizációs folyamatban. Az én munkafolyamat leggyakrabban előre feldolgozni az adatokat, majd nem a tényleges megjelenítés QGIS.
lássunk egy példát az egyik ilyen folyamatra.
Animáció a vonatok és voronois fenti ad egy játékos példa a hatalom PostGIS. Volt néhány millió vonat GPS pont a helyi adatbázisban, és már létrehozott animációk a pontok csak mozog. De ki akartam próbálni, hogyan néz ki egy animáció Voronoi vonalakkal.
először is, mert volt több GPS pontot minden vonat percenként, azt akartam, hogy csoportosítani őket, hogy én lenne egy reprezentatív pont minden perc vonatonként. Először kézzel készítettem egy táblázatot a kapott pontokhoz. A következő lekérdezést írtam
INSERT INTO trains.voronoipoints
SELECT '2018–01–15 09:00:00' AS t,
geom
FROM (SELECT St_centroid(St_collect(geom)) AS geom,
trainno
FROM (SELECT geom,
trainno
FROM trains.week
WHERE time > '2018–01–15 09:00:00'
AND time < '2018–01–15 09:01:00') AS a
GROUP BY trainno) AS b
ha darabokra fékezzük a lekérdezést, láthatjuk a puzzle következő darabjait:
- láthatja az SQL lekérdezés néhány normál elemét (INSERT INTO, SELECT, AS, FROM, WHERE, and, GROUP BY)
- a geom, a trainno és az idő oszlopnevek a heti táblázatomban a trains nevű sémában
- az alkérdezés a visszaadja az összes GPS pontot, amelyet a kért időkereten belül nyomon követtek.
- mert én válassza ki az összes GPS pontok nyomon belül egy perc, lehet, hogy több pontot minden vonat. Csak egyet akartam, hogy a voronoi vonalak ésszerűbb legyen. Ezért használom az ST_Collect-et a pontok csoportosítására és egy többpontos geometria létrehozására. Az ST_Centroid a többpontos geometriát a centroidon található egyetlen pontra cseréli (B alkérdezés), és az adatokat vonatszámok szerint csoportosítja.
ahhoz, hogy ugyanazt a dolgot többször is megtehessem, volt egy egyszerű Python szkriptem, amely ugyanazt a lekérdezést hurkolta néhány százszor, ahol a kezdő és a befejező idők voltak a paraméterek. Miután minden percben sikeresen találtam egy reprezentatív pontot, csak a következő parancsot futtattam (11,5 másodperc alatt):
SELECT t, ST_VoronoiLines(geom) from trains.voronoipoints
ezután hozzáadtam az eredményt a QGIS-hez, és megjelenítettem a Time Manager segítségével. Lehet, hogy ez egy kicsit hacky módja az eredmény elérésének, és egy tapasztaltabb SQL felhasználó teljesen egyetlen SQL paranccsal tette meg, de még mindig nagyon elégedett vagyok az eredménnyel. Bár lehet, hogy értelmetlen.
végül elég egyszerű, de az eredmény úgy néz ki, mint a magasabb szintű matematika (és ez!), mivel minden kemény munkát a PostGIS végez. Azért is, mert vonatonként csak egy pontra tudtam elvégezni a Voronoi-elemzést, a feldolgozási idő csak másodperc volt több százezer pont esetében.
a lekérdezések feldolgozási ideje gyakran exponenciálisan növekszik az adatmennyiségek növekedésével. Ezért kell okosnak lennie a lekérdezésekkel.
alapszabály, hogy minél több adatot kell lekérnie egy lekérdezésnek, és minél több műveletet kell elvégeznie az adatbázisnak (rendezés, csoportosítás stb.), annál lassabb és ezáltal kevésbé hatékony. Egy hatékony SQL lekérdezés csak azokat a sorokat és oszlopokat tölti le, amelyekre valóban szüksége van. Az SQL úgy működhet, mint egy logikai puzzle, ahol valóban alaposan át kell gondolnia, mit szeretne elérni.
azt is meg kell jegyeznem, hogy a lekérdezések teljesítményének módosítása csúszós lejtő, és eltévedhet a végtelen optimalizálás világában. Nagyon fontos megtalálni az egyensúlyt az “optimális lekérdezés” és az optimális lekérdezés között. Különösen, ha nem egy millió felhasználó számára készít alkalmazást, néhány milliszekundum itt vagy ott valószínűleg nem fogja ringatni a hajóját.
Hogyan kezdjük el?
merem mondani, hogy a tanulás SQL még előnyösebb egy átlagos GIS felhasználó, mint a tanulás JavaScript, Python vagy R. SQL szintaxis csak kisebb változások az évek során, és SQL készségek nagyon jól átruházható.
megállapítottam, hogy az SQL tanulási görbéje nem igazán meredek az alapok elvégzéséhez, de eltarthat egy ideig, hogy valóban lássa, milyen előnyökkel járhat a térbeli elemzés. De azt javasoljuk, hogy legyen türelmes, és próbálja bonyolultabb analitika és célja a gyorsabb feldolgozás. Végül látni fogja a különbséget.
először, amikor az SQL alapjait tanulja, megtanulja, hogyan kell lekérdezni az adatokat egyetlen táblázatból olyan alapvető adatkiválasztási technikákkal, mint az Oszlopok kiválasztása, az eredményhalmaz rendezése és a sorok szűrése. Ezután megismerheti a speciális lekérdezéseket, például a több tábla összekapcsolását, a beállított műveletek használatát és az alkérdezés elkészítését. Végül megtudhatja, hogyan kezelheti az adatbázis-táblákat, például új tábla létrehozását vagy egy meglévő tábla szerkezetének módosítását.
de vannak olyan eszközök is, amelyek segítenek Önnek!
QGIS egy nagyszerű eszköz az úgynevezett DB Manager. Hasonló GUI-t kínál az adatbázisához, de sokkal tömörített módon és a QGIS-en belül. Módosíthatja és hozzáadhatja a táblákat, indexeket adhat hozzá, és sok alapvető műveletet elvégezhet jobb kattintható módon.
ellenőrizze a pgAdmin-t is, amely a PostgreSQL legnépszerűbb adminisztrációs és fejlesztési platformja. Számos módja van, hogy az adatokat a PostGIS (pl ogr2ogr, shp2pgsql). Általában azt javasoljuk, hogy próbálja ki a különböző eszközöket és módszereket dolgozik az adatokat.
néhány apró kísérletet végeztem a Python és a PostGIS kombinálásával. A Python (vagy R) és a PostGIS együttes használata valóban a következő szintre emelheti az adatfeldolgozást és az automatizálást. Csak ötvözi az alapvető script képességeit Python és csatlakozik PostGIS segítségével psycopg2 jó módja annak, hogy az induláshoz.
úgy érzi, hogy el akarja kezdeni a PostGIS használatát?
- csak töltse le a telepítőket, és telepítse a PostGIS-t a helyi gépére. Kövesse az oktatóanyagok utasításait;
- töltsön be néhány adatot oda. Kezdje egy Shapefile segítségével QGIS DB Manager vagy chech például ez a bemutató, hogyan lehet A természetes föld adatokat PostGIS;
- kezdj el játszani körül SQL. Kezdje az alapokkal (az adatok kiválasztása, szűrése és módosítása), és lassan látni fogja, hogy milyen előnyökkel járhat a munkafolyamat.
következtetések
ha a munkamódszer jelenleg nem hatékony, csak az eszközök cseréje nem teszi jobbá az eredményt, vagy a folyamat kevésbé fájdalmas. Meg kell változtatnia az adatkezeléssel kapcsolatos gondolkodásmódját. Az adatbázisok nem hatékony felhasználásának számos módja van. Bízz bennem, láttam őket, sőt kipróbáltam néhányat.
a dolgok megváltoztatása csak a változás kedvéért, nincs értelme. Ha a napi munka csak néhány pontot ábrázol a térképen hébe-hóba, akkor ezt a jövőben is megteheti a Shapefiles és a csv fájlokkal. Talán még hatékonyabb is lenne így.
de.
ha komoly térbeli elemzéseket szeretne végezni, automatizálni a folyamatokat, vagy bármilyen módon áthelyezni a spatal adatokkal való munka módját a következő szintre, erősen ajánlom, hogy ismerkedjen meg a PostGIS-szel, különösen a spatial SQL-vel. Az SQL tanulása is szórakoztató lehet. Komolyan.
végül, de nem utolsósorban. Ahogy Tom rámutatott: a PostGIS használata geohipster hitelt ad!
egy dolgot csak röviden említettem, hogy a PostGIS nyílt forráskódú és szabadon elérhető. Ez azt jelenti, hogy a kis költségvetéssel vagy anélkül dolgozó embereknek (mint én) nincs belépési akadálya. A kereskedelmi térbeli adatbázisok rendkívül drágák lehetnek. Nagy köszönet illeti a projekten dolgozó összes aktív fejlesztőt!
köszönöm az olvasást! Nézd meg a honlapon további információt rólam, vagy dobj egy megjegyzést Twitter.
szeretne többet megtudni? Források ezt a blogbejegyzést, és további PostGIS olvasás
RTFD. A PostGIS dokumentáció nagyon jó.
PostGIS guru Paul Ramsey számos előadást tart a témáról különböző szempontból a webhelyén
nagyszerű anyagok a határtalan a PostGIS bevezetéséről.
Anita Graser írt egy fantasztikus sor blogbejegyzések kezeléséről mozgás adatok PostGIS.
nézze meg a PostGIS könyveket Regina Obe
ezt a Boston GIS oktatóanyagot használtam, amikor először telepítettem a PostGIS-t helyben
Extra a dataviz-t végző emberek számára: érdekes kísérlet a színek 3d pontként történő tárolásáról a PostGIS-ben