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

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

> Welcome to the Community,
Thanks!!!

> Sounds like fascinating work - especially the security work.
The Security part is tough indeed, with all that JAAS...

> Just a quick reply on the uDig front -

> >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.
> >  
> >
> It will be finished at the end of this month.  uDig is less of a 
> building block and more of a GISPlatform in your context.  You can take 
> a very small amount of uDig (just enough to see things on the screen) if 
> that is all you need. Being able to pair down uDig to be applicable to 
> users is goal of the project - it would be nice to know how this is not 
> being met. Although if you did not know this was a design goal it may 
> just be a documentation problem.
> 
> Jody
Well, it was also a matter of a little "laziness" on our side I must
confess...
Ingest the Eclipse RCP, the Eclipse EMF, etc. was overwhelming.
Also we tried the variuos uDig versions, from the 0.1 on, but we never
really
managed to make them work on our own data, so we gave up and decided to
develop
a simplier solution, taking only the burden to learn the Eclipse RCP.
Now things seems much better, I just downloaded and tried the 0.9 RC3
version
and it worked, so we'll soon see how to take advantage of it, but we have to
deliver our first client app by the end of March, so we'll use the final
uDig version.

> After talking to cholmes I should apparently rephrase,

> The Eclipse RCP provides a Platform (similar to a micro kernal) to which 
> you can add only the content you need.
> You can treat the uDig code base in a similar manner - a GIS Platform to 
> which you can add only the uDig plugins that are required for your 
> users.  So if you making a kiosk for community planning you would not 
> include plugins associated with printing.
> 
> Jody
That's what we thoght it was from the start. Now we have much more
experience
on the RCP, so we'll probably be able to see were the dependencies between
the variuos plugins are and where to cut and sew (my collague Gabriele is
working on the client).

But, for example, if we would like to use only the cartography part of uDig
and its printing capabilities, can they live without the uDig Repository???

I don't know if you already read it but I send you an excerpt of a document
I sent to Chris Holmes, that may explain how our client apps should be.

Bye
Paolo Rizzi

----------------------------------------------------------------------------
------

SISClient
The client will be based upon the Eclipse RCP and potentially could include
plugins from uDig. The main difference from uDig is that we don't have to
provide a powerful general purpose GIS client, instead we must build clients
to do the back-office work of each office (they willl fill forms with data,
etc.) integrating a cartography. For example the first client we're building
is for an office responsible of keep tracking of public sole occupation (if
you want to put tables on the pavement in front of your own Bar, for
example, you have to ask for an authorization and pay a fee). This office
will have a client to manage the requests and to see and draw on a
cartography the shapes representing the occupations.
As you can imagine, people that will use this client will not be GIS
experts, nor they should be given any opportunity to see (or worse to write)
on whatever data they like. Their client will have a fixed configuration and
though, for example, all the DataStore wizards that uDig has, must not be
present.
Also we're trying to build this first client as general as possible, so that
when we'll be about to build the next specific client for another office,
it'll only be a matter of configuring the right Ecplise plugins and the
right DataStores. We would like to have a system where one will launch an
"empty" client, log into the system, be presented with a list of the
applications he has the right to use, choose an application and have the
"empty" client populated with the Eclipse plugins for that specific
application and connected to the right DataStores. Obviuosly there'll be a
server supporting it.