[webmap-discuss] comments on osgeo design in wiki

[Cameron Shorter]

chris wrote:
> Hi All,
> 
> Cameron invited me to put comments intot he wiki but my comments are
> fairly general and long winded so I thought it would be more
> appropriate to put them here.  keep in mind I know nothing of
> Javascript and I also tend to think of high level design in terms of
> building interface walls between the more changeable functionality and
> the more generic.
> 
> Generally, it all looks good. My main feeling is that design seems to
> have begun too low level, I'd like to see the bigger architectural
> picture.  Would help to define this as  a geospatial pipeline
> architecture (e.g. like in attached image) and work from there
> Including main pipeline stages: network, Object System (OS), User IO,
> graphic Display System (DS), server communication (full duplex
> handling of user requests, tracking, collaboration info (chat etc),
> data fetch and service requests). I don't see classes for the server
> side processing – but that is potentially where a lot of the work will
> be done.

Fair point about the design being too low level.
The aim of the design is to explain to OpenLayers developers how we 
should extend OpenLayers.

I'd like document the OpenLayers design but that is beyond scope.

> 
> I started to get a picture of how class hierarchies shown work
> together as a whole after seeing the parser diagram at the bottom. Is
> the parser the highest level class?

There are a number of other OpenLayers classes which are not included in 
my diagram.

You can have a look at the class documentation at http://openlayers.org/ .

> 
> I think it is very useful in the long term to have clear separation
> between object system and display system, think of the OS as the model
> and the DS as the View in a MVC design. A monolithic object/display
> class hierarchy gets too unweildy (I note the text on keeping the
> separation at a higher level still).  In my Phd research and work on
> planet-earth.org and other geospatial stuff I find this separation
> essential to ensure high fidelity over large scale – e.g. it helps
> with applying a floating origin
> (http://planet-earth.org/cw05/FloatingOrigin.pdf). Note: although I
> work from a 3D perspective :) these numerical matters also apply to
> 2D.

I'm all for the Model/View/Controller design pattern. (That is how we 
coded Mapbuilder).

OpenLayers goal is to provide a wrapper over Yahoo/Google/MSN maps and 
consequently have lined up with the Y/G/M maps design, which is not a 
strict MVC.

The graphics code I'm proposing is aimed at fitting in the the existing 
OpenLayers code.

> 
> Separation again: if u can define class or classes that isolate the
> code that is needed to make client cross browser/OS portable then that
> would go a long way to ensure its longevity. I think it will be
> perilous to ignore historical experience, despite the hype/excitement
> over Ajax: http://www.coachwei.com/blog/_archives/2006/9/27/2367882.html
> . On this subject, I see some DOM calls. From what I gather, some
> people believe that using DOM can alleviate many of the platform
> portability issues. I hope this is the case.

The platform incompatability issues will be in the Graphics packages 
which has a well defined generic interface - protected through a Abtract 
  Factory, and in the Parser code which will need XML calls. Again, the 
Parser code will use a cross browser library. (I will be initially using 
Mapbuilder code for this which uses http://sarissa.sf.net )

> 
> I assume the raster layer class is to be the image data handler. I'm
> not sure there is enough here: what about interface class (or rather,
> abstract class) for layer::raster to use for multiple image format
> handling and also have a look at multirez image handling (tiling).
> This would provide layer with a consistent interface but handle the
> dynamic loading of whatever image reader was required. All then proly
> need to be extended to "tiled" versions.

The OpenLayers guys have already written WMS and Titled WMS, Yahoo, MSN, 
Google layers (which are all raster based). I'm not sure whether the 
RasterLayer will actually become a class, it is just a suggestion which 
might or might not be acted upon.

> 
> Use cases are v low level.  Need to take a step back and look at the
> big picture. Perhaps look at use cases for w3d Geospatial Incubator
> Group: http://www.w3.org/2005/Incubator/geo/charter. Note the emphasis
> on handling semantic as well as spatial searches, and the inclusion of
> time.

Point taken. There are quite a few other use cases which I haven't got 
round to adding yet.

> 
> No interface classes are shown.

> A high level analysis of functionality
> that changes over a range of use cases versus functionality that is
> common would be useful. Interfaces can then be defined to separate the
> more dynamic from the more stable functionality that gets reused
> across use cases. E.g. the processing of geo data has a number of
> generic, stable operations (overlay, draw etc) that are always used no
> matter if the input is from GML, KML, a DEM format, image data etc.
> So, an interface class can be defined to provide a common interface
> for all these and it dynamically loads the GML reader if the user is
> just getting GML or some other reader as appropriate. Saves on client
> run time footprint and also breaks up the design nicely. All the data
> format readers form the dynamic part separated from the stable part by
> the interface.  Note: I tend to use this sort of pattern in java and
> don't know if you can use such dynamic loading in javascript, but
> perhaps the same design principles should apply. Note I use the term
> interface loosely: in Java terms I often use an "abstract" class
> rather than an "interface" class because it usually has some method
> code in it.


Javascript doesn't have a concept of an interface class like Java.
You simulate an interface through inheritance.
I think I have this concept built in to an extent.
> 
> Need to have objects for spatial reference model:
> (http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_IEC_18026_Ed1.html).

Yes, I haven't addressed SRS in this design.
I'm only focusing on the Vector Rendering part of the design.
The Spacial Reference System (SRS) is part of the Geography classes (I 
just haven't included it in the attributes).

> 
> e.g. need objects for Ellipsoid, datum, SRS, projection, etc. this
> site: http://www.ai.sri.com/geovrml/1.1/doc/concepts.html has a nice
> subset that I think could be adopted.

Yes, I haven't included to keep the UML simple. These classes should 
follow the GML naming convensions.

> 
> What about supporting 3D data? Consider: output can go to either 2D or
> 3D. Most geodata maps into a 3D position, in general so perhaps a
> layer can be defined that preserves the 3D. Time data is significant
> too.

Good point, you might be able to help in designing this.
GML3 can store 2D or 3D Geometries.
There will probably need to be a 3D Graphics class, and maybe a 
3DRenderer too.


> 
> Consider how you are going to handle scaling from earth to human scale.

Yes this is a big problem to address and I have given a lot of thought 
to it, but I think there is a lot of room for optimisation.

Initially, I think we will have a different layer for each zoom level.

> 
> Consider the handling of LOD. Multirrez tiling essential.

LOD?

> 
> Is "Line" a polyline?

Yes.

> 
> 
> -- 
> 
> cheers,
> 
> chris
> 
> ------------------------------------------------------------------------
> 
> 
> ------------------------------------------------------------------------
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: webmap-discuss-unsubscribe at mail.osgeo.org
> For additional commands, e-mail: webmap-discuss-help at mail.osgeo.org


-- 
Cameron Shorter
http://cameron.shorter.net