[Gfoss] OT ma non troppo: integrazione tra informazione geografica e prodotti per la BI

[Fabio D'Ovidio]

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 a gmail.com