comments on osgeo design in wiki

[chris]

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.

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?

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
graphics library standalone: this is good but I am talking about a
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.

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.

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.

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.

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.

Need to have objects for spatial reference model:
(http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_IEC_18026_Ed1.html).
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.

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.

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

Consider the handling of LOD. Multirrez tiling essential.

Is "Line" a polyline?


--

cheers,

chris
-------------- next part --------------
A non-text attachment was scrubbed...
Name: GeoSimPipeline.png
Type: image/png
Size: 120904 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/mail_webmap-discuss/attachments/20061102/0150b889/GeoSimPipeline.png