[udig-devel] Presentation of our team and our work (LONG)

[P.Rizzi Ag.Mobilità Ambiente <paolo.rizzi@xxxxxxxxx>]

Hi all,
with this message I would like to present our team to the users and
developers of GeoTools, GeoServer and uDig.

We're a team of three people currently working as consultants for an Agency
called A.M.A. - Agenzia Milanese Mobilità e Ambiente (Mobility  and
Environment Agency - Milan (Italy)).

We've been hired to build what we call SIS (Sistema Informativo Strade -
Streets Information System), a system able to store the official street
network graph and all the information related or relatable to streets, so
that various offices of the municipality will have a central place to store
and exchange information.

We decided to use GeoTools, GeoServer and uDig as the foundation of our
system. Particularly we decided to use DataStores as our only data access
mechanism, so that all of our system data will be accessible via some sort
of DataStore. This will be true for any kind of data, not only for
geospatial data.

We also devised that a DataStore could be used as an interface to a service,
and so all the modules of our system (or plugins if you like this naming
more) will be DataStores. For example we have a service called Locator
capable of converting addresses to geographic coordinates and viceversa, or
to found the street and the exact place on that street where a given address
is located. This service will appear as a normal DataStore where one can do
queries like "street='Via Rembrandt'" and get back one or more Features with
all the other information. At the same 
manner one can do a query like "x=1553433.774 and y=5479883.2244" and
receive the same Features. It appears like a normal DataStore, but
internally there's Java code that parses the Filter and uses other
DataStores to lookup street names, and so on.

So we're building a framework where the variuos modules (aka DataStores) can
be plugged in. The framework will also have integrated security, so that
each user will be able to see, read, and write only his authorized data.
This framework will be available both to server and client applications, for
example GeoServer will be attached on top of it, exposing data through WFS
and WMS.

On the client side we planned to use uDig as the building block of our
different clients (each office will need a specific client targeted to the
jobs the office carries on), but uDig is far too general and powerful for
our users. So we adopted the Eclipse RCP anyway, but got no code from uDig,
we'll see when it will be finished.

At the moment we're integrating GeoServer inside an EAR J2EE application,
deployed  under Jboss so that all the "normal" Data and DataConfig present
in the GeoServer's ServletContext are deleted and replaced with the
configuration of the various deployed modules. This way DataStores,
FeatureTypes, Namespaces and Styles are automatically available through
GeoServer, without the need of manually configuring them through the Web
interface or directly messing up the catalog.xml file and the dataTypes
directories.

All of the above is based on the Meta infrastructure. In the past months we
defined the data model of our system in terms of the variuos Entity Types
(Street, Junction, etc.), their parent/child relationship
(Street<-UrbanStreet), explicit relationships (Street->Junction), structure
(the Attributes of each Entity), description ("A Street is a..."), etc. All
this information (plus other about Validation, Security, etc.) are managed
by the Meta infrastructure. When a module is plugged into the system, its
Meta information is read and merged with other modules one. From this Meta
info we can define on the fly the FeatureTypes exposed by the module and we
can automatically add them to GeoServer.

So to add a module to the framework, in its server incarnation, one has
simply to package it in a SAR archive (a JBoss JMX service archive) along
with an xml configuration file and drop it in the JBoss deploy directory.
The DataStore and its FeatureTypes will magically appear in GeoServer.

The Meta infrastructure also provides a type discovering mechanism, that
gives access to an Entity MetaType given it's unique name String. The
MetaType, in turn, holds a reference to the FeatureSource that implements
that Entity, so one module can use another one by simply asking for it by
name. You can find an overview of the Meta Infrastructure and download the
complete Framework at:
	
http://docs.codehaus.org/display/GEOTOOLS/Meta+Information+Infrastructure

We're are working on the server side right now, but the framework will be
usable on the client side also, this is a very important point. Another
thing to be pointed out is that the Meta Information Infrastructure has
nothing to do with ISO Metadata, but can be used to store whatever kind of
information.

So we're writing a lot of code that could be useful in many places inside
GeoTools, GeoServer and uDig and we hope to be able to contribute it back to
the community. We only need to follow the priorities given by the goals for
which we've been hired for in the first place.

Best Regards

Paolo Rizzi (aka myself)(amagis@xxxxxxxxx | paolo.rizzi@xxxxxxxxx)
	developing the Meta Infrastructure and the framework

Luca Sigfrido Percich (luca.percich@xxxxxxxxx)
	author of the data model and developing many special modules and
DataStores

Gabriele Ceranto (gabriele.ceranto@xxxxxxxxxxxxxx)
	working on the client side with the Eclipse RCP