Skip to content
dioptre edited this page Aug 14, 2012 · 1 revision

Rasdaman Documentation

rasdaman quick installation guide for Debian This is a quick guide to install rasdaman on a Debian-type Linux system; it has been tested on Debian Squeeze. It assumes having a Linux user rasdaman under which all installation will be done. Target installation directory is ~rasdaman/install, but this can be changed by adapting $RMANHOME in step 2.

Log in to the target system as user rasdaman Choose your installation directory (here: /home/rasdaman/install) and further settings (you may want to put these into ~rasdaman/.bashrc for automatic loading upon login; don't forget to reload it first time through source rasdaman/.bashrc) export RMANHOME=/rasdaman/install export PATH=$PATH:$RMANHOME/bin:/usr/lib/postgresql/8.4/bin export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$RMANHOME/lib export JAVA_HOME=/usr/lib/jvm/jdk1.6.0 export JRE_HOME=$JAVA_HOME/jre export CATALINA_HOME=/var/lib/tomcat6 Install required packages: sudo apt-get install autoconf automake autotools-dev bison comerr-dev flex gawk git-core g++ krb5-multidev libecpg-compat3 libecpg-dev libecpg6 liberror-perl libgdal1-dev libgfortran3 libgssrpc4 libjpeg-dev libkrb5-dev libltdl-dev libncurses5-dev libnetpbm10-dev libpgtypes3 libpng12-dev libpq-dev libreadline-dev libreadline6-dev libssl-dev libtiff4-dev libtiffxx0c2 libtool m4 postgresql-8.4 postgresql-common zlib1g-dev doxygen openjdk-6-jdk tomcat6 Get and compile rasdaman, configured to sit locally (!) in ~rasdaman/install git clone git://kahlua.eecs.jacobs-university.de/rasdaman.git cd rasdaman ./configure --prefix=/home/rasdaman/install --with-hdf4 --with-netcdf make Install it mkdir ../install make install Add super user in postgres (same name as the local user) sudo -u postgres createuser -s rasdaman -P Setup the rasdaman database create_db.sh Start the rasdaman server start_rasdaman.sh Insert demo data rasdaman_insertdemo.sh localhost 7001 $RMANHOME/share/rasdaman/examples/images/ rasadmin rasadmin

Installing petascope petascope is the OGC web-frontend for rasdaman, implemented as a Java servlet. See the user guide for more details and a list of the supported OGC standards.

This is a short how-to on installing petascope.

prepare PostgreSQL

add a user to PostgreSQL

sudo -u postgres createuser -s petauser -P

you may need to allow trust-based access in PostgreSQL

editor /var/lib/pgsql/data/pg_hba.conf

add the below to the pg_hba.conf (before the ident lines):

#------------------------------------------------------------

"local" is for Unix domain socket connections only

local all all trust

IPv4 local connections:

host all all 127.0.0.1/32 trust

IPv6 local connections:

host all all ::1/128 trust #------------------------------------------------------------

reload PostgreSQL

sudo /etc/init.d/postgresql reload Settings files

When rasdaman is installed to $RMANHOME, the petascope settings files will be installed in $RMANHOME/etc:

petascope.properties (specify connection details and other parameters needed by petascope) log4j.properties (specify loging details) Please adapt these files accordingly before proceeding further, because the update_petascopedb.sh for example depends on the petascope.properties.

If these files are at a different place, then the confDir parameter in petascope's web.xml file ($CATALINA_HOME/webapps/petascope/WEB-INF/web.xml) should be accordingly set.

Setup the database

set up the petascope database structure in PostgreSQL (PostgreSQL needs to be running)

$RMANHOME/bin/update_petascopedb.sh

additionally you can insert petascope examples

$RMANHOME/bin/petascope_insertdemo.sh Deploy to Tomcat

compile the sources

make

the result is a petascope.war file ready for deployment in applications/petascope/build/dist

deploy it to Tomcat for example

$CATALINA_HOME should usually be /var/lib/tomcat6/webapps

cp applications/petascope/build/dist/petascope.war $CATALINA_HOME/webapps

alternatively when configuring rasdaman, the path for deploying it can be specified with

./configure .. --with-wardir=$CATALINA_HOME/webapps

so that it can be installed with

make install

if you're not interested in petascope, compilation can be completely disabled with

./configure .. --disable-java

customize configuration files

adjust log details, verbosity, etc.

editor $RMANHOME/etc/log4j.properties

to adjust the petascope settings

editor $RMANHOME/etc/petascope.properties

to adjust Web service settings

(make sure to backup because it may be overwritten when petascope is redeployed)

editor $CATALINA_HOME/webapps/petascope/WEB-INF/web.xml Finally

Start petascope using, e.g., the Tomcat administration interface; usually it's deployed automatically by Tomcat The petascope interface will then be available typically at localhost:8080/petascope Problems

In case of problems it is best to look at the Tomcat log file, usually in /var/log/tomcat6/catalina.out

Development

The petascope directory (applications/petascope) can be directly opened in NetBeans as a web project.

rasgeo rasgeo is a client component of petascope that is able to easily import data into rasdaman along with the geo-metadata into petascope, provided that the data can be read by GDAL. To setup rasgeo for use:

go to rasgeo directory

cd $RASDAMAN/applications/rasgeo

setup metadata table used exclusively by rasgeo

your user should have write access to the RASBASE database in PostgreSQL

make setupdb

install connection file, which specifies how to connect to rasdaman and PostgreSQL

make connectfile

adapt the template connection file

editor ~/.rasdaman/rasconnect

Example file:


host=localhost rasport=7001 pgport=5432 rasdbname=RASBASE petadbname=petascopedb rasuser=rasadmin raspassword=rasadmin petauser=petauser petapassword=petauser

add rasadmin/rasadmin (the same user credential used in rasdaman) to PostgreSQL

as a workaround for a bug in rasgeo's user management (ticket #125)

sudo -u postgres createuser -s rasadmin -P That's all, now you can happily use rasgeo; check the "user guide" for more details.

rview rview is a desktop visualization client component of rasdaman, that communicates with rasdaman via RPC, so rpcbind/portmapper should be installed and running in order to use rview.

The rpcbind service has to be started in insecure mode, or rasdaman has to be started as root, in order for rview to be able to connect to rasdaman.

To start rpcbind in insecure mode:

note that the service script location may vary among different Linux distributions

editor /etc/init.d/rpcbind

or in recent Ubuntu's

editor /etc/init/portmap.conf

then add '-i' to the OPTIONS variable

GDAL How to compile GDAL with rasdaman support:

Get latest GDAL source Compile and install (in the /home/rasdaman/gdal) ./configure --prefix=/home/rasdaman/gdal --mandir=/home/rasdaman/gdal/share/man --includedir=/home/rasdaman/gdal/include/gdal --with-threads --with-grass=no --with-hide-internal-symbols=yes --with-libtiff=internal --with-geotiff=internal --with-jasper --with-netcdf --with-xerces --with-geos --with-sqlite3 --with-curl --with-pg --with-ogdi --with-python --with-odbc --with-static-proj4=yes --with-spatialite=/usr --with-cfitsio=no --with-epsilon=/usr --with-rasdaman=/home/rasdaman/install make make install Setup environment export GDAL_HOME=/home/rasdaman/gdal export PATH=$PATH:$GDAL_HOME/bin export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$GDAL_HOME/lib Security Issues There are several security measures available, which should be taken. Among them are the access right mechanisms found in Tomcat, web server, rasdaman, and PostgreSQL. We highly recommend to make use of these.

For Tomcat, Web server, and PostgreSQL we refer to the pertaining documentation. For rasdaman, we recommend to change the default user passwords in rasdaman (rasguest/rasguest for read-only access, rasadmin/rasadmin for read-write and administrator access) to not run into the Oracle "Scott/tiger" trap. Even better, add separate, private users. For all these actions, the rascontrol utility is your friend (cf. installation guide). Along the same line we recommend to configure petascope access to rasdaman using a read-only login which is different from the default one provided in the settings.properties file.

The servlet is safe against SQL injection attacks - we are not aware of any means for the user to send custom queries to the PostgreSQL server or the rasdaman server. XSRF and XSS represent no danger to the service because there is no user generated content available. The service doesn't use cookies.

Petascope User guide The petascope component of rasdaman implements the OGC interface standards WCS 2.0, WCS-T 1.4, WCPS 1.0, and WPS 1.0. For this purpose, petascope maintains its additional metadata (such as georeferencing) which is kept in separate relational tables. Note that not all rasdaman raster objects and collections are available through petascope by default; rather, they need to be registered through the petascope administration interface.

Petascope is implemented as a war file of servlets which give access to coverages (in the OGC sense) stored in rasdaman. Internally, incoming requests requiring coverage evaluation are translated into rasql queries by petascope. These queries are passed on to rasdaman, which constitutes the central workhorse. Results returned from rasdaman are forwarded to the client, finally.

For installation, this war file needs to be deployed and configured for use with some rasdaman server installation. See the installation section for details.

WCS

"The OpenGIS Web Coverage Service Interface Standard (WCS) defines a standard interface and operations that enables interoperable access to geospatial coverages." ( WCS standards)

Petascope supports WCS 2.0; see this demo.

WCPS

"The OpenGIS Web Coverage Service Interface Standard (WCS) defines a protocol-independent language for the extraction, processing, and analysis of multi-dimensional gridded coverages representing sensor, image, or statistics data. Services implementing this language provide access to original or derived sets of geospatial coverage information, in forms that are useful for client-side rendering, input into scientific models, and other client applications. Further information about WPCS can be found at the WCPS Service page of the OGC Network. ( http://www.opengeospatial.org/standards/wcps)

The WCPS language is independent from any particular request and response encoding, allowing embedding of WCPS into different target service frameworks like WCS and WPS. The following documents are relevant for WCPS; they can be downloaded from www.opengeospatial.org/standards/wcps:

OGC 08-068r2: The protocol-independent ("abstract") syntax definition; this is the core document. Document type: IS (Interface Standard. OGC 08-059r3: This document defines the embedding of WCPS into WCS by specifying a concrete protocol which adds an optional ProcessCoverages? request type to WCS. Document type: IS (Interface Standard. OGC 09-045: This draft document defines the embedding of WCPS into WPS as an application profile by specifying a concrete subtype of the Execute request type. There is a demo sandbox and demo video; see also the WCPS manual and tutorial.

The petascope implementation supports both XML and Abstract Syntax.

To send a abstract syntax request: A post request must be sent. The query string must be sent in a post parameter named query. To send a request as a XML file, a multi-part post request must be sent. Only one file must be sent. The Mime type has to be text/xml. To send a request as XML: A post request must be sent. A post parameter named xml must be attached. If you intend to implement forms-based access: To obtain a proper query from an XML page a form must be used. The method should be post and action should be an URL pointing to the servlet access point. The form should contain either a file field or a text/hidden field that has the name xml or query. An error in the access method will generate an HTML query input form.

WPS

"The OpenGIS Web Processing Service (WPS) Interface Standard provides rules for standardizing how inputs and outputs (requests and responses) for geospatial processing services, such as polygon overlay. The standard also defines how a client can request the execution of a process, and how the output from the process is handled. It defines an interface that facilitates the publishing of geospatial processes and clients’ discovery of and binding to those processes. The data required by the WPS can be delivered across a network or they can be available at the server." ( OGC Web Processing Service)

Petascope integrates with the 52°north WPS allowing to submit a WCPS request via WPS and deliver sets of coverages or scalars as results. The WCPS query can be in either XML or abstract syntax.

WMS

"The OpenGIS Web Map Service Interface Standard (WMS) provides a simple HTTP interface for requesting geo-registered map images from one or more distributed geospatial databases. A WMS request defines the geographic layer(s) and area of interest to be processed. The response to the request is one or more geo-registered map images (returned as JPEG, PNG, etc) that can be displayed in a browser application. The interface also supports the ability to specify whether the returned images should be transparent so that layers from multiple servers can be combined or not."

Petascope supports WMS 1.0.0/1.1.0. How to publish a WMS layer.

Deployment

First, the original war file from 52 north needs to be adapted for this to work. This can be done with make wps from the petascope directory. Note that the wps target in the Makefile needs to be adapted for this to work.

To integrate a newly deployed custom n52 war with petascope WCPS

go to Upload Process and upload `petascope/src/main/resources/n52/ProcessCoverages.java and petascope/src/main/resources/n52/ProcessCoverages.xml Save configuration In Algorithm Repositories a property "Algorithm=petascope.wps.n52.ProcessCoverages" for the UploadedAlgorithmRepository needs to be added. Deactivate the LocalAlgorithmRepository Internals

Incoming WPS Execute requests invoking the ProcessCoverages process are forwarded by the 52°north to petascope, stripped off the WPS specifics. The resulting WCPS request is processed, and the result is returned to WPS.

Technically, the coupling consists of an adapter class (a Process). The process identifier is petascope.wps.n52.ProcessCoverages.

Demo

See this small earthlook we have set a demo too, available EarthLook WPS demo. There is a simple test client done by n52.

Limitations

as the WCS CRS extension is not yet approved by OGC (although submitted by the WCS.SWG) CRS handling is still limited.

Clone this wiki locally