Re: [udig-devel] AVL (Automatic Vehicle Location)

[Jesse Eichar <jeichar@xxxxxxxxxxxxxxx>]

On Fri, 2005-04-15 at 23:59 -0700, Ahmed Al-Obaidy wrote:
> Hi.
> Im sorry for being late in response but it was the
> weekend here in Iraq
> 
> What I had understood is this:
> 
> -Creating a layer, that contains the moving vehicles
> position on real GPS coordinates.
> 
> -Store that layer in a server such as WMS.
> 
> -The part Im not sure of is how to build the tool
> and how to plug it in UDIG
> 
> The other thing what should be discussed is the update
> mechanism Is it pooled or event driven (would it be
> necessary to load the entire layer in a regular
> period? ....or just get the updates on status change.
> 
> Thank you again
> Ahmad
>  
> 

A coupe of points I should point out is that new IGeoresources can be
created by extending the ServiceExtension extension point.  That allows
you to have "anything" as your resource.  It can provide any type of
events you desire.  

With regards to the UDIG, virtually all classes fire events for all
sorts of state changes.  The non-public API is based on EMF which is
strongly event based.  However not all of the events have made it to the
public API as of yet.  Although we are open for requests.  For a list of
Layer events that can be made public you can look at all the Constants
in ProjectPackage.java that start with LAYER__.  

That said I would probably create my own resource and ServiceExtension
and listen to events on that object.  

Jesse
> 
> --- jeichar@xxxxxxxxxxxxxxx wrote:
> 
> > Quoting Ahmed Al-Obaidy <ahmad@xxxxxxxxxxxxxx>:
> > 
> > > Thank you Jesse and Jody for the response..
> > > 
> > > Jesse: Cloud you please give me more details about
> > > your idea to solve this problem.
> > > Especially about the tool extension point and how
> > I
> > > can save it in centralized server that many
> > clients
> > > could access simultaneously.
> > > 
> > > Thank you very much again.
> > > 
> > > Ahmad
> > > 
> > 
> > My understanding of your problem is a little shaky
> > right now.  So I can't give
> > you a perfect design.  I also don't know where you
> > stand in your understanding
> > of UDIG so I'll outline some of the main parts of
> > the UDIG system and maybe you
> > can get an idea of how to approach the problem.  
> > 
> > 1. Tools are used to interact with the user, not too
> > much of a surprise I'm
> > sure.  There is a framework associated with tools
> > and the extension point to
> > make developing tools easier.  A tool receives mouse
> > events, keyboard events and
> > using those event can affect the current map.  I
> > guess I should note that tools
> > only apply if there is an open map.  
> > 
> > 2. A map has layers.  Each layer (usually)
> > corresponds to a IGeoResource that
> > exists in the catalog.  An important point to note
> > is that nothing says a layer
> > MUST be rendered, but typically they are.  A Map has
> > other bits as well but I
> > don't think they apply to our discussion right now.
> > 
> > 3. GeoResources are part of the catalog and are
> > handles to "real" data.  A
> > georesource might be a handle to a layer in a WMS or
> > a feature type in a WFS.
> > 
> > 4. Services contain GeoResources and are handles to
> > "real" services (a WMS for
> > example.)
> > 
> > So given this a possibility might be to have a
> > georesource/service pair be the
> > handles to the centralized server.  A Layer will
> > reference the georesource and a
> > tool can be developed that manipulates the data in
> > the georesource.
> > 
> > That's one idea.  If you have other suggestions
> > please let me know and I'll try
> > to provide some feedback.
> > 
> > Jesse
> > 
> > _______________________________________________
> > User-friendly Desktop Internet GIS (uDig)
> > http://udig.refractions.net
> >
> http://lists.refractions.net/mailman/listinfo/udig-devel
> > 
> 
> _______________________________________________
> User-friendly Desktop Internet GIS (uDig)
> http://udig.refractions.net
> http://lists.refractions.net/mailman/listinfo/udig-devel