Positioning namespace sample code?

Editor
Jan 29, 2011 at 9:50 PM

I've poked around all the available resources and am unable to find a basic intro to the Positioning namespace. Can anybody point me in the right direction, or provide some (C#) code samples? The API documentation is pretty thin.  I'm looking to connect a USB or Bluetooth GPS device and parse the raw NMEA strings.  I've got a Earthmate BT-20 that works great, but of course, uses a 'standard NMEA' string format that is not quite the same 'standard' as the Garmin.  DeLorme (the manufacturer) has yet to make the mainstream of GPS vendors supported in most common geospatial apps, but they make a solid product.

If there is an effort underway to get some documentation together (like there is in the GIS specific namespaces), I'd be happy to particiapte once I get a handle the object model.  I'm also wondering if anybody has ported any of the Positioning classes to the .NET MicroFramework?  On the embedded development end of the spectrum, folks are using something like a GHI FEZ device to standardize data retrieval from GPS devices on a common (open source) library that running on .NET MF.  The Positioning libraries go along way toward a well organized object model to meet that goal, and I would be jazzed to fill in the gaps between these two OS efforts.

Cheers,

Eric

Coordinator
Jan 31, 2011 at 4:58 AM
Hi Eric. Others can comment on this as well, but I can tell you that the online documentation for the DotSpatial API which can be found here: http://www.mapwindow.org/downloads/documentation/dotspatial/web-friendly/Index.html was automatically generated from the comments in the source code. So if the documentation on .Positioning is too sparse, then we need to have someone (either the original developers or users like yourself) go in and add documentation through comments in code so that when we rebuild the online API doc, it will capture it... - Dan

On Sat, Jan 29, 2011 at 3:50 PM, ransomhall <notifications@codeplex.com> wrote:

From: ransomhall

I've poked around all the available resources and am unable to find a basic intro to the Positioning namespace. Can anybody point me in the right direction, or provide some (C#) code samples? The API documentation is pretty thin. I'm looking to connect a USB or Bluetooth GPS device and parse the raw NMEA strings. I've got a Earthmate BT-20 that works great, but of course, uses a 'standard NMEA' string format that is not quite the same 'standard' as the Garmin. DeLorme (the manufacturer) has yet to make the mainstream of GPS vendors supported in most common geospatial apps, but they make a solid product.

If there is an effort underway to get some documentation together (like there is in the GIS specific namespaces), I'd be happy to particiapte once I get a handle the object model. I'm also wondering if anybody has ported any of the Positioning classes to the .NET MicroFramework? On the embedded development end of the spectrum, folks are using something like a GHI FEZ device to standardize data retrieval from GPS devices on a common (open source) library that running on .NET MF. The Positioning libraries go along way toward a well organized object model to meet that goal, and I would be jazzed to fill in the gaps between these two OS efforts.

Cheers,

Eric

Read the full discussion online.

To add a post to this discussion, reply to this email (DotSpatial@discussions.codeplex.com)

To start a new discussion for this project, email DotSpatial@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com




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


Developer
Jan 31, 2011 at 4:56 PM

The beauty of this XML-style documentation is that the documentation lives right with the code and this means it is easy to keep the comments in sync with the code. If a developer changes the code, they can check to make sure the documentation is still complete. Also, these comments will appear as part of intellisence, so a developer can "check the documentation" from within the IDE.

 

There are many recognized XML tags.

http://msdn.microsoft.com/en-us/magazine/cc302121.aspx

Editor
Jan 31, 2011 at 6:16 PM

Daniel & mudnug:

I'm all over using XML commenting and tools like SandCastle.  My own code commenting usually suffers from the same issues. It tends to be sparse and added late because the boss said to at a code review. I've found that documentation like code examples, and 'see also' links are often not included in the XML because of the extra effort involved (particularly formatting the examples; code inside code???). Turns out it make a big difference when coming up to speed on a new object model. The skill comes in presenting it in a way that is both helpful, straightforward, and makes sense at a high level. Devs tend to get lost in the 'code weeds' and miss that point. I can see this effort happening on the GIS side of this codebase, but am personally more interested in the device related stuff (see prev post).  I could spend a few cold winter nights figuring all this out, but would rather help add these details so the next guy who wonders how he can write his own GPS tool comes away from the experience believing it's the best thing since [insert cliche here].

In an attempt to garner some creds on this forum, it's worth mentioning that I do MS development for a living, and also have a degree in Geology. I am familiar with the current state of the GIS/GPS/GeoXXX software market in general.  I find the best options overpriced, and the worst options just that - not worth downloading even if they are free. I'm not a hobbyist with nothing better to do on the aforementioned winter nights than whining that I can't find the ON button. Well, I really don't have much else to do with my free time after the kids are in bed, but that is another matter...

