[DotNet-OSGeo] some random thoughts

Tue Jun 1 13:34:55 EDT 2010

Another thing knocking around in the back of my head is using Mono.Simd
for accessing SSE instruction sets on modern processors.. Or Perhaps
OpenCL to enable GPUs to be used...

jd

From: Daniel Ames [mailto:dan.ames at isu.edu] 
Sent: 01 June 2010 16:05
To: John Diss
Cc: dotnet at lists.osgeo.org
Subject: Re: [DotNet-OSGeo] some random thoughts

John, 

Nicely summarized - I think you've pretty much laid out all of the main
considerations in designing a common .NET underlying framework... Here
are some thoughts on your points.

- Dan

	Personally I think all parts of the application should be split
into an interface and an implementation. All interfaces should only
demand other interfaces in their contracts. This will allow much easier
replacement of core components in future. IOC/DI can be used to bind the
concrete implementations together. We should avoid building a tightly
coupled monolith.

Agreed. It's the question of building an open source cathedral or an
open source bazaar. Maybe what we need is a well-planned city where
individuals can contribute different elements but they all fit together.

	All interfaces should closely resemble their OSGeo counterparts
- there is no point in building a standard if by doing so you ignore the
standard.

Critical imao 

	Licensing should be thought out up front. The project will never
be the go-to source for .Net developers if there is the slightest hint
of GPL and a lot of people don't understand LGPL either so that is also
a turnoff.

On some of our projects we are going with BSD which is like LGPL in
spirit but is only one paragraph which is nice. Alternatively we
continue to use LGPL and make sure to educate people as to what that
means (ie. commercial use is OK). 

	All external apis where possible should be parallelizable. E.g
collections should be synchronized.

Cool, but not sure how feasible. Thoughts?

	Data access should be async.

Especially for web based data access. Maybe not for file based? 

	There should be a caching block developed with multiple
backends. Uses ranging from caching data/ partial screen renders,
wms/wfs output etc.

Not sure exactly what the implications are... but interesting idea. 

	Supported frameworks should be considered up front - my personal
preference would be to start with a clean slate at .Net 4 or at a
minimum 3.5.

We were targeting 3.5 because it would be more likely to be mono
compliant... (does MONO really support all of .NET 4 now?) 

	If we hope to support MONO (which I think we should) we must
ensure that any rendering api's have a potential replacement in Mono.
Mono is currently compatible with .net 4.

 Any ideas on how much of .NET 4 is implemented in MONO now? 

	GDI+ is terrible in a server context - "A Generic Exception
Occurred" is the best way to ruin my day/week/month. A while ago I had a
play with Cairo and D2D both are promising - wip is available in the
JDSymbolizer branch at http://sharpmapv2.googlecode.com. D2D is platform
agnostic whereas the Cairo I was using was x86 only. It was also an
experiment to allow different rasterizers to be used in the same control
and also multi pass rendering ala OsGeo Symbology.

Our approach has been to - again - use interfaces. So we have developed
an "iMap" interface that could be swapped out with different rendering
engines depending on the platform or user preference. We need to commit
this soon to the System.Spatial codeplex site and get some feedback from
others.  

	Reliance on native apps/dlls should be avoided where possible
and replaced asap when they are used to get a result. They reduce the
portability of the resulting framework and make building for AnyCPU much
harder as you get BadImageFormatExceptions thrown whenever an x86 native
assembly is loaded into an x64 app domain. This in turn makes the build
configs harder to maintain.

Agreed. This is why it's important to for example support GDAL as a data
provider plug-in. Essentially any native app or dll needed should be
supported as a plug-in rather than as a core framework component.  

	Any class expecting to retrieve (vector/attribute) data from a
datasource should demand IQueriable<I/TFeature> rather than a
FeautureProvider or similar. DataTable / Dataset should be avoided. The
query syntax should be either linq against TFeature and/or based on
expressions taken from the OSGeo Filter spec.

Not sure I understand... can you explain further? 

	All data classes should be marked [Serializable].

Agreed 

	Where possible the classes should be [CLSCompliant]

Agreed 

	Any style/symbology should be based on the OsGeo symbology spec
/SLD i.e multiple rules evaluated in a loop for each feature allowing
for complex styles to be built up.

Agreed. We've started using this approach in a new renderer for
MapWindow that we'd like to share with the community in the
System.Spatial.Symbology(?) namespace... 

	Potential for 3D should be considered and planned for if
appropriate.

One approach is through the iMap interface. Using the common interface
for a map would allow someone to build an OpenGL or DirectX map and swap
it in with full 3-D capabilities. 

	Silverlight/Moonlight has massive potential for browser based
gis / mapping / processing / grid computing. Supporting it should
definitely be planned for but it imposes its own forced async style
which may have implications elsewhere. Also win phone 7 will be
Silverlight based. Novell have MonoTouch and MonoDroid in progress for
IPhone and Android respectively and www.KoushikDutta.com  is working on
another free Android/Mono platform.

What are all the implications of supporting Silverlight and Moonlight?
Is it possible to have a standard .NET DLL that can be used in a
Silverlight application? 

	Labelling engine is extremely important it should be capable of
creating very crude/fast maps and also picture perfect - what the
general public expect.

Yes. ArcGIS does this by having a pretty good labeling engine and then
an expensive add-on (Mapplex) that does the atlas style labeling - which
is nicer but slower. So there needs to be support for both, perhaps with
better labeling available through a plug-in. We ought to be able to
reuse/port from other good open source labeling engines... 

	MS C#/dotspatial group style guidelines should be followed -
everyone's code should look the same. Perhaps a developer R#/stylecop
profile should be created and enforced by a CI server.

Agreed. Is it possible to do this kind of enforcement using Codeplex? 

	Source control should be backed with a CI / Test server.

Can this be done on Codeplex? 

	There should be an IRC channel created or perhaps 2. #dotspatial
and #dotspatial-dev. I suggest freenode.net as #OSGeo and #SharpMap are
already there.

Agreed - will do.  

	Perhaps the logs should be taken and made available somewhere.

Yeah, any ideas on how to do this other than just through the codeplex
log browser? 

	Documentation should be easy to find and of high quality.
Perhaps the group needs a sister website separated from codeplex where
it is easier to manage the wiki/ public contribution etc. The codeplex
wiki is very limited in this respect.

Yes agreed. This is the number one complaint I believe of any/every open
source GIS project that there isn't adequate high quality documentation.
We've registered "dotSpatial.org" so maybe that should point to a
non-Codeplex server where we can maintain documentation and project
description/etc. Then have pointers to the Codeplex site for source
code, issues and forums. What do you think of this approach? Would you
(John or others) be interested/willing to help decide what would go such
a separate site? layout, etc?

	Any way got to do some work.. more to come...

	If possible it would be good to arrange an informal meeting
sometime on irc.  I am in London, FObermaier is in Germany and
Pauldendulk is in Holland so it may make sense to have it late afternoon
here / morning in the US

Agreed. I'll set up the freenode channel unless someone else has already
done it and then let's schedule a chat for anyone interested in
joining...  

	All the best

	jd

	_______________________________________________
	DotNet mailing list
	DotNet at lists.osgeo.org
	http://lists.osgeo.org/mailman/listinfo/dotnet

-- 
Daniel P. Ames, Ph.D. PE
Associate Professor, Geosciences
Idaho State University - Idaho Falls
amesdani at isu.edu
geology.isu.edu
www.mapwindow.org

************************************************************************
*
See you at IEMSS 2010: http://www.iemss.org/iemss2010/
************************************************************************
*

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/dotnet/attachments/20100601/5cc9d7f3/attachment-0001.html