comments on osgeo design in wiki

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

comments on osgeo design in wiki

chris-194
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

GeoSimPipeline.png (56K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [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: [hidden email]
> For additional commands, e-mail: [hidden email]


--
Cameron Shorter
http://cameron.shorter.net
_______________________________________________
Dev mailing list
[hidden email]
http://openlayers.org/mailman/listinfo/dev