Looking forward to helping out,

Eric

 

Developer
Jan 31, 2011 at 6:49 PM

Hi Eric, I'm glad to hear you re getting involved, and I think DotSpatial is in a very critical niche right now that is drastically undersupported for Windows .Net.  MapWindow and DotSpatial are essentially the hot topic and open source hasn't been as popular in Windows because licensing usually is a problem.  Our compromise is to drop back some of our own protections so that commercial users can use it, and hopefully this will help start up the market for GIS code that raise the bar for the starting point for developers interested in GIS.

Part of our hope is to pull together various open initiatives into a cohesive framework that is hopefully not too challenging to actually use.  DotSpatial has a lot of intellisense comments, but I think suffers in the area of redundancy.  In other words, a lot of my comments are sort of meaningless restatement of the property name.  So the property is named "FillColor" and the comment might be something like "Gets or sets the FillColor for this layer".  What people getting started really need is an example showing how to use the FillColor correctly along with other concerns.  How do you set the fill color of a shape based on its index?  How do you set the fill color based on an attribute?  How do you change the fill color for a selection?  Etc.  My hope is that this kind of supportive example code will grow on the site as developers continue to post informative help.

In some cases, the intellisense is even worse off.  That is, we inherited a GPS3/GeoFramework2 library that is now Positioning, and so it is legacy code that was more or less uncommented and undocumented.  This is fine, but there is no magic bullet here.  Someone will have to add that eventually by hand.  The challenge is that as our initiative grows and more components get donated, it is more and more likely that that code will be missing even the basic intellisense comments.  Professional software pays for people to create that stuff, but it costs a lot of money.  The amount of ESRI documentation is staggering, and people still feel lost when using it.  Our best hope is to have an active human community that can respond to questions reasonably quickly with the pertinent bits to help someone get unstuck.  If we can keep that going, then the formal documentation issue is less deadly, and over time has a tendency to write itself in the form of answers to real questions.  Anyway, that has been my experience with open source documentation.  We'll do the best we can though.

Ted

Developer
Feb 1, 2011 at 9:42 AM
Edited Feb 1, 2011 at 10:02 AM

Eric, DotSpatial.Positioning under the main trunk of the repository builds but will not detect any devices - it's still not working since security attributes were changed after the original code was contributed to DotSpatial from GPS.NET and GeoFrameworks projects in a working state for .NET versions up to and including .NET 4.0. The only "working" version is in the DotSpatial\DotSpatial.Positioning\DotSpatial.Positioning.Compact folder - despite it's name it isn't just for the compact framework. The solution can be found in DotSpatial\DotSpatial.Positioning\DotSpatial.Positioning.Compact\GPS\DotSpatial.Positioning (Visual Studio 2010).sln though I notice that the project paths are mangled so you may need to find the projects yourself. GPS Diagnostics (CSharp).csproj is a demo application that shows pretty comprehensively how to use the libraries. No-one has ported the code to .NET MicroFramework that i'm aware of but it shouldn't be too hard to acheive.

[Edit] Inherited Legacy Code? "Legacy code is source code that relates to a no-longer supported or manufactured operating system or other computer system" - Ouch Ted!

Editor
Feb 2, 2011 at 1:49 AM

Just the needle I was looking for. Thx tidyup!

I managed to get the demo app running, detect a device, and start collecting data with a minimum of effort.  This is a great starting point. The Position.GPS namespace actually does have some decent xml commenting, and the demo app puts it all together nicely.  I would like to hear opinions on why this namespace has a bunch of WinForms controls in it.  The rest of the classes are decidedly data centric.  Any thoughts on refactoring these Controls into a more appropriate (UI specific) library?  I'll do a little more analysis over the next week and come back with some suggestions.  What's the process for moving forward with changes? Does one of you coordinate that, or is it more or less a free for all? 

Thanks for all the great feedback,

Eric

Developer
Feb 2, 2011 at 9:15 AM

Glad to be of help Eric - It's great to see some interest building in developing DotSpatial.Positioning as it's pretty much just been BigStickCarpet and myself for some time now! We're both busy with full time jobs but still keen to help where we can. It would be good to have you on board to help with the DotSpatial.Positioning side of things so please feel free to join the project as a developer.

I guess these forums and the DotSpatial developers Google group provide the place to discuss further development. Even though I brought the library to DotSpatial I'm just another developer on DotSpatial so the coordination of these efforts should come from Dan, Ted or Mike. These forums and the DotSpatial developers google group would provide the place to discuss further development as a total free for all might get a little too out of control ;). Go ahead and contact me directly in regards to Positioning related stuff if you think it would make things easier. We can always post info of public interest to the forums and cc the coordinators. Perhaps It would be good to get someone (me or BigStick?) who has a bit of history with the projects involved in the decision making process in relation to the Positioning libraries and DotSpatial integration.

