Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[udig-devel] Re: MapContext and AOI discussion

Zitat von Jody Garnett <jgarnett@xxxxxxxxxxxxxxx>:

> Gabriel Roldán wrote:
> >So a MapContext document could be persisted and once "reloaded" used to show
> >your previously working map view, as it was.
[...]
> >If using it as a model, in a MVC framework, changing the AOI may raise an
> >event to update the views: update the map view to the "working area", update
> >the legend to show only visible layers at the current scale, etc.

Hm. Obviously the AOI is not ONLY intended to restore the last map view, but is
also used as a "working area" to which the user can reset the map viewport.
Makes sense, although in this case the AOI is not "essential" to a map context,
although it is functionality something that a GIS application SHOULD provide.

Jody wrote:
> Thanks Gabriel were were just trying to figure out if Matthias had
> separated out the Map model (of layers and zorder and style) from the
> Viewport model (AOI and CRS).
>
> The two can be quite cleanly separated, or the Map can contain a
> Viewport model. We just could not tell what Matthias had in mind.

Why not ask me? ;-)
Well, I haven't yet decided on anything finally - and your opinion is essential.

When I started I had the plan for the objects to separate essential content from
optional information needed in widgets or specific applicatios (The former are
what I called "object interfaces".)
At the current state it looks to me if it is not a good idea any more:
All the UI related stuff, such as layer/map icons, the map CRS and now the AOI
are things need to be defined somewhere. Integrating them into the basic
framework (the one in the UML diagram) is much easier than putting them on top
of all the interfaces there. This is why in the end I put icons, metadata and
map CRS into the framework. Having the icons(or glyphs) in there allows to
directly use the objects in maplayer/legend widgets. Having the mapCRS in
there, allows to directly use the objects for rendering.
The AOI on the other hand is imho not directly needed, but if you like I will
include it into MapContect interface. (Although the fact that it depends on the
map CRS gives me a bit of an headache. Nor do I like the solution of the current
MapContext to only allow to change the CRS when changing the AOI. But that's
another topic.)

P.S. Just thinking: A map should also have a background color attribute. (Or
even image??? Better not!) If AOI is included I'd like to include the
background color as well, especially as it is relevant for rendering.

Z-Order is done by the indices of a MapLayerGroup's children. So it is included.
(But not any specific logic for scale bars and compass roses and such. I think
this should be a concern of the application, not of the map model. Agree?)

Jody, when you mention "Viewport model" I think of something different, namely
the map pane's "viewport model", i.e. mapping pixels to coordinates and vice
versa and knowing the current area displayed on the map pane. So I don't use
this term here.

> figure out if Matthias had separated out the Map model from the Viewport model

But to ultimately answer your question: Are "map content" attributes separated
from "map display" attributes (namely CRS, AOI and background color)?

Yes and no.
- Yes, because in my current concept all the mentioned "map display" attributes
currently live in "MapContext", simply because they are not needed for simple
map layer groups, only for the top level group - the map.
- No, because (1) the distinction is not strict since icons/glyphs are already
at the root of the interface tree (or top in my diagram) and because (2) there
is no such distinction in MapLayer (it is simply not necessary up to now,
imho).

Hope I could confuse you completely. ;-)

> The two can be quite cleanly separated

What would we gain? That's the big question for me.

Matthias Basler
c9bama@xxxxxxxxxxx

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


Back to the top