DotSpatial Wiki Rss Feed

Updated Wiki: Steering Committee

danames — Tue, 18 Jun 2013 17:06:57 GMT

Project Steering Committee

The DotSpatial Project Steering Committee consists of project leaders from several key .NET open source GIS projects as well as active users of .NET GIS libraries. The purpose of the steering committee is to help guide the development of the DotSpatial libraries, to make decisions on key project milestones and goals, and to help promote the libraries amongst the OSGeo and .NET open source communities.

The size of this committee is flexible though we are presently shooting for a committee of 12 or so. The Steering Committee discussion list is here: https://groups.google.com/forum/#!forum/dotspatial-sc

Current Steering Committee Members:

Daniel P. (Dan) Ames - Brigham Young University (Project Manager)
Aaron Parks - RTI International
James Rineer - RTI International
Gennadii Donchyts - Deltares
Arnold Engelmann - DHI Water and Environment
Kurt Wolfe - U.S. Environmental Protection Agency
Mark Gray - AQUA TERRA Consultants

Former Steering Committee Members:

Ted Dunsford - GEI Consultants
John Diss - Newgrove
Michael Gerlek - LizardTech
John Lindsay - University of Guelph
Paul den Dulk - Geodan
Jeen de Vegt - TopX Group

Project Steering Committee Actions

Our project steering committee meets by email and/or conference call to regularly discuss critical issues to help establish direction for the project. See the list of steering committee decisions.

Updated Wiki: Steering Committee

danames — Fri, 14 Jun 2013 22:55:58 GMT

Project Steering Committee

The DotSpatial Project Steering Committee consists of project leaders from several key .NET open source GIS projects as well as active users of .NET GIS libraries. The purpose of the steering committee is to help guide the development of the DotSpatial libraries, to make decisions on key project milestones and goals, and to help promote the libraries amongst the OSGeo and .NET open source communities.

The size of this committee is flexible though we are presently shooting for a committee of 12 or so including the following:

Current Steering Committee Members:

Daniel P. (Dan) Ames - Idaho State University (Project Manager)
Aaron Parks - RTI International
Gennadii Donchyts - Deltares
Arnold Engelmann - DHI Water and Environment

Former Steering Committee Members:

Ted Dunsford - GEI Consultants
John Diss - Newgrove
Michael Gerlek - LizardTech
John Lindsay - University of Guelph
Paul den Dulk - Geodan
Jeen de Vegt - TopX Group
Kurt Wolfe - U.S. Environmental Protection Agency
Mark Gray and Jack Kittle - AQUA TERRA Consultants

Project Steering Committee Actions

Our project steering committee meets by email and/or conference call to regularly discuss critical issues to help establish direction for the project. See the list of steering committee decisions.

Updated Wiki: Steering Committee

danames — Thu, 13 Jun 2013 14:53:32 GMT

Project Steering Committee

The DotSpatial Project Steering Committee consists of project leaders from several key .NET open source GIS projects as well as active users of .NET GIS libraries. The purpose of the steering committee is to help guide the development of the DotSpatial libraries, to make decisions on key project milestones and goals, and to help promote the libraries amongst the OSGeo and .NET open source communities.

The size of this committee is flexible though we are presently shooting for a committee of 12 or so including the following:

Current Steering Committee Members:

Daniel P. (Dan) Ames - Idaho State University (Project Manager)
Aaron Parks - RTI International
Gennadii Donchyts - Deltares

Former Steering Committee Members:

Ted Dunsford - GEI Consultants
John Diss - Newgrove
Michael Gerlek - LizardTech
Arnold Engelmann - DHI Water and Environment
John Lindsay - University of Guelph
Paul den Dulk - Geodan
Jeen de Vegt - TopX Group
Kurt Wolfe - U.S. Environmental Protection Agency
Mark Gray and Jack Kittle - AQUA TERRA Consultants

Project Steering Committee Actions

