Re: [udig-devel] Re: Wiki page created for new map, map layer and render

[Jesse Eichar <jeichar@xxxxxxxxxxxxxxx>]

On Thu, 2005-08-11 at 11:06 +0200, Matthias Basler wrote:
> Hi Jesse,
> 
> thank you for your help on this. I guess you don't mind if I put some of your
> explainations and opinions on the page...
> 
> 
> > 2. Layers can have more than 1 resource and there is a preferred one.
> > This is because a Web Map Service and a Web Feature Service could all
> > refer to the same data.
> 
> So one ILayer - multiple IGeoResources.
> My first idea on this was that the handling of data "sources" is done within
> IGeoResource (hidden from the API user), but internally mutiple sources (file,
> WMS, WFS etc.) can be queried. But this current solution obviously has the
> advantage that one can just take the preferred IGeoResource
>   public IGeoResource getGeoResource();
> or EXPLICITELY use a specific one from the list gotten from
>   public List<IGeoResource> getGeoResources();
> if one is interested in certain capabilities not offered by every source.
> 

One thing I've realized and we use this approach a lot in udig is the
getResource(Class) and hasResource(Class) methods.  These method are
used to hide the fact that there are multiple GeoResources.  GetResource
attempts to satify the request using all the GeoResources it knows
about.  For example getResource(FeatureStore.class) attempts to find a
FeatureStore.  Thanks to these methods it usually doesn't matter if
there are one or more GeoResource.  (Note the difference between
GeoResource and Resource.  GeoResource is the handle).  

Having difference GeoResources for a WMS and a WFS is desirable for
understanding what is happening and simplifying the GeoResource
implementations but not for a programmer trying to use the layer
interface.  

> > 5.  Both ReferencedEnvelopes and Envelopes are used because
> > ReferencedEnvelopes were introduced part way through the developement
> > and we haven't yet put them through the entire system.  GEOAPI has a
> > Envelope object as well but it is unwieldly so we didn't use that.
> 
> I just got a good explaination from Martin on this topic. He proposed to use the
> GeoAPI interface in the longer term.
> What exactly do you find "unwieldly"? Is there any chance to improve the
> interface so we all find it acceptable and can start using it. It's just that I
> don't like the current use of JTS:Envelope either, since it is not an interface,
> but a class.

The unwieldy part isn't terrible it just comes from being a general
solution.  For example getMax(dimension).  Not the end of the world
obviously and having some factory methods for creating them would
probably make them much more pleasant to use.  They are much better than
Envelope because the have a CRS and the generality may be needed in the
future.

> Two other issues I will put onto the page are:
> A. the question of how to allow undoable operations - currently I believe that
> the basic API does not need to support this and applications will be able to
> put support for undo/redo on top of the interfaces.

In udig, the Map is one of the central components of the system but I
can't think of any reason that Map and undo/redo have to be tied
together in general.  I think the idea of having Commands and
CommandManagers etc... it is important but I think it is up to the
implementer how to relate the two.

> B. if/how to support locking of objects (making them completely or temporarily
> immutable). This involves that the end user can lock the object, but also that
> some map layers or environments might not offer editing capabilities at all.
> This is not a big deal to implement, just something to think about.