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

[Ahmed Al-Obaidy <ahmad@xxxxxxxxxxxxxx>]

Hi….
I’m 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 I’m 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
 


--- 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
>