Our project steering committee meets by email and/or conference call to regularly discuss critical issues to help establish direction for the project. See the list of steering committee decisions.

New Comment on "AddingManyShapesCS"

achraf0A1 — Sun, 12 May 2013 14:00:55 GMT

can somebody help me? i want to add features, in my shapefile, i'm working with the vb net

New Comment on "Adding a Geographic Coordinate System to a Feature Set"

danwalkerak — Sun, 12 May 2013 06:24:44 GMT

was=has

New Comment on "TableVB"

achraf0A1 — Thu, 09 May 2013 14:58:56 GMT

please, how can i display all the values in a datagridview?

New Comment on "DotSpatial.Controls.Toolbox"

Luffy16 — Sun, 05 May 2013 17:53:41 GMT

Hi , I followed the steps of the questions "Why are there no tools in my toolbox?" and until now I don't have the toolbox loaded , could you please help me ? Thanks

Updated Wiki: Design Principles

danames — Tue, 30 Apr 2013 13:48:26 GMT

Design Principles

This page describes DotSpatial software design principles and project policies related to coding conventions, naming and namespaces, compiling and build settings, unit testing, deployment, etc.

Source Code Management

This project source code is managed through TFS (Team Foundation Server). To use the TFS connection, you need developer permissions. For read only access, use SVN.

Coding Conventions