As these projects come from a previously commercial heritage the user controls were bundled into the GPS library probably for simplicity of use. The Winforms controls (obviously) are used to display the GPS data in a graphical interface so we never found reason to pull them out. If your thinking embedded I can see why you might want to modularize the library - I can't think of any major reasons off the top of my head why they couldn't be pulled to a separate dll. I know Ted has some cautionary thoughts on dependencies and fragmentation but I'm not sure we need to be concerned about that kind of thing in this case as the UI controls are pretty discrete at this stage. I guess this may change if/when the geo-spatial parts are merged more tightly with DotSpatial proper.

Developer
Feb 2, 2011 at 3:51 PM

Actually, I think separating out the WindowsForms stuff is appropriate, and is very much in the theme of what we have done elsewhere.  How easy it will be I don't know, but hopefully it won't be terrible.  Especially if we separated it into DotSpatial.Positioning.Forms.  This would follow the model we have tried to implement everywhere else in DotSpatial to separate the UI stuff.  I'm not saying we have succeeded everywhere, but my goal is to have anything that references System.Windows.Forms in the DotSpatial.XXX.Forms sub project.  Also, I like the "Design" strategy that was demonstrated by the creative authors of GPS3/GeoFrameworks.  It separates out the stuff that relies on System.Design or whatever so that you could build the WindowsForms classes using the Client Profile.  We have not succeeded at doing that for all DotSpatial yet, but with the exception of the use of the property grid control in the layout view, it should not be hard to accomplish and would make our libraries even more useful for folks.  The organizational rule is that each project should have a folder like if you are working with DotSpatial.Positioning, we should have a folder for DotSpatial.Positioning.  This folder should contain the DotSpatial.Positioning, DotSpatial.Positioning.Design and DotSpatial.Positioning.Forms projects.

If you want to help Eric, we would be delighted to make you a developer if you aren't one already.  Don't worry about too much chatter on this just yet, since there are only about three of you guys outside of myself that are even involved with this.  Keeping the world informed on your improvements is appreciated.

Ted

Coordinator
Feb 2, 2011 at 4:03 PM
Agreed. This is a good example of trying to make all the code consistent so that future users and developers can find stuff where they expect to. In that spirit I like the idea of the winforms controls being in a DotSpatial.Positioning.Controls name space so that it follows like the other project components... Eric, I know that Tidyup and BigStick would be very happy to have another person helping with some of this work. So let's do get you developer rights... - Dan

On Wed, Feb 2, 2011 at 9:51 AM, shade1974 <notifications@codeplex.com> wrote:

From: shade1974

Actually, I think separating out the WindowsForms stuff is appropriate, and is very much in the theme of what we have done elsewhere. How easy it will be I don't know, but hopefully it won't be terrible. Especially if we separated it into DotSpatial.Positioning.Forms. This would follow the model we have tried to implement everywhere else in DotSpatial to separate the UI stuff. I'm not saying we have succeeded everywhere, but my goal is to have anything that references System.Windows.Forms in the DotSpatial.XXX.Forms sub project. Also, I like the "Design" strategy that was demonstrated by the creative authors of GPS3/GeoFrameworks. It separates out the stuff that relies on System.Design or whatever so that you could build the WindowsForms classes using the Client Profile. We have not succeeded at doing that for all DotSpatial yet, but with the exception of the use of the property grid control in the layout view, it should not be hard to accomplish and would make our libraries even more useful for folks. The organizational rule is that each project should have a folder like if you are working with DotSpatial.Positioning, we should have a folder for DotSpatial.Positioning. This folder should contain the DotSpatial.Positioning, DotSpatial.Positioning.Design and DotSpatial.Positioning.Forms projects.

If you want to help Eric, we would be delighted to make you a developer if you aren't one already. Don't worry about too much chatter on this just yet, since there are only about three of you guys outside of myself that are even involved with this. Keeping the world informed on your improvements is appreciated.

Ted

Read the full discussion online.

To add a post to this discussion, reply to this email (DotSpatial@discussions.codeplex.com)

To start a new discussion for this project, email DotSpatial@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com




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


Dec 15, 2012 at 1:16 AM

Hi Everybody,

I have just downloaded dotspatial from dotspatial.codeplex.com.

When i open solution from my HDD: \DotSpatial.Positioning\DotSpatial.Examples.DemoGPS\C#\GPS Diagnostics (CSharp) in VS2012, i got messages:

Solution 'GPS Diagnostics (CSharp)' (0 projects)

DotSpatial.Positioning (load faild)

DotSpatial.Positioning.Design (load faild)

DotSpatial.Positioning.Forms (load faild)

GPS Diagnostics (CSharp) (unavailable)

Please help,

Thank you,