[DotNet-OSGeo] More introductions and a joint development proposal...

Wed Jun 16 17:41:54 EDT 2010

So the rendering is at the top level.  This way, projects that use the same
layering, symbology, and data access can simply swap out what they use for
rendering pretty easily.  Right now the C# MapWindow6 Map control is 2D and
draws with GDI+.  However, we have a very early prototype for a DirectX 3D
map that is built on top of the same framework for the non-drawing
components.  Both implement a single IMap interface, so as far as the legend
component is concerned, we can unplug one map and plug in another very
easily.

Dan and I are interested in moving the code that we have for the various
MapWindow 6 components into the System.Spatial namespace, and then the code
will be centrally located so that we can focus as a larger group on how to
refactor these code libraries to better suit the multiple kinds of projects
that are out there.  There are, for example, going to be silverlight
projects that are allergic to the Forms and GDI+ drawing.  At the same time,
there are mono friendly projects that cannot work with WPF, but might be
able to digest silverlight (moonlight).  I'm currently working in .Net 3.5,
but there are purportedly some major advantages to switching to 4.0, like
allowing silverlight projects to reference libraries that are not
silverlight.

So maybe the first step is to make a basic dump of what we have and then
start getting feedback from the community on how we can go about refactoring
things to help as many people as possible.  Again, we want a bazaar, not a
cathedral in this environment.

Dr. Harold A. Dunsford Jr.  (Ted)
Dept. Geosciences
Idaho State University

On Wed, Jun 16, 2010 at 9:54 AM, Michael P. Gerlek <mpg at lizardtech.com>wrote:

>  I’m late getting back to the party, but…
>
>
>
> * How does MapWindow v6 do its graphics – WPF, Forms, GDI, DirectX, ..?
>
>
>
> * I’m totally in favor of filling out a Spatial namespace.  Not sure if it
> is PC to hijack the System top level namespace, but that aside I’d love to
> see something like this come together.  Especially if we can keep things
> safe for Mono folks too.  What can I do to help?   GDAL and liblas both have
> .NET bindings, so those could be used for raster and LAS support.
>
>
>
> * “OSGeo.NET” has a nice ring to it :-)
>
>
>
> * Do we have a listing of .NET geo projects somewhere?  I started a page (
> http://wiki.osgeo.org/wiki/DotNetProjects) once upon a time, but it is
> likely very out of date now.
>
>
>
> -mpg
>
>
>
> *From:* dotnet-bounces at lists.osgeo.org [mailto:
> dotnet-bounces at lists.osgeo.org] *On Behalf Of *Daniel Ames
> *Sent:* Tuesday, May 18, 2010 11:49 PM
> *To:* dotnet at lists.osgeo.org
> *Subject:* [DotNet-OSGeo] More introductions and a joint development
> proposal...
>
>
>
> Thanks to all of you who have joined this list in the last couple of days
> since we created it. Very cool to see that there is indeed interest in .NET
> open source! (Of course we all knew it...).
>
>
>
> OK, so by way of introductions, I've been the project leader of the
> MapWindow project for the past several years (http://www.MapWindow.org)
> which is a C++ ActiveX control wrapped by a VB.NET desktop application
> that hosts plugins - mostly written in C#. Of course it's all open source
> from the ground up. Our desktop app is probably the most popular tool in our
> arsenal with about 6,000 downloads per month.
>
>
>
> Our latest effort has been to create a fully C# version of everything for
> reasons that I'm sure you all would understand (such as getting away from
> ActiveX/COM "DLL Hell"...) That project is here:
> http://mapwindow6.codeplex.com
>
>
>
> As we've been working on this here in my lab in Idaho, it struck several of
> us that we should start working as a broader OSGeo .NET group on
> constructing a core set of libraries that fit snugly into the .NET
> Framework. The goal here would be to build on a common namespace in such a
> way that we result in tools that all live and work nicely together.
>
>
>
> So here is my proposal... we would like to participate in a group effort to
> develop a set of .NET based GIS related libraries under the "System.Spatial"
> namespace. This could include things such as "System.Spatial.Projections"
> "System.Spatial.Data" etc. All of these would be compatible libraries that -
> together - give programmers a complete set of tools for building GIS enabled
> software. We would just need all of the interested parties who are working
> on separate tools, to contribute their tools - retooled under the new
> namespace...
>
>
>
> Who knows... if we do it right, maybe Microsoft would go so far as to give
> it a stamp of approval and link to it from their .NET developer sites...
>
>
>
> In any case, please give this idea some thought... We have started a
> placeholder CodePlex project for this effort at
> http://dotspatial.codeplex.com and have made the first contribution which
> is a full port of PROJ4 to a C# DLL called System.Spatial.Projections.dll.
> We've also started listing ideas on what the various sub-namespaces could be
> (on that codeplex site  home page).
>
>
>
> Any feedback or thoughts on this idea would be much appreciated!  Also,
> anyone have any ideas on what a good "dotSpatial" logo might look like? and
> how could/should we get various developers of various low-level C# DLLs to
> contribute?
>
>
>
> Dan
>
>
> --
> 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/
> *************************************************************************
>
> _______________________________________________
> DotNet mailing list
> DotNet at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/dotnet
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/dotnet/attachments/20100616/6d627066/attachment.html