An overarching goal is to develop tools that look and feel like the .NET framework. Therefore we try to follow the standardized .NET convention e.g. as described in The Framework Design Guidelines Book (http://www.amazon.com/Framework-Design-Guidelines-Conventions-Libraries/dp/0321545613) and as defined by the FxCop tool for Visual Studio or Gendarme for MONO. We also encourage following coding conventions defined by StyleCop.
All source code files should include the copyright notice header.
Contributors are encouraged note major code contributions and changes with a date in the header. This is primarily to help recognize contributions.
Our preferred language for the core components is C#. Extensions and applications can be written in C# or VB.NET or other .NET language.
U.S. English will be used for all internal documentation, exception strings, enumerations, and ToString methods in the core components. Internationalization will generally occur only at the application level.
Don't commit broken code.

Naming, Namespaces, Assembly, General Architecture

DotSpatial is the root of the namespace. Namespaces should be descriptive of function not of sub-project. In other words "Topology" not "NTS". This requires more integration of projects - but will also help meet the goal of a well-integrated project.
Assemblies should be named to match the associated namespace - e.g. DotSpatial.Topology.dll should contain the DotSpatial.Topology namespace.
Extensions of a namespace can be compiled to a separate assembly such as DotSpatial.Topology.Foo.dll. Extensions might also include project names such as DotSpatial.Data.Raster.GDAL.dll as a wrapper for the GDAL unmanaged code/data provider.
Maintain clear separation (e.g. in namespacing and assemblies - following MVVM style) of GUI code from core functionality - this is to help support unit testing as well as UI portability (e.g. use of WPF versus Silverlight versus Windows forms).
The core libraries including data, topology, tools, interfaces, and controls will not reference or require any external libraries beyond the .net framework.

Compiling and Build Settings

In Visual Studio 2010 Warning Level should be set to Level 4 and treat warnings as errors (find equivalent setting for Mono). We don't want code that generates lots of warnings.
Build Configurations: If a specific project contains only managed code, by default we should build using the anycpu compiler switch. The resulting managed module is PE32/agnostic, running on x86 Windows as a 32-bit application and on x64 Windows as a 64-bit application. Things are different when a project contains methods that call unmanaged code. We really have 2 cases here: If a specific project interoperates with unmanaged code (x86 library) we should build using the x86 compiler switch. The resulting managed module is PE32/x86, running on x86 Windows as a 32-bit application and on x64 Windows as a WoW64 application. If a specific project interoperates with unmanaged code (x64 library) we should build using the x64 compiler switch. The resulting managed module is PE32/x64, doesn't run on x86 Windows, and runs on x64 Windows as a x64 application.

Unit Testing

We will write extensive unit tests for all functions to test functionality against appropriate standards.
Use of multiple data sets for testing.

Deployment

Our goal is zip file based deployment. In other words, all current assemblies can be downloaded in a single zip file for use by third party programmers.
Applications can/should be deployed using an installer (e.g. MSI, Click Once, Inno Setup)

Assembly and Versioning Info

All Assembly information should be provided in every DotSpatial assembly as follows (either in the VersionInfo.cs, AssemblyInfo.cs, AssemblyInfo.vb):
- <Assembly: AssemblyTitle("DotSpatial.MyAssembly")>
- <Assembly: AssemblyDescription("Brief statement of purpose of the assembly.")>
- <Assembly: AssemblyCompany("DotSpatial Project Team")>
- <Assembly: AssemblyProduct("DotSpatial - www.dotspatial.org")>
- <Assembly: AssemblyCopyright("Copyright (C) 1998-2013 DotSpatial Project Team")>
- <Assembly: AssemblyTrademark("DotSpatial is a trademark of the DotSpatial Project Team")>
- <Assembly: AssemblyConfiguration("32 bit versus 64 bit or any CPU build/release")
- <Assembly: AssemblyCulture(if non-gui then state "Culture Neutral", otherwise state approach for handling languages)
- <Assembly: ComVisible(false)>
- <Assembly: CLSCompliant(true)>
- <Assembly: AssemblyVersion(major.minor)> This is where other assemblies that reference the assembly will look. If this number changes, other assemblies have to update their references to this assembly! The AssemblyVersion is required.
- <Assembly: AssemblyFileVersion(major.minor.revision.build)>Used for deployment. Increase this number for every deployment. It is used by setup programs. Use it to mark assemblies that have the same AssemblyVersion, but are generated from different builds.
- <Assembly: AssemblyInformationalVersion(Friendly Version Name)>This is the version we use when talking to users or for display on the website. This version can be a string, like '1.0 Release Candidate'. (see http://stackoverflow.com/questions/64602/what-are-differences-between-assemblyversion-assemblyfileversion-and-assemblyin)

Sample Code, Applications, and Programmer Documentation

Every assembly should have a short (paragraph) relatively static description on the CodePlex wiki.
All libraries and functions should have well documented sample code on the CodePlex web site.
A few small sample applications will be built that can be downloaded and explored as a means to study the API.
Internal code should be documented with the /// comment notation.

Copyright:

When you commit code to DotSpatial you are transferring your copyright of that code to the DotSpatial project copyright holders.

Updated Wiki: Design Principles

danames — Tue, 30 Apr 2013 13:46:01 GMT

Design Principles

This page describes DotSpatial software design principles and project policies related to coding conventions, naming and namespaces, compiling and build settings, unit testing, deployment, etc.

Source Code Management using Mercurial

This project is set up using Mercurial. This is a relatively new versioning control system that allows extremely rapid diff checks, commits and advertises itself as handling push and pull operations more smoothly than SVN. Here are some resources regarding Mercurial.

Coding Conventions

An overarching goal is to develop tools that look and feel like the .NET framework. Therefore we should follow the standardized .NET convention e.g. as described in The Framework Design Guidelines Book (http://www.amazon.com/Framework-Design-Guidelines-Conventions-Libraries/dp/0321545613) and as defined by the FxCop tool for Visual Studio or Gendarme for MONO. We also encourage following coding conventions defined by StyleCop.
All source code files should include the copyright notice header.
Contributors are encouraged note major code contributions and changes with a date in the header. This is primarily to help recognize contributions.
Our preferred language for the core components is C#. Extensions and applications can be written in C# or VB.NET or other .NET language.
U.S. English will be used for all internal documentation, exception strings, enumerations, and ToString methods in the core components. Internationalization will generally occur only at the application level.
Don't commit broken code.

Naming, Namespaces, Assembly, General Architecture

DotSpatial is the root of the namespace. Namespaces should be descriptive of function not of sub-project. In other words "Topology" not "NTS". This requires more integration of projects - but will also help meet the goal of a well-integrated project.
Assemblies should be named to match the associated namespace - e.g. DotSpatial.Topology.dll should contain the DotSpatial.Topology namespace.
Extensions of a namespace can be compiled to a separate assembly such as DotSpatial.Topology.Foo.dll. Extensions might also include project names such as DotSpatial.Data.Raster.GDAL.dll as a wrapper for the GDAL unmanaged code/data provider.
Maintain clear separation (e.g. in namespacing and assemblies - following MVVM style) of GUI code from core functionality - this is to help support unit testing as well as UI portability (e.g. use of WPF versus Silverlight versus Windows forms).
The core libraries including data, topology, tools, interfaces, and controls will not reference or require any external libraries beyond the .net framework.

Compiling and Build Settings

In Visual Studio 2010 Warning Level should be set to Level 4 and treat warnings as errors (find equivalent setting for Mono). We don't want code that generates lots of warnings.
Build Configurations: If a specific project contains only managed code, by default we should build using the anycpu compiler switch. The resulting managed module is PE32/agnostic, running on x86 Windows as a 32-bit application and on x64 Windows as a 64-bit application. Things are different when a project contains methods that call unmanaged code. We really have 2 cases here: If a specific project interoperates with unmanaged code (x86 library) we should build using the x86 compiler switch. The resulting managed module is PE32/x86, running on x86 Windows as a 32-bit application and on x64 Windows as a WoW64 application. If a specific project interoperates with unmanaged code (x64 library) we should build using the x64 compiler switch. The resulting managed module is PE32/x64, doesn't run on x86 Windows, and runs on x64 Windows as a x64 application.

Unit Testing

We will write extensive unit tests for all functions to test functionality against appropriate standards.
Use of multiple data sets for testing.

Deployment

Our goal is zip file based deployment. In other words, all current assemblies can be downloaded in a single zip file for use by third party programmers.
Applications can/should be deployed using an installer (e.g. MSI, Click Once, Inno Setup)

Assembly and Versioning Info

All Assembly information should be provided in every DotSpatial assembly as follows (either in the VersionInfo.cs, AssemblyInfo.cs, AssemblyInfo.vb):
- <Assembly: AssemblyTitle("DotSpatial.MyAssembly")>
- <Assembly: AssemblyDescription("Brief statement of purpose of the assembly.")>
- <Assembly: AssemblyCompany("DotSpatial Project Team")>
- <Assembly: AssemblyProduct("DotSpatial - www.dotspatial.org")>
- <Assembly: AssemblyCopyright("Copyright (C) 1998-2013 DotSpatial Project Team")>
- <Assembly: AssemblyTrademark("DotSpatial is a trademark of the DotSpatial Project Team")>
- <Assembly: AssemblyConfiguration("32 bit versus 64 bit or any CPU build/release")
- <Assembly: AssemblyCulture(if non-gui then state "Culture Neutral", otherwise state approach for handling languages)
- <Assembly: ComVisible(false)>
- <Assembly: CLSCompliant(true)>
- <Assembly: AssemblyVersion(major.minor)> This is where other assemblies that reference the assembly will look. If this number changes, other assemblies have to update their references to this assembly! The AssemblyVersion is required.
- <Assembly: AssemblyFileVersion(major.minor.revision.build)>Used for deployment. Increase this number for every deployment. It is used by setup programs. Use it to mark assemblies that have the same AssemblyVersion, but are generated from different builds.
- <Assembly: AssemblyInformationalVersion(Friendly Version Name)>This is the version we use when talking to users or for display on the website. This version can be a string, like '1.0 Release Candidate'. (see http://stackoverflow.com/questions/64602/what-are-differences-between-assemblyversion-assemblyfileversion-and-assemblyin)

Sample Code, Applications, and Programmer Documentation

Every assembly should have a short (paragraph) relatively static description on the CodePlex wiki.
All libraries and functions should have well documented sample code on the CodePlex web site.
A few small sample applications will be built that can be downloaded and explored as a means to study the API.
Internal code should be documented with the /// comment notation.

Discussion points needing resolution:

Which unit testing system to use?
If, how, where to set up automated builds?
If and how should we link the sample code in the wiki pages to the automatic builds and unit tests to ensure that the sample code does not get out of date?
Version numbering. How and who decides when the version numbering changes? Should each library change independently? or should there be a global Version 1.x of the full DotSpatial package?

Updated Wiki: Video Demonstrations

danames — Mon, 29 Apr 2013 20:10:49 GMT

Video Presentations of DotSpatial Projects

BYU GIS Programming Class Spring 2013

Project Team	Video Presentation	Title
Steve Hall & Jeff McCarty	http://youtu.be/ef8Y_JcugjU	Reservoir Builder
Jocelynn Anderson & Nicole Williams	http://youtu.be/QMV8LIu2X0Q	Hydropower Prospector
Paul Chatterton & Ashley Blood	http://youtu.be/W3KKhI-9GpQ	Hiking Trail Analyzer
Karsten Busby, Ed Kern, & Stephen Bolster	http://youtu.be/kDz9qJa1Uvo	Stream Profiler 1.0
Mitchell Hess & Justin Brewer	http://youtu.be/OlALbA3PsNg	Hydro Power Prospector
Scott Christensen & Spencer Taylor	http://youtu.be/HFAaBzx37Ps	Trail Statistics
Kevin Couch & Joel Johansen	http://youtu.be/O4gk2mML740	Hydro-Power Prospector
Tony Melcher & Herman Dolder	http://youtu.be/UQ0LdgmBBvI	Hydropower
David Merrell & Nathan Dye	http://youtu.be/IEUI965O4EU	Hitchhiker’s Guide
Jaycee Smith & Keelan Jensen	http://youtu.be/hULUEtdycPk	Hiking Trail Analyzer
Fidel Perez & Carlos A. Osorio-Murillo	http://youtu.be/piVy2dxNzKY	Soil Profiler
Kelvin Smith & Nathan Swain	http://youtu.be/M8m_lfzz3a4	Mole Map Beta
Derek Whitman & Derrick Turner	http://youtu.be/YiaZMY2WfsY	The Soil Profiler

Updated Wiki: Video Demonstrations

danames — Mon, 29 Apr 2013 20:10:19 GMT

Video Presentations of DotSpatial Projects

BYU GIS Programming Class Spring 2013

Project Team	Video Presentation	Title
Steve Hall & Jeff McCarty	http://youtu.be/ef8Y_JcugjU	Reservoir Builder
Jocelynn Anderson & Nicole Williams	http://youtu.be/QMV8LIu2X0Q	Hydropower Prospector
Paul Chatterton & Ashley Blood	http://youtu.be/W3KKhI-9GpQ	Hiking Trail Analyzer
Karsten Busby, Ed Kern, & Stephen Bolster	http://youtu.be/kDz9qJa1Uvo	Stream Profiler 1.0
Mitchell Hess & Justin Brewer	http://youtu.be/OlALbA3PsNg	Hydro Power Prospector
Scott Christensen & Spencer Taylor	http://youtu.be/HFAaBzx37Ps	Trail Statistics
Kevin Couch & Joel Johansen	http://youtu.be/O4gk2mML740	Hydro-Power Prospector
Tony Melcher & Herman Dolder	http://youtu.be/UQ0LdgmBBvI	Hydropower
David Merrell & Nathan Dye	http://youtu.be/IEUI965O4EU	Hitchhiker’s Guide
Jaycee Smith & Keelan Jensen	http://youtu.be/hULUEtdycPk	Hiking Trail Analyzer
Fidel Perez & Carlos A. Osorio-Murillo	http://youtu.be/piVy2dxNzKY	Soil Profiler
Kelvin Smith & Nathan Swain	http://youtu.be/M8m_lfzz3a4	Mole Map Beta
Derek Whitman & Derrick Turner	http://youtu.be/YiaZMY2WfsY	The Soil Profiler

Updated Wiki: Video Demonstrations

danames — Mon, 29 Apr 2013 16:05:54 GMT

Video Presentations of DotSpatial Projects

BYU GIS Programming Class Spring 2013

Project Team	Video Presentation	Title
Steve Hall & Jeff McCarty	http://youtu.be/ef8Y_JcugjU	Reservoir Builder
Jocelynn Anderson & Nicole Williams	http://youtu.be/QMV8LIu2X0Q	Hydropower Prospector
Paul Chatterton & Ashley Blood	http://youtu.be/W3KKhI-9GpQ	Hiking Trail Analyzer
Karsten Busby, Ed Kern, & Stephen Bolster	http://youtu.be/kDz9qJa1Uvo	Stream Profiler 1.0
Mitchell Hess & Justin Brewer	http://youtu.be/OlALbA3PsNg	Hydro Power Prospector
Scott Christensen & Spencer Taylor	http://youtu.be/HFAaBzx37Ps	Trail Statistics
Kevin Couch & Joel Johansen	http://youtu.be/O4gk2mML740	Hydro-Power Prospector
Tony Melcher & Herman Dolder	http://youtu.be/UQ0LdgmBBvI	Hydropower
David Merrell & Nathan Dye	http://youtu.be/IEUI965O4EU	Hitchhiker’s Guide
Jaycee Smith & Keelan Jensen	http://youtu.be/hULUEtdycPk	Hiking Trail Analyzer
Fidel Perez & Carlos A. Osorio-Murillo	http://youtu.be/m3FYzogDnUo	Soil Profiler
Kelvin Smith & Nathan Swain	http://youtu.be/M8m_lfzz3a4	Mole Map Beta
Derek Whitman & Derrick Turner	http://youtu.be/YiaZMY2WfsY	The Soil Profiler

Updated Wiki: Documentation

danames — Mon, 29 Apr 2013 16:00:14 GMT

Documentation for Programmers

DotSpatial Programmer Tutorials

Video demonstrations of DotSpatial based applications
Visit the DotSpatial Tutorials page
Review sample code
Develop a plugin, using our template.
Find the packages on nuget.

DotSpatial SDK Style Documentation

View the SDK-style documentation online or download the software development kit (SDK) style DotSpatial API documentation as a single chm file (use 7-Zip to extract it).

Developer Getting Started Guide

The Getting Started Guide was written in 2009 and is partly out of date. It could help get you started with the basics of dragging and dropping controls as well as controlling symbology. Any references to "MapWindow.dll" should be replaced with DotSpatial.

Library Specific Documentation

Documentation for Code Contributors

The design architecture of DotSpatial follows two paradigms. The first is to separate the graphical user interfaces from the business logic. The second is to use a larger number of modules to increase code reusability, and allow access to parts of the framework without requiring the entire thing. However, great energy is being spent to ensure the libraries work as well together as if they were all part of the same framework. Additionally, see the specific resources for users and code contributors below.

Which Libraries Have Documentation and Are Available For Download?

The goal of the DotSpatial framework is to increase code re-usability by subdividing a fully working GIS framework down into smaller, specialized components. Part of that process involves the separation of the System.Windows.Forms dependent GUI layer from the business layer. The major libraries are shown below.

**Framework Libraries**
Namespace	Contents	Available	Docs
DotSpatial.Analysis	WhiteBox and some functions from MapWindow
DotSpatial.Data	Data access objects for FeatureSet, Raster, & Images.
DotSpatial.Data.Rasters.GdalExtension	optional GDAL support for image and raster files.
DotSpatial.Modeling	Place holder for non-GUI modeling code
DotSpatial.Positioning	GeoFrameworks 2 and GPS.NET 3
DotSpatial.Projections	Proj4
DotSpatial.Serialization	XML serialization code for saving projects.
DotSpatial.Symbology	Layers, Cartographic Symbolizers
DotSpatial.Topology	NetTopologySuite/JavaTopologySuite Topology methods.

**Graphical User Interface Libraries**
Namespace	Contents	Available	Docs
DotSpatial.Controls	Map, Legend, Ribbon, Toolbox, Layout etc.
DotSpatial.Data.Forms	Data Dialogs or Open File dialog methods
DotSpatial.Modeling.Forms	Modeling controls, tool dialogs, and dialog elements
DotSpatial.Projections.Forms	Windows Forms Dialogs related to projections
DotSpatial.Symbology.Forms	Windows Forms Dialogs & components for symbology

Updated Wiki: Documentation

danames — Mon, 29 Apr 2013 15:59:48 GMT

Documentation for Programmers

DotSpatial Programmer Tutorials

Video demonstrations of DotSpatial based applications
Visit the DotSpatial Tutorials page
Review sample code
Develop a plugin, using our template.
Find the packages on nuget.

DotSpatial SDK Style Documentation

View the SDK-style documentation online or download the software development kit (SDK) style DotSpatial API documentation as a single chm file (use 7-Zip to extract it).

Developer Getting Started Guide

The Getting Started Guide was written in 2009 and is partly out of date. It could help get you started with the basics of dragging and dropping controls as well as controlling symbology. Any references to "MapWindow.dll" should be replaced with DotSpatial.

Library Specific Documentation

Documentation for Code Contributors

Which Libraries Have Documentation and Are Available For Download?

**Framework Libraries**
Namespace	Contents	Available	Docs
DotSpatial.Analysis	WhiteBox and some functions from MapWindow
DotSpatial.Data	Data access objects for FeatureSet, Raster, & Images.
DotSpatial.Data.Rasters.GdalExtension	optional GDAL support for image and raster files.
DotSpatial.Modeling	Place holder for non-GUI modeling code
DotSpatial.Positioning	GeoFrameworks 2 and GPS.NET 3
DotSpatial.Projections	Proj4
DotSpatial.Serialization	XML serialization code for saving projects.
DotSpatial.Symbology	Layers, Cartographic Symbolizers
DotSpatial.Topology	NetTopologySuite/JavaTopologySuite Topology methods.

**Graphical User Interface Libraries**
Namespace	Contents	Available	Docs
DotSpatial.Controls	Map, Legend, Ribbon, Toolbox, Layout etc.
DotSpatial.Data.Forms	Data Dialogs or Open File dialog methods
DotSpatial.Modeling.Forms	Modeling controls, tool dialogs, and dialog elements
DotSpatial.Projections.Forms	Windows Forms Dialogs related to projections
DotSpatial.Symbology.Forms	Windows Forms Dialogs & components for symbology

New Comment on "ReadProj4Strings"

tmanthey — Thu, 25 Apr 2013 09:31:00 GMT

That is outdated. ProjInfo now has static methods. In this example use: ProjectionInfo.FromProj4String("+proj=aea +lat_1=20 +lat_2=-23 +lat_0=0 +lon_0=25 +x_0=0 +y_0=0 +ellps=WGS84 +datum=WGS84 +units=m +no_defs ");

Updated Wiki: Discussion Images

danames — Mon, 04 Mar 2013 15:34:06 GMT

This is a test page

Updated Wiki: Discussion Images

danames — Mon, 04 Mar 2013 15:33:18 GMT

This is a test page

Updated Wiki: Roadmap

danames — Fri, 01 Feb 2013 17:40:28 GMT

Immediate Goals

Goals for 1.5 are generally related to enhanced stability (list bug numbers here that we should target):

Issue 23782 - GDAL Extension and GeoTiff files error
Issue 23848 - Feature selection

Version 1.4 was released in November 2012.

Seeking Functionality

In Fall 2010, Anderson Sandes did a survey of over 300 GIS professionals in an effort to assess the relative importance of selected GIS functionality. The results of his survey are currently in preparation for publication in a GIS journal. Results indicate the following ranking of GIS functionality (with average "importance rating" in parentheses.):

(1) view vector data: 6.51, (2) view attribute data: 6.48, (3) display data on map: 6.42, (4) support different projections and coordinates systems: 6.40, (5) edit attribute data: 6.35, (6) save edited attribute data: 6.34, (7) edit vector data: 6.32, (8) save edited vector data: 6.32, (9) view raster data: 6.14, (10) perform basic analyses (e.g. clip features and create buffers): 6.06, (11) connect to databases: 5.94, (12) perform joins and spatial joins: 5.91, (13) allow printing of maps: 5.9, (14) allow customization of map symbology: 5.80, (15) perform georeferencing: 5.76, (16) perform advanced analyses (e.g. density, interpolation): 5.5, (17) support web-based data sources (e.g. support conversion to KML format and create web mapping services: 5.29, (18) perform statistic analyses (e.g. analyses of patterns and clusters): 5.10, (19) save edited raster data: 5.08, (20) edit raster data: 4.8, and (21) geocode: 4.78.

The following table lists each of these categories of functionality together with specific DotSpatial details and tasks, in the context of a road map for releases of the DotSpatial library.

Feature/Functionality	Associated Issue(s)	Version	Version	Version	Version	Version
		0.7 1 Oct 2010	0.8 31 Jan 2011	0.9 31 Mar 2011	1.0 13 June 2011	1.1
Read and Write Vector Data
- Shapefiles (Read/Write)		X	X	X	X
- WFS (Read)					X
- ESRI Personal Geodatabase (Read/Write)
- Other
Read and Write Raster Data
- Binary Grid, BGD (Read/Write)		X	X	X	X
- GeoTIFF (Read/Write)					X
- ESRI Coverage (Read)
- Web Coverage Service, WCS (Read)					X
- NetCDF (Read/Write)					X
Map Display and Interaction
- Symbology		X	X	X	X
- Zoom and Pan Navigation		X	X	X	X
- Layer Management	250	X	X	X	X
- Complex Symbology		X	X	X	X
Labeling
- Simple Feature labeling		X
- Label Rotation Based on a Feature Attribute	246
Attribute Tables
- DBF (shapefile) (Read/Write)
- ODBC Database Connection (Read/Write)	206
Topology and Topological Analyses		X	X	X	X
- NTS integration		X	X	X	X
- Topological analyses			X	X	X
Plugins/Extensions			X	X	X
- GPS			X	X	X
- Model Builder and tools			X	X	X
- GPS Integration			X	X	X
- Improved Feature/Raster/Image Identifier	249			X
				X
Projections
- Support all MW4 Projections and better Projection info	194, 247, 245
Project Management
- Support all MW4 Project Files and Symbology Files
- DotSpatial Project files (dspx)
Documentation
- End user/GUI documentation
- Programmer documentation
- Demonstration Code

New Comment on "RandomPointsVB"

camiza — Sat, 22 Dec 2012 18:47:50 GMT

After executing the code and move the points, make a selection and FID value of the elements of the selection is -1, anyone can help me? Sorry for my English... :)

New Comment on "TableVB"

mark00153 — Sun, 09 Dec 2012 15:23:15 GMT

Revised: Dim fs As FeatureSet = FeatureSet.Open(FilePath) fs.FillAttributes() Dim dtOriginal As DataTable = fs.DataTable For row As Integer = 0 To dtOriginal.Rows.Count - 1 Dim original As Object() = dtOriginal.Rows(row).ItemArray Next