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

[Matthias Basler <Matthias.Basler@xxxxxxxxxxx>]

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.

I'm starting to like this approach.

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

> 6.  I don't think the blackboard needs to be part of the main interface
> but it is really useful for collaboration between plugins and it sees a
> lot of use, though not by us (udig developers) but rather plugin
> developers.  If it is not part of the main interfaces then we can add it
> to out extended interfaces.

That matches my opinion.

> 7. Each layer does have a CRS that you can explicitly set.  If it is not
> explicitly set then it is the CRS defined by the IGeoResource.getInfo()
> object. Typically if the layer is a feature layer then the CRS defined
> in the feature type is the layer's CRS.

Good to know.

> 8. I agree completely with being able to group layers.  I believe
> GEOAPI's layer has that concept.

Yes. It's just that I personally find its realization not exactly
intuitive.

> 2. I like # 3 for map/layer interfaces. Is a layer group also a layer?

That the thing I'm currently working on. Yesterday I tested both possibilities:
#4 (a map with grouping function) and #3 (a separate MapLayerGroup interface).
Opposing my initial expectations the preliminary results show that the latter
results in easier interfaces and implementations (although the number of
interfaces and classes is significantly higher).
To your second question: That depends on us. Currently I test following
hierarchy:
- I MapLayer and I MapLayerGroup both extend I MapElement (which states that
they both can be children of an I MapLayerCollection).
- I MapContext and I MapLayerGroup both extend IMapLayerCollection (which states
that they both can contain I MapElements).

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

Matthias Basler
c9bama@xxxxxxxxxxx

----------------------------------------------------------------
This mail was sent through http://webmail.uni-jena.de