andrea antonello ha scritto:
La feature che piu' mi ha impressionato e' la possibilita' di definire
un flusso di lavoro in modo grafico (ex, leggi da db, leggi da tiff,
esegui calcolo, manda mail con risultato etc etc) ed e' poi possibile
esportare il flusso di lavoro come applicazione java da lanciare su un
server.
E' esattamente ciò che fa anche Pentaho con GeoKettle... dove puoi definire una trasformazione con vari step e\o un job ossia una serie di trasformazioni.
Per ora Geokettle legge\scrive da e su PostGIS e ci sono ancora tante cose che devo provare (tipo la gestione della topologia...)
per il momento:
Using GeoKettle
GeoKettle can be used the exact same way as Pentaho Data Integration (PDI). Please refer to the PDI user documentation included in this distribution.
Demo transformations showing the use of the geospatial extensions are also included in this distribution, in the samples/transformations/geokettle directory. The new features for geospatial data are documented here:
* *Geometry Value type*: In addition to the basic Value types (e.g.
Number, String, Date, ...) existing in PDI, GeoKettle introduces a
new Geometry Value type, supporting vector geospatial data
(geometries such as Point, Line and Polygon). A Geometry Value is
automatically generated when reading a geometry field from a
supported spatial DBMS or GIS file format. For example, when using
the "Table input" step with a table (from a PostgreSQL DBMS with
the PostGIS extensions installed) containing a column with a
GEOMETRY type, the corresponding Geometry Value will be part of
the output for this step. The capability to convert a Well-Known
Text (WKT) string to a Geometry is also supported: changing the
value type of a String to Geometry (with the Select Values step)
will yield a valid Geometry value if the string contents is a
valid WKT string. Conversion from Geometry to String does the
opposite (converting the geometry as a WKT string).
The Geometry Value type is implemented using objects from the
GeOxygene framework (http://oxygene-project.sourceforge.net). All
geometry objects are abstracted with the GM_Object interface (a
GM_Object reference is encapsulated in the ValueGeometry class in
GeoKettle).
* *Access to Geometry Values in JavaScript*: It is possible to
access the GeOxygene framework objects contained in Geometry
values in the "Modified JavaScript" step. This makes possible the
use of spatial analysis functions such as buffer calculations,
overlays, metric operators, etc. An example transformation using
Geometry values in JavaScript is included in the distribution.
* *Input / output with spatial DBMS*: For now, only PostGIS is
supported as a spatial DBMS. Support for GEOMETRY columns is
natively supported with the PostgreSQL driver (by using the
PostGIS driver wrapper, included in the distribution). One only
has to choose the PostgreSQL native (JDBC) connection type when
creating the database connection. If the database in question is
configured with the PostGIS extension, all GEOMETRY columns will
transparently be read as Geometry values (no need to use PostGIS's
AsText() or AsBinary() geometry accessors), whether one uses the
"Table input", "Database lookup" or "Database join" steps.
Likewise, Geometry values will be transparently converted to the
native DBMS geometry type when written to a GEOMETRY column (in
any database output step, such as "Table output", "Insert /
Update" or "Dimension lookup/update").
* *Topological predicates*: Kettle conditions
(be.ibridge.kettle.core.Condition class) have been extended with
topological predicate functions, allowing the comparison of
Geometry fields based on topological relationships. The new
functions are: GIS_INTERSECTS, GIS_EQUALS, GIS_CONTAINS,
GIS_CROSSES, GIS_DISJOINT, GIS_WITHIN, GIS_OVERLAPS, GIS_TOUCHES
and GIS_ISVALID. All of them are binary predicates (comparing one
field to another) except for GIS_ISVALID which is unary (returns
true or false based on the validity of the geometry in a single
field). For example, if we want to know if values for a certain
"City" field are located within values from a "State" field, we
would use the GIS_WITHIN predicate. If the City point is located
within the State polygon for the current row, the expression
evaluates to true (otherwise, false). These new topological
predicates can be used in any step based on the Condition class,
i.e. "Filter rows" and "Join rows (cartesian product)". A demo
transformation (intersection.ktr) is included in the distribution.
* *"GIS file input" step*: A new "GIS file input" step is present in
the Experimental steps. This supports the reading of GIS data
files; for now only Shapefiles are supported. The geometry
(contained in the SHP file) is read to a field named "the_geom"
(with a Geometry value type) and all other alphanumerical fields
(contained in the DBF file) are read to fields with the
corresponding name and value type. Unlike the existing "ESRI
Shapefile Reader" step from PDI, which reads geometries contained
in the Shapefile as X and Y numeric fields representing the
coordinates of points, this new "GIS file input" step reads
geometries as Geometry values.
* *"Spatial Analysis" step*: The new "Spatial Analysis" step (in
Experimental steps) is a placeholder for a future GUI dialog
providing an easy to use interface for spatial analysis functions
such as buffers, overlays and other metric/geometric operators.
For now, it does nothing at all. The "Modified JavaScript" step
can be used to manipulate Geometry objects, in order to perform
spatial analysis, as explained in the "Access to Geometry Values
in JavaScript" section.
--
Ing. Fabio D'Ovidio
INOVA Open Solutions s.r.l.
Web : http://www.inovaos.it
Tel.: 081 197 57 600
mail: fabiodovidio@gmail.com
)
) su pentaho+openlayers+GeoRSS+WFS-T+WMS+SLD.