GeoFrameworks Issue Tracking System

Issue #321 (Assigned, Research in progress): Trial error on using SatelliteViewer and SatelliteSignalBar

Mon, 24 Aug 2009 01:34:09 GMT

Monday, July 06, 2009 at 1:55:49 AM by Jan van Veen

Hello,

We've licensed the Control Toolbox components.
We're using the SatelliteViewer and SatelliteSignalBar.
But when we try to open the form, which contains these controls, a trial exception (on the GeoFrameworks.GPS assembly) is raised.
In our Program.cs (Main routine) we've added our license key.

Is this a known issue?
Or can't we use these controls with our license?

If you need further information, I'm willing to send this.

Thank you in advance,

Jan van Veen
VekraSOFT

Tuesday, July 14, 2009 at 6:00:02 AM by Jan van Veen

Hello,

We're one week later, and still no response.
Can you please respond to my problem?

Thanks.

Jan van Veen

Tuesday, July 14, 2009 at 12:27:13 PM by Jon Person

Hi Jan, my apologies for the delay in responding to this issue.  We had to fire the person in charge of support while we were out of town who, alas, also apparently took a vacation.    I'll be happy to refund you for the User Controls took box since this was a clear slip-up on our part.

Can you send me a portion of the exception you're getting?  I want to make sure that you're using the latest version of the libraries and that you're referencing the correct .NET platform.

I'll be available on MSN Messenger as well.  If you're on, this will help us get a solution more quickly.

Thursday, July 16, 2009 at 5:54:45 AM by Jan van Veen

Dear Jon,

Thanks for the refund.

I added you to MSN messenger, but didn't see you online recently.

Here are the source files of my form, where the problem is located.
We're using VS2008 on Microsoft .NET CF 3.5.

[editied, public system]

Thanks in advance,

Jan van Veen

Friday, July 17, 2009 at 6:16:44 AM by Jan van Veen

Dear Jon,

I received the Refund notification.
Did you also managed to download my source files?

Thanks in advance,

Jan van Veen
VekraSOFT

Tuesday, July 21, 2009 at 9:42:10 AM by Jon Person

Jan, can you please email them to me? I edited the link out of your message since this is a public system.

Friday, August 14, 2009 at 5:08:26 AM by Jan van Veen

Dear Jon,

I sent you the files before my holiday (3 weeks ago) and didn't receive a reaction.
Did you receive my e-mail correct?

Thanks for your response,

Kind regards,

Jan van Veen
VekraSOFT

Monday, August 24, 2009 at 1:34:09 AM by Jan van Veen

Again, another week has passed without a sign of life...
Can anyone please respond to my issue?!

Thanks.

Jan van Veen
VekraSOFT

Issue #334 (Fixed (Queued for release)): Roll Back GPS.NET 3.0 Controls to 2.0

Sun, 26 Jul 2009 14:18:05 GMT

Tuesday, July 21, 2009 at 11:06:40 AM by Jon Person

The general consensus of the beta is that the 3.0 user controls are not as good as they were in 2.0. Unless somebody objects here, I will proceed with rolling all of the controls back to how they looked and behaved in version 2.0, then reengineer the Radar control.

Anyone object to this?

Sunday, July 26, 2009 at 2:18:05 PM by Jon Person

3.0 controls have now been rolled back to 2.0. I wish this would have happened during the beta period, but this timing could not have been avoided.

Optimizations were put in place to improve the performance of these controls as well.

Issue #339 (Released): GeoFramework 2.0.0 Source Code Now Available on CodePlex!

Sun, 26 Jul 2009 11:58:06 GMT

Sunday, July 26, 2009 at 11:58:06 AM by Jon Person

I'm very pleased to announce that the complete C# source code for the GeoFramework library is now available on CodePlex! (This is the source code for GeoFramework.dll.) This library has been stable and unchanged for some time, and I feel that the objects presented in this library are low-level enough to be open-source while not undercutting ourselves.

Due to licensing, existing users of GPS.NET and GIS.NET will still need to use the assemblies we publish. Yet, this open source project will give developers the opportunity to extend the framework and revise it as they see fit.

You can find the project online here: http://geoframework.codeplex.com

Issue #12 (Postponed for Later): Cannot find GPS device for HTC Kaiser, HTC Polaris, HTC Touch Cruise, HTC TyTN II, AT&T Tilt, AT&T 8925, and anything else with the word "QualComm" in it.

Fri, 20 Jun 2008 08:50:43 GMT

Tuesday, May 06, 2008 at 2:40:06 AM by Jon Person

Reports have arrived regarding mobile devices manufactured by High Tech Computing (HTC), namely the HTC Kaiser, TyTN II, AT&T Tilt, and AT&T 8925. This device uses a proprietary GPS Intermediate Driver (GPSID) which GPS.NET has problems with. Specifically, the GPSID is supposed to allow users to configure any shared port name (e.g. the "Program Port"), as well as any hardware port. Strangely, however, attempts to set the hardware port on these devices always fails. The port always returns to "(None)" no matter what we try and set it to.

Tuesday, May 06, 2008 at 2:42:50 AM by Jon Person

I now have an AT&T Tilt device in-house. After a couple of hours, I'm able to get NMEA data from the device, but I'm seeing a number of issues. First, to connect to this device, a manual connection to COM4: at 4800 baud is required. I was able to get GPS data by creating an NmeaStream using a SerialStream on COM4: at 4800 baud:

NmeaStream test = new NmeaStream(new SerialStream(CommunicationPort.Com4, BaudRate.Baud4800));

... next, however, is the actual NMEA data. Several NmeaSentenceException errors are being thrown because the NMEA data arriving from the HTC is malformed. Since the checksum calculation is failing, a majority of NMEA data from the device is being distrusted by GPS.NET.

Tuesday, May 06, 2008 at 2:45:09 AM by Jon Person

Since we can't just tell end-users to stop using the $700 mobile device they've already purchased, a workaround will now be necessary to support the HTC devices. Specifically, I will need to record the malformed NMEA sentences then adjust the NmeaSentence objects to be more lax when it comes to enforcing the checksum. This is a horrible workaround to implement because the checksum is critical to determine whether or not data is trustworthy. Simply ignoring the checksum can cause all manner of inaccurate data to become trusted. I will try to implement this workaround ONLY for devices with a proprietary GPSID; this should let GPS.NET continue to enforce NMEA checksums unless there's no other choice.

Tuesday, May 06, 2008 at 2:46:07 AM by Jon Person

5/6/2008: I'm researching the malformed NMEA checksums now and hope to begin work on a patch today. With the beta of GIS.NET 3.0 coming up on the 15th, it'll be a little tough to get time to get this implemented smoothly, but it's my top priority for GPS.NET 2.0. This fix will not be deferred to 3.0.

Tuesday, May 06, 2008 at 5:46:51 AM by Jon Person

So, it looks like the GPS.NET 2.3.21 workaround for HTC devices is to somehow detect the host device as HTC (if that's possible), then utilize COM4:/4800. This is a normal combination, so now why doesn't 4/4800 auto-detect?

Tuesday, May 06, 2008 at 6:44:43 AM by Jon Person

After examining the NMEA data, it is actually a lot more healthy than I expected.  Only a few errors are thrown by the AT&T Tilt.  $GPGGA sentences are completely blank before a fix is obtained:

OK: $GPRMC,,V,,,,,,,,,,N*53
OK: $GPGSA,A,1,,,,,,,,,,,,,,,,*32
OK: $GPVTG,,T,,M,,N,,K*4E
OK: $GPGSV,3,1,10,01,69,354,,05,17,061,27,11,27,292,,12,10,047,*7A
OK: $GPGSV,3,2,10,14,50,046,,20,11,306,23,22,37,113,27,30,21,081,27*73
OK: $GPGSV,3,3,10,31,64,174,30,32,66,326,*7F
Failed sentence: $GPGGA,,,,,,0,,,,,,,,*66
      Exception: A $GPGGA sentence contained unrecognizable data.
          Trace:    at GeoFramework.Gps.Nmea.GpggaSentence..ctor(String sentence) in C:\Source Code\GPS.NET\2.3.20\Nmea\GpggaSentence.cs:line 225
   at GeoFramework.Gps.Nmea.NmeaStream.ReadSentence(Boolean allowExceptions) in C:\Source Code\GPS.NET\2.3.20\Nmea\NmeaStream.cs:line 740
   at GeoFramework.Gps.Nmea.NmeaInterpreter.OnParseIncomingData() in C:\Source Code\GPS.NET\2.3.20\Nmea\NmeaInterpreter.cs:line 2075
   at GeoFramework.Gps.Interpreter.ParsingThreadProc() in C:\Source Code\GPS.NET\2.3.20\Interpreter.cs:line 1428

Monday, May 19, 2008 at 5:51:11 AM by Jon Person

Okay... some more information on the infamous HTC TyTn II. It appears now that this "cutting edge" device supports only 4800 baud connections in the GPSID. This design breaks the standard once again (can you tell I'm disappointed with this device?) since some GPS connections should work at any baud rate. Connections to the GPSID and Bluetooth devices typically support ANY baud rate simply because a virtual serial port is accepting the connection. When the TyTn II is first detected, GPS.NET is using a baud rate of 57600, which is not supported.

Every other aspect of this device is really great! I mean, I use this device as my phone now. But OH MY GOD the GPS chip is horrible. At any rate, I need to work on getting the HTC's GPSID to use 4800 baud.

Monday, May 19, 2008 at 7:55:30 AM by Jon Person

And now the plot thickens. I have GPS.NET automatically (and gracefully) detecting the QualComm GPS Chip. But now, upon connection, the QualComm chip returns no data for about 9-10 seconds, then transmits ar large chunk of sentences. There is no steady stream of NMEA data from this device. Increasing the NmeaStream.ReadTimeout to 10 seconds works around this delay, but I'm concerned now about latency. Holy mother of God, can this chip get any worse? Seriously, DONT BUY THESE DEVICES IF YOU WANT TO WRITE A COMMERCIAL GPS APP. I don't care how pretty and shiny they are.

Monday, May 19, 2008 at 7:58:17 AM by Jon Person

Considering the large number of people using this device, I'm going to push out a fix today with this workaround. Hopefully I can nail down the ten-second delay, but if I can't people should at least be able to get an inflow of data and get this device detecting smoothly. It's 10AM now, I'll crank on this until about noon.

Monday, May 19, 2008 at 8:34:56 AM by Jon Person

Sure enough, the TyTn reports an eight-second delay between bursts of NMEA data.  This is a severe problem and it reminds me of a similar problem long ago on the Epic Fail Hewlett-Packard HW6515 which had a similar delay.  Look at the UTC Time values (the 1st words after $GPGGA):

10:00:54 AM --> $GPGSV,3,3,11,22,52,284,25,24,21,122,16,26,07,037,23*42
[EIGHT SECOND PAUSE]
10:01:03 AM --> $GPGGA,160054.0,3933.395726,N,10500.860317,W,1,10,1.2,1702.5,M,,,,*21
10:01:04 AM --> $GPGSV,3,1,11,03,30,289,18,06,41,260,20,09,27,105,14,14,29,206,15*77
[EIGHT SECOND PAUSE]
10:01:12 AM --> $GPGSV,3,2,11,15,20,043,14,18,68,021,29,19,15,317,29,21,63,119,21*7D
10:01:12 AM --> $GPGGA,160104.0,3933.395747,N,10500.859950,W,1,07,2.4,1702.5,M,,,,*22

... after the pause, the time reported is now eight seconds behind.  This is a bad chip, folks.

A build is now underway with this patch.  When it's released, you'll start seeing the GPS detected like this:

"Shared GPS Device (QualComm GpsOne Card, version 0.0)"

... the SharedGpsDevice class will look for this registry key to identify HTC devices:

HKLM\System\CurrentControlSet\GPS IntermediateDriver\Drivers\GPSOneDevice

... when present, the port COM4: at 4800 baud will automatically be set as the base device, allowing the device to be used automatically without any extra code.  There's a chance that the design of other GPS.NET classes may be responsible for the delay.  Since I've already identified areas of improvement for 3.0, I'll likely make the TYTN the first target test device for the new framework to see if that does the trick.

The release supporting this workaround will be online by 12:00 Noon today, Mountain Time.

Friday, June 20, 2008 at 8:50:43 AM by Jon Person

In the interest of giving developers more control over the timeout of reading NMEA data, I've added two static properties to NmeaStream, DefaultReadTimeout and DefaultWriteTimeout. This property will be set to 3-5 seconds by default, but for QualComm chipsets this will be set to 15 seconds.

Issue #337 (Assigned, Research in progress): TypeInitializationException occurs in C# GPS 3.0 demo project.

Thu, 23 Jul 2009 18:14:30 GMT

Thursday, July 23, 2009 at 12:08:15 PM by Tony Dantona

I get a TypeInitialization error when I start up the C# demo project. I was told this error is due to an expired license. I downloaded the latest demo which indicates the license is good until Aug 1st, 2009, but this did not resolve the issue. I even substituted a license sent to me by Jon Person which I was told was valid until Sept 15:
[assembly: GeoFrameworksLicense("175FD1-3JB254-XAB1Y1-X3X31X-5GUXA3-3AYVXM")]
To no avail.

Thanks,
Tony

Thursday, July 23, 2009 at 6:14:30 PM by Jon Person

The key does indeed look valid.

Which GeoFrameworks references are you using in your project?

Issue #336 (Assigned, Research in progress): Maximizing the window containing GIS.NET takes you to the wrong lat/long on the map.

Wed, 22 Jul 2009 08:39:48 GMT

Wednesday, July 22, 2009 at 8:39:48 AM by Franklin Hernandez Paz

When maximizing, the GIS.Net component takes you further north and at a high zoom level. I have to zoom in to allow me to see the map as the only thing I can see is the ocean (blue background). I use VS 2008 and this happens randomly on any of the samples that come with the compent. Easy to reproduce by just running on of the samples and try to maximize (first thing) before panning the map.
Best Regards
Franklin

Issue #330 (Released): Selection Should Redraw when Selected Objects Change

Tue, 21 Jul 2009 11:27:09 GMT

Tuesday, July 21, 2009 at 6:52:35 AM by Rui Guimaraes

If an object is manualy deselected the object will still look selected in the map. You have to take some action (like moving the map) for the image to refresh.

This is more strange when you manually move a selected object. The selection will still be in the previous place and the object will be in another. Only after you pan/zoom/etc the map, the selection will be in the right place

Tuesday, July 21, 2009 at 9:53:46 AM by Jon Person

[some sample code which modifies the position of a Marker.  The marker is also selected, yet the selection does not change]

   void _node_PropertyChanged(object sender, System.ComponentModel.PropertyChangedEventArgs e)
        {
            if (e.PropertyName == "GeoInfo")
            {
                base.Location = new Position(((NodeVersion)sender).Latitude.ToString(), ((NodeVersion)sender).Longitude.ToString());
            }
        }

Tuesday, July 21, 2009 at 11:27:09 AM by Jon Person

This issue resulted in a number of improvements to the Selection class:

1) The "ClearSelectedItems" method has been removed. The "Clear" method was already sufficient.
2) The "Clear" method will now call "Refresh" causing the selection to actually disappear on the Map control.
3) The "Deselected" event was not properly caught by the Map control, thus causing deselected objects to remain in the selection. This is now fixed.
4) The Selection class now has a "Deselect" method which, when called, will exclude an object from a selection.

Issue #333 (Released): Satellite IsFixed property Always Appears False

Tue, 21 Jul 2009 09:43:57 GMT

Tuesday, July 21, 2009 at 9:43:57 AM by Jon Person

The IsFixed property of the Satellite class always seems to be false in the NmeaInterpreter. This should get updated whenever a $GPGSA sentence is parsed.

Issue #332 (Released): Exception While Disposing of Gauge Control

Tue, 21 Jul 2009 09:25:41 GMT

Tuesday, July 21, 2009 at 9:25:41 AM by Jon Person

The Gauge control uses a Timer to execute animations in the control. Sometimes, the Timer will fire during the Dispose method on another thread, resulting in an exception. All Timer callbacks should have exception handling to prevent any exception during disposal.

Issue #335 (Released): Add FixedSatelliteCount property to NmeaInterpreter

Tue, 21 Jul 2009 11:19:59 GMT

Tuesday, July 21, 2009 at 11:18:47 AM by Jon Person

For some GPS devices, information about fixed GPS satellites is not available. This information is normally transmitted via the $GPGSA sentence, but alas this sentence is not always available.

However, in lieu of no $GPGSA sentence, the $GPGGA sentence still returns a number indicating the number of fixed satellites. Add a property to the NmeaInterpreter called "FixedSatelliteCount" which returns this number.

Tuesday, July 21, 2009 at 11:19:59 AM by Jon Person

The property has been added. It will change one of two ways: 1) When a $GPGGA sentence has been parsed, and 2) When a $GPGSA sentence with actual fix information is parsed.

Issue #301 (Postponed for Later): Unhandled Exceptions Should Be Thrown, Not Channeled Through Events

Tue, 14 Jul 2009 12:14:20 GMT

Monday, June 08, 2009 at 11:52:18 AM by Niels Keurentjes

When an event handler invoked from GPS.NET's worker threads causes an exception to be thrown which is not caught inside the handler it is discarded by the threads. This behaviour is intended to avoid application crashes resulting from uncaught exceptions, since the thread cannot easily do anything else with the exception. However it means in practice that implementers may not be notified of exceptions occurring in their own code or external libraries they invoke from the event handler.

I think expected behaviour would be to ignore the exception and just let the application crash - it's the implementer's code at fault and if he lets an exception escape uncaught it should halt the application.

Alternatively the GPS.NET framework could use Asynchronous Procedure Calls (APC) to show a messagebox detailing the exception, however I consider the 'total crash' a more correct response to uncaught exceptions.

Friday, June 12, 2009 at 10:57:36 PM by Jon Person

Hi Neils,

I like your suggestion. Phil and I have gona back and forth on how to handle exceptions which are un-catchable because they occur on a separate thread. When we last discussed the issue, we favored events such as "ExceptionOccurred" as a way to channel exceptions. The thought here is that we didn't want end users to one day get an uncatchable exception.

I'm willing to open this back up for discussion, however. It would be great to hear other developers chime in as well.

Sunday, June 21, 2009 at 9:18:39 AM by Phil Smith

The problem really comes from unhandled exceptions in binaries released by our clients, in which case the application just disappears. The event is there to log such errors and attempt to recover from them in a production environment.

For debugging purposes, though, I see your point. An alternative would be only use the event in run mode, but not in design mode.

Wednesday, July 01, 2009 at 8:39:16 PM by Bud Cribar

I would also prefer an ExceptionOccurred event so that it could be handled in a more user friendly way than crashing the application.

Tuesday, July 14, 2009 at 12:14:20 PM by Jon Person

A good compromise here might be to check the value of System.Diagnostics.Debugger.IsAttached. When true, we could be pretty certain that a developer is using the code and can actually do something about the exception. Then, when False, perhaps only the event is used since prudction stability is so important.

I'll keep this issue open so others can weigh in.

Issue #329 (Assigned, Research in progress): Add Ability to Edit Shapes via the Mouse/Stylus

Tue, 21 Jul 2009 09:39:04 GMT

Monday, July 20, 2009 at 12:09:35 PM by Robert Smart

Would it be possible to add an 'edit' property to the geographic object. When edit is true, the shape will be drawn in edit mode, with movable handles at the vertices (or on the point if it is a point shape). When edit is set to false the shape is drawn normally. The shape should also have style proprties related to the editing and grab handle style. I can supply details of when a similar technique is used on a google map if required.

Thanks

Tuesday, July 21, 2009 at 9:39:04 AM by Jon Person

Hi Rob, we'll most likely implement a Decoration object to facilitate object editing. The big challenge we have right now is that much of the GIS.NET framework is interwoven with GDI+/GDI, making it harder to port to newer graphics systems like WPF. As a result, we'll most likely have to separate visual members such as Visible, IsSelectable, etc. from the GeographicObject class so developers can easily target different graphics systems.

However, an object inheriting from Decoration would be a good fit for the 3.0 framework. Since it can be redrawn very quickly, it would be ideal for shape editing.

Issue #328 (Cannot Reproduce): Runtime Error in setup script

Mon, 20 Jul 2009 12:30:03 GMT

Sunday, July 19, 2009 at 11:08:06 PM by Hagen Piotraschke

Dear Support,

after a bluescreen during upgrade my GPS.NET 2.0 installation a new installation does not work :-(

The installer is crashing with the following error:

Runtime Error in setup script:

Source File: GPS.NET 2.0
Line Number: 222

List index out of bounds (18)

Do you have any idea to fix this problem?

Thanks in advance & best regards from Eastern Germany,

Hagen

Monday, July 20, 2009 at 11:22:30 AM by Jon Person

Hmm. I did make a change to improve installation to a custom folder, I will test it again right now.

Monday, July 20, 2009 at 12:30:03 PM by Jon Person

Hi Hagen, I tried the installer with custom folders and couldn't reproduce the error. Are you doing anything special like a custom installation? That would help me try and recreate the exact conditions you have.

Issue #325 (Postponed for Later): Add an "Opacity" property to Geographic Object classes

Thu, 16 Jul 2009 16:08:47 GMT

Monday, July 13, 2009 at 6:44:35 AM by Robert Smart

Is it possible to add in an opacity property? This would make it much easier to make layers translucent. this is especially applicable on image files as there is a lot of code involved in setting the pixel transparency.

Thanks.

Tuesday, July 14, 2009 at 12:23:46 PM by Jon Person

I would love to support this; I agree that partial transparency would significantly improve maps on mobile devices. Unfortunately, Microsoft deviced to exclude support for the Alpha channel from all drawing operations on the .NET Compact Framework, probably for the sake of minimizing speed and memory usage.

It is possible to work around this, but it's a significant task, using low-level API calls or a replacement library such as "Xross." I think our best bet is to wait for silicon heat problems to be solved so that mobile devices can catch up to the speed of desktops. Then, we probably won't need the "Compact" framework any longer.

Thursday, July 16, 2009 at 4:08:47 PM by Jon Person

As it turns out, Rob was talking about adding an "Opacity" property to *all* objects on the Desktop Framework. I agree this would be a powerful feature to add, especially when combined with the animation abilities of movable items. I do, however, need to research the performance implications of adding this kind of processing to the GeographicPath class. This would also require significant changes to the Style objects since they would need to accept a GeographicPath object instead of a GraphicsPath object.

Issue #174 (Behavior Is By Design): Support MouseDragAction.Select on the Compact Framework

Tue, 21 Jul 2009 09:33:21 GMT

Thursday, October 23, 2008 at 7:14:53 AM by

Hi I just wanted confirm that in the Compact Framework GeoFramework.Gis.MouseDragAction.Select is not implemented yet? In the code I have:

map1.MouseDragAction = GeoFramework.Gis.MouseDragAction.Select;
map1.Selection.SelectionShape = GeoFramework.Shapes.Decorations.SelectionShape.Rectangle;

When I perform the action I get a "NotImplementedException". Will this be available in a Compact Framework release in the near future? Thanks for your help.

Tuesday, July 21, 2009 at 9:33:21 AM by Jon Person

That's correct. You see, mobile devices are extrordinarily slow compared with desktops, making any sort of high-speed animations impossible to implement. I mean, you can even watch a TextBox redraw on these devices! As a result, as much as we'd like to implement the ability to draw a selection, we'll likely need faster PDA processors before this is really possible.

I'll keep the request on our list to implement.

Issue #205 (Postponed for Later): Add "ToHectares()" to the Area class

Mon, 08 Dec 2008 11:48:21 GMT

Friday, November 28, 2008 at 6:55:46 AM by Peter van Rees

Would it be possible to add a 'ToHectares' method to the Area object? I use this unit very often, and keep coding 'Area.ToSquareMeters / 10000'

Thanks!

Monday, December 08, 2008 at 11:48:21 AM by Jon Person

I see the conversion rates for Hectare are straightforward, so I'll have this implemented soon. This seems reasonable to implement in both GeoFramework 1.0 and 2.0.

Issue #324 (Behavior Is By Design): Lost Communication with Serial Port

Wed, 15 Jul 2009 04:14:40 GMT

Thursday, July 09, 2009 at 10:12:15 PM by Jean-Francois Dionne

Hi, the GPS Class working great, but sometime it lost the communication with the GPS serial Port, and when I do a "search for gps" it doesn't "scan" the port again... maybe a thread doesn't close the port? Any idea?

Tuesday, July 14, 2009 at 12:16:01 PM by Jon Person

Hi, Jean-Francois. GPS.NET 2.0 will maintain a cache of previously detected GPS devices. As a result, when a device detection is started a second time, those devices are passed over. We can, however, override this behavior by making a call to "GeoFramework.IO.Devices.ResetDevices()". This will flush the cache and give you the behavior you seek.

The threading model in 2.0 is stable to the point where even a ThreadAbortException will trigger stable shutdown. I think this issue has to do with the cache.

Wednesday, July 15, 2009 at 4:14:40 AM by Jean-Francois Dionne

Thank, I'll add the "ResetDevices" on my "Failure detection" function

Issue #323 (Cannot Reproduce): OverflowException When Attempting to Create Speedometer

Tue, 14 Jul 2009 12:19:52 GMT

Wednesday, July 08, 2009 at 10:21:56 AM by Márcio Sete

When I try to use the speedomeeter, i receive this exception:

System.InvalidOperationException was unhandled
  Message="Erro ao criar o formulário. Consulte Exception.InnerException para obter detalhes. O erro é: The type initializer for 'GeoFramework.Speed' threw an exception."
  Source="VIU2.0"
  StackTrace:
       at VIU2.My.MyProject.MyForms.Create__Instance__[T](T Instance) in 17d14f5c-a337-4978-8281-53493378c1071.vb:line 190    at VIU2.My.MyProject.MyForms.get_testeGauges()    at VIU2.PainelControle.ProgressBar1_Click(Object sender, EventArgs e) in D:\Projetos core quad\VIU\Sistema de Monitoramento de Imagens\slnViuVs2008\VIU2.0\PainelControle.vb:line 4323    at System.Windows.Forms.ToolStripItem.RaiseEvent(Object key, EventArgs e)    at System.Windows.Forms.ToolStripItem.OnClick(EventArgs e)    at System.Windows.Forms.ToolStripControlHost.HandleClick(Object sender, EventArgs e)    at System.Windows.Forms.Control.OnClick(EventArgs e)    at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)    at System.Windows.Forms.Control.WndProc(Message& m)    at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)    at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)    at System.Windows.Forms.NativeWindow.DebuggableCallback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)    at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG& msg)    at System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(Int32 dwComponentID, Int32 reason, Int32 pvLoopData)    at System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32 reason, ApplicationContext context)    at System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32 reason, ApplicationContext context)    at System.Windows.Forms.Application.Run(ApplicationContext context)    at Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.OnRun()    at Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.DoApplicationModel()    at Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.Run(String[] commandLine)    at VIU2.My.MyApplication.Main(String[] Args) in 17d14f5c-a337-4978-8281-53493378c1071.vb:line 81    at System.AppDomain._nExecuteAssembly(Assembly assembly, String[] args)    at System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence assemblySecurity, String[] args)    at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()    at System.Threading.ThreadHelper.ThreadStart_Context(Object state)    at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)    at System.Threading.ThreadHelper.ThreadStart()
  InnerException: System.TypeInitializationException
       Message="The type initializer for 'GeoFramework.Speed' threw an exception."
       Source="GeoFramework"
       TypeName="GeoFramework.Speed"
       StackTrace:
            at GeoFramework.Speed..ctor(Double value, SpeedUnit units)    at GeoFramework.Controls.Speedometer..ctor()    at VIU2.testeGauges.InitializeComponent() in D:\Projetos core quad\VIU\Sistema de Monitoramento de Imagens\slnViuVs2008\VIU2.0\testeGauges.Designer.vb:line 26    at VIU2.testeGauges..ctor()
       InnerException: System.OverflowException
            Message="Arithmetic operation resulted in an overflow."
            Source="GeoFramework"
            StackTrace:
                 at GeoFramework.Speed..ctor(Double value, SpeedUnit units)    at GeoFramework.Speed.ToKilometersPerHour()    at GeoFramework.Speed.ToMetricUnitType()    at GeoFramework.Speed.ToLocalUnitType()    at GeoFramework.Speed..cctor()
            InnerException:

Tuesday, July 14, 2009 at 12:19:52 PM by Jon Person

Hi Marcio, the cause of this exception isn't jumping out at me, but I do see that your assembly versions are a bit out-of-date. You're entitled to free minor updates for 2.0; it couldn't hurt to update to the latest version. However, since we're deadline with Form controls, it will help to remove controls before upgrading:

1) Remove any GPS controls from forms in your project.
2) Download the latest version of GPS.NET 2.0 from here: http://www.geoframeworks.com/DownloadProducts.aspx.
3) Install it
4) Re-open your project, and re-add controls.

... once you've finished this process, you can download newer updates without having to remove controls. The removal is only necessary because the assembly version numbers changed. They have since been frozen in order to simplify upgrading.

Issue #326 (Released): Change AppendChecksum from protected to public

Thu, 16 Jul 2009 09:33:24 GMT

Thursday, July 16, 2009 at 9:30:41 AM by Jon Person

[posted by Jon on behalf of Peter]

The AppendChecksum method is currently protected. However, developers may need to create a proprietary NMEA sentence and need to append a checksum. If the AppendChecksum method were public, this would be easy.

Thursday, July 16, 2009 at 9:33:24 AM by Jon Person

AppendChecksum has been changed to public.

Issue #327 (Released): GPGGA Object Should Return Fixed Satellite Count

Thu, 16 Jul 2009 09:38:25 GMT

Thursday, July 16, 2009 at 9:37:43 AM by Jon Person

[posted by Jon on behalf of Juan]

The GpggaSentence object in GPS.NET 3.0 appears to ignore the fixed satellite count statistic, returning -1 even if a value exists in the sentence.

Thursday, July 16, 2009 at 9:38:25 AM by Jon Person

This value was originally ignored because more descriptive information for the satellite count is available in the GPGSA sentence. In other words, if the count were non-zero, no actual satellite information would be available until the next GPGSA sentence is processed.

Still, it makes sense for the sentence object to at least correctly parse the value for custom values. The NmeaInterpreter will still ignore the value in favor of the actual list of fixed satellites in the GPGSA sentence.

Issue #317 (Cannot Reproduce): Shapefile doesnt display in Map

Tue, 14 Jul 2009 12:22:37 GMT

Sunday, June 21, 2009 at 12:40:32 AM by Luis Hidalgo

Display a esri shapefile
I,m using Visual Studio 2005 on Windows Vista Home, is it a problem with that version

Tuesday, July 14, 2009 at 12:22:37 PM by Jon Person

Hi Louis, I'm not sure if we resolved this issue over email before I went out-of-town. Can you send me the ESRI shapefile via email and let me know if this is still an issue for you?

Issue #319 (Assigned, Research in progress): Translating Lat/Long into UTM in special zones 31/32V

Tue, 14 Jul 2009 13:00:08 GMT

Thursday, June 25, 2009 at 6:14:03 PM by Mark Clifford

I have been evaluating your product by using it to emulate some calculations I am doing to verify that my calculations are correct.

I have found that when converting Lat/Lon data into UTM using:

UniversalTransverseMercatorCoordinate.FromPosition(latlon)

Is returning a UTM location that is invalid in the area of the special UTM zones 31 & 32V.  It appears the limits for these zones are backwards.

I have found that your code defines UTM 31V as being 9degrees wide with 32V being only 3 degrees wide.  This should be the other way around.

To check this I entered a UTM zone as 32V 499999 6900000 and converted it to lat/lon, which gives the correct location.  But when I convert it back to UTM it returns:
31V 811549 6914453

where the western 31V boundary should be 500000 as well as its meridian.

Tuesday, July 14, 2009 at 1:00:08 PM by Jon Person

Hi Mark, my apologies for the delay. Phil Smith was supposed to be handling Geodesy.NET issues, but was let go since support responsibilities fell behind. I will look into reversing the width of zones like you stated. You'll get an email here as progress is made on the issue.

Issue #285 (Postponed for Later): Add support for smaller grid intervals

Sun, 17 May 2009 10:35:44 GMT

Monday, May 11, 2009 at 2:16:22 PM by Jon Person

Right now, the Grid object forbids any grid interval below one degree. This is a safeguard against misuse. For example, if the interval were 0.0001 degrees, a whopping number of grid lines would be generated. So may that the Map could not draw. Some users, however, need grid lines at small intervals.

Monday, May 11, 2009 at 2:18:40 PM by Jon Person

Modify Grid to have a MaximumExtent property, controlling the area for which grid lines are generated. Next, add a Grid constructor accepting an extent and interval, like this:

public Grid(GeographicRectangle extent, Angle interval)

... the constructor should do a sanity check to see how many grid lines this actually creates, and throw an exception if the number is too large.

Lastly, the remaining constructors should no longer enforce an interval > one degree and instead perform the sanity check.

Sunday, May 17, 2009 at 10:35:44 AM by Phil Smith

The default Grid was meant to be a simple grid for displaying latitude and lingitude lines on a world map. I can see many different applications of grids that the current grid lacks, such as labeling the grid lines. Linear (projected) grids would also be very useful. A UTM grid could come of this, as well as any other type of grid in projected coordinates. The orginal Grid class was left unsealed so developers could create their own custom grids. I belive some of our customers have done so.

If we do this as part of the GIS.NET Framework , Grid should to becaome an abstract base with other grid types inheriting from it. The idea that a grid is only lines of latitude and longitude is rather limited.

Issue #141 (Postponed for Later): Improve Support for Transparent Images on the Compact Framework

Tue, 02 Sep 2008 06:49:35 GMT

Monday, September 01, 2008 at 4:37:52 PM by Olle Pettersson

Can the support for drawing images with transparency (PNG) in the map on Compact Framework be extended?

I noticed that if an image is styling a permanent object, its transparency info is not used during rendering. Only movable objects keep their transparency.

However when one movable object renders on top of another movable object the transparency does not work any more.

Is it possible to have all the movable objects in the map render with transparency against both permanent objects and any other movable objects underneath them (by z-order)?

The ideal would be to have transparency work when rendering both movable and permanent objects but I am not sure how that would affect performance. For us, transparent rendering would be most important for movable objects.

Tuesday, September 02, 2008 at 6:49:35 AM by Jon Person

I believe that the Compact Framework's method of handling transparent is quite crippled compared to the desktop. The CF sets transparent pixels to the background color, instead of making them set to the underlying pixels. The end result is still opaque.

Alpha blending will require some P/Invoke API calls. Check out this blog entry: http://blogs.msdn.com/chrislorton/archive/2006/04/07/570649.aspx. We may integrate this into the Picture class.

Issue #100 (Released): The AT&T Tilt produces a $GPGGA sentence GPS.NET doesn't recognize

Mon, 13 Jul 2009 12:37:14 GMT

Monday, July 14, 2008 at 4:54:50 AM by Bud Cribar

The ATT Tilt returns this sentence
$GPGGA,,,,,,0,,,,,,,,*66

which causes this exception

GeoFramework.Gps.Nmea.NmeaSentenceException: A $GPGGA sentence contained unrecognizable data. ---> System.FormatException: FormatException
at System.Number.ParseInt32()
at System.Int32.Parse()
at System.Int32.Parse()
at GeoFramework.Gps.Nmea.GpggaSentence..ctor()
at GeoFramework.Gps.Nmea.NmeaStream.ReadSentence()
at GeoFramework.Gps.Nmea.NmeaInterpreter.OnParseIncomingData()
at GeoFramework.Gps.Interpreter.ParsingThreadProc()
at GeoFramework.Gps.Nmea.GpggaSentence..ctor()
at GeoFramework.Gps.Nmea.NmeaStream.ReadSentence()
at GeoFramework.Gps.Nmea.NmeaInterpreter.OnParseIncomingData()
at GeoFramework.Gps.Interpreter.ParsingThreadProc()

Thursday, September 04, 2008 at 2:17:38 PM by Jon Person

Thanks Bud, the sentence is supposed to have a minimal set of data, but I will add more checks in GpggaSentence to handle this non-standard format.

Wednesday, July 01, 2009 at 8:46:31 PM by Bud Cribar

I downloaded the latest version (which was 2.03.20) and it still has the problem. Is there a build 2.03.21 which has the fix in it?

FormatException
>>> Exception
$GPGGA,,,,,,0,,,,,,,,*66
<<< Exception
7/1/09Time: 12:48:04 PM
Rev. 3.00 Build 3469
GeoFramework.Gps.Nmea.NmeaSentenceException: A $GPGGA sentence contained unrecognizable data. ---> System.FormatException: FormatException
at System.Number.ParseInt32()
at System.Int32.Parse()
at System.Int32.Parse()

Monday, July 13, 2009 at 12:37:14 PM by Jon Person

Finally this is fixed. Sure enough, the blank word for satellite count (word #7) was failing. I will begin a build for this now.

Issue #37 (Postponed for Later): Where did the forum go?

Sat, 11 Jul 2009 17:58:18 GMT

Wednesday, May 21, 2008 at 7:48:02 AM by Jon Person

Several people have sent in emails asking where the forum went. The forum was originally intended to be a peer-to-peer support system where people could share code and help each other out. Unfortunately, some people were using the forum to get technical support even though it was pretty clearly labeled that people should be using email or live chat for this. So, after this occurred a few times, we got a bit tired of "Where is support???" and trying to explain things clearly. This new system solves the problem by giving people a direct link to us, but also in the public eye. By having every issue public to everybody, and providing instant notification of issues as they progress, we become more accountable for responding to issues, which is really a good thing.

We'll be expanding this system to spin off a Knowledge Base for the more common issues and walkthroughs, and I'll be posting YouTube training videos to help guide folks through the major concepts of our components, especially the new 3.0 framework since there's so much to it.

Tuesday, June 30, 2009 at 10:18:40 PM by

My mouse accidently opened this topic when I was looking through topics, so it can be closed again. I do agree though that something more needs to be done to get community collabaration. There are so many things I'd love to know how to do with these assemblies, but the documentation is almost worse than trying to decipher windows driver development kit sdk.

Saturday, July 11, 2009 at 5:58:18 PM by Jon Person

No worries. Yeah, I agree about the forum. Documentation and white papers are my primary priority once GPS3 is released.

Issue #320 (Cannot Reproduce): GeoTIFF Loading Error in DF35 GIS.NET 3 Example

Mon, 29 Jun 2009 14:55:39 GMT

Friday, June 26, 2009 at 12:49:11 PM by Jon Person

There appears to be an error when loading the "ShadedReliefLandAndOcean.tif" GeoTIFF image.  The exception is a NullReferenceException;  a stack trace follows:

   at GeoFramework.Shapes.IO.GeoTiff.ReadTags()
   at GeoFramework.Shapes.IO.GeoTiff..ctor(Stream stream)
   at GeoFramework.Shapes.IO.GeoTiff..ctor(String fileName)
   at GeoFramework.Gis.Examples.GeoTiffForm..ctor() in C:\Program Files (x86)\GeoFrameworks\GIS.NET 3.0\Desktop Framework 3.5\Examples\C#\9. GeoTIFF Images\GeoTiffForm.cs:line 25
   at GeoFramework.Gis.Examples.MainForm.geoTiffLink_LinkClicked(Object sender, LinkLabelLinkClickedEventArgs e) in C:\Program Files (x86)\GeoFrameworks\GIS.NET 3.0\Desktop Framework 3.5\Examples\C#\MainForm.cs:line 125
   at System.Windows.Forms.LinkLabel.OnMouseUp(MouseEventArgs e)
   at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
   at System.Windows.Forms.Control.WndProc(Message& m)
   at System.Windows.Forms.Label.WndProc(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
   at System.Windows.Forms.NativeWindow.DebuggableCallback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
   at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG& msg)
   at System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(Int32 dwComponentID, Int32 reason, Int32 pvLoopData)
   at System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32 reason, ApplicationContext context)
   at System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32 reason, ApplicationContext context)
   at GeoFramework.Gis.Examples.Program.Main() in C:\Program Files (x86)\GeoFrameworks\GIS.NET 3.0\Desktop Framework 3.5\Examples\C#\Program.cs:line 19
   at System.AppDomain._nExecuteAssembly(Assembly assembly, String[] args)
   at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
   at System.Threading.ThreadHelper.ThreadStart()

Friday, June 26, 2009 at 1:02:34 PM by Jon Person

It looks like the examples cannot find the FreeImage library. Since it's unmanaged, we'll have to install it somewhere it can always be found.

Friday, June 26, 2009 at 1:12:05 PM by Jon Person

FreeImage is being added (again) to the installer targeting the Windows system folder.

Friday, June 26, 2009 at 1:16:16 PM by Jon Person

That is resolved, but now I get a "BadImageFormat" exception as if the DLL were corrupted.  I'm unassigning this.  Phil, can you make sure a working copy of the FreeImage unmanaged DLL is in Surround?

   at GeoFramework.Imaging.FreeImage.GetVersion_()
   at GeoFramework.Imaging.FreeImage.GetVersion()

Monday, June 29, 2009 at 2:55:39 PM by Phil Smith

Downloaded the latest installer. All the dll's installed correctly and the GeoTIFF example ran without error. Closing.

Issue #310 (Released): Allow Customers to Add Users to a GeoFrameworks Account

Thu, 25 Jun 2009 21:22:05 GMT

Friday, June 12, 2009 at 11:33:13 PM by Jon Person

Currently, the GeoFrameworks web site associates only a single user to an account.  This can be troublesome if, for example, a reseller set up the account but their customer accidentally lost their license keys.  As a result, it would be helpful if additional email addresses could be associated with an account, allowing it to be shared.

The system shall be expanded to allow email addresses and names to be linked to an account.  Each linked user will also have an access level:

1) Administrator - Can change any account setting, modify email preferences, and edit the Google PageRank program.  Can add or remove other account associations.
2) Purchaser - Can review previous orders and look up license keys.  Cannot edit account settings.
3) Developer - Can look up license keys.  Cannot view orders or edit account settings.

... if you all would like to see other changes, feel free to chime in.

Thursday, June 25, 2009 at 9:22:05 PM by Jon Person

User account management is now live on the GeoFrameworks web site. All existing customers have been migrated to the new system with Administrator privileges and can now create other accounts.

Issue #316 (Behavior Is By Design): Increment Version Number of Subsequent Releases

Wed, 24 Jun 2009 08:54:19 GMT

Wednesday, June 17, 2009 at 6:54:49 AM by Peter van Rees

As far as I can tell version numbers of assemblies stay exactly the same with every bug fix release. This makes it impossible to tell which version you are working with at any given moment, and it complicates distribution because the default mechanism of replacing files based on their versionnumbers does not work.

I understand major, and even minor stay the same, but why is revision or build not incremented when a new version is released?

Wednesday, June 24, 2009 at 8:54:19 AM by Jon Person

Hi Peter, we originally did increment the version number on releases, but this caused problems with developers. Specifically, Windows Forms apps use an absolute reference to components. For example, if an "NmeaInterpreter" is on a Form, there is a specific version number attached to that control. If the version number changes, the form breaks.

We could probably look into releasing "Publisher Policy" assemblies but this looks to be a messy solution right now because it involves adding special assemblies to the Global Assembly Cache. If we do several releases in a week, it can quickly clutter up the GAC. For now, it seems cleaner to leave the version number alone (as Microsoft does for the framework itself) and instead try to keep developers in the loop as new releases occur.

Issue #315 (Cannot Reproduce): VS 2005 problems with GPS.NET 2.0

Wed, 24 Jun 2009 08:51:32 GMT

Wednesday, June 17, 2009 at 5:25:50 AM by Marco Schoenen

Hello,

first of all, sorry for my english.

While opening "form1" in the vb.net cf 2.0 example or while adding the "nmeainterpreter" to my own wm5 project /form, I get the following error message:

Die Datei oder Assembly "Microsoft.CompactFramework.Build.Tasks, Version=9.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" oder eine Abhängigkeit davon wurde nicht gefunden. Das System kann die angegebene Datei nicht finden.
Ausblenden

bei System.ModuleHandle.ResolveType(Int32 typeToken, RuntimeTypeHandle* typeInstArgs, Int32 typeInstCount, RuntimeTypeHandle* methodInstArgs, Int32 methodInstCount)
bei System.ModuleHandle.ResolveTypeHandle(Int32 typeToken, RuntimeTypeHandle[] typeInstantiationContext, RuntimeTypeHandle[] methodInstantiationContext)
bei System.Reflection.Module.ResolveType(Int32 metadataToken, Type[] genericTypeArguments, Type[] genericMethodArguments)
bei System.Reflection.CustomAttribute.FilterCustomAttributeRecord(CustomAttributeRecord caRecord, MetadataImport scope, Assembly& lastAptcaOkAssembly, Module decoratedModule, MetadataToken decoratedToken, RuntimeType attributeFilterType, Boolean mustBeInheritable, Object[] attributes, IList derivedAttributes, RuntimeType& attributeType, RuntimeMethodHandle& ctor, Boolean& ctorHasParameters, Boolean& isVarArg)
bei System.Reflection.CustomAttribute.GetCustomAttributes(Module decoratedModule, Int32 decoratedMetadataToken, Int32 pcaCount, RuntimeType attributeFilterType, Boolean mustBeInheritable, IList derivedAttributes)
bei System.Reflection.CustomAttribute.GetCustomAttributes(RuntimeType type, RuntimeType caType, Boolean inherit)
bei System.RuntimeType.GetCustomAttributes(Type attributeType, Boolean inherit)
bei System.ComponentModel.ReflectTypeDescriptionProvider.ReflectGetAttributes(Type type)
bei System.ComponentModel.ReflectTypeDescriptionProvider.ReflectedTypeData.GetAttributes()
bei System.ComponentModel.TypeDescriptor.TypeDescriptionNode.DefaultTypeDescriptor.System.ComponentModel.ICustomTypeDescriptor.GetAttributes()
bei System.ComponentModel.TypeDescriptor.TypeDescriptionNode.DefaultTypeDescriptor.System.ComponentModel.ICustomTypeDescriptor.GetAttributes()
bei System.ComponentModel.TypeDescriptor.TypeDescriptionNode.DefaultTypeDescriptor.System.ComponentModel.ICustomTypeDescriptor.GetAttributes()
bei System.ComponentModel.TypeDescriptor.GetAttributes(Type componentType)
bei Microsoft.CompactFramework.Build.MetadataService.GetTypeAttributes(Type desktopType)
bei Microsoft.CompactFramework.Design.DeviceCustomTypeDescriptor.GetAttributes()
bei System.ComponentModel.TypeDescriptor.TypeDescriptionNode.DefaultTypeDescriptor.System.ComponentModel.ICustomTypeDescriptor.GetAttributes()
bei System.ComponentModel.TypeDescriptor.GetAttributes(Object component, Boolean noCustomTypeDesc)
bei System.ComponentModel.TypeDescriptor.GetAttributes(Object component)
bei Microsoft.CompactFramework.Design.FilterTypeDescriptionProvider.RegisterInstance(Object instance, IServiceProvider provider, Boolean recurseInstance, Boolean setdefaults, Boolean toplevel, Dictionary`2 exceptedProperties, Dictionary`2 childexclusions)
bei Microsoft.CompactFramework.Design.CreateInstanceService.OnComponentAdding(Object sender, ComponentEventArgs ce)
bei System.ComponentModel.Design.DesignerHost.AddToContainerPreProcess(IComponent component, String name, IContainer containerToAddTo)
bei System.ComponentModel.Design.DesignerHost.Add(IComponent component, String name)
bei System.ComponentModel.Design.DesignerHost.System.ComponentModel.Design.IDesignerHost.CreateComponent(Type componentType, String name)
bei System.ComponentModel.Design.Serialization.DesignerSerializationManager.CreateInstance(Type type, ICollection arguments, String name, Boolean addToContainer)
bei System.ComponentModel.Design.Serialization.DesignerSerializationManager.System.ComponentModel.Design.Serialization.IDesignerSerializationManager.CreateInstance(Type type, ICollection arguments, String name, Boolean addToContainer)
bei System.ComponentModel.Design.Serialization.CodeDomSerializerBase.DeserializeInstance(IDesignerSerializationManager manager, Type type, Object[] parameters, String name, Boolean addToContainer)
bei System.ComponentModel.Design.Serialization.ComponentCodeDomSerializer.DeserializeInstance(IDesignerSerializationManager manager, Type type, Object[] parameters, String name, Boolean addToContainer)
bei System.ComponentModel.Design.Serialization.CodeDomSerializerBase.DeserializeExpression(IDesignerSerializationManager manager, String name, CodeExpression expression)
bei System.ComponentModel.Design.Serialization.CodeDomSerializer.DeserializeStatementToInstance(IDesignerSerializationManager manager, CodeStatement statement)
bei System.ComponentModel.Design.Serialization.CodeDomSerializer.Deserialize(IDesignerSerializationManager manager, Object codeObject)
bei System.Windows.Forms.Design.ControlCodeDomSerializer.Deserialize(IDesignerSerializationManager manager, Object codeObject)
bei System.ComponentModel.Design.Serialization.TypeCodeDomSerializer.DeserializeName(IDesignerSerializationManager manager, String name, CodeStatementCollection statements)

I cannot edit my form anymore.

Thanks your help.

With best regards
Marco

Wednesday, June 24, 2009 at 8:51:32 AM by Jon Person

Hi Marco, Visual Studio 9.0 is Visual Studio 2008. The project you're working on is probably using Compact Framework 3.5, not 2.0. Check that your project is actually using .NET CF 2.0. You can do this using the Project Properties; there's a drop-down box where you can target 2.0 or 3.5.

This problem is probably happening because the project is version 3.5 but is refencing 2.0 assemblies. Compact Framework 2.5 is not compatible with 2.0. It's important that the project and all its references use the same version of the Compact Framework.

Issue #318 (Released): Improvements in selection

Wed, 24 Jun 2009 08:47:57 GMT

Monday, June 22, 2009 at 9:54:56 AM by Rui Guimaraes

Regarding the improvement reported in bug #299 in the following point:

"
3) The two properties would be read/write for the Layer class, thus allowing objects such as geographic files to be loaded but then also excluded from a search without forcing developers to inherit EsriShapefile.
"

While loading a ESRI file with to an layer with th option IsSelectable = false I am still able to select objects in this layers. I was expecting not to be able to do so.

Wednesday, June 24, 2009 at 8:47:57 AM by Jon Person

The Layer class now has a read/write IsSearchable property which will control search behavior. When set to False, it will effectively disable Search methods both for the layer and any child objects.

Issue #309 (Released): Improvements to the Documentation System

Wed, 17 Jun 2009 23:23:35 GMT

Friday, June 12, 2009 at 11:20:02 PM by Jon Person

Documentation is quite a challenge for component developers these days.  The Microsoft Sandcastle solution is an absolute joke, usable only by the engineer who wrote it.  Open source projects like NDoc are sadly no longer supported.  As a result, we've developed a home-grown documentation system which uses .NET Reflection to import our components into a SQL Server.  The system is paired with an ASP.NET front end and now delivers over 10,000 web pages of content for all products.

The system has been needing improvements for some time now.  First, the system did not clearly indicate if types and members were supported on the Compact Framework.  Second, the system did not document types or members existing only on the CF.  Lastly, the import process was extremely slow, since each type and member required a stored procedure call to the server.

The system is now being overhauled to support both the desktop and mobile device types and members, and is being replaced with a bulk-insert system which can drop and re-import the entire document infrastructure in about 10 seconds.  This will eliminate the normal downtime of the system.

Due to signficiant database table changes, the current system will be offline.  I'll probably finish the new system over the weekend.

I'm also considering opening this system up to other developers eventually.  The SQL/ASP.NET solution has so far worked extremely well for us, and it would be a shame to see no .NET documentation solution out there for others.

Wednesday, June 17, 2009 at 11:23:35 PM by Jon Person

The documentation system now separates examples out to separate pages to make them easier to navigate. Also, icons have been added for all types and members which are also supported on the Compact Framework.

Issue #314 (Behavior Is By Design): Trial License Keys Expired for GPS.NET 3.0

Tue, 16 Jun 2009 10:12:58 GMT

Tuesday, June 16, 2009 at 7:04:09 AM by Hagen Piotraschke

There's an issue with GPS.NET 3.0 beta (with all builds since 2009-06-10), so I see only exceptions. Neither using in WinForms nor in WPF is working. Also the example app in C:\Program Files (x86)\GeoFrameworks\GPS.NET 3.0\Desktop Framework 3.5\GPS Diagnostics is crashing with an exception during start, and there's no documentation for my purchased GPS.NET 3.0 :-(

So I asked the support as well the sales channel for any possibility to use my licence key for 3.0 with the "old" stable 2nd version. I'm sure, the enhancements of GPS.NET 3.0 are fine, but on the other hand it should be also possible to wait some weeks for this...

What can you suggest for my problem(s)?

Kind regards,

Hagen

Tuesday, June 16, 2009 at 10:12:58 AM by Jon Person

Hi Hagen,

Certainly, I will add a license key for 2.0 to your account. Version 3.0 is still in beta right now, which is why documentation and examples are still sparse at the moment. We have a database update in progress now but once it completes I'll add the second key for you.

Issue #302 (Cannot Reproduce): USB-Receiver (u-blox 5) not detected

Tue, 16 Jun 2009 13:11:11 GMT

Tuesday, June 09, 2009 at 5:45:55 AM by Hagen Piotraschke

After purchasing GPS.NET 3.0 for .NET Framework 2.0 and 3.5 today I see the first issue:

An USB Receiver with u-blox 5 chipset (http://www.navilock.de/produkte/gruppen/3/Kabel_Empfaenger/60095_NL-402U.html) and used with the USB driver Version 1.2.0.1 from u-blox (http://www.u-blox.com/en/usb-drivers.html), which is realizing a COM port, is not detectable for GPS.NET! Any other GPS application can use this COM port to read the NMEA from there. Is it possible to see the problem in the 5 Hz refresh rate of the GPS receiver?

Kind regards from Eastern Germany,

Hagen

Tuesday, June 09, 2009 at 5:38:21 PM by Jon Person

Hi Hagen, thanks for your detailed bug report. I'm curious what the specific baud rate and COM: port are for the GPS device? With this information it should be easier for me to help you get this device working. Usually a USB-to-serial driver will work fine so long as the device transmits well-formed NMEA data.

There was also a fix to baud rate detection this afternoon. If your device uses a baud rate other than 4800 then this fix could improve connectivity.

Tuesday, June 09, 2009 at 5:42:47 PM by Jon Person

According to the PDF specification, the device supports the most common NMEA sentences at all baud rates (4800-115200). I'm curious if this could be caused by the baud rate issue discovered today.

GPS.NET 3.0 is still in beta for about another 2-3 weeks; most of the time will be spent on examples and documentation.

Wednesday, June 10, 2009 at 3:22:41 AM by Hagen Piotraschke

Hi Jon,
and thank you for the fast response! I'm not sure if it's only a problem of this u-blox 5 receiver...
Today I've tried it again with a bis fat Trimble box over a real RS232 (COM 1 with 9600 Baud) - and this was also not detected (of course no problem with a terminal)! Then I've seen the new build an installed it with removing the prior installation. After that I refreshed all references to the GeoFrameworks assemblies - but what happened? The app is crashing by Devices.BeginDetection() before InitializeComponent() in Window1()! Maybe I'm a Greenhorn, but I'm really confused now :-(
Is there any example code for GPS.NET 3.0 in a WPF application?
Thanks a lot in advance & best regards from "good old europe"!
Hagen

Tuesday, June 16, 2009 at 1:11:11 PM by Jon Person

Hi Hagen, there was a recent fix for the baud rate detection in GPS.NET 3.0 beta. I've added a key for 2.0 for you so you can write your application against that. 3.0 will be in beta for another couple of weeks yet.

Issue #313 (Released): Beta Trial Period Extended to August 1st

Mon, 15 Jun 2009 22:59:19 GMT

Monday, June 15, 2009 at 10:18:35 PM by Jon Person

The beta trial period for GPS.NET 3.0 has been extended to August 1st. An official release will be made before this date; the extension gives us more time to complete non-coding requirements such as documentation and examples.

The extended trial results in a new trial key, which will be updated for the "GPS Diagnostics" example applications. Developers can copy this new trial key to their own applications.

Monday, June 15, 2009 at 10:59:19 PM by Jon Person

Developers can use this trial key to unlock the GPS.NET 3.0 assemblies until August 1st, 2009.

1JCFD1-3JB254-XAB1Y1-X3X31X-5GUX33-3AYVXB

Issue #299 (Released): Improve the behavior of the Selection events

Mon, 15 Jun 2009 10:07:16 GMT

Wednesday, June 03, 2009 at 2:55:08 AM by Rui Guimaraes

After a selection is complete (SelectComplete) the list of selected Objects (Selection.Items) is still empty. We would expect that the highlighted (selected) objects would be be in that list.

This is happening in the GIS.NET 3.0 C# Examples of selection as well.

Monday, June 15, 2009 at 9:26:41 AM by Jon Person

Developers are expecting the Map.Selection.Items property to be populated when the SelectComplete event fires. However, the current code only poppulates the list after the event, which doesn't make sense.

Monday, June 15, 2009 at 10:06:19 AM by Jon Person

The current selection behavior of the Map control is such that the "SelectComplete" event is raised before the Selection.Items property is populated. This is not intuitive.

Monday, June 15, 2009 at 10:07:16 AM by Jon Person

In order to improve selection behavior, modifications are being made:

1) An "IsSearchable" virtual, read-only property is being added to GeographicObject. When overridden, allows any object to be excluded from Search methods.
2) An "IsSelectable" virtual, read-only property is being added to GeographicObject. When overridden, allows any object to be excluded from a selection.
3) The two properties would be read/write for the Layer class, thus allowing objects such as geographic files to be loaded but then also excluded from a search without forcing developers to inherit EsriShapefile.

Issue #311 (Released): Provide the Ability to Disable Searching When Selections Change

Mon, 15 Jun 2009 14:34:14 GMT

Monday, June 15, 2009 at 8:19:21 AM by Robert Smart

It would be good to allow the user to be able to drag a box on the screen without having it automatically select everything. The user can then use the zoom option. This feature would speed up the zooming process on complicated datasets.

Some events around the selection box would also compliment the behavior (like 'SelectionMade' or something).

A few methods like zoomToSelection and SelectAllInBox would allow the user to control behavior from the code.

Some events around the zooming (like 'ZoomedIn', 'zoomedOut', 'ZoomChanged') would also help developers program custom dataloading.

A ZoomToScale method would also be nice.

Monday, June 15, 2009 at 2:34:14 PM by Jon Person

Two new properties were added to a build this morning which should help you implement this behavior.

GeographicObject.IsSelectable and GeographicObject.IsSearchable let you exclude objects from search and selection operations. With these properties, you should now be able to set "Map.PermanentItems.IsSelectable = false;" to disable selection behavior for objects.

Issue #312 (Released): GML Deserialization Should Work with GML Snippets

Mon, 15 Jun 2009 08:37:39 GMT

Monday, June 15, 2009 at 8:27:53 AM by Jon Person

[Posted by Jon Person]

The GML deserialization code appears to have problems if a snippet of GML is deserialized. Calling a Marker, Line, or Polygon constructor with an XmlReader is not working.

Monday, June 15, 2009 at 8:28:45 AM by Jon Person

For speed, the GmlFile class used atomized strings for GML elements. This performed very well. However, it also prevented GML deserialization from working for any non-atomized strings. For developers deserializaing GML without using the GmlFile class, deserialization would not work.

Monday, June 15, 2009 at 8:30:19 AM by Jon Person

The deserialization technique for GML has been changed from atomized strings to ordinal string comparison. This is slightly slower, but will enable functionality for deserializing snippets of GML without using the GmlFile class.

Monday, June 15, 2009 at 8:37:39 AM by Jon Person

The new code has tested successfully.  A release is pending.

            [C#]
            string snippet = "<geoframework:vectormappolygon xmlns:geoframework=\"http://www.geoframeworks.com/gml\"><gml:featureMember xmlns:gml=\"http://www.opengis.net/gml\"><gml:Polygon><gml:exterior><gml:posList dimension=\"2\" count=\"17\">5.7705547569658542 52.484496988352973 5.7702403956759145 52.484340179189758 5.7675665246690722 52.485806443705769 5.7688538264945883 52.486713560071401 5.7726450116120045 52.486232795679292 5.7702986310963604 52.486136153746386 5.7722106725246958 52.485322957088641 5.7721587644958934 52.485297066247668 5.7721248511284413 52.485297176211041 5.7718260543068425 52.485272085464302 5.7712275578397705 52.485091883091258 5.7710985990545751 52.48498806349226 5.7710973165353661 52.484987288782193 5.7702918731441519 52.48532971295738 5.7709146078493641 52.484876922560609 5.7706699453092893 52.484729131451218 5.7705836744823209 52.484599388529951</gml:posList></gml:exterior></gml:Polygon></gml:featureMember></geoframework:vectormappolygon>";
            XmlTextReader reader = new XmlTextReader(new MemoryStream(ASCIIEncoding.ASCII.GetBytes(snippet)));
            Polygon test = new Polygon(Projection.Default, reader);

Issue #308 (Released): Email Notifications Added for All Issues

Fri, 12 Jun 2009 23:16:32 GMT

Friday, June 12, 2009 at 11:16:32 PM by Jon Person

The Issue Tracking System has been improved to send email notifications for issues:

1) You will be emailed when a new issue is posted with a link to the issue's web page, where you can check its status.
2) You will be emailed when a new comment has been added. If the issue is assigned to a developer, they will also be copied.
3) You will be emailed when there is new activity for an issue. If the issue is assigned to a developer, they will also be copied.

... these improvements will improve communication between you and our technical support team, and should help to move issues along more quickly.

Issue #296 (Behavior Is By Design): In SmartDevice projects, I can't add controls from toolbox

Mon, 01 Jun 2009 21:12:00 GMT

Monday, June 01, 2009 at 5:05:16 PM by Corey Smith

When I drag controls (Altimeter, Clock, Compass, Radar, etc.) from the VS toolbox onto my form or into the control area the controls are not added to my form. As I am dragging, it appears normal, etc. but when I let go of the mouse button, the control is not added to my form. I checked to make sure my toolbox is referencing the correct DLL and it is pointing to the assembly "GeoFramework.Gps (3.0.0.0)"

Monday, June 01, 2009 at 9:12:00 PM by Corey Smith

I uninstalled GPS.net 2 and reinatlled 3 Beta and this resolved my issue

Issue #307 (Released): NullReferenceException on Desktops With No Serial Devices

Tue, 09 Jun 2009 19:47:25 GMT

Tuesday, June 09, 2009 at 7:44:03 PM by Jon Person

I picked up an HP Mini 1000 this past week in order to test our software against the Intel Atom processor and Solid-State Drives. So far I'm really impressed with the combintion of this device and Windows 7 RC1. A 16GB CompactFlash drive was set up with ReadyBoost (probably overkill lol), and the RAM was upgraded to 2GB for about $26US. Considering the low cost of these mini-laptop "netbooks," I see them as an excellent host platform for developers who need more processing power than Smartphone/WM5 devices, but still need maximum portability.

While testing, I encountered an error in GPS3 beta, caused by the fact this netbook has no serial devices.

Tuesday, June 09, 2009 at 7:47:25 PM by Jon Person

The netbook has no serial devices. As a result, the registry key HKLM\HARDWARE\DEVICEMAP\SERIALCOMM was completely missing. I've added null checking to this and will do the same to other device classes.

Issue #303 (Released): Intermittant IOException in NmeaReader Class

Tue, 09 Jun 2009 17:44:31 GMT

Tuesday, June 09, 2009 at 8:22:53 AM by Corey Smith

I am getting the following exception when using the NetworkDevice as the source.  This happens after connecting just fine, and reading in many sentences of NMEA data.  I output the NMEA data to the output window, and it is included below.

System.IO.IOException occurred
  Message="No data is available from the underlying stream."
  Source="GeoFramework.Gps"
  StackTrace:
       at GeoFramework.Gps.Nmea.NmeaReader.ReadSentence()
  InnerException:
null

Output window:
Main -- User started main server
$GPGGA,,,,,,0,,,,,,,,*66
$GPRMC,,V,,,,,,,,,*31
A first chance exception of type 'System.OverflowException' occurred in mscorlib.dll
$GPGSA,A,1,,,,,,,,,,,,,50.00,50.00,50.00*35
$GPGSV,1,1,02,12,12,087,13,18,41,101,17*7C
$GPGGA,,,,,,0,,,,,,,,*66
$GPRMC,,V,,,,,,,,,*31
A first chance exception of type 'System.OverflowException' occurred in mscorlib.dll
$GPGSA,A,1,,,,,,,,,,,,,50.00,50.00,50.00*35
$GPGGA,,,,,,0,,,,,,,,*66
$GPRMC,,V,,,,,,,,,*31
A first chance exception of type 'System.OverflowException' occurred in mscorlib.dll
$GPGSA,A,1,,,,,,,,,,,,,50.00,50.00,50.00*35
$GPGSV,1,1,01,14,71,330,20*49
$GPGGA,,,,,,0,,,,,,,,*66
$GPRMC,,V,,,,,,,,,*31
A first chance exception of type 'System.OverflowException' occurred in mscorlib.dll
$GPGSA,A,1,,,,,,,,,,,,,50.00,50.00,50.00*35
$GPGSV,1,1,01,14,71,330,20*49
$GPGGA,,,,,,0,,,,,,,,*66
$GPRMC,,V,,,,,,,,,*31
A first chance exception of type 'System.OverflowException' occurred in mscorlib.dll
$GPGSA,A,1,,,,,,,,,,,,,50.00,50.00,50.00*35
$GPGSV,1,1,01,14,71,330,20*49
$GPGGA,,,,,,0,,,,,,,,*66
$GPRMC,,V,,,,,,,,,*31
A first chance exception of type 'System.OverflowException' occurred in mscorlib.dll
$GPGSA,A,1,,,,,,,,,,,,,50.00,50.00,50.00*35
$GPGSV,1,1,01,14,71,330,20*49
$GPGGA,,,,,,0,,,,,,,,*66
$GPRMC,,V,,,,,,,,,*31
A first chance exception of type 'System.OverflowException' occurred in mscorlib.dll
$GPGSA,A,1,,,,,,,,,,,,,50.00,50.00,50.00*35
$GPGSV,1,1,01,14,71,330,20*49
$GPGGA,,,,,,0,,,,,,,,*66
$GPRMC,,V,,,,,,,,,*31
A first chance exception of type 'System.OverflowException' occurred in mscorlib.dll
$GPGSA,A,1,,,,,,,,,,,,,50.00,50.00,50.00*35
$GPGSV,1,1,01,14,71,330,20*49
$GPGGA,,,,,,0,,,,,,,,*66
$GPRMC,,V,,,,,,,,,*31
A first chance exception of type 'System.OverflowException' occurred in mscorlib.dll
$GPGSA,A,1,,,,,,,,,,,,,50.00,50.00,50.00*35
$GPGSV,1,1,01,14,71,330,20*49
$GPGGA,,,,,,0,,,,,,,,*66
$GPRMC,,V,,,,,,,,,*31
A first chance exception of type 'System.OverflowException' occurred in mscorlib.dll
$GPGSA,A,1,,,,,,,,,,,,,50.00,50.00,50.00*35
$GPGSV,1,1,01,14,71,330,20*49
$GPGGA,,,,,,0,,,,,,,,*66
$GPRMC,,V,,,,,,,,,*31
A first chance exception of type 'System.OverflowException' occurred in mscorlib.dll
$GPGSA,A,1,,,,,,,,,,,,,50.00,50.00,50.00*35
$GPGSV,1,1,01,14,71,330,20*49
$GPGGA,,,,,,0,,,,,,,,*66
$GPRMC,,V,,,,,,,,,*31
A first chance exception of type 'System.OverflowException' occurred in mscorlib.dll
$GPGSA,A,1,,,,,,,,,,,,,50.00,50.00,50.00*35
$GPGSV,1,1,01,14,71,330,20*49
$GPGGA,,,,,,0,,,,,,,,*66
$GPRMC,,V,,,,,,,,,*31
A first chance exception of type 'System.OverflowException' occurred in mscorlib.dll
$GPGSA,A,1,,,,,,,,,,,,,50.00,50.00,50.00*35
$GPGSV,1,1,01,14,71,330,20*49
$GPGGA,,,,,,0,,,,,,,,*66
$GPRMC,,V,,,,,,,,,*31
A first chance exception of type 'System.OverflowException' occurred in mscorlib.dll
$GPGSA,A,1,,,,,,,,,,,,,50.00,50.00,50.00*35
$GPGSV,1,1,01,14,71,330,20*49
$GPGGA,,,,,,0,,,,,,,,*66
$GPRMC,,V,,,,,,,,,*31
A first chance exception of type 'System.OverflowException' occurred in mscorlib.dll
$GPGSA,A,1,,,,,,,,,,,,,50.00,50.00,50.00*35
$GPGSV,1,1,01,14,71,330,20*49
$GPGGA,,,,,,0,,,,,,,,*66
$GPRMC,,V,,,,,,,,,*31
A first chance exception of type 'System.OverflowException' occurred in mscorlib.dll
$GPGSA,A,1,,,,,,,,,,,,,50.00,50.00,50.00*35
$GPGSV,1,1,01,14,71,330,20*49
$GPGGA,,,,,,0,,,,,,,,*66
$GPRMC,,V,,,,,,,,,*31
A first chance exception of type 'System.OverflowException' occurred in mscorlib.dll
$GPGSA,A,1,,,,,,,,,,,,,50.00,50.00,50.00*35
$GPGSV,1,1,01,14,71,330,20*49
$GPGGA,,,,,,0,,,,,,,,*66
$GPRMC,,V,,,,,,,,,*31
A first chance exception of type 'System.OverflowException' occurred in mscorlib.dll
$GPGSA,A,1,,,,,,,,,,,,,50.00,50.00,50.00*35
$GPGSV,1,1,01,14,71,330,20*49
$GPGGA,,,,,,0,,,,,,,,*66
$GPRMC,,V,,,,,,,,,*31
A first chance exception of type 'System.OverflowException' occurred in mscorlib.dll
$GPGSA,A,1,,,,,,,,,,,,,50.00,50.00,50.00*35
$GPGSV,1,1,01,14,71,330,20*49
$GPGGA,,,,,,0,,,,,,,,*66
$GPRMC,,V,,,,,,,,,*31
A first chance exception of type 'System.OverflowException' occurred in mscorlib.dll
$GPGSA,A,1,,,,,,,,,,,,,50.00,50.00,50.00*35
$GPGSV,1,1,01,14,71,330,20*49
$GPGGA,,,,,,0,,,,,,,,*66
$GPRMC,,V,,,,,,,,,*31
A first chance exception of type 'System.OverflowException' occurred in mscorlib.dll
$GPGSA,A,1,,,,,,,,,,,,,50.00,50.00,50.00*35
$GPGSV,1,1,02,14,71,330,20,30,16,115,22*7B
$GPGGA,,,,,,0,,,,,,,,*66
$GPRMC,,V,,,,,,,,,*31
A first chance exception of type 'System.OverflowException' occurred in mscorlib.dll
$GPGSA,A,1,,,,,,,,,,,,,50.00,50.00,50.00*35
$GPGSV,1,1,02,14,71,330,20,30,16,115,22*7B
$GPGGA,,,,,,0,,,,,,,,*66
$GPRMC,,V,,,,,,,,,*31
A first chance exception of type 'System.OverflowException' occurred in mscorlib.dll
$GPGSA,A,1,,,,,,,,,,,,,50.00,50.00,50.00*35
$GPGSV,1,1,02,14,71,330,20,30,16,115,22*7B
$GPGGA,,,,,,0,,,,,,,,*66
$GPRMC,,V,,,,,,,,,*31
A first chance exception of type 'System.OverflowException' occurred in mscorlib.dll
$GPGSA,A,1,,,,,,,,,,,,,50.00,50.00,50.00*35
$GPGSV,1,1,01,30,16,115,22*49
$GPGGA,,,,,,0,,,,,,,,*66
$GPRMC,,V,,,,,,,,,*31
A first chance exception of type 'System.OverflowException' occurred in mscorlib.dll
$GPGSA,A,1,,,,,,,,,,,,,50.00,50.00,50.00*35
$GPGSV,1,1,02,30,16,115,23,31,30,195,15*73
$GPGGA,,,,,,0,,,,,,,,*66
$GPRMC,,V,,,,,,,,,*31
A first chance exception of type 'System.OverflowException' occurred in mscorlib.dll
$GPGSA,A,1,,,,,,,,,,,,,50.00,50.00,50.00*35
$GPGSV,1,1,02,30,16,115,23,31,30,195,15*73
$GPGGA,,,,,,0,,,,,,,,*66
$GPRMC,,V,,,,,,,,,*31
A first chance exception of type 'System.OverflowException' occurred in mscorlib.dll
$GPGSA,A,1,,,,,,,,,,,,,50.00,50.00,50.00*35
$GPGSV,1,1,02,30,16,113,22,31,32,195,19*7A
$GPGGA,,,,,,0,,,,,,,,*66
$GPRMC,,V,,,,,,,,,*31
A first chance exception of type 'System.OverflowException' occurred in mscorlib.dll
$GPGSA,A,1,,,,,,,,,,,,,50.00,50.00,50.00*35
$GPGSV,1,1,02,30,16,113,22,31,32,195,19*7A
$GPGGA,,,,,,0,,,,,,,,*66
$GPRMC,,V,,,,,,,,,*31
A first chance exception of type 'System.OverflowException' occurred in mscorlib.dll
$GPGSA,A,1,,,,,,,,,,,,,50.00,50.00,50.00*35
$GPGSV,1,1,02,30,16,113,23,31,32,195,19*7B
$GPGGA,,,,,,0,,,,,,,,*66
$GPRMC,,V,,,,,,,,,*31
A first chance exception of type 'System.OverflowException' occurred in mscorlib.dll
$GPGSA,A,1,,,,,,,,,,,,,50.00,50.00,50.00*35
$GPGSV,1,1,02,30,16,113,23,31,32,195,19*7B
$GPGGA,,,,,,0,,,,,,,,*66
$GPRMC,,V,,,,,,,,,*31
A first chance exception of type 'System.OverflowException' occurred in mscorlib.dll
$GPGSA,A,1,,,,,,,,,,,,,50.00,50.00,50.00*35
$GPGSV,1,1,02,30,16,113,23,31,32,195,19*7B
$GPGGA,,,,,,0,,,,,,,,*66
$GPRMC,,V,,,,,,,,,*31
A first chance exception of type 'System.OverflowException' occurred in mscorlib.dll
$GPGSA,A,1,,,,,,,,,,,,,50.00,50.00,50.00*35
$GPGSV,1,1,02,30,16,113,23,31,32,195,19*7B
$GPGGA,,,,,,0,,,,,,,,*66
$GPRMC,,V,,,,,,,,,*31
A first chance exception of type 'System.OverflowException' occurred in mscorlib.dll
$GPGSA,A,1,,,,,,,,,,,,,50.00,50.00,50.00*35
$GPGSV,1,1,02,30,16,113,22,31,32,195,19*7A
$GPGGA,,,,,,0,,,,,,,,*66
$GPRMC,,V,,,,,,,,,*31
A first chance exception of type 'System.OverflowException' occurred in mscorlib.dll
$GPGSA,A,1,,,,,,,,,,,,,50.00,50.00,50.00*35
$GPGSV,1,1,02,30,16,113,22,31,32,195,19*7A
$GPGGA,,,,,,0,,,,,,,,*66
$GPRMC,,V,,,,,,,,,*31
A first chance exception of type 'System.OverflowException' occurred in mscorlib.dll
$GPGSA,A,1,,,,,,,,,,,

Tuesday, June 09, 2009 at 5:44:31 PM by Jon Person

Hi Corey, I experienced the same exception today while testing another device. This happened intermittantly; the device simply didn't repond within the timeout. I've beefed up the NmeaReader class to try up to five times to get something other than null before giving up. This was enough to resolve the issue for the other device I'm testing, so hopefully it affects you as well.

Regarding the OverflowException, would you be able to get a stack trace from the exception? I'll work on trying to repro the exception from the sentences you pasted.

Issue #306 (Released): Microsoft Bluetooth Stack Detection Improved

Tue, 09 Jun 2009 18:22:12 GMT

Tuesday, June 09, 2009 at 6:22:12 PM by Jon Person

The code used to detect whether the Microsoft Bluetooth stack was installed was reporting a false negative in some devices. As a result, Bluetooth features were disabled when they could have functioned. The Devices.IsBluetoothSupported property has been rewritten with a more reliable detection method.

Issue #305 (Released): Baud Rate Detection Improved

Tue, 09 Jun 2009 17:37:12 GMT

Tuesday, June 09, 2009 at 1:03:22 PM by Jon Person

A customer reported issues regardin the "TDS Nomad," a rugged portable device.  Specifically, the GPS.NET 3.0 diagnostics utility appeared to hang during detection.  They shipped us a device and we're able to use it to find and improve baud rate detection.

The TDS Nomad is an excellent test device because it uses a non-standard baud rate (9600).  As it turns out, there were two issues:

1) The detection process was not strict enough when looking for valid NMEA data.  As a result, the test would end prematurely at one-higher baud rate than it should have.  This is now fixed.
2) The baud rate, once discovered, was not being properly saved to the Device object or the registry.  This is also fixed, which will significantly improve connectivity and connectivity times after initial detection.

One issue remains: the TDS Nomad seems to hang during a call to ReadFile, yet simply pausing and resuming the debugger resolves the issue.  I have more to research, but it's possible this device may have subtle interaction with the UI.  This is insane, yet we saw it before with the HP 6515 years ago (whose driver launched a splash screen.  Lame, right?)   I'll have more soon, but this improvement, when released, will significantly improve detection.

Tuesday, June 09, 2009 at 5:37:12 PM by Jon Person

The additional issue was nothing. The device had the "$GPRMC" sentence turned off. A release will now be posted with these improvements to baud rate detection, which will improve detection for many devices.

Issue #304 (Open): When i try to get the zoom level from a pic extent, i get 16, but then the tileset generator generates from 13.

Tue, 09 Jun 2009 11:49:31 GMT

Tuesday, June 09, 2009 at 11:49:31 AM by Phil Marks

Want to be able to determine the highest zoom level of a document, before i generate it. I have sent an email to GF tech support with code and screen shots.

Issue #213 (Behavior Is By Design): GPS.NET 3.0 Official Feature Request Thread

Mon, 06 Apr 2009 09:20:37 GMT

Monday, December 08, 2008 at 5:13:44 PM by Jon Person

Hi everyone.  Development for GPS.NET 3.0 has been underway for about a week now, and so far I'm excited to see the progress already being made.  For example, the device detection for Bluetooth has been sped up significantly, and can communicate directly with BT devices if you have the Microsoft stack installed.

Currently, my primary goals for GPS.NET 3.0 are listed below, but I very much welcome your feedback.  What do you want to see?

1) Greatly reduced CPU use during normal operations.

... this has been a common topic for feedback.  The 2.0 engine did a lot of "hand-holding" to make programming easier for novice developers.  For example, we got a little tired of explaining why "Invoke" was necessary to make sure a TextBox is updated from a Form's own thread, so we decided to make the engine call "Invoke" when necessary.  This made life easier for novices, but added some significant overhead to the engine.

The 3.0 engine removes this automatic thread marshalling feature completely.  This makes the component more efficient, but it also helps to eliminate the dependency on Windows Forms, thus opening the door up for pure WPF applications.

2)  Better baud rate detection

Developers often asked for ways to speed up device detection.  A lot of the slowdown would happen when trying to determine the correct baud rate for a particular port.  I have improvements started for this, but need to get more devices out of storage to finish up the routine.  If it works, however, it will perform baud rate detection in about 10% of the time as before.

3) Improved support for Bluetooth

Bluetooth is a very popular communication technology for GPS because it lets the device be wireless, plus it also makes life easier for developers by letting them use a GPS device from either their desktop or mobile computers.  Support for Bluetooth in GPS2 was lacking in some regards.  For example, it required that devices be "paired" in order to create a virtual serial port.  For 3.0, I've completely rewritten the Bluetooth communication library to be slimmed down and faster, and so far it's working.  I'm thankful that the Microsoft Bluetooth stack is growing in popularity, because MS is the only provider with an API that can be P/Invoked easily.  Other providers such as Broadcom would require an unmanaged interop DLL, which would be very messy and confusing to implement.

4) Support for automatic coordinate conversion

Phil Smith's excellent work on "Geodesy.NET" finally provides full coordinate conversion support for our products.  GPS.NET 3.0 will include a property which, when set, will automatically convert incoming WGS84 coordinates to another coordinate system.  This will finally streamline support for our international friends.

5) Better support for custom NMEA sentences

The architecture for GPS.NET 3.0 has already been rewritten to use interfaces as a way to "build" NMEA sentences.  Interfaces such as "IPositionSentence" would be implemented if a sentence contains latitude/longitude data, for example.  With this approach, developers will very easily be able to create custom sentences, and add support for proprietary sentences transmitted by a handful of devices.

6) Improved/managed serial port code

After a lot of thought and review, I reluctantly decided to make GPS.NET 3.0 use .NET's own "SerialPort" class.  I originally avoided this class in order to have finer control over serial port behavior, but after a lot of testing I believe that the managed SerialPort will be suitable.  This approach will also help GPS.NET to be ported to Linux and Apple systems via the Mono project.  In other words, if I can make GPS.NET 100% managed, then it could work on more platforms.

7) Better GPS User controls

During the development of GIS.NET 3.0 I learned a ton about optimization, particularly in regards to graphics.  The original "DoubleBufferedControl" was fast, but a new class will be written which uses the advances learned in GIS3.  I expect about 40% improved framerates for animation on the desktop; mobile devices will probably be sped up as well due to a *reduction* in multithreading.  (Thread context switching on mobile devices is very expensive!)   Plans are also now in the works for a "Radar" gauge control which will let developers plot simple icons relative to the current GPS location.

8) Better GPSID support

When GPS.NET 2.3 was out, there weren't many flavors of the GPS Intermediate Driver.  However, with the introduction of the QualComm GPS chip, found in HTC and AT&T devices, people started writing proprietary drivers.  Not only that, but these drivers used a completely different registry structure than the standard GPSID structure.  This let to big problems, such as essentially breaking the GPSID on some devices.  I want to conduct a thorough analysis of various GPSID registry structures now for GPS3 to see just how good we can streamline the support.   For this, I'm going to need the registry dumps from several developers.  I'll start another thread for that.

Tuesday, December 09, 2008 at 4:36:52 AM by Alan Walters

For the most part the GPS.NET 2.x has worked very well for our clients. The primary issue that I have encountered while using GPS.NET 2.x is the bluetooth connectivity. We are using Panasonic Toughbooks (CF18) that when the Bluetooth connection is lost for more than a few minutes the user must manually reconnect with the device - even though in the settings it has the "Auto Connect" turned on. Most other computers we have used do not have this problem. So if it can reconnect to a bluetooth device without having to be "re-paired" would be a major improvement for us. Alan

Thursday, December 11, 2008 at 2:56:54 PM by Alan Walters

The other request I would like to make (assuming it won't already do so) is that it can run as a service. With our app the want to track the vehicle even if no one is logged on.

Thursday, December 11, 2008 at 8:25:51 PM by

GPS.NET 2.x has worked brilliantly for us. (Mostly PDA use) The only devices that gave us minor issues were the HP units like the 'Travel Companion (WM5)' and the older iPaqs with PPC2003 - even with Bluetooth disabled they would give a Bluetooth error or start the Bluetooth Detection for no good reason (eg When GPSID is configured to use the internal GPS)

Looking forward to auto coordinate conversion and general optimizations.

Saturday, January 31, 2009 at 1:55:51 PM by Peter Simpson

For GPS.NET 3.x I would offer the following feedback:
1. Change the Project and DLL names from "GeoFramework.PocketPC.*" to "GeoFrameworks.Mobile.*" since these days PocketPC is old school from 2003.
Is it GeoFramework or GeoFrameworks with "s"?
2. What is the 3.x solution for no GPS fix returning 0,0 somewhere in Africa? I talked with David L. in Seattle about this and he thought instead of returning NULL,NULL that you could return the max values.

Thursday, February 12, 2009 at 5:02:23 AM by David Hanley

Couple of comments:

1. Enhance documentation to include more examples would be very helpful.

Thursday, February 12, 2009 at 5:03:47 AM by David Hanley

Maintain backward compatibility wherever possible i.e. code written for 2.3 can still compile with 3.0 libraries (I am sure you will).

Thursday, February 19, 2009 at 4:28:26 PM by Jon Person

Hi Peter, GPS3 will be returning a value of NULL. The non-null (0°,0°) value of GPS2 cuased problems with developers because that could be a valid value. A null value will be more explicit that, truly, no information is available. Unfortunately, I believe a maximum value would cause the same problems that 0,0 did.

Thursday, February 19, 2009 at 4:30:41 PM by Jon Person

Hi David, yes we'll be maintaining backwards compatibility. With GPS3 80% complete now, there are only minor changes:

1) NMEA sentences are designed to implement interfaces in order to better support custom sentences.
2) Generic collections such as List<Satellite> are used instead of ArrayList (now that we don't need to support VS2003)
3) Bluetooth classes are streamlined.
4) GPS3 will use GeoFramework 2.0, the same library used by GIS.NET 3.

Monday, April 06, 2009 at 9:20:37 AM by Jon Person

GPS.NET 3.0 is nearly complete. Backwards compatibility looks very good right now. Core classes such as Interpreter, DilutionOfPRecision, SignalToNoiseRatio are largely unchanged. The static "Devices" class is moving to the GeoFramework.Gps namespace to make it more visible, and a new "GeoFramework.Gps.Devices" namespace exists to organize new objects such as SerialDevice, NetworkDevice, BluetoothDevice, and others. I'll be sure to include specific upgrade messages so they'll show up in the compiler and tell you exactly how to make the adjustment in code.

Issue #295 (Behavior Is By Design): Failed to create component 'DoubleBufferedControl' - Error while adding control from within IDE

Mon, 08 Jun 2009 12:55:09 GMT

Monday, June 01, 2009 at 4:40:55 PM by Corey Smith

1) Created Smart Device Project, CF3.5, Targeting WM6
2) Added NMEAIntrepreter from toolbox
3) Added DoubleBufferedControl from toolbox
Immediately after dropping DoubleBufferredControl on to form, I got the following error from the Visual Studio IDE:

Microsoft Visual Studio Failed to create component 'DoubleBufferedControl'. The error message follows:
'System.MissingMethodException: Cannot create an abstract class.
at System.RuntimeTypeHandle.Createlnstance(RuntimeType type, Boolean publicOnly, Boolean noCheck, Boolean& canBeCached, RuntimelviethodHandle& ctor, Boolean& bNeedSecurityC heck)
at S.estem.RuntimeType.CreatelnstanceSlow(Boolean publicOnly, Boolean fillCache)
at S.estem.RuntimeType.CreatelnstancpJmpi(Boolean publicOnly, Boolean skipVisibilityChecks, Boolean fillCache)
at System.Activator.Createlnstance(Type type, Boolean nonpublic)
at System.RuntimeType.Createlnstancelmpl(BindingFIags bindingAttr, Binder binder, Object[) args, Culturelnfo culture, Object[)
activationAttributes)
at System.Activator.Createlnstance(Type type, BindingFlags bindingAttr, Binder binder, Object[) args, Cultureinfo culture, Object[) activationAttributes)
at
System.ComponentModel.Design.DesignSurface.Createinstance(Type type)
at
Microsoft.VisualStudio.Design.VSDesignSurface.Createinstance(Type type)
at System.ComponentModel.Design.Designer...'

Monday, June 01, 2009 at 4:42:39 PM by Corey Smith

I don't even know what the DoubleBufferedControl is used for, so I could be not using it as it was intended, but I'm sure you'd like to handle the error in your code, so I thought I'd report it.

Monday, June 08, 2009 at 12:55:09 PM by Jon Person

Hmm, the DoubleBufferedControl is an abstract class, so it shouldn't even be showing up in the toolbox. It's also part of the older GPS.NET 2.0 framework. I wonder if you have the older framework installed?

It's also possible that this class exists because of the "Upgrade" class. I bet that's the problem. For a time this class was part of the regular GPS3 assembly, but it ended up causing confusion because beta testers thought the classes were real, not just shims to help with upgrading.

Now that that's been moved to a separate assembly, this problem should now be resolved.

Issue #297 (Released): In Compact Framework GPS.net 3 Beta, I get "A user break has occured in..."

Mon, 08 Jun 2009 12:48:28 GMT

Monday, June 01, 2009 at 7:30:49 PM by Corey Smith

Stacktrace is:
at Debugger.Break
at SerialDevice.Reset
at Interpreter.ParsingThreadProc

I have a feeling that a 'Debugger.Break' may have accidentially been left in the GPS.net 3 Beta source code....

Monday, June 08, 2009 at 12:48:28 PM by Jon Person

Sure enough, a Break statement existed in SerialDevice.Reset. Some "to-do" code was present, but is now cleaned up.

Issue #275 (Released): Line.Search should check for line intersection on the Compact Framework

Fri, 05 Jun 2009 13:58:54 GMT

Sunday, May 03, 2009 at 9:31:08 AM by Jon Person

On the Compact Framework, the Search method of the Line class will return the line object if its *extent* contains the point. This should be changed to be more specific; the object should be returned only if the point rests on the line.

Friday, June 05, 2009 at 1:58:54 PM by Phil Smith

Intersection hit testing is now based on a pixel radius rather than an extent intersection. The MouseClickRadius property can be set to increase or decrease precision for cllick and mouse movement events.

Issue #300 (Postponed for Later): Streamline background searching behavior in the Map control

Fri, 05 Jun 2009 13:46:25 GMT

Friday, June 05, 2009 at 1:46:25 PM by Phil Smith

Object mouse event detection in the Map control requires a deep search, which is enabled by default regardless of whether or not corresponding events are even wired. There's no fast way to check whether or not individual objects have events wired, thus validating the need for a search in the first place. This is remedied by the AllowObjectMouseEvents property on the map control. But again, it's set to true by default. A quick solution would be to enable the background searching based on the Map controls ItemMouse_____ events. Individual events are still not considered in this case, which seems to me a separate behavior pattern which may or may not be inclusive of the Map all inclusive event.

Investigating this situation has led to some basic search behavior inconsistancies which would require some signifigant object model changes that probably better suited for a major version change.

Issue #298 (Released): Exception During Design-Time: Code generation for property 'writetimeout' failed...

Wed, 03 Jun 2009 10:07:00 GMT

Tuesday, June 02, 2009 at 8:24:09 PM by Corey Smith

Every few minutes (while I am switching between code and the designer) an error pops up in Visual Studio; this is not while I am running my code, this is a design-time exception.  The error is: "Code generation for property 'WriteTimeout' failed.  Error was: 'Property accessor 'WriteTimeout' on object 'NmeaIntrepreter1' threw the following exception: 'Specified method is not supported.'' "

Then, when I click OK, I have a warning in my Error List which is: "'Public Property BaseStream() As Object' is obsolete: 'GPS.NET 3.0 uses 'Device' objects instead of 'Stream' objects in order to more easily recover from lost connections.  Use the 'Start(Device)' method with a device class such as 'SerialDevice' or 'BluetoothDevice'.'."

When I doulble click that warning, it takes me to the IDE-generated designer code for my form.  There is a line of code that is trying to set the BaseStream of NmeaInterpreter1, but that is not supported in v3.  So, I delete that line and everything is fine until a minute later, this all happens again.

It seems that something is automatically generating code that is obselete.  It is quite a hassle to deal with constantly.

Wednesday, June 03, 2009 at 8:31:19 AM by Jon Person

Ahh right. The Obsolete members got put in, but then did not have a DesignerSerialization attribute also added. Now that the Obsolete members have moved to a separate assembly, I'll remove these members.

Wednesday, June 03, 2009 at 10:07:00 AM by Jon Person

All "Obsolete" attributes have been removed from the production assemblies. Also, new "upgrade helper" assemblies have been added to the installers. These assemblies, with names such as "GeoFramework.Gis.UpgradeFromVersion2" house all Obsolete attributes. They are designed to be referenced by developers who need to upgrade from version 2.0 to 3.0. The assembly reference is then shed once the transition is complete.

Issue #284 (Released): Windows 7: Suspend or Hibernate Disables Bluetooth

Wed, 03 Jun 2009 10:04:46 GMT

Monday, May 11, 2009 at 9:02:13 AM by Jon Person

This is not a bug with GPS.NET but in Windows and it affects GPS software developers. On the Windows 7 beta (build 7022 and 7000), the Microsoft Bluetooth stack will cease to function if the computer is suspended or placed into Hibernation. The only solution is to reboot the machine.

Monday, May 11, 2009 at 9:02:35 AM by Jon Person

Beta feedback was sent to Microsoft advising them to restart the BT stack upon a resume.

Wednesday, June 03, 2009 at 10:04:46 AM by Jon Person

This appears to be fixed as of Windows 7 Release Candidate 1. By the way, you can download the RC for free from Microsoft as a 32-bit or 64-bit ISO: http://www.microsoft.com/Windows/windows-7/download.aspx. The downloader includes a utility to burn the ISO to a DVD. We've had great success with Windows 7; I would recommend anyone running Vista consider upgrading to the RC.

Issue #276 (Released): Objects are sometimes selected which are not inside of the selection polygon

Sun, 31 May 2009 14:57:36 GMT

Monday, May 04, 2009 at 9:55:01 AM by Jon Person

When searching for objects based on a selection polygon, objects are sometimes selected which lay outside of the selection polygon. This can be seen in the Desktop Framework example for selecting by objects. The example shows the state of Florida with counties. Selecting a county sometimes selects cities not within the county. It almost appears that objects are being selected which are within the *extent* of the county rather than the polygon of the county itself.

Monday, May 04, 2009 at 10:59:42 AM by Jon Person

This appears to be a problem with the GDI+ GraphicsPath object. It is not testing points with the appropriate precision. I think we should replace this with our PolyMath routines.

Sunday, May 31, 2009 at 2:57:36 PM by Phil Smith

The issue is that the GDI+ objects use convex hull algorithms to evaluate polygon boundries. Geospacial geometry is rarely convex, so more accurate algorithms are needed to calculate boundary intersections for searching and selection.

Added a static property to the GeographicPath class, "GeographicPath.BoundaryTestBias". The GDI+ routines are fastest but can be inaccurate when comparing concave polygons. The bias can be set for speed or accuray. See the associated enum for details about the two settings.

Issue #286 (Behavior Is By Design): Assistance With ESRI Projections

Thu, 28 May 2009 12:55:18 GMT

Thursday, May 14, 2009 at 6:15:31 AM by Kyle Fischer

Display of ESRI data in version 2.0 was very good. Version 3.0 seems to misrepresent the data. I am seeing ESRI lines that are squiggly where they should be straight. In version 2, no matter what projection I used, the ESRI data came out perfectly.

Sunday, May 17, 2009 at 1:40:46 PM by Phil Smith

A screenshot would be helpful to illustrate what you are talking about. You can email it to support@geoframeworks.com. You might want to attach the shapefile as well. What projection were you using in 2.0? There were only 2 other types besides the default Plate Caree'.

Thursday, May 28, 2009 at 12:55:18 PM by Kyle Fischer

The version 2.0 projection was LambertConformalConic. In version 3.0 I was using the default Mercator projection. I changed the projection to a TransverseMercator projection and the display irregularities seemed to go away

Issue #294 (Released): Upgrade Assistance from GPS.NET 2.0 to 3.0

Tue, 26 May 2009 18:50:23 GMT

Tuesday, May 26, 2009 at 6:35:23 PM by Jon Person

In order to ease the transition from GPS.NET 2.0 to 3.0, "Obsolete" attributes have been added.  The idea here is that most developers will swap out their project references from 2.0 to 3.0 then build their solution to see what needs to be done.

With these attributes in, developers can examine compiler warnings for specific, detailed instructions on how to change code to its 3.0 equivalent.  For this process to work best, developers should temporarily hide compiler errors and instead show only warnings.   This will produce a clean to-do list of upgrade steps, and most if not all errors will be resolved when warnings are addressed.

We'll keep these attributes in the 3.0 libraries for several months.  Since they increase the size of assemblies, however, we'll eventually post a notice here and remove upgrade attributes.  We may do this sooner once a vast majority of developers upgrade to 3.0.

NOTE: Some work is still necessary for the GPS controls.  I'll have that wrapped up by the end of the week.

Tuesday, May 26, 2009 at 6:50:23 PM by Jon Person

Also, a 40% discount has been applied to all GPS.NET 2.0 licensees. People who have tried the beta and are ready to upgrade may do so online now. Once you sign into your account, the discount will automatically be applied when you add GPS.NET 3.0 to your cart.

You can sign into your account using this link: https://secure.geoframeworks.com/Secured/Default.aspx.

Issue #293 (Released): GPS 3 Beta - for Pocket PC (Compact Framework) - Can't start NMEAInterpreter - Get 'does not support invoking delegates asynchronously'

Mon, 25 May 2009 21:53:57 GMT

Monday, May 25, 2009 at 8:08:44 AM by Corey Smith

Can't start NMEAInterpreter - Get 'does not support invoking delegates asynchronously'

System.NotSupportedException

".NET Compact Framework does not support invoking delegates asynchronously."

StackTrace:
" at GeoFramework.Gps.Nmea.NmeaInterpreter.OnReadPacket()\r\n at GeoFramework.Gps.Interpreter.ParsingThreadProc()\r\n"

Monday, May 25, 2009 at 8:09:38 AM by Corey Smith

This is in VS 2008, CF 3.5, Vista Enterprise x64, WM6

Monday, May 25, 2009 at 11:15:12 AM by Phil Smith

Fixed.

Monday, May 25, 2009 at 9:53:57 PM by Corey Smith

I was already extremely impressed with you GPS.NET product, and that was a fast fix! You guys are great!

Issue #292 (Released): Licensing Problem in GPS.NET 3.0 Beta

Wed, 20 May 2009 16:12:47 GMT

Wednesday, May 20, 2009 at 4:12:00 PM by Jon Person

In the beta of GPS.NET 3.0, production license keys failed to work, causing an error for the assembly "GeoFramework.Drawing." The key itself was valid.

Wednesday, May 20, 2009 at 4:12:47 PM by Jon Person

Licensing behavior had to be adjusted recently to support "dependency licenses." That is, where one license key works on multiple assemblies. The GPS3 license had not been coded properly to include the GeoFramework.Drawing assembly. This is now resolved, and production licensing behavior now precisely matches trial licensing for dependencies.

Issue #291 (Released): #287: Geoframework.Projections.Common.UTM() Handling of South-Oriented Coordinates

Wed, 20 May 2009 14:44:59 GMT

Wednesday, May 20, 2009 at 11:50:42 AM by Gilson J do Nascimento

Regarding issue: #287.

I have tried to use the Common.UTM(bool southOriented, int zoneNumber, Ellipsoid ellipsoid) overload. Tried using both values "true" and "false" for southOriented. Results are the same regardless of this boolean value: {90°00'00,0000"S;045°00'00,0000"W}.

Used some other tools to validate results, for example:
http://www.apsalin.com/convert-universal-transverse-mercator-to-geodetic.aspx

Wednesday, May 20, 2009 at 2:44:59 PM by Phil Smith

There is a indeed a problem in the Geoframework.Projections.Common.UTM() methods in how coordinates are interpreted. Firstly, the handling of south oriented corrdinates was incorrect. Beyond that, the interpretation of coordinates was inconsitent with UTM, thus the Tranverse Mercator projections returned from these methods was not a standard UTM projection.

The behavior of the Common.UTM() methods has been changed so that the overloads that accept a UTM Zone Letter or Zone Number as a parameter return a standard UTM projection, while overloads that accept a latitude and longitude parameter return a non-standard UTM projection, which is only suitable for displaying single UTM zones on the GIS 3 Map control.

And finally, the handling of south oriented coordinates in the standard UTM() overloads has been corrected.

Note that this issue affected projections returned from the Common.UTM() methods only. UTM projections obtained from the GeoFramework.Geodesy.CoordinateReferenceSystems namespace were unaffected.

Issue #290 (Released): Make the Map.Selection animation optional

Tue, 19 May 2009 16:11:39 GMT

Tuesday, May 19, 2009 at 3:36:20 PM by Ryan Dotson

The selection animation is often useful, but we are finding some cases where it is undesired. In Remote Desktop sessions for example, it results in poor performance due to the constant updates. Also, a few of the machines that run our application are server-class computers but have really poor video cards. The .Net rendering appears to have no hardware acceleration, and it uses up signficant CPU resources (> 30%, if the selection occupies a large area of the screen).

Is is possible to make the animation optional to control this behavior?

I realize I could work out my own selection system, but this seems like it could be solved simply within the existing framework.

Tuesday, May 19, 2009 at 3:58:01 PM by Jon Person

Hi Ryan, we can add a boolean property such as IsAnimated to the Selection class.

Tuesday, May 19, 2009 at 4:11:39 PM by Jon Person

The property has been added to the Selection object. Let me know if you want to revisit this later. I may add an additional property such as "AnimationInterval". The current hard-coded interval is 50ms; changing that to something like 250ms even should significantly reduce CPU use.

Issue #289 (Released): Provide the ability to convert to UTM and MGRS representations

Sat, 16 May 2009 20:29:58 GMT

Saturday, May 16, 2009 at 8:29:58 PM by Phil Smith

UTM representation of positions was overlooked with the addition of Geodesy.Net. This oversight has been corrected along with the ability to conver coordinates to the Military Grid Reference System (MGRS). Two new structures in the GeoFramework.Geodesy namespace, UniversalTransverseMercatorCoordinate and MilitaryGridReferenceSystemCoordinate have methods that can be used to convert Position objects to and from UTM and MGRS representation.

Issue #287 (Behavior Is By Design): Apparently there is a problem with UTM convertion to Geodetic

Sat, 16 May 2009 19:24:39 GMT

Friday, May 15, 2009 at 5:19:58 AM by Gilson J do Nascimento

**Converting from UTM to Geodetic**

Based on the code below:

Projection projection = Common.UTM(ZoneLetter.K , 23, Ellipsoid.Clarke1866);
ProjectedCoordinate proj1 = new ProjectedCoordinate(682120.949, 7827079.605);
Position posTrace = projection.ToPosition(proj1);

Shouldn´t posTrace be {19°38'39,5128"S;43°15'47,0557"W} instead of {39°35'24,0073"S;042°52'44,9457"W} ?

Saturday, May 16, 2009 at 7:24:39 PM by Phil Smith

That particular UTM overload sets the projection center to to the center of zone 23K. I believe you are looking for the Common.UTM(bool southOriented, int zoneNumber, Ellipsoid ellipsoid) overload.

Issue #269 (Postponed for Later): Add tileset objects for Google Maps and Virtual Earth

Tue, 14 Apr 2009 11:18:40 GMT

Tuesday, April 14, 2009 at 11:18:40 AM by Jon Person

It's theoretically possible to write GIS.NET 3.0 objects which display Google Maps or Virtual Earth 2D tiles inside of a Map control. We already support their projections, so all that's necessary is a mechanism to calculate which tiles to request. Let's see if we can develop a formula for calculating tile requests and objects for these providers. There are some licensing implications for end-users since Google and Microsoft may have fee requirements, but since we're not providing the actual content, we're in the clear.

Issue #92 (Postponed for Later): Add Support for WKB Files

Mon, 07 Jul 2008 18:11:53 GMT

Monday, July 07, 2008 at 1:25:33 PM by Ted Macy

We store all of our data in Open GIS WKT and/or WKB format. I understand that writing a WKT parser can be timeconsuming, and that there are areas where the spec is ambiguous. However, WKB seems to be pretty straight forward. Can you consider adding the ability to generate a shape from WKB, and save a shape to WKB?

Monday, July 07, 2008 at 1:31:30 PM by Jon Person

We can probably add that in, I'd like to get some feedback from others, and also see if you have a link or code you could send us to speed up the implementation process?

Monday, July 07, 2008 at 6:11:53 PM by Ted Macy

I will provide a link to the OGC spec, and I will provide the code that I have used to read a wkb and generate a shape. I'm sure the shape generation is not efficient, but I think you'll find the WKB reader might be satisfactor for inclusion within a shape constructor or static shape factory.

Issue #74 (Released): Support for 64-bit versions of Windows

Fri, 15 May 2009 02:42:34 GMT

Wednesday, June 18, 2008 at 10:05:29 AM by Jon Person

Requests have arrived via email requesting support for 64-bit versions of Vista and XP. I'm very curious about this, especially if it would relax the memory limitations of the .NET Framework. For example, try loading a 1-gigabyte GeoTIFF in .NET using "Image.FromFile()" and it will fail. I think it's worth revving up 64-bit build/dev machines to at least see if it can handle it. Better memory limits alone to me would immediately justify 64-bit support for GIS3.

Wednesday, June 18, 2008 at 10:39:37 AM by Jon Person

To my surprise, Dell isn't even offering systems which are 64-bit right now. But I'll find another provider

Friday, May 15, 2009 at 2:42:34 AM by Jon Person

This issue was resolved several months ago; our build server now generates cross-platform assemblies for all products. Both 32-bit and 64-bit systems are supported in the same DLL's.

Issue #204 (Postponed for Later): Add Support for Spatial Indexing

Thu, 27 Nov 2008 14:26:46 GMT

Issue #268 (Postponed for Later): Add Support for Buffering and Calculated Shapes

Fri, 10 Apr 2009 11:22:28 GMT

Friday, April 10, 2009 at 11:22:28 AM by Phil Smith

We've gone back and forth on issues of perfeormance vs accuracy in the calculations employed by GIS.NET (boundary intersections, for example). I think the existing model is sound, but requests for things like creating geo buffers and other calculated shapes hint at a direction we have not specifically addressed. Additional suggestions are appreciatred.

Issue #249 (Postponed for Later): Unable to load OS Mastermap GML file into tileset assistant to create tiles

Thu, 05 Mar 2009 19:42:02 GMT

Friday, February 20, 2009 at 2:15:35 AM by

When trying to import the original OS Mastermap gml file the following exception is thrown

System.Xml.XmlException was unhandled
  Message="'Element' is an invalid XmlNodeType. Line 11, position 2."
  Source="System.Xml"
  LineNumber=11
  LinePosition=2
  StackTrace:
       at System.Xml.XmlReader.ReadEndElement()
       at GeoFramework.GeographicRectangle.ReadXml(XmlReader reader)
       at GeoFramework.GeographicRectangle..ctor(XmlReader reader)
       at GeoFramework.Shapes.IO.GmlFile.ReadHeader()
       at GeoFramework.Shapes.IO.GmlFile..ctor(Stream stream, Type pointType, Type lineType, Type polygonType)
       at GeoFramework.Shapes.IO.GmlFile..ctor(String filePath, Type pointType, Type lineType, Type polygonType)
       at GeoFramework.Shapes.IO.GeographicDataSource.Open(String filePath, Type pointType, Type lineType, Type polygonType)
       at GeoFramework.Tilesets.WizardForm.OnStepChanged() in C:\Program Files\GeoFrameworks\GIS.NET 3.0\Tileset Utility\C#\WizardForm.cs:line 136
       at GeoFramework.Tilesets.WizardForm.ShowStep(Panel panel) in C:\Program Files\GeoFrameworks\GIS.NET 3.0\Tileset Utility\C#\WizardForm.cs:line 66
       at GeoFramework.Tilesets.WizardForm.nextButton_Click(Object sender, EventArgs e) in C:\Program Files\GeoFrameworks\GIS.NET 3.0\Tileset Utility\C#\WizardForm.cs:line 214
       at System.Windows.Forms.Control.OnClick(EventArgs e)
       at System.Windows.Forms.Button.OnClick(EventArgs e)
       at System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent)
       at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
       at System.Windows.Forms.Control.WndProc(Message& m)
       at System.Windows.Forms.ButtonBase.WndProc(Message& m)
       at System.Windows.Forms.Button.WndProc(Message& m)
       at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
       at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
       at System.Windows.Forms.NativeWindow.DebuggableCallback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
       at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG& msg)
       at System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(Int32 dwComponentID, Int32 reason, Int32 pvLoopData)
       at System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32 reason, ApplicationContext context)
       at System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32 reason, ApplicationContext context)
       at System.Windows.Forms.Application.Run(Form mainForm)
       at GeoFramework.Tilesets.Program.Main() in C:\Program Files\GeoFrameworks\GIS.NET 3.0\Tileset Utility\C#\Program.cs:line 17
       at System.AppDomain._nExecuteAssembly(Assembly assembly, String[] args)
       at System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence assemblySecurity, String[] args)
       at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
       at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
       at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
       at System.Threading.ThreadHelper.ThreadStart()

After removing the line causing the issue from the gml file I am able to continue to the preview option. The preview option shows an empty map and when completed the tileset directory only has the tileset config xml file and no tiles.

I then used a converter to conveert the OS mastermap gml file into a mapinfo file. When trying to load these files I recieved the following exception

System.IndexOutOfRangeException was unhandled
  Message="Index was outside the bounds of the array."
  Source="GeoFramework.Shapes"
  StackTrace:
       at GeoFramework.Shapes.IO.MapInfoFileSummary..ctor(StreamReader reader)
       at GeoFramework.Shapes.IO.MapInfoFile.ReadHeader()
       at GeoFramework.Shapes.IO.MapInfoFile..ctor(Stream stream, Type pointType, Type lineType, Type polygonType, Encoding encoding, String textColumnName)
       at GeoFramework.Shapes.IO.MapInfoFile..ctor(String filePath, Type pointType, Type lineType, Type polygonType, Encoding encoding, String textColumnName)
       at GeoFramework.Shapes.IO.MapInfoFile..ctor(String filePath, Type pointType, Type lineType, Type polygonType)
       at GeoFramework.Shapes.IO.GeographicDataSource.Open(String filePath, Type pointType, Type lineType, Type polygonType)
       at GeoFramework.Tilesets.WizardForm.OnStepChanged() in C:\Program Files\GeoFrameworks\GIS.NET 3.0\Tileset Utility\C#\WizardForm.cs:line 136
       at GeoFramework.Tilesets.WizardForm.ShowStep(Panel panel) in C:\Program Files\GeoFrameworks\GIS.NET 3.0\Tileset Utility\C#\WizardForm.cs:line 66
       at GeoFramework.Tilesets.WizardForm.nextButton_Click(Object sender, EventArgs e) in C:\Program Files\GeoFrameworks\GIS.NET 3.0\Tileset Utility\C#\WizardForm.cs:line 214
       at System.Windows.Forms.Control.OnClick(EventArgs e)
       at System.Windows.Forms.Button.OnClick(EventArgs e)
       at System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent)
       at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
       at System.Windows.Forms.Control.WndProc(Message& m)
       at System.Windows.Forms.ButtonBase.WndProc(Message& m)
       at System.Windows.Forms.Button.WndProc(Message& m)
       at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
       at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
       at System.Windows.Forms.NativeWindow.DebuggableCallback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
       at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG& msg)
       at System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(Int32 dwComponentID, Int32 reason, Int32 pvLoopData)
       at System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32 reason, ApplicationContext context)
       at System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32 reason, ApplicationContext context)
       at System.Windows.Forms.Application.Run(Form mainForm)
       at GeoFramework.Tilesets.Program.Main() in C:\Program Files\GeoFrameworks\GIS.NET 3.0\Tileset Utility\C#\Program.cs:line 17
       at System.AppDomain._nExecuteAssembly(Assembly assembly, String[] args)
       at System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence assemblySecurity, String[] args)
       at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
       at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
       at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
       at System.Threading.ThreadHelper.ThreadStart()

The gml import file can be provided upon request along with the tileset config file which has been produced. Any help will be greatly appreciated.

Thankyou.

Friday, February 20, 2009 at 5:20:42 PM by Jon Person

I believe that the Mastermap format differs enough from GML to throw a monkey wrench into our reader. I would like to support this format, however, if it's at all possible since it's based upon GML. Would you be able to email me a GML file which causes this error? You can send it to me directly here: jperson@geoframeworks.com. Thanks for taking the time to report details of this issue.

Thursday, March 05, 2009 at 7:42:02 PM by Jon Person

We have the example MasterMap data file now, thank you. We'll need some time to analyze this file carefully to add support. Requests for OSM are more common so we'll likely work this into GML if it's at all possible. I'm marking this issue as Postponed since a firm deadline is unavailable, but we'll certainly be dedicating time to it.

Issue #118 (Postponed for Later): Add decorations for drawing lines and polygons

Wed, 13 Aug 2008 18:41:35 GMT

Wednesday, August 06, 2008 at 2:48:00 AM by Ted Macy

Your built-in selection mouse handling is very nice.   You display excellent graphics and I don't want to replicate them.  However, we also need the ability to draw line segments and line strings on the map.  For my own immediate needs, if I could just get you to draw the selection object, w/o performing the selection search I would be happy (at least for a while :)).   There are operations that I will need to perform once a line is drawn.

In other packages that we are migrating from, there were two line drawing modes... line segment, where you click on a location, drag to another location, and release, giving you a two-position straight line segment.   And then there is the method of drawing a polyline (a linestring) which would be the same method as drawing a polygon.   You just don't close it.

From the selection standpoint, imagine that I trace a stream on a background image, and I want to find all houses within 300 feet.  So there is merit in having a line-based selection tool, including lines selected from a layer.

And, while I'm asking... I've never seen the right-click and drag, left click to insert vertex method of polygon drawing.  Would it be possible to get a setting added that would implement a left-click to start the polygon and add vertices, and double-click to end the drawing mode?    I do realize that your solution provides more mouse-based operations w/o the user explicitly being forced to define a mouse-action mode to start an operation, but the user education for our customers will be quite significant, and frankly, they don't like change.  We'll take a lot of flack if we FORCE them to change the way the operate.

Thanks!

Wednesday, August 13, 2008 at 6:41:35 PM by Jon Person

Yes, the logic in the Selection class could be opened up into a more general-purpose means to draw lines and polygons. Perhaps it can also be configured to where the buttons involved with starting, continuing, and committing selection points can be configured. I agree that we shouldn't force end-users to use the control one specific way.

I believe Phil and I discussed the problem with making controls interactive (versus having people write their own) but this seems a common enough feature to me to discuss further.

Issue #106 (Postponed for Later): What is an XML solution for georeferencing images?

Mon, 17 Nov 2008 17:36:05 GMT

Tuesday, July 15, 2008 at 4:06:01 PM by Jon Person

The GeoTIFF file format is a widely-used way to embed georeferencing information such as Tie Points, Projection, Ellipsoid, and Datum right inside of a single image.  That's fine, but it quickly becomes problematic for the .NET Framework, because the .NET Framework cannot write image metadata.  As a result, we've found that it'll take extreme amounts of labor to support writing GeoTIFF imagery in the native TIFF format.

But then... isn't XML replacing all file formats?  I'd like to get some feedback from the community here.  We can easily implement an XML format which, when paired with any image .NET supports, can let users georeference any image... not just TIFF.

So here's the question:  How tied is your organization to the GeoTIFF format?  Would you be able to use a GIS.NET XML-based solution to georeferencing images?

Tuesday, July 15, 2008 at 4:20:33 PM by Jon Person

The file format would look like this:

MyImage.jpg
MyImage.jpg.xml

... using the same base filename but adding ".xml"

The XML file itself would contain:

1) The projection of the image
2) A list of two or more "tie points" (geographic coordinates [lat/long]) for the image

... since our Projection and Position classes already support XML, reading and writing the file would be trivial.

Monday, July 21, 2008 at 3:00:56 AM by Marcel Suter

I would very welcome this.

I have now worked quite a long time trying to get a proper support of bitmapped data for my evaluation work. I have now found that ER Mapper is able to produce correctly formatted GeoTIFFs, but still i am very unsure about that format at all. I need to produce correctly projected images out of images, which i will then use in GIS 3.0. For me, it would be much simpler to use an XML-Format, since I am familiar with XML, but not with GeoTIFF. I do still not have found satisfying tool support for GeoTIFF.

What would be very good, would be some support to convert from XML to GeoTIFF and vice versa in a programmatic way and probably an Example app for this. Thus I could produce correctly referenced XML files and then "export" them to GeoTIFF for compatibility reasons.

Again, this would be VERY NICE! :-)

Tuesday, August 12, 2008 at 2:02:17 PM by Jon Person

Yes, this will be implemented soon and most of the work is already finished. What needs to happen is both the Projection and the Geographic Tie Points of an image needs to be serialized to XML. Right now the Projection class can be serialized via WriteXml, and tie points can be written individually since Position is GML/XML compliant. A Picture.Save() method will be implemented to encapsulate this functionality; in the meantime you can make XML files using this approach.

Thursday, October 23, 2008 at 11:57:45 PM by Peter van Rees

We use a lot of gif and jpg files. Now using the world file format from Esri (http://en.wikipedia.org/wiki/World_file) which lacks projection info. I would welocome this solution!

Monday, November 17, 2008 at 5:36:05 PM by Jon Person

Just an update that I hope to revisit this issue in the next week. We already have the code necessary to serialize a projection, so adding code to de/serialize a Picture object should be trivial at this point.

Issue #226 (Postponed for Later): Implement MapMouseEventArgs to include coordinates in map mouse events.

Mon, 16 Feb 2009 21:33:37 GMT

Tuesday, December 30, 2008 at 6:05:03 AM by Peter van Rees

Would it be possible to:

1. make the parameter on the OnClick method of a Layer/GeographicObject object of type GeoFramework.PositionEventArgs instead of System.EventArgs? Now there is no simple way to find out where the click occurred within the Layer/GeographicObject.

2. Inlude the projected coordinates in GeoFramework.PositionEventArgs? (just for convenience)

Tuesday, December 30, 2008 at 6:26:58 AM by Peter van Rees

hmmm... Somehow the mouse events do not get fired at all in my app. Do I need to enable them somewhere?

Tuesday, December 30, 2008 at 11:13:27 AM by Jon Person

Hmm, that's a great idea, actually. We'd probably do a MapMouseEventArgs with pixel/projected/geographic coordinates. Also, if you have a Polygon and it's Click event is fired, the coordinate will already be fully contained by the polygon.

Tuesday, December 30, 2008 at 11:51:09 AM by Peter van Rees

Great! Can you tell me more about what to expect from these events on a layer? They don't seem to be fired at all. I expected the events to be fired if the mouse event took place within the layers extent.

Can you give an estimate of the moment this will be implemened? (in other words can I wait for it, or should I implement a workaround for now?)

Monday, February 16, 2009 at 9:33:37 PM by Jon Person

Hi Peter, a workaround is best. Our hands are tied regarding this method because it would be a breaking change. I'll be sure it does get implemented for a major release.

Issue #230 (Released): Improved HTC Device Detection

Thu, 19 Feb 2009 16:24:56 GMT

Wednesday, January 14, 2009 at 12:10:53 PM by Yatin Patel

trying to detect internal device on htc 7501 advantage phone (Windows mobile 6) but it does not detect any device. any suggestions?? it works fine with microsoft gps api.

Thanks

Thursday, January 15, 2009 at 10:58:22 AM by Jon Person

The HTC series of devices uses a proprietary GPS Intermediate Driver. It's quite possible that their registry structure has changed again. Are you able to export anything from the registry? If so, I'd like to give you the path to a registry branch I'd like you to export. Then, I can have a look and it'll help me determine why the device isn't being picked up.

Friday, January 16, 2009 at 8:06:43 AM by Yatin Patel

yes i can export anything from registry.

Friday, January 16, 2009 at 8:12:20 AM by Yatin Patel

suggestion, as i can run any third party mapping software successfully without changing anything, it also detects gps so easily, can we not do the same for gps.net framework?

Wednesday, January 21, 2009 at 11:28:39 AM by Yatin Patel

please give me path to a registry branch so that i can export and send it to you.

Friday, February 06, 2009 at 2:20:35 PM by Jon Person

Hi Yatin, my apologies for the delay. The registry branch to export is:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\GPS Intermediate Driver

Thursday, February 19, 2009 at 4:24:56 PM by Jon Person

We now have proper HTC support in GPS3. The design of the GPSID functionality is so different, however, that we can't implement all this in GPS2 as we originally hoped. We'll shoot for a release in April.

Issue #228 (Released): NmeaInterpreter hangs during Start on Samsung Omnia and Samsung Epix

Fri, 15 May 2009 02:39:00 GMT

Monday, January 12, 2009 at 3:02:13 AM by

Hello,

we are experiencing a problem where the GeoFramework seems to hang. Precisely a call to a method does not return.

This Problem occurs on Samsung Omnia and Samsung Epix (i907).

Code snippet to reproduce the problem:

GpsStream stream = new GpsStream();
NmeaInterpreter interpreter = new NmeaInterpreter(stream);
// the following call does not return. Waittime > 5 min.
interpreter.Start();

I'm referencing GeoFRamework.PocketPC.dll (1.4.7.0) and GeoFramework.Gps.PocketPC.dll (2.3.20.0)

I can also send you the complete source code of our test-application.

Kind regards
Cem Aslan

Monday, January 12, 2009 at 12:04:28 PM by Jon Person

This is most likely caused by a missing registry entry on the Samsung devices. On these devices, the registry value which indicates the "Program Port" is missing by default. This can be corrected by going into the GPS Intermediate Driver control panel then specifying a port (usually "GPD1:"). When you click "OK" the registry value should be saved.

Monday, January 12, 2009 at 1:30:28 PM by Jon Person

If you want to repair this registry value, manually, you can do this:

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\GPS Intermediate Driver\Multiplexer]
"DriverInterface"="GPD1:"

Thursday, January 22, 2009 at 3:54:44 AM by

Yes, setting the Port to GPD1: resolves the issue. Unfortunately some of our customers use also Programs that need a Com-Port setting (and stop working if it is set to GPD1:) But since other programs that use the Windows Mobile Intermediate driver work independet of this settings it would be nice if GeoFrameworks could work independet, too. Further when setting the Port to GPD1: the hanging-issue is solved but the application still gets no GPS-Position. Are there any known issues with Samsung Windows-Moble Phones?

Sunday, February 15, 2009 at 4:18:40 PM by Jon Person

Alright. We have the Samsung Omina i900 in-house now. After trying all afternoon, attempts to connect to the default GPSID port (COM3:) fails to read any data. It now appears that the Omina has incorrect settings by default for the GPSID. It looks like the Samsung GPS Card will need specific handling to make it work seamlessly. Uh, Samsung? Care to test your stuff before releasing it to market?

Sunday, February 15, 2009 at 8:55:05 PM by Jon Person

After a full day of research, I'm happy to report that we have the Omina now working smoothly with GPS.NET 3.0. The key was using smaller buffer sizes; the GPSID driver apparently cannot handle anything larger than about 512 bytes. If a buffer is too large, a call to read data from the port will hang indefinitely.

This is clearly a bug in the design of the Omina's GPSID driver. Development of GPS.NET 3.0 is in full swing right now, and I expect to have it released perhaps as soon as April 1.

Friday, May 15, 2009 at 2:39:00 AM by Jon Person

This issue has been resolved as of GPS.NET 3.0, which gracefully detects HTC hardware such as the Samsung Omina. The problem is caused by an undocumented buffer size requirement of the hardware. Any buffer size over their limit causes the hang that you speak of.

Issue #217 (Released): Error: A port name must be specified in order to open a serial connection.

Fri, 15 May 2009 02:38:23 GMT

Friday, December 12, 2008 at 2:30:03 PM by Jon Person

Rare reports of this error have arrived, and a developer was kind enough today to assist me with troubleshooting the cause of the error. As a result, some changes are now being review for the "SharedGpsDevice" class. The effects are positive and far-reaching enough that I've decided to roll them into GPS.NET 2.0 instead of postponing them for version 3.0, now under development.

This exception is caused by the technique GPS.NET uses to determine the name of the shared program port. After looking at the code, and discussing the approach with John Spaith, the guy at Microsoft who wrote the GPSID (and a great person, I might add!) we identified better approaches. I will now be working on a fix, and once it passes tests for all the mobile devices, will roll it out. This will also be implemented into GPS3's "IntermediateDriver" class.

Friday, December 12, 2008 at 2:35:08 PM by Jon Person

FYI: The stack trace of this error is:

"A port name must be specified in order to open a serial connection. Port names are typically three
letters followed by a number, such as "COM7:". "

GeoFramework.IO.Serial.SerialStream..ctor()
at GeoFramework.IO.Serial.SerialStream..ctor()
at GeoFramework.IO.SharedGpsDevice.GetHardwareStream()
at GeoFramework.IO.Devices.GetStreamByProtocol()
at GeoFramework.IO.GpsStream.Refresh()
at GeoFramework.IO.GpsStream.get_Length()
at GeoFramework.Gps.Interpreter.Start()

... a missing registry value causes a null to be passed into the SerialStream constructor.

Friday, December 12, 2008 at 2:57:37 PM by Jon Person

I'll be using an AT&T Tilt, Intermec CN3, and an iPAQ 2945b as the primary test models for these changes. The Tilt represents an example of a proprietary GPSID. The Intermec represents a semi-standard device (a built-in in GPS but mostly standard registry), and the iPAQ is a completely standard device. These test cases should satisfy the three major designs for GPSID functionality.

Thursday, February 19, 2009 at 4:25:46 PM by Jon Person

Tests are completed for the HTC, AT&T Tilt and Samsung Omina series for GPS3. The design of the GPSID feature is fundamentally different, however, so we can't work this into GPS2 as we originally had hoped.

Friday, May 15, 2009 at 2:38:23 AM by Jon Person

This issue has been resolved in GPS.NET 3.0, which has a rewritten, cleaner implementation for the GPS Intermediate Driver. This error will no longer occur.

Issue #110 (Released): PositionChanged returns incorrect PostionTimeStamp on AT&T Tilt

Fri, 15 May 2009 02:37:28 GMT

Saturday, July 19, 2008 at 6:20:25 AM by Bud Cribar

The following sequence of sentences are produced by the ATT Tilt

$GPGGA,165822.0,4030.537242,N,10500.836529,W,1,08,1.7,1480.5,M,,,,*24
$GPRMC,165822.0,A,4030.537242,N,10500.836529,W,18.4,91.9,140708,,,A*75
$GPGSA,A,3,32,20,11,16,14,30,23,255,,,,,2.8,1.7,2.2*0F
$GPVTG,91.9,T,,M,18.4,N,34.1,K*5A
$GPGSV,3,1,11,01,50,056,,05,04,032,31,11,23,255,32,14,28,074,27*75
$GPGSV,3,2,11,16,16,158,,20,44,307,28,22,09,135,,23,15,278,33*7E
$GPGSV,3,3,11,30,20,050,32,31,77,060,,32,70,307,*4A
$GPRMC,,V,,,,,,,,,,N*53
$GPGSA,A,1,,,,,,,,,,,,,,,,*32
$GPVTG,,T,,M,,N,,K*4E
$GPGSV,3,1,11,01,50,056,,05,04,032,31,11,23,255,32,14,28,074,27*75
$GPGSV,3,2,11,16,16,158,,20,44,307,28,22,09,135,,23,15,278,33*7E
$GPGSV,3,3,11,30,20,050,32,31,77,060,,32,70,307,*4A
$GPRMC,,V,,,,,,,,,,N*53
$GPGSA,A,1,,,,,,,,,,,,,,,,*32
$GPVTG,,T,,M,,N,,K*4E
$GPGSV,3,1,11,01,50,056,,05,04,032,30,11,23,255,35,14,28,074,26*72
$GPGSV,3,2,11,16,16,158,,20,44,307,25,22,09,135,,23,15,278,36*76
$GPGSV,3,3,11,30,20,050,32,31,77,060,25,32,70,307,21*4E
$GPGGA,165837.5,4030.533208,N,10500.729856,W,1,03,3.8,1480.5,M,,,,*2D

When the gps_PositionCHanged event is fired on the last $GPGGA sentence parse the e.PositionTimeStamp is incorrectly reported as 1/1/01

Saturday, July 19, 2008 at 6:22:55 AM by Bud Cribar

Problem with the fractional timestamp?

Thursday, July 24, 2008 at 8:12:20 AM by Bud Cribar

This happens on my Garmin iQue M3 also.... I put in a trap to detect 01/01/01 and here are some results...

7/24/08Time: 8:23:30 AM
Rev. 2.00 Build 3125
Year = 101/01/01 00:00:00.00000
Curr:
>>> Warning
<<< Warning
7/24/08Time: 8:23:30 AM
Rev. 2.00 Build 3125
Year = 101/01/01 00:00:00.00000
Curr:
>>> Warning
<<< Warning
7/24/08Time: 8:23:30 AM
Rev. 2.00 Build 3125
Year = 101/01/01 00:00:00.00000
Curr:
>>> Warning
<<< Warning
7/24/08Time: 8:23:30 AM
Rev. 2.00 Build 3125
Year = 101/01/01 00:00:00.00000
Curr:
>>> Warning
<<< Warning
7/24/08Time: 8:34:10 AM
Rev. 2.00 Build 3125
Year = 101/01/01 00:00:00.00000
Curr:
>>> Warning
<<< Warning
7/24/08Time: 8:34:10 AM
Rev. 2.00 Build 3125
Year = 101/01/01 00:00:00.00000
Curr:
>>> Warning
<<< Warning
7/24/08Time: 8:35:38 AM
Rev. 2.00 Build 3125
Year = 101/01/01 00:00:00.00000
Curr:
>>> Warning
<<< Warning
7/24/08Time: 8:35:38 AM
Rev. 2.00 Build 3125
Year = 101/01/01 00:00:00.00000
Curr:
>>> Warning
<<< Warning
7/24/08Time: 8:35:38 AM
Rev. 2.00 Build 3125
Year = 101/01/01 00:00:00.00000
Curr:
>>> Warning
<<< Warning
7/24/08Time: 8:35:39 AM
Rev. 2.00 Build 3125
Year = 101/01/01 00:00:00.00000
Curr:
>>> Warning
<<< Warning
7/24/08Time: 8:35:39 AM
Rev. 2.00 Build 3125
Year = 101/01/01 00:00:00.00000
Curr:
>>> Warning
<<< Warning
7/24/08Time: 8:35:40 AM
Rev. 2.00 Build 3125
Year = 101/01/01 00:00:00.00000
Curr:
>>> Warning
<<< Warning
7/24/08Time: 8:35:40 AM
Rev. 2.00 Build 3125
Year = 101/01/01 00:00:00.00000
Curr:
>>> Warning
<<< Warning
7/24/08Time: 8:35:41 AM
Rev. 2.00 Build 3125
Year = 101/01/01 00:00:00.00000
Curr:

Wednesday, August 13, 2008 at 7:20:39 PM by Jon Person

Hmm... I remember we found a problem with the milliseconds-parsing code being incorrect. This was resolved I believe in version .20; it did indeed involve the fractional milliseconds parsing. Could it be that this is what causes the tests on your end to report different values?

Wednesday, August 13, 2008 at 7:21:21 PM by Jon Person

hmm PositionTimeStamp should be the current date. this is strange. I'll go check now

Thursday, September 04, 2008 at 2:16:27 PM by Jon Person

Hi Bud, do you have a log of GPS data which can go along with the failed sentence? I need some help to repro the exact moment where the date/time stamp becomes incorrect.

Sunday, October 19, 2008 at 5:11:01 PM by Bud Cribar

Yes,
This is the actual log that the ATT Tilt produced and caused the error...
$GPGGA,165822.0,4030.537242,N,10500.836529,W,1,08,1.7,1480.5,M,,,,*24
$GPRMC,165822.0,A,4030.537242,N,10500.836529,W,18.4,91.9,140708,,,A*75
$GPGSA,A,3,32,20,11,16,14,30,23,255,,,,,2.8,1.7,2.2*0F
$GPVTG,91.9,T,,M,18.4,N,34.1,K*5A
$GPGSV,3,1,11,01,50,056,,05,04,032,31,11,23,255,32,14,28,074,27*75
$GPGSV,3,2,11,16,16,158,,20,44,307,28,22,09,135,,23,15,278,33*7E
$GPGSV,3,3,11,30,20,050,32,31,77,060,,32,70,307,*4A
$GPRMC,,V,,,,,,,,,,N*53
$GPGSA,A,1,,,,,,,,,,,,,,,,*32
$GPVTG,,T,,M,,N,,K*4E
$GPGSV,3,1,11,01,50,056,,05,04,032,31,11,23,255,32,14,28,074,27*75
$GPGSV,3,2,11,16,16,158,,20,44,307,28,22,09,135,,23,15,278,33*7E
$GPGSV,3,3,11,30,20,050,32,31,77,060,,32,70,307,*4A
$GPRMC,,V,,,,,,,,,,N*53
$GPGSA,A,1,,,,,,,,,,,,,,,,*32
$GPVTG,,T,,M,,N,,K*4E
$GPGSV,3,1,11,01,50,056,,05,04,032,30,11,23,255,35,14,28,074,26*72
$GPGSV,3,2,11,16,16,158,,20,44,307,25,22,09,135,,23,15,278,36*76
$GPGSV,3,3,11,30,20,050,32,31,77,060,25,32,70,307,21*4E
$GPGGA,165837.5,4030.533208,N,10500.729856,W,1,03,3.8,1480.5,M,,,,*2D

Sunday, October 19, 2008 at 5:14:07 PM by Bud Cribar

If you feed that data to an interpreter and set a breakpoint on the gps_PositionCHangedEvent you will see that e.PositionTimeStamp is incorrectly reported as 1/1/01 on the last GPGGA sentence

Monday, November 17, 2008 at 5:09:46 PM by Jon Person

Hmm, it looks like we'll need special support for the AT&T Tilt sentence. Is it called the "Tilt" as in breaking a pinball machine?

Friday, May 15, 2009 at 2:37:28 AM by Jon Person

We had to remove the notion of a timestamp associated with each position. But, we've replaced this with a public synchronization object which can be locked to prevent race conditions and ensure that a set of values are unchanged as you read them.

Issue #104 (Released): Enabling Devices.IsClockSynchronizationEnabled seems to bring device to a crawl

Fri, 15 May 2009 02:34:09 GMT

Tuesday, July 15, 2008 at 1:00:50 PM by Neil Andrews

If I set Devices.IsClockSynchronizationEnabled to true, the device seems to slow right down as if CPU usuage has gone right up. If I do not set this property everything is ok.

Thanks
Dan

Tuesday, July 15, 2008 at 1:06:14 PM by Jon Person

Hmm, that's strange. When this property is enabled, then changes to the UTC date/time will cause the device's internal clock to be reset -- as long as a GPS satellite fix is present. This code requires a P/Invoke to set the system time. I'd assume that's where the bottleneck is. The only other possible bottleneck would be the subscription to the UtcDateTimeChangted event which would fire frequently.

Tuesday, July 22, 2008 at 3:06:18 PM by Jon Person

Hi neil, after looking at the code, this does look like a bottleneck at the API level. The additional event subscription alone isn't enough to justify the slowdown. I'll keep this issue alive in the form of Postponed so that it gets revisited in 3.0.

Friday, May 15, 2009 at 2:34:09 AM by Jon Person

The engine for GPS.NET 3.0 has been slimmed down considerably compared to version 2.0, so I do now expect an improvement. We're using a slightly different technique to update the system clock now. I'd honestly be surprised to see a huge improvement at the API level but it should at least be noticably better.

Issue #73 (Postponed for Later): Support for Digital Elevation Model (DEM) files

Wed, 18 Jun 2008 09:59:34 GMT

Wednesday, June 18, 2008 at 9:59:34 AM by Jon Person

Requests have arrived via email to add support for ASCII DEM files in GIS3. I have no objection to this personally; can we get some others to chime in on how soon they'd like to see this feature?

Issue #32 (Postponed for Later): Add support for MicroStation DGN file format.

Mon, 19 May 2008 09:33:59 GMT

Monday, May 19, 2008 at 9:32:43 AM by Jon Person

Some customers have requested support for the "DGN" file format, which is for the MicroStation CAD application. While this format is not used as much as, say, ESRI or MapInfo, the MicroStation application itself is in use today by many large organizations for geographic purposes. Supporting the file format would help users bridge the gap from MicroStation to more targeted GIS applications.

Monday, May 19, 2008 at 9:33:59 AM by Jon Person

Several variations of GDN exist. Can we get some feedback on which variations are best to support? It looks like the newer "V8 GDN" variation would be preferable to support. I'll add the Adobe PDF technical specification documents to SCC now.

Issue #3 (Postponed for Later): Add support for MapInfo TAB file format

Wed, 30 Apr 2008 04:41:00 GMT

Issue #266 (Released): Add "IsLoading" to Tileset

Fri, 15 May 2009 02:14:55 GMT

Thursday, April 09, 2009 at 7:32:54 AM by Phil Marks

I could put a wait-cursor up while the tileset thread is loading tiles not already loaded.

Thursday, April 09, 2009 at 4:20:13 PM by Jon Person

I think Phil's trying to synchronize the behavior of the Map with his own application; enabling or disabling buttons based on Map behavior. As in the other issue, this is a thread synchronization issue and we can't block threads just for this. However, making Tileset.IsLoading return true when the loading thread has an active workload would help him to control his UI better.

Friday, May 15, 2009 at 2:14:55 AM by Jon Person

The property has been added. This boolean will return true whenever the loading thread has a workload.

Issue #274 (Behavior Is By Design): Can a Tileset view the exact extent of my data?

Fri, 15 May 2009 02:19:24 GMT

Friday, April 24, 2009 at 8:50:09 AM by Phil Marks

For tilesets on my PDA: Once the tileset is created, and i run it on the PDA, if i zoom to the rectangle of the original corner points of my map, the screen is pretty will filled up, such that on at least 2 sides there is no margin. I want that situation to be the outermost tiles, without wasting the topmost level on a more zoomed out map which has lots of margin. Then, 2 levels would have a more usefull map, and still not have the larger number of tiles which it takes to produce 3 levels. Same for maps with more levels. If i zoom to fit on my PC, the top levels of my maps fill the screen. I want this to be the same for my PDA maps as well. This way, on my PDA, i can get 3 good levels out of a single map, without expending all the memory which it takes to produce corresponding tilesets with 4 levels, the way it is now.

Friday, May 15, 2009 at 2:19:24 AM by Jon Person

Unfortunately, this is not possible. Tilesets use a fixed zoom-level algorithm for all tilesets. This is done for the following reason: by using a single set of zoom levels, it allows tilesets to be compatible with one another. They can be combined into a single map this way.

I see your point, that you're probably trying to zoom into a specific extent. Instead of changing the zoom level behavior itself (which would cause other problems), you can change the Map control to not zoom by zoom level. This would let you zoom to a specific extent, though you may get some scaling behavior as tile bitmaps are scaled.

Issue #272 (Released): OnMouseMoveNone throws unhandled exception

Tue, 28 Apr 2009 07:47:16 GMT

Wednesday, April 22, 2009 at 2:21:52 PM by Ryan Dotson

We have a customer seeing periodic unhandled exceptions that crash the application.  I have implemented an UnhandledException event to catch and log the details.  It appears the problem is coming from Geoframeworks Libraries.  Please help!

Here are the details:

Exception: Index was outside the bounds of the array.
Source: GeoFramework.Drawing
Stack Trace:
at GeoFramework.Shapes.Layer.CalculateProjectedExtent()
   at GeoFramework.Shapes.GeographicObject.get_ProjectedExtent()
   at GeoFramework.Shapes.Layer.CalculateProjectedExtent()
   at GeoFramework.Shapes.GeographicObject.get_ProjectedExtent()
   at GeoFramework.Shapes.Layer.CalculateProjectedExtent()
   at GeoFramework.Shapes.GeographicObject.get_ProjectedExtent()
   at GeoFramework.Shapes.Layer.Search(PointF projectedPoint, List`1 results)
   at GeoFramework.Gis.Map.Search(PointF projectedLocation)
   at GeoFramework.Gis.Map.OnMouseMoveNone(Object chezburger)
   at System.Threading._ThreadPoolWaitCallback.WaitCallback_Context(Object state)
   at System.Threading.ExecutionContext.runTryCode(Object userData)
   at System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode code, CleanupCode backoutCode, Object userData)
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
   at System.Threading._ThreadPoolWaitCallback.PerformWaitCallbackInternal(_ThreadPoolWaitCallback tpWaitCallBack)
   at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback(Object state)

Wednesday, April 22, 2009 at 2:38:59 PM by Ryan Dotson

A few more details: There are objects that are being added to the map layers constantly as the application runs.. I believe all the calls to Layer.Add() are wrapped in an Invoke() delegate call even though the objects are created on a worker thread. Just in case, is the Add() method threadsafe? Is there a locking object that is necessary?

Saturday, April 25, 2009 at 9:27:58 AM by Phil Smith

The immediate issue of cross-thread exceptions been resolved. Consuming the Map controls ExceptionOccured event allows for trapping errors that occur on an internal thread. The mouse event thread was not triggering this event when encountering exceptions.

Tuesday, April 28, 2009 at 7:47:16 AM by Jon Person

Regarding your other question, Ryan: All geographic objects are thread-safe, with the exception of GeographicPath whose GraphicsPath object is not always locked. You may modify Layer and other GeographicList-derived objects from multiple threads. The only real threading issues arise when you try to access or modify GraphicsPath objects from multiple threads in a GeographicPath.

Issue #265 (Released): Problem reading values from last column of DBF file

Mon, 11 May 2009 15:05:16 GMT

Tuesday, April 07, 2009 at 2:13:09 AM by João Saraiva

(This is just to create an issue corresponding to a problem already reported by e-mail)

I believe I found a problem with your DbaseReader: apparently it cannot correctly load values when the specified column name is the last one on the DBF (in my particular case, a set of IDs are not being read correctly when the ID column is in the last position).

Best regards,
João Saraiva

Monday, May 11, 2009 at 3:05:16 PM by Phil Smith

The file position in the dbase reader was off by one, truncating the last byte of each record. Fixed.

Issue #252 (Cannot Reproduce): GIS.NET 3.0 VB.NET Example, Desktop Framework 3.5 Reference Exception

Thu, 05 Mar 2009 19:31:36 GMT

Friday, February 27, 2009 at 2:45:22 AM by

After installing the trial version of GIS.NET and loading the VB.NET I opened the GIS.NET Example (VB.NET) project in the …\GIS.NET 2.0\Desktop Framework 3.5\Examples\VB.NET folder

When I ran the project for the first time I got the following error:
Could not load file or assembly 'GeoFramework, Version=2.0.50727.0, Culture=neutral, PublicKeyToken=3ed3cdf4fdda3400' or one of its dependencies. The system cannot find the file specified.

Searching my hard-drive for the file gave the following results:
…\GIS.NET 2.0\Desktop Framework 2.0\ GeoFramework.dll contains version 1.4.3600.7
…\GIS.NET 2.0\Desktop Framework 3.5\ GeoFramework.dll contains version 2.0.50727.1

How can I get the project to run?
Regards,
Sietse Wijnker,
SW-Software

Thursday, March 05, 2009 at 7:31:36 PM by Jon Person

This error suggests that an older assembly is being referenced somehow. The newer builds of GIS.NET should be looking for version 2.0.0.0 (not version 2.0.50727.0). This can be resolved with these steps:

1) Remove the assembly reference for GeoFramework or GeoFramework.PocketPC
2) Re-add the assembly reference via the Add Reference dialog. You should see version "2.0.0.0" in the list.
3) Rebuild the project

Issue #283 (Released): Changing the Quality property has no effect at run-time

Thu, 07 May 2009 16:47:13 GMT

Thursday, May 07, 2009 at 4:17:27 PM by Jon Person

The Quality property of the Map control functions when it's changed during design-time, but once an application starts the property has no effect.

Thursday, May 07, 2009 at 4:25:42 PM by Jon Person

Changes at run-time will now update quality settings for all map objects (permanent items, movable items, and decorations).

Thursday, May 07, 2009 at 4:47:13 PM by Jon Person

(NOTE: Fixed in both the live branch and the branch for GPS3 User Controls)

Issue #280 (Released): Improve GML support for "" tags

Thu, 07 May 2009 12:38:41 GMT

Thursday, May 07, 2009 at 12:26:57 PM by Jon Person

There are many ways in GML to represent an extent of some kind.  Recently, more files are showing up whose extends are in the form of a gml:Emvelope with two embedded <gml:Pos> tags.   GIS.NET 3 should be improved to support this, and similar envelope formats.

Example:

     <gml:Envelope srsName="urn:adv:crs:DE_DHDN_3GK3_NI100">
        <gml:pos>3568912.140 5798882.760</gml:pos>
        <gml:pos>3580879.680 5812112.870</gml:pos>
      </gml:Envelope>

Thursday, May 07, 2009 at 12:38:41 PM by Jon Person

The GeographicRectangle(XmlReader) constructor now handles <gml:pos> tags for corner points. The corner points can be in any order; the left/top/right/bottom will be calculated from min/max values.

Issue #279 (Released): ArgumentNullException when opening ESRI Shapefile with Line object

Tue, 05 May 2009 11:50:45 GMT

Tuesday, May 05, 2009 at 11:50:08 AM by Jon Person

When constructing an ESRI Shapefile object, custom Types can be specified for points, lines and polygons.  When the Line or Polygon types were used, however, the following exception would occur:

System.ArgumentNullException was unhandled
  Message="Value cannot be null. Parameter name: con"
  ParamName="con"
  Source="mscorlib"
  StackTrace:
       at System.Reflection.Emit.DynamicILGenerator.Emit(OpCode opcode, ConstructorInfo con)
       at GeoFramework.Shapes.IO.GeographicDataSource.SetLineType(Type type)
       at GeoFramework.Shapes.IO.GeographicDataSource..ctor(Stream stream, Type markerType, Type lineType, Type polygonType, Encoding encoding, Projection projection)
       at GeoFramework.Shapes.IO.EsriShapefile..ctor(Stream stream, Type pointType, Type lineType, Type polygonType, Encoding encoding, Projection projection, String textColumnName)
       at GeoFramework.Shapes.IO.EsriShapefile..ctor(String filePath, Type pointType, Type lineType, Type polygonType, Encoding encoding, Projection projection, String textColumnName)
       at GeoFramework.Shapes.IO.EsriShapefile..ctor(String filePath, Type pointType, Type lineType, Type polygonType)

... this exception indicates that a constructor with two parameters (Projection and List<Position>) was expected but not found.

Tuesday, May 05, 2009 at 11:50:45 AM by Jon Person

This has been fixed. Constructors were added to Line, Polygon, LabeledLine and LabeledPolygon to accept a Projection and a List<Position>.

Issue #277 (Released): Selections should not include objects whose Visible property is False.

Mon, 04 May 2009 10:58:40 GMT

Monday, May 04, 2009 at 10:58:25 AM by Jon Person

The Search(Polygon, SearchMode, List<GeographicObject>) method was not testing the Visible property. As a result, invisible objects were still being returned in a search.

Monday, May 04, 2009 at 10:58:40 AM by Jon Person

This is now fixed. The Visible property is now included in the search.

Issue #261 (Released): Add ability to modify Tileset loading thread priority

Tue, 28 Apr 2009 12:40:21 GMT

Tuesday, March 31, 2009 at 11:51:33 AM by Phil Marks

I have a form with a map control on it. Also on this form is a button, "Global Disarm" which needs to be able to be pushed, even as my tilesets are being loaded. Sometimes my tilesets take 15 seconds to load, and the important button gets starved out as the map is rendering. I would like to be able to lower the priority of the tileset rendering threads so that i can push the disarm button at any time without the delay.

Friday, April 03, 2009 at 7:14:05 PM by Jon Person

I concur with Phil's request. All threads in our components should expose a "Priority" property to help developers tune relative performance of threads.

Monday, April 06, 2009 at 9:13:18 AM by Jon Person

A new instance property "LoadingThreadPriority" is now being added to Tileset. It should be set as early as possible. The default priority has also been changed from AboveNormal to Normal to reduce interference with the main application.

Tuesday, April 28, 2009 at 12:40:21 PM by Jon Person

This has been re-fixed after rolling back a previous release.

Issue #267 (Released): GPS Diagnostics Control Panel for Mobile Devices

Wed, 15 Apr 2009 17:46:24 GMT

Thursday, April 09, 2009 at 4:18:43 PM by Jon Person

The GPS Diagnostics Control Panel utility has been released!   We're very excited about this utility because it will reduce the amount of time all of us spend troubleshooting GPS device connections.   This utility also uses the brand new GPS.NET 3.0 beta framework, which offers vastly improved device detection, a smaller footprint, and smaller CPU use.

HOW TO INSTALL

You can find the installer on our main downloads page (http://www.geoframeworks.com/DownloadProducts.aspx).  The installer is geared towards end users (your customers) and installs the utility from the desktop.  When the installer is run, a new icon will be placed in the Control Panel of your mobile device, in the System tab.  A restart is necessary before this will show up.  Once a restart is complete, tap the icon labeled "GPS Diagnostics".

TROUBLESHOOTING GPS ISSUES

When the utility is run, you are presented with a brief welcome screen.  Tap Next.  GPS.NET 3.0 device detection will be started in a new window.  A ListView at the top will display all of the devices which are being tested, and a ListBox underneath will display messages as device detection progresses.   If a device is confirmed as a GPS device, its icon changes and it will be colored green.  If a device fails detection, an error message is shown in the third column of the list view (scroll right to see it).

After anywhere from 10-40 seconds, detection will complete.  At this point you can tap "Next" to troubleshoot any issues, or "View Log" for a record of devices and testing results.  We'll explain logging in a moment.  Tap Next, and the final screen will show any devices which were confirmed as a GPS device.  Suggestions are displayed on this screen if any problems are found, and a suggestion can be tapped to troubleshoot it.   For example, tapping on the "Bluetooth is turned off." suggestion will cause a diaglog to appear asking you if you want to enable Bluetooth.  Other positive messages are displayed here, such as whether the GPS Intermediate Driver is on and properly configured, and which serial port and baud rate should be used.

TROUBLESHOOTING INDIVIDUAL DEVICES

You can perform tests and learn more about any device by tapping on it.  You can tap on a device in the ListView during detection, or in the ListView on the summary screen.  Tapping an icon will bring up a new window, listing properties of the device.  An icon is displayed depending on the status of the device.  A red shield indicates problems; a GPS icon indicates success, and etc.  From this screen, an analysis can be performed on the device.  An analysis will open the device and examine the NMEA data to confirm that all major GPS features such as position, bearing, and speed are actually supported.  A message box will be displayed after the analysis is complete.  After analysis completes, the "Analyze" menu changes to "View Log".

LOGGING

Logging is part of this utility and should be used to more quickly troubleshoot GPS connectivity problems.  Logging is performed automatically whenever the utility is run, and whenever a device is analyzed.  Log text files are created in the root folder of the device:  "GPS Diagnostics Log.txt" for device detection, and other files depending on the name of the GPS device tested.

SENDING LOGS TO GEOFRAMEWORKS

Logs can be viewed from the utility and sent directly to us via our Web Service if you need further support.  After detection completes, a "View Log" menu will appear.  Clicking this will bring up the log file generated by detection.  From this screen, you can examine the log and, if you like, you can send the log file to us.  All reported logs are anonymous and sent to us via the internet.   We welcome and encourage logs from you and your customers for all of your devices because it helps us make adjustments to our software and build a real-time list of supported GPS devices.

FUTURE PLANS

The intent of this utility is to minimize technical support time and to automate the process of getting GPS to work.  The utility should identify problems with specific devices and provide real-time feedback.  The utility depends on GPS.NET 3.0 for all major functionality, and therefore we plan to release the C# source code of the project via CodePlex for you to do with as you wish.  You'll be able to modify, brand, and re-release the utility, plus it will serve as an excellent way to learn about GPS.NET 3.0's device detection features.

GPS.NET 3.0 BETA TESTING

Since this utility uses GPS.NET 3.0 beta, it's the fastest way to see how it works on your equipment.  If you want to help us beta test GPS.NET 3.0, run this utility and you'll know instantly how it works with your equipment.  We've tested this utility extensively on HTC hardware including the AT&T Tilt, Samsung Omina, HTC P3300, and others.  If you send us log files for your experience, it will really help us produce an official release more quickly.

FEEDBACK

You're welcome to make suggestions!  You can contact us via email at "support@geoframeworks.com."

Thursday, April 09, 2009 at 4:23:42 PM by Jon Person

BETA TESTING PERIOD

This utility will stop working on July 1st, 2009. We'll have GPS.NET 3.0 officially released before then. You'll be able to access the source code for this utility and compile it using your own purchased GPS3 license keys. GPS.NET 2.0 users will get a 40% discount towards 3.0, and the 3.0 DLL will include all GPS User Controls (they will no longer be a separate plug-in).

Thursday, April 09, 2009 at 4:47:43 PM by Jon Person

You're welcome to report bugs as a response to this issue, to keep everything organized. Posting a new issue is okay, too, and probably a faster way to get our attention actually.

Wednesday, April 15, 2009 at 4:24:05 PM by Jon Person

After a bunch of logs came in (thank you!!!) we've found that the .NET SerialPort class is completely unable to work with the GPS Intermediate Driver on older Windows Mobile 5.0 devices. So, I'll be rewriting the SerialStream class in order to regain connectivity on WM5; I think it's important we maintain support due to the logs. I will have it completed by the end of the week and released.

Wednesday, April 15, 2009 at 5:46:24 PM by Jon Person

The bug behind the failure of the .NET SerialPort is hilarious.

Issue #116 (Released): Requests/Issue on mouse actions

Fri, 10 Apr 2009 11:03:34 GMT

Wednesday, August 06, 2008 at 1:04:23 AM by Ted Macy

The ZoomOut does not zoom out as fast as zooming in. ZoomOut should be the inverse of zooming in. If I zoom in four times, I could be able to get to the original extent with four zoom outs. To do this, if I have a ZoomPercent of 20%, then on a ZoomIn, I go to 80% of the current extent. On a ZoomOut, I should go to 125% of the current extent... not 120%. I can use the Zoom(percent) function in code to get this behavior, but I loose the advantage of the built-in mouse managers.

And, can we get an additional option on the mouse click and doubleclick action enumerations? I would like ZoomInAndCenter as a combined option. When a person clicks on a map to zoom in, default behavior on most systems is to zoom in and make the clicked point be the center of the map.

Friday, August 08, 2008 at 3:35:31 PM by Phil Smith

The default mouse behavior is to zoom in and out using a constant percent regardless of the starting and end points of a zoom. You example actually changes the zoom percent from one direction to the other (from 20% to 25%). There are other methodogies we can explore for consideration in a future release.

Monday, August 18, 2008 at 4:08:15 PM by Jon Person

Right, we'd need to implement a FIFO stack of zoom levels, which adds to the memory footprint. If we implemented this I imagine it would be DF only.

Friday, April 10, 2009 at 11:03:34 AM by Phil Smith

Some zoome level changes wre implemented with the Tileset changes, including a ZoomMode setting that performs the exact behavior described here. Closing.

Issue #259 (Behavior Is By Design): Sample program of Compact Framework 2.0 VB.NET for Pocket PC works in Mobile OS but not in WINCE device

Mon, 06 Apr 2009 09:18:37 GMT

Tuesday, March 17, 2009 at 6:36:37 AM by

The Sample program which you have provided (Compact Framework 2.0 VB.NET for Pocket PC ) is working in smart phone device having Mobile OS 6.1 but when we deploy the same in the windows CE device having WINCE 5.0, it doesn't search the embedded GPS device. It searches the com ports but the embedded GPS device which is available on com port no. 1, it is unable to detect.

Thursday, March 19, 2009 at 8:48:36 PM by

Saturday, March 21, 2009 at 7:46:05 PM by Jon Person

Hi Sameer. Since there's no GPS Intermediate Driver on WindowsCE, we should check into the COM: port and baud rate settings for this particular device. I suspect that the baud rate may be a non-standard rate such as 9600, and this is causing the device to be unconnectable. Also, can you tell us which specific device you're working with? This can help us research the settings.

Sunday, March 22, 2009 at 3:30:21 AM by

I've just discovered this issue too. I'm using a MIO device running WinCE 5.0.

If I choose COM2 57600 in 3rd party GPS programs it works fine but GPS .NET fails to detect the device. Is there a way to force GPS .NET to use a particular COM port/baud?

Monday, April 06, 2009 at 9:18:37 AM by Jon Person

Yes, you can modify the static GeoFramework.IO.Devices.SerialBaudRates collection. It should include the baud rate 57600 by default already, but you could clear the list and add BaudRate.Baud57600 if necessary.

Issue #256 (Behavior Is By Design): Trial licensing for GPS.NET

Sat, 21 Mar 2009 19:47:23 GMT

Wednesday, March 11, 2009 at 6:54:56 PM by

Just downloaded the demo applicaiton, am trying to view the gps.net demo application. even after pasting in the license key the system does not accept. I am pasting the informaiton in the assembly.vb file per instructions.

Saturday, March 21, 2009 at 7:47:23 PM by Jon Person

There should be two license keys: one for GPS.NET and the other for the GPS.NET Control Toolbox. Some people mistakenly activate a trial of GIS.NET instead of GPS.NET since the product names are so similar. Let's go to this page and make sure that the trial you've activated is for GPS.NET, not GIS.NET: http://www.geoframeworks.com/FreeTrial.aspx

Issue #263 (Released): PowerEvent, SafeHandle and SafeFileHandle are deprecated

Mon, 06 Apr 2009 09:16:51 GMT

Monday, April 06, 2009 at 9:16:33 AM by Jon Person

The PowerEvent class was a feature provided for GPS.NET version 2.0 to add notification of critical power events such as suspending or resuming a device. After extensive testing and development, the PowerEvent class is now deprecated. Specifically, a new technique has been found which eliminates the need for this class. The classes "SafeHandle" and "SafeFileHandle" were being used by PowerEvent, and are thus no longer necessary. GPS.NET 3.0 will still support connection recovery when power is lost, it's just a better technique.

Monday, April 06, 2009 at 9:16:51 AM by Jon Person

Elimination of PowerEvent will also reduce battery use further for GPS.NET 3.0.

Issue #262 (Behavior Is By Design): Running latest Geoframeworks sample code on a HTC Touch

Fri, 03 Apr 2009 19:12:47 GMT

Wednesday, April 01, 2009 at 7:53:39 PM by

I can compile, install and run the C# sample code, and I can detect the GPS device. It even shows the satellite locations (9 or 10 of them) and signal strengths etc. (Radio Button "Use any available GPS device" is selected) so it seems to be actual live data.

BUT, nothing else seems to display anything. Ie on the "location" tab ALL the properties have "..." (ie latitude, longtitude etc - the only field that says anything is the date/time) and on the satellites page, the compass, altitidue and speed are all non responsive. And on the "precison" page I have set the Maximum HDOP and mx VDOP to ensure that it says "Position readings are being accepted" etc etc. Is this an issue with the HTC touch? As it appears to be talking to the GPS ok but not getting much further. I don't know if it matters, but when you push "Start" on the home page, the hourglass icon spins for the whole time you are on any of the pages..is this normal? And says "Connecting to GPS device.." in the status bar.

Also, if you select the "use specific GPS device", and push search, it does not return any results...

We have purchased a licence last year for this, but I downloaded the latest version off the website just now and got the demo registration codes just in case the new version needed them.

Any help would be appreciated.

Friday, April 03, 2009 at 7:12:47 PM by Jon Person

Hmm, it looks like no valid data is arriving from the HTC device. GPS.NET 2.0 has had quite a battle with HTC devices thanks to the unique GPS Intermediate Driver on these devices. They are very strict about buffer sizes; any size too large immediately breaks the driver. Unfortunately, the changes required to elegantly resolve this issue were too much of an architecture change for 2.0, so we rolled changes into 3.0, which supports all HTC devices smoothly and without extra code. I'd like to suggest a workaround but I believe the best option will be to experiment with the beta of GPS.NET 3.0, which I expect will be released within a couple of weeks (around April 15).

Issue #258 (Released): Map Rotation in Compact Framework does work

Tue, 31 Mar 2009 14:06:03 GMT

Thursday, March 12, 2009 at 1:42:48 PM by

I'd like to be able to provide a simple boundary mapping application on a Windows Mobile device. This is easier if the user can rotate the map so that it is "pointed" in the direction he or she is moving. When I set the Rotate property, it will rotate, but then and ArguementOutOfRangeException is thrown. I'd like the map to rotate without the exception.

Thursday, March 12, 2009 at 1:43:53 PM by

"Due to resource limitations currently affecting the majority of compact devices, the rotation of imagery is not supported." is the exception message. I don't think I have any mapping components that have an "image", though - just a polygon, line and marker.

Tuesday, March 31, 2009 at 2:06:03 PM by Phil Smith

The search condition for image types was incorrect; fixed.

Issue #251 (Behavior Is By Design): Add feature to map control to notify user when paint is done so that "after-paint" actions (like enable a button) can be taken

Tue, 31 Mar 2009 14:02:29 GMT

Monday, February 23, 2009 at 9:42:59 AM by Phil Marks

This is a request for a new feature.
With regard to being able to know when a paint of a tileset is done on my PDA:
1. My immediate aim is to be able to hit the zoom button, disable some buttons, have the new rendition of the tileset appear, and then re-enable those buttons, in that order. If this feature were added to GIS.NET, it would also allow the user to put up a progress bar to be shown while zooming is taking place.
2. The problem is that my “after-paint” code, starts execution a few seconds before that new rendition of the tileset appears.
3. After I’ve opened the tileset, it happens mainly as I am first zooming in and panning to the levels.
4. As I am doing the first zooms, after I hit the zoom button, my subsequent code starts executing (i.e. my buttons are re-enabled) a few seconds before the tileset displays in its new rendition.
5. If, after the zoom button is hit, I wait on an auto-reset event, and then, at the end of my paint routine, I release the event, the situation is improved, but still noticeable. The undesired behavior also is evident if i use the CurrentProjectedExtentChanged() routine to release the autoreset event.
6. Once I’ve zoomed and panned around a bit, the difference between when I hit the zoom button and when the tileset appears in its new rendition is less evident.
7. The most difficult problem is getting the zoomed-tileset to actually appear on the screen before I can start my “after-map” code.
8. If I had an event which doesn’t fire until the new tileset rendition appears, all of the above problems would go away.

Wednesday, March 04, 2009 at 3:50:41 AM by João Saraiva

+1.

This feature (which would be somewhat similar to the Wait() method of the EsriShapefile class, I suppose) would also allow us to easily overcome a minor limitation of the Tileset on the PocketPC: sometimes, due to the asynchronous loading of the map tiles, the map is not repainted with the newly-loaded tiles (the hourglass default tile is displayed indefinitely). I notice this mostly when loading tiles for a new zoom level. Nevertheless, I find this to be only a minor inconvenience, as a pan-up and pan-down (or similar operation) will properly paint the map.
With this operation, we could wait on the loading thread (or, at the very least, regularly poll it), and issue a Map.Repaint() request when the tiles finish loading (as they would already be in memory, this call should execute fairly quick).

Best regards,
João Saraiva

Thursday, March 05, 2009 at 1:41:38 PM by Phil Smith

The Paint event fires every time the map is updated after the new render is complete and is the closest to a "paint complete" that we can provide. The issue is that several individual updates may occur durring a period of time (drag panning with the mouse, for example) and there is no way to know which one is the "last" event programatically. There are many ways a user can "stop" interacting with the map that could be intrpreted as the end of a paint operation, but few have a definitive end event that would signal concretely that the user is done interacting with the map for the time being or that all data has been added etc.

Thursday, March 05, 2009 at 7:37:55 PM by Jon Person

I concur with Phil's assessment. In addition to that, some paint operations such as loading Tile images from disk occur on a separate thread. An after-paint event would have to some how synchronize all threads before the event, which will slow performance dramatically. We need to remember that paint operations can happen 100+ times per second if objects are being loaded; the behavior of a user interface should assume that asynchronous map rendering operations are the rule, not the exception.

Friday, March 06, 2009 at 9:00:32 AM by João Saraiva

Yes, no argument here regarding the asynchronous nature of tileset loading :-) . Actually, I have been doing some experiments and have noticed that most of my problems with the map not being shown sometimes seem to occur only when I use a Cache object (i.e., a hierarchy consisting of Map -> Cache -> Tileset); if I remove the Cache from the hierarchy, the map is always shown (performance is a bit lower, but that is to be expected, I suppose). Nevertheless, tileset behavior is different depending on whether a Cache object is present. I still have to investigate this further, though.

As for the topic at hand, perhaps the ideal here would be some sort of compromise: adding a property to the Tileset that states whether tiles are still being loaded or not. Something like this, I think:

public class Tileset {
private bool _isLoadingTiles = false;
public bool IsLoadingTiles {
get { return _isLoadingTiles; }
private set { _isLoadingTiles = value; } // this is private and simple, so the JIT is very likely to inline it
}

private void TheTilesLoadingProcedure() {

// Do some stuff

// wait on the loading manual-reset event

IsLoadingTiles = true;

// Do the tile loading

IsLoadingTiles = false;

// Do additional necessary stuff
}
}

Perhaps this would help the OP with his problem, since he could use a combination of "polling property value + sleeping the UI thread depending on the result" to approximate the desired behavior. But you are the experts at this, so feel free to shoot my suggestion down if it would raise more trouble than it's worth.

BTW (and with no intention to "hijack" this topic...), I have also noticed issue 156 (https://secure.geoframeworks.com/Secured/ViewIssue156.aspx). Is this still valid? Should we _not_ use the Cache? I ask this because the docs still mention that using a Cache object is recommended.

Best regards,
João Saraiva

Tuesday, March 31, 2009 at 2:02:29 PM by Phil Smith

The Invalidated event firs when the Tileset is done loading a batch of tiles, which in turn redraws the map. This is way off topic fromn a generic paint notification for the map control.Closing.

Issue #229 (Released): Null Reference occurs while MIF file loading if MID file is empty

Tue, 31 Mar 2009 13:57:28 GMT

Tuesday, January 13, 2009 at 3:43:31 PM by

I think, file must be skipped and/or event about invalid file must be generated.
Map files recieved from xyzmaps.com shop and invalid, but exception cannot be handled (occurs on bacground thread)

    Background background = new Background(GeoFramework.Drawing.Styles.Style.Default);

    public MainForm()
    {
        InitializeComponent();
        m_gisMap.Add(StreamMonitor.Current);

        Cache staticObjects = new Cache();
        m_gisMap.Add(staticObjects);

        staticObjects.Add(background);

        string directory = @".\MapSources\MapInfo\edinberg_mif";
        string ext = "mif";

        foreach (string file in Directory.GetFiles(directory, "*." + ext))
        {
            try
            {
                GeographicDataSource source = StyledGeographicFile.Open(file);
                staticObjects.Add(source);
            }
            catch (Exception ex)
            {
                Trace.WriteLine(file);
            }
        }

        m_gisMap.ZoomToFit();
    }

Exception:
System.NullReferenceException was caught
  Message="Object reference not set to an instance of an object."
  Source="GeoFramework.Shapes"
  StackTrace:
       at GeoFramework.Shapes.IO.MapInfoMidReader.Initialize()
       at GeoFramework.Shapes.IO.MapInfoMidReader..ctor(Stream stream, Encoding encoding, String titleColumnName)
       at GeoFramework.Shapes.IO.MapInfoMidReader..ctor(String fileName, Encoding encoding, String titleColumnName)
       at GeoFramework.Shapes.IO.MapInfoFile..ctor(Stream stream, Type pointType, Type lineType, Type polygonType, Encoding encoding, String textColumnName)
       at GeoFramework.Shapes.IO.MapInfoFile..ctor(String filePath, Type pointType, Type lineType, Type polygonType, Encoding encoding, String textColumnName)
       at GeoFramework.Shapes.IO.MapInfoFile..ctor(String filePath, Type pointType, Type lineType, Type polygonType)
       at GeoFramework.Shapes.IO.GeographicDataSource.Open(String filePath, Type pointType, Type lineType, Type polygonType)
       at GeoFramework.Shapes.IO.GeographicDataSource.Open(String filePath)
       at GeoFramework.Shapes.IO.StyledGeographicFile.Open(String filePath)
       at MapTest.MainForm..ctor() in D:\Work\GisNetTest\MapTest\MainForm.cs:line 51

*.MIF file content
Version 300
Charset "WindowsLatin1"
Delimiter ","
CoordSys Earth Projection 8, 79, "m", -2, 49, 0.9996012717, 400000, -100000 Bounds (-7845061.1011, -15524202.1641) (8645061.1011, 4470074.53373)
Columns 3
  Code Decimal(5, 2)
  Name Char(40)
  Id Integer
Data

*.MID file content - file empty

Tuesday, March 31, 2009 at 1:57:28 PM by Phil Smith

Added handling so that empty MapInfo data files are skipped.

Issue #135 (Released): Letting projected Data (like TileSets) define both projections and zoom levels

Tue, 17 Mar 2009 09:45:48 GMT

Monday, August 25, 2008 at 11:39:18 PM by Olle Pettersson

I do not understand all the GIS magic that goes on under the hood when rendering maps, so please bear with me if I don’t make much sense.

The way that I understand TileSets is that it renders fast because all the map data they represent has already been projected into screen coordinates beforehand. Therefore when rendering them again this process intensive step can be skipped.

Now, when we use these TileSets on a CF device, it looks ok - but not perfect. The tiles do not always line up and look a bit distorted at certain zoom levels. I suppose this is because they are rendered at different zoom levels on the CF device compared when they are generated on the desktop. Could there be a way to let the TileSets also define the zoom levels on the device so they are always rendered without stretching? (Just like a TileSet now defines the projection of a map)

That way the Tiles would not have to interpolate to the zoom levels between the points they were generated. This might lead to bigger ‘jumps’ between zoom but I think it would be ok if the tiles can be rendered without distortion. Plus, wouldn’t it be faster too? Because no extra work has to be done to the tiles before drawing to screen?

Can this be supported in GIS.NET 3.0? it would require the TileSet to define a starting zoom and ZoomPercentage and then making sure somehow that these zoom levels are always maintained.

Tuesday, August 26, 2008 at 9:55:06 AM by Jon Person

Exactly, tilesets are designed to eliminate the task of translating, rotating and scaling thousands of vectors on a tiny, slow mobile device CPU.

The Tileset class uses what we refer to as a "tile coordinate system" to reduce a single tile into a (X, Y, Z) coordinate (X, Y and zoom level).  The technique used to calculate the zoom level would produce the same result on any computer, but I believe you might be onto something.  In rare cases a zoom level may be chosen which would cause bitmaps to be scaled UP, which is bad.  It could be that a quick check needs to be implemented which bumps the zoom level if necessary to ensure that tile bitmaps only ever get scaled down.

Right now, the concept of predefined zoom levels is being discussed.  The problem with this is that everybody will have their own interpretation of the "best" zoom levels.  The formula used to calculate zoom levels is based off of the performance of scaling a number of bitmaps, so I feel that's been pretty well optimized.

Assuming the "distortion" you speak of is indeed caused by tiles being scaled UP, then I think we can resolve that quickly.  The task of calculating the rendered pixel size of tiles is trivial, so it would be easy to bump zoom levels automatically.

Tuesday, August 26, 2008 at 5:24:02 PM by Olle Pettersson

So it would be possible then to have the map only zoom to the zoom levels defined by the TileSet coordinate system? Can zoom levels be bumped both up and down to prevent any scaling at all?

I think it that this would work especially well on CF devices like ours. If the tiles only have to get rendered at the same zoom levels they were generated at, no up or down scaling would be required. On top of the tiles we can still have other movable geographical objects as normal, with the added benefit that the tiles will look pixel perfect.

I see what you mean though, that developers will all have different ideas about what zoom levels they need.

But I was thinking that if the TileSet is allowed to define the zoom levels, then no scaling of the bitmaps is necessary... so scaling would not be factor when using zoom levels defined by the TileSet. You just jump to the zoom levels you have.

Friday, August 29, 2008 at 8:27:03 PM by Jon Person

Right yes I believe there would be something like a Map.SetZoomLevel() method which would zoom in to the precise place where no bitmap-scaling would be needed for tiles, improving performance as you suggest. I have to work with Phil to make sure the mathematics are correct but this should be straightworward to work into a build.

Tuesday, March 17, 2009 at 9:45:48 AM by Phil Smith

I believe this issue is resolved in the tileset generation chamges. Zoom levels are configurable and specific to the data used to generate the tileset as well as parameters to control the resolution of the tileset when drawn (i.e. a tileset can be generated with the size of a compact device in mind). This prevents distortion from scaling the individual tiles.

Issue #117 (Released): Add the ability to follow an object, which also rotates the map

Tue, 17 Mar 2009 09:39:17 GMT

Wednesday, August 06, 2008 at 2:26:29 AM by Ted Macy

The Follow method on the map is a very nice feature. Would you consider an enhancement to support following with rotation? This would let us build a UI that emulates the Garmin or TomTom navigation units. Ideally, the map would be drawn such that the position of the following marker is about 1/4 the map height from the bottom, with the map rotated about that point based upon the most recent reasonable heading from the marker being followed. Maybe the relative screen position of the following marker should be a settable parameter?

Wednesday, August 13, 2008 at 6:27:45 PM by Jon Person

This is a good idea. For desktops, rotation would be trivial since CPUs can easily support it. For mobile devices, however, rotation is far more expensive in terms of CPU use. I believe that rotation for Bitmap images on the Compact Framework was completely removed because of this. As a result, the concept of "track-up navigation" is expensive for all mobile devices.

We're waiting for Intel to solve the silicon heat problems so that we can see the CPU speed of mobile devices dramatically improve and catch up with desktops. They're still using silicon in their next-gen chips, but apparently a better insulator.

So, for desktops I think this is reasonable since we can calculate bearing by comparing the current location with the previous one, but it's likely this would not be supported on the CF until CPU speeds are nearly double what they are now (and reach around 1GHz).

Monday, August 25, 2008 at 10:02:30 PM by Olle Pettersson

I was wondering if it could be supported on the Compact Framework as well, if there are no images that needs to be rotated in the Map Control? then the case would be that you have only vector data in the Map.

Perhaps is could be left in and throw a NotSupported exception if you try to follow a marker on top of a map containing images. Just as it does now when trying to rotate a map with images in it.

Tuesday, March 17, 2009 at 9:39:17 AM by Phil Smith

Added "FollowBearingUp()" to the map control. Works similar to "Follow()" except that the map rotates to the bearing derived from the markers current and previous position.

Issue #257 (Behavior Is By Design): How to determine the COM: port of a GPS device

Sun, 15 Mar 2009 18:19:27 GMT

Thursday, March 12, 2009 at 5:23:40 AM by

I wan to find out that in which Comport my Gps device is Connecting.My GPS device is Windows CE and Im using .net Compact framework 3.5
Please help me to find out the Com Port of that device.

Thursday, March 12, 2009 at 5:25:24 AM by

How to detect the Com port Automatically??

Sunday, March 15, 2009 at 6:19:27 PM by Jon Person

GPS.NET is designed to automatically search for and use a serial-based, NMEA-compliant GPS device. The best way to get information about GPS devices on the system is via the GeoFramework.IO.Devices static (shared) class. This class exposes information about detected GPS devices and can also control the detection process itself. The Device class is used to provide information about devices. Other classes build upon this class; namely SerialDevice. Look at the GeoFramework.IO.Devices.GpsDevices collection. You should see one or more SerialDevice objects once detection has completed (assuming your device is powered on and detectable). You can then examine the CommunicationPort property to find the port.

Issue #254 (Behavior Is By Design): "Device is not connected" error when launching examples.

Thu, 05 Mar 2009 19:30:01 GMT

Tuesday, March 03, 2009 at 11:03:22 AM by

I have downloded trial versions of GPS.Net 2.0 and GIS.NET 3.0. I have registered the trial version as well. It was a tedious procedure thro' your web-site. I don't know whether the trial version is activated or not.

Now if I launch any VB.NET examples, the Pocket PC 2003 device gets launched and later on I get error message as Device is not connected.

I am unable to check Geoframeworks tools. Pls assist.

Thursday, March 05, 2009 at 7:30:01 PM by Jon Person

The trial license key system works by associating license keys with your IP address. When you go to http://www.geoframeworks.com/FreeTrial.aspx it will tell you how much time you have left on your trial(s), and whether you can activate or extend any more trial license keys.

The specific error you mention sounds like a problem related to ActiveSync or mobile device support in Visual Studio. Do you have a real, newer mobile device such as Windows Mobile 5 to test with?

Issue #253 (Behavior Is By Design): GIS.NET Tileset Assistant (C#) throws an exception

Thu, 05 Mar 2009 19:39:42 GMT

Saturday, February 28, 2009 at 11:02:11 AM by

Tileset Assistant is unmodified, except for the project being converted to VS2008.

When trying to import some of the sample shapefiles, I get "Cross-thread operation not valid: Control 'chooseGeographicAreaMap' accessed from a thread other than the thread it was created on." in WizardForm::PermanentItems_Loaded() on the "chooseGeographicAreaMap.ZoomToFit()" instruction.

Thursday, March 05, 2009 at 7:39:42 PM by Jon Person

This sounds like an older issue which was resolved in a more recent build. Specifically, we noticed that the navigation methods such as ZoomToFit() were reading properties which required thread-marshaling. For example *reading* the Size property of a Form cannot be multithreaded. We've cached common Form variables to escape from the (lame) single-threaded model and resolve this error.

Let's try updating to the latest build.

Issue #255 (Released): Tileset Configuration file parsing of map extent is not culture-independent

Thu, 05 Mar 2009 14:02:17 GMT

Wednesday, March 04, 2009 at 3:35:15 AM by João Saraiva

This is similar to issue 247 (https://secure.geoframeworks.com/Secured/ViewIssue247.aspx). When parsing of the Tileset configuration file (at least on the PocketPC), the deserialization of the tileset's extent is still using the current locale. For example, the following excerpt (greater than and lesser than characters removed because of ASP.NET) of the "_Tileset Configuration.xml" (using the WGS84/UTM29N zone) will yield a _very_ big extent, when that extent should actually be of only a few square klicks:

geoframework:dataExtent 564.1093,-4649.679,569.9694,-4646.772 /geoframework:dataExtent
geoframework:coverageExtent 561.062,-4650.6,571.7285,-4644.2 /geoframework:coverageExtent

(this tileset config file was generated in a desktop pc with Portuguese localization, so this file's generation is culture-independent, as it should be :-) ).

If one tries to load this is an English-localized system, this works fine, as the dot is the expected separator between the integer and fractional parts of the rectangle's corners. However, if we change the device's localization to Portuguese (or, I suppose, any other language in which that separator is a comma), the parsed rectangle will be huge. The most immediate consequence of this is that the map/tileset will not be displayed (likely because it is too tiny, in the context of the parsed extent).
This is not a show-stopper bug, but it can impact the framework's usefulness in non-English-localized systems.

Best regards,
João Saraiva

Thursday, March 05, 2009 at 2:02:17 PM by Phil Smith

Added culture invariance to numeric parsing in the tileset configuration.

Issue #250 (Behavior Is By Design): Can't directly create GeoTiff from Image and coordinates

Mon, 23 Feb 2009 13:17:41 GMT

Saturday, February 21, 2009 at 10:29:37 PM by Ryan Dotson

Similar to Issue #81, I have an Image and a set of coordinates that I would like to use to create a GeoTiff to add to a map.

The CreateTo() methods all must output the image to a stream or to a file. Writing the tiff to a MemoryStream and reading it back in works, but is not efficient.

I would just like to use the loaded image a la:

GeoTiff tiff = new GeoTiff(Image, GeoTiffKeySummary);

The documentation references a GeoTiff.Create() method which I think would work but it does not appear to exist anymore...

Monday, February 23, 2009 at 1:17:41 PM by Phil Smith

GDI+ doesn't support adding new property items directly. There is a work around for this, but it makes the Image object unwritable using GDI+ Image.Save() methods. I believe this is because the defaultTIFF encoder does not recognize or account for the the GeoTiff tags. In any case, I'm not sure why you'd want to use a geotiff and not persist it in the first place. All the effort put into tagging the Image object would be lost. If you really need to georeference an image and not persist it, the Picture object is alot simpler to use.

Issue #243 (Cannot Reproduce): NullReferenceException during Search(PointF)

Thu, 19 Feb 2009 16:23:26 GMT

Monday, February 16, 2009 at 3:57:47 PM by Jon Person

When testing the "Zooming Form" example for Desktop Framework 3.5, an exception is raised.  The call stack is as follows:

   at GeoFramework.Gis.Map.Search(PointF projectedLocation)
   at GeoFramework.Gis.Map.OnMouseClickSearch(Object chezburger)
   at System.Threading._ThreadPoolWaitCallback.WaitCallback_Context(Object state)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
   at System.Threading._ThreadPoolWaitCallback.PerformWaitCallbackInternal(_ThreadPoolWaitCallback tpWaitCallBack)
   at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback(Object state)

Thursday, February 19, 2009 at 4:23:26 PM by Jon Person

This is a tough one to reproduce. I've made a note to investigate more thoroughly when I can get it to occur again.

Issue #218 (Cannot Reproduce): Resources LoadException on Windows Mobile 6.0

Thu, 19 Feb 2009 14:05:03 GMT

Wednesday, December 17, 2008 at 1:20:20 AM by

I'm experiencing some odd issues while testing, so after enabling debugging on the device (Windows Mobile 6.0 - CF.Net 3.5), I logged the following LoadExceptions:

Loading module [\Programmer\PLT2008\da-DK\GeoFramework.PocketPC.resources.exe]
Attempt to load [\Programmer\PLT2008\da-DK\GeoFramework.PocketPC.resources.exe] has failed (err 0x80001001).
Failed to load [GeoFramework.PocketPC.resources, Version=1.4.3600.7, Culture=da-DK, PublicKeyToken=3ED3CDF4FDDA3400]

Loading module [\Programmer\PLT2008\da\GeoFramework.PocketPC.resources.dll]
Attempt to load [\Programmer\PLT2008\da\GeoFramework.PocketPC.resources.dll] has failed (err 0x80001001).
Failed to load [GeoFramework.PocketPC.resources, Version=1.4.3600.7, Culture=da, PublicKeyToken=3ED3CDF4FDDA3400]

Note.... GeoFramework.PocketPC.dll - version 1.4.50727.7

Please advice?

Monday, February 16, 2009 at 9:20:17 PM by Jon Person

It's unusual that there'd be any search for resources using the local culture. It's possible this could be a natural part of searching for resources. Is this an exception which halts execution? Or just a first-chance exception?

Thursday, February 19, 2009 at 2:05:03 PM by Jon Person

The version number you have suggests an older assembly. We should update you to the latest build.

Issue #244 (Behavior Is By Design): Unable to load Countries.shp in Visual Studio 2005

Thu, 19 Feb 2009 16:21:07 GMT

Thursday, February 19, 2009 at 4:20:37 PM by Jon Person

"An exception occurs when I run the .NET 2.0 example in VS 2005. It blows when it tries to load Countries.shp."

Thursday, February 19, 2009 at 4:21:07 PM by Jon Person

I was unable to reproduce this issue on any platform. Countries.shp loads properly. It's possible that the target machine does not have enough RAM to load the over 3 million points used in the example.

Issue #246 (Behavior Is By Design): On My PDA, when i zoom, i disable some buttons, then the buttons are re-enabled. seconds later, my tiles appear

Thu, 19 Feb 2009 16:20:00 GMT

Tuesday, February 17, 2009 at 1:55:02 PM by Phil Marks

i'm trying to disable some buttons on my form until the full map shows up. But the code goes right past the zoom and re-enables the buttons a second or so before the tiles appear. This is confusing for the user, who should not be hitting buttons or zooming again until the tiles are shown.

Thursday, February 19, 2009 at 4:17:31 PM by Jon Person

More via Phil: "On My PDA, when i zoom, i disable some buttons, then the buttons are re-enabled. seconds later, my tiles appear"

Thursday, February 19, 2009 at 4:20:00 PM by Jon Person

The Map control can be a multithreaded control. This design allows intense map operations to be performed without blocking the host application. As a result, however, work must be performed to synchronize the map with functions in your application.

Lets try hooking into the "CurrentProjectedExtentChanged" event. This event is called whenever the visible area of the Map has changed, and it's called after a paint operation. Use this event to re-enable your buttons and that should give you the behavior you're looking for.

Issue #247 (Released): WorldFile parsing does not ignore current culture

Thu, 19 Feb 2009 07:17:34 GMT

Thursday, February 19, 2009 at 7:17:34 AM by João Saraiva

When parsing a WorldFile, the Decimal.Parse method should be invoked using the InvariantCulture. Otherwise, something that would be a valid UTM coordinate will be considered invalid if the current PC's culture does not use . as a separator between the integer and fraction parts.

E.g.:

The world file:

2.1403229999999871
0
0
-2.1403229999999258
564109.20263558044
4649678.3586806776

will yield an "empty" rectangle if the current PC is set to Portuguese localization.

Best regards,
João Saraiva

Issue #248 (Released): MissingMethodException on Compact Framework 2.0 when initializing Tileset

Thu, 19 Feb 2009 13:59:31 GMT

Thursday, February 19, 2009 at 1:58:48 PM by Jon Person

A MissingMethodException occurs when attempting to open a tileset using Compact Framework 2.0. This appears to happen during the static constructor for Tileset, and is not related to licensing.

Thursday, February 19, 2009 at 1:59:31 PM by Jon Person

The default namespace for the GIS.NET Framework CF20 project was incorrect. It was "GeoFramework" but should have been "GeoFramework.Shapes". This discrepancy caused a failure to load resources used by the Tileset class. This has been resolved, and a new build has begun.

Issue #214 (Released): GPS Intermediate Driver Registry Analysis Project

Tue, 17 Feb 2009 17:35:11 GMT

Monday, December 08, 2008 at 5:53:55 PM by Jon Person

In order to improve the GPS Intermediate Driver support for GPS.NET 3.0, I'd like to solicit the help of you, and the whole development community here.  Specifically, there are a number of devices with proprietary registry structures, such as the AT&T Tilt, the HTC TyTn II, and the Samsung Omina.  I would like to get a registry dump from users to help me with understanding and accommodate the varying structures.

I'd love your feedback on this.  Here's how to help:

1) Download the "Mobile Registry Editor" utility from here: http://mobile-registry-editor.en.softonic.com/pocketpc.  This utility will let you access the registry of your cradled device.
2) Navigate to HKLM\System\CurrentControlSet\GPS Intermediate Driver
3) Export the entire branch to a text file.  Don't worry, there's nothing personally identifying.
4) Post the contents as a response to this issue for all of us to take a look at.

Friday, December 12, 2008 at 3:08:38 PM by Jon Person

HTC Kaiser / AT&T Tilt

REGEDIT4

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\GPS Intermediate Driver]
"OldLogFile"="\windows\GPSLogFileBack.txt"
"CurrentLogFile"="\windows\GPSLogFile.txt"
"IsEnabled"=dword:00000001

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\GPS Intermediate Driver\Multiplexer]
"DriverInterface"="COM4:"

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\GPS Intermediate Driver\Multiplexer\ActiveDevice]
"Index"=dword:00000004
"Prefix"="COM"
"Context"=dword:12344160
"Flags"=dword:00000002
"Keep"=dword:00000001
"Dll"="GPSID_QCT.dll"

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\GPS Intermediate Driver\Drivers]
"SleepOnNoData"=dword:000003e8
"RetryWaitOnError"=dword:00000003
"OutputBufferSize"=dword:00001000
"InputBufferSize"=dword:00001000
"CurrentDriver"="GPSOneDevice"

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\GPS Intermediate Driver\Drivers\GPSOneDevice]
"Version"=dword:00000001
"PollInterval"=dword:000001f4
"DriverName"="TAI"
"FriendlyName"="QualComm GpsOne Card, version 0.0"
"InterfaceType"="POLL"

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\GPS Intermediate Driver\Drivers\GPSOneEmulate]
"Filex"="\windows\GPSOneFileSimulation.txt"
"FriendlyName"="QualComm GpsOne File, version 0.0"
"InterfaceType"="File"

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\GPS Intermediate Driver\Drivers\GPSOnePort]
"CommPort"="COM1:"
"FriendlyName"="QualComm GpsOne Card, version 0.0"
"InterfaceType"="COMM"

Friday, December 12, 2008 at 3:08:54 PM by Jon Person

Intermec CN3

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\GPS Intermediate Driver]

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\GPS Intermediate Driver\Multiplexer]

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\GPS Intermediate Driver\Multiplexer\ActiveDevice]
"Context"=dword:12344160
"Flags"=dword:00000002
"Keep"=dword:00000001
"Dll"="GPSID.dll"

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\GPS Intermediate Driver\Drivers]
"CurrentDriver"="Control Panel Configured Device"

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\GPS Intermediate Driver\Drivers\IntermecSiRF3]
"Baud"=dword:0000e100
"InterfaceType"="COMM"
"CommPort"="COM3:"
"FriendlyName"="Internal SiRF3"
"PlugIn"="SiRF3gps.dll"

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\GPS Intermediate Driver\Drivers\Control Panel Configured Device]
"Baud"=dword:0000e100
"InterfaceType"="COMM"
"CommPort"="COM3:"

Tuesday, February 17, 2009 at 5:17:59 PM by Jon Person

I am pleased to report that the Samsung Omina and HTC devices are now working flawlessly with GPS 3.0 code. I will be targeting April 2009 for release.

Tuesday, February 17, 2009 at 5:35:11 PM by Jon Person

(This affects all devices using Qualcomm or Samsung GPS chipsets.)

Issue #238 (Released): I can't load the Tileset example for the Compact Framework (some XML elements appear to be missing)

Mon, 16 Feb 2009 21:10:03 GMT

Friday, February 13, 2009 at 4:13:40 AM by João Saraiva

Hi!

I've recently begun evaluating GIS.NET 3.0 for use in a PDA application (.NET Compact Framework) that we are developing. Your approach to Tilesets really seems to hit the jackpot regarding the OOM exceptions that plague the .NET CF :-) .

However, I am unable to successfully run your example for the CF. Although the program itself is fine, the Tileset constructor bombs because it cannot find some XML elements in the _Tileset Configuration.xml file. More precisely, the exception thrown is:

Example.exe
ArgumentOutOfRangeException
Tileset extents cannot be empty.
Parameter name: CoverageExtent, DataExtent

at GeoFramework.Shapes.TilesetConfiguration.Validate()
at GeoFramework.Shapes.TilesetConfiguration.Open()
at GeoFramework.Shapes.TilesetConfiguration.Initialize()
at GeoFramework.Shapes.Tileset..ctor()
at SmartDeviceProject3.Form1..ctor()
at SmartDeviceProject3.Program.Main()

The contents of the XML file are (tags are removed to avoid ASP.NET exception):

<geoframework:tileset xmlns:geoframework="http://www.geoframeworks.com/gml">
  
  <geoframework:projection geoframework:type="GeoFramework.Projections.Orthographic">
    <geoframework:transverseLatitude>0</geoframework:transverseLatitude>
    <geoframework:firstStandardParallel>0</geoframework:firstStandardParallel>
    <geoframework:secondStandardParallel>0</geoframework:secondStandardParallel>
    <geoframework:centerLatitude>39.204887527777778</geoframework:centerLatitude>
    <geoframework:centerLongitude>-104.207874</geoframework:centerLongitude>
    <geoframework:falseEasting>
      <Units>Centimeters</Units>
      <Value>0</Value>
    </geoframework:falseEasting>
    <geoframework:falseNorthing>
      <Units>Centimeters</Units>
      <Value>0</Value>
    </geoframework:falseNorthing>
    <geoframework:scale>1</geoframework:scale>
    <geoframework:azimuth>0</geoframework:azimuth>
    <geoframework:ellipsoidEpsgNumber>7052</geoframework:ellipsoidEpsgNumber>
    <geoframework:allowOverrange>False</geoframework:allowOverrange>
  </geoframework:projection>
  <geoframework:isFrozen>False</geoframework:isFrozen>
  <geoframework:earliestTile>2008-07-08T13:36:30</geoframework:earliestTile>
  <geoframework:files>
    ... (not relevant, I think)
  </geoframework:files>
</geoframework:tileset>

It seems the XML file is missing some info (namely "coverageExtent" and "dataExtent"). Am I correct? If so, could you please post a new XML file, so that I can check whether your Tileset solution will work well in our deployment environment?

Best regards,
João Saraiva

P.S.: Just a suggestion :-) : you should use javascript to encode the issue's text. Otherwise, users may see the typical ASP.NET yellow screen indicating that a dangerous value was submitted (in this case, the XML file contents).

Monday, February 16, 2009 at 9:10:03 PM by Jon Person

This issue is now resolved. Tilesets were rebuilt using the new Tileset Generator and tested on CF20 and CF35 for both C# and VB.NET. A new download will be necessary: http://www.geoframeworks.com/DownloadProducts.aspx

Issue #235 (Released): Map collection methods should affect perment items, movable items, and decorations

Tue, 10 Feb 2009 15:21:42 GMT

Tuesday, February 10, 2009 at 2:20:17 PM by Jon Person

Collection methods inside of the Map control appear to affect only permanent items. Methods such as Add, Remove, and Clear should affect all three kinds of object collections: permanent items, movable items and decorations.

Tuesday, February 10, 2009 at 3:21:42 PM by Phil Smith

Clear and Remove methods now affect the Decorations collection.

Issue #237 (Released): Area, Length and Perimeter calculation methods aren't working correctly

Tue, 10 Feb 2009 15:21:02 GMT

Tuesday, February 10, 2009 at 3:21:02 PM by Phil Smith

Length, ArcLength (Line object), Area, ArcArea, Perimiter and ArcPerimeter (Polygon object) properties had some issues with their calculations that lead to some inordinate results. The net goal of these properties is for approxomations only. the "Arc" versions of these properties use meridinal distances and are considered more accurate, but slighty slower in performance.

Issue #234 (Released): Exception when adding an object to a selection.

Fri, 06 Feb 2009 14:15:51 GMT

Friday, February 06, 2009 at 10:55:50 AM by Ryan Dotson

I have a background thread updating the Location property of a class derived from Vehicle.
This works fine with the rendering, but if you drag a selection over the object, an "Parameter is not valid" exception is thrown from GDI+.

I have narrowed the problem down to a threadig issue by adding an OnTimer event to the control containing the Map and updating the Marker.location there. (This fixes the problem, but is not a preferred solution).  It seems like if the rendering is thread-safe, then the selection functionality should be too.  Is there a synchronization object that should be used for updating a geographic object's location?

A stack trace is below:
   at System.Drawing.Drawing2D.GraphicsPath.AddPath(GraphicsPath addingPath, Boolean connect)
   at GeoFramework.Shapes.Decorations.Selection.Select(IList`1 items)
   at GeoFramework.Gis.Map.OnMouseUpSelect(Object mouseEventArgs)
   at GeoFramework.Gis.Map.OnMouseUp(MouseEventArgs e)
   at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
   at System.Windows.Forms.Control.WndProc(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
   at System.Windows.Forms.NativeWindow.DebuggableCallback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
   at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG& msg)
   at System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(Int32 dwComponentID, Int32 reason, Int32 pvLoopData)
   at System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32 reason, ApplicationContext context)
   at System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32 reason, ApplicationContext context)
   at System.Windows.Forms.Application.Run(Form mainForm)

Friday, February 06, 2009 at 2:15:51 PM by Jon Person

Hi Ryan, thanks for the detailed bug report. We use a synchronization object internally to ensure that a GraphicsPath is only accessed by one thread at a time. However, this object was marked as "protected" since we didn't want novice developers to get themselves into hanging issues. I've fixed this problem my changing the syncroot from "protected" to "internal" and it is now locked by the Selection object whenever a geographic object is being added to the selection. This will have slight performance implications when selecting hundreds of shapes.

Issue #233 (Released): null exception when adding Cache

Fri, 06 Feb 2009 09:28:09 GMT

Thursday, February 05, 2009 at 9:20:06 PM by

I'm evaluating GIS.Net with a trail version.
Downloaded installer and installed it.
Created new VS 2008 Windows Application.
Generated Key. Copied sources code for both Program.Main() and AssemblyInfo.cs
Drag and Dropped a Map object from toolbox into new Form.
Added following code.

Null exception when adding Cache.

Example code:

public Form1()
        {
            InitializeComponent(); // Designer code with map1 = Map object

            Cache cache = new Cache();

            map1.Add(cache); // Causes exception here
            map1.Add(new Compass());
        }

Thursday, February 05, 2009 at 10:30:38 PM by

Exception details

System.NullReferenceException was unhandled
  Message="Object reference not set to an instance of an object."
  Source="GeoFramework.Gis"
  StackTrace:
       at GeoFramework.Gis.Map.ReTransformContexts()
       at GeoFramework.Gis.Map.OnAfterAddItem(GeographicObject item)
       at GeoFramework.Gis.Map.Add(GeographicObject item)
       at GeoFramework.Form1..ctor() in C:\Users\USER\Documents\Visual Studio 2008\Projects\GeoFramework\GeoFramework\Form1.cs:line 19
       at GeoFramework.Program.Main() in C:\Users\USER\Documents\Visual Studio 2008\Projects\GeoFramework\GeoFramework\Program.cs:line 36
       at System.AppDomain._nExecuteAssembly(Assembly assembly, String[] args)
       at System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence assemblySecurity, String[] args)
       at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
       at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
       at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
       at System.Threading.ThreadHelper.ThreadStart()
  InnerException:

Thursday, February 05, 2009 at 11:03:29 PM by

Friday, February 06, 2009 at 9:28:09 AM by Phil Smith

The VS design behavior seems to affect the order of events. For instance, dropping a control on a form then running the application will not generate a resize event, while adjusting the size of the control in the form designer, then running the application will. A fix in is place that considers this inconsistancy and will be available in the next build. In the mean time, simply resizing the Map control in the form designer should serve as a workaround.

Issue #232 (Released): Pan and Zoom methods sometimes cause NotSupportedException on the CF

Mon, 02 Feb 2009 19:05:31 GMT

Monday, February 02, 2009 at 7:05:31 PM by Jon Person

The ZoomTo() method of the Map control in GIS.NET 3.0 will occasionally throw a NotSupportedException. This can occur if the ZoomTo method is called from a thread other than the Form's own thread. The problem appears to be a call to read the "Size" property of the Map. The Size property should be cached. (Invoking a call just to read a Size property is overhead which quickly adds up on the painfully slow CF.)

Issue #164 (Released): Request for an Improved Tileset Generator

Thu, 22 Jan 2009 12:36:06 GMT

Tuesday, September 30, 2008 at 10:43:21 AM by

I have been playing around with generating Tilesets on the desktop framework and then using them on the compact framework. That all works very nicely. I was wondering is there a quick way to generate the full Tileset for the entire map? I noticed that when I zoom in, the desktop framework only generates the tiles for the area I am looking at. When I pan, then it creates some more. I would like to be able to generate all the tiles at one go. Is that what the TilesetGenerator class is supposed to do (mentioned in issue#88 - How do we make tilesets)? And if yes, which namespace is it in? Thanks.

Thursday, October 09, 2008 at 9:54:18 PM by Jon Person

The TilesetGenerator was originally intended to generate full tilesets, yes.  But, since we improved the Tileset class to generate, load, and save tiles asynchronously, the function of generating tiles merged into the Tileset class.   Now, the "Generate" method can be used to request that a tile be generated.

A development challenge remains, which is still under development.  The initial tileset generator loaded ALL data, which worked fine until people started loading massive amounts of data.  As a result, we want to design the generator to be able to load and render tiles one layer at a time.  This takes a lot more time to develop since we must be able to intelligently work with available memory while not taking over the host application.

So, for now, the new methods in Tileset are the means of generating a tileset in an automated fashion.  We'll be improving this to be more intuitive, and our goal is to let developers start a generation task which can run overnight.

Monday, November 17, 2008 at 5:43:11 PM by Jon Person

I still have automatic generation in my to-do list. The real showstopper right now is detecting how much memory the class is allowed to play with and working within those means to avoid OutOfMemoryException errors. I may have to produce an interim solution that assumes all data files will load into memory at once just to get people moving forward. This would work well on 64-bit machines, at least.

Thursday, January 22, 2009 at 12:36:06 PM by Phil Smith

A fully funtional tileset generator is now part of GIS.NET 3.0. An application wizard will be included to assist developers with rapid creation of tilesets. The application will be deployed in the next release of GIS.NET 3.0 as source code that can be compiled and redistributed as per our existing licensing arrangements as well as the GNU General Public License.

Issue #212 (Released): Ability to call ZoomToFit() after loading aTileset

Thu, 22 Jan 2009 12:25:36 GMT

Monday, December 08, 2008 at 12:56:11 PM by Jon Person

Right now, when a Tileset is created, it's extent is as large as the entire Earth. Internally, this has its advantages, but for developers, it forces them to have to determine the extent of the view they want to see, then make a call to "ZoomTo" to initialize the map. It would be preferable if developers could make a call to "ZoomToFit()" after opening a Tileset to easily initialize a map.

Thursday, December 18, 2008 at 1:18:35 PM by Jon Person

Phil has this implemented nicely as part of the new Tileset Generator being rolled out this week. I'm unassigning myself since Phil's got this done.

Thursday, January 22, 2009 at 12:25:36 PM by Phil Smith

Fixed with the tileset generator changes

Issue #231 (Released): IList implementation in the Map control is incomplete

Thu, 22 Jan 2009 12:25:10 GMT

Thursday, January 22, 2009 at 11:11:51 AM by Phil Smith

Som methonds/properties were ommited from the IList implementation in the Map control.

Thursday, January 22, 2009 at 12:25:10 PM by Phil Smith

Add(), Remove, and InsertAt members of the IList interface are now fully finctional.

Issue #224 (Released): Address deserialization issues of remaining projections.

Thu, 08 Jan 2009 09:26:59 GMT

Monday, December 29, 2008 at 9:33:28 PM by Phil Smith

The following projections require special attention to properly deserialize.

AzimuthalEquidistant
Krovak
ObliqueMercator
ObliqueTransformation
SpaceObliqueMercator
TunisiaMiningGrid

Thursday, January 08, 2009 at 9:26:59 AM by Phil Smith

Completed

Issue #227 (Released): Copy constructor for Polygon should accept Polygon, not Line

Mon, 05 Jan 2009 09:58:46 GMT

Monday, January 05, 2009 at 6:31:47 AM by Peter van Rees

The 'copying' constructor of the polygon shape takes a line shape as parameter. This seems a mistake to me, I would expect it to take another polygon.

Monday, January 05, 2009 at 9:58:46 AM by Jon Person

I see the Polygon(Line) constructor and agree it should be Polygon instead. Fixed.

Issue #225 (Behavior Is By Design): How to Calculate Area in GPS.NET 2.0

Tue, 30 Dec 2008 11:15:02 GMT

Monday, December 29, 2008 at 10:18:18 PM by

hai,
I have a requirement of calculating area of a irreugular polygon based on the latitude and longitude.I capture a set of points of an irregular polygon using my GPS enabled PDA. i need to calculate the area of that polygon. Is there any functions in GPS .net 2.0 which suports this. or how can i do this.

Tuesday, December 30, 2008 at 11:15:02 AM by Jon Person

The PositionCollection class in GPS.NET 2.0 does have an Area and Perimeter property. Add the positions into a PositionCollection. Make sure the first and last objects in the collection are the *same* for a closed polygon. Then read the Area property.

Issue #223 (Released): Projection XML deserialization is incomplete

Mon, 29 Dec 2008 21:31:12 GMT

Monday, December 29, 2008 at 9:29:50 PM by Phil Smith

The Initialize() method of all projections need to be overidden to properly deserialize from XML.

Monday, December 29, 2008 at 9:31:12 PM by Phil Smith

Prjection deserialization as been fixed for all but 6 projections. These will be addressed in a separate issue.

AzimuthalEquidistant
Krovak
ObliqueMercator
ObliqueTransformation
SpaceObliqueMercator
TunisiaMiningGrid

Issue #222 (Behavior Is By Design): Using the "Pens" .NET object doesn't seem to work with Style objects

Mon, 29 Dec 2008 21:23:24 GMT

Monday, December 29, 2008 at 6:57:32 AM by Peter van Rees

It took me about a day to figure out that a polygon with

style = UnscaledOutlinedFilledStyle(Pens.DarkGray, Brushes.Red)

does not get drawn, while one with

New UnscaledOutlinedFilledStyle(New Pen(Color.DarkGray, 1), Brushes.Red)

does. I find this pretty unintuitive. Are these two pens different? It would be nice if the first example would just work. If this is somehow not possible maybe an exception can be thrown or something?

Monday, December 29, 2008 at 9:38:53 AM by Jon Person

Wow, this is interesting. Since the Pens static class is part of the .NET Framework itself, I can only guess as to why its behavior would cause a failure. I am under the belief that any call to "Pens.DarkGray" would return a *new* Pen object, instead of the same object, and that the width of a pen returned from "Pens" would have a width of 1.0.

I think we'll need to run this code here at the office to reproduce the issue and compare the two Pen objects side-by-side.

Monday, December 29, 2008 at 1:41:58 PM by Peter van Rees

As far as I know pens.darkgray does not return a new object, but one from a static internal collection. (I was just reading about it) Would that be causing the problems?

Monday, December 29, 2008 at 2:26:19 PM by Peter van Rees

let me know if you need more info. I only tested it in my (large) solutin I am currently working on, so I am not entirely sure it can be reproduced in a small scale test. (sorry, no edit available, so I made a new post)

Monday, December 29, 2008 at 9:23:24 PM by Phil Smith

It does not return a new object. The .Net static Pens and Brushes can't be modified and they
also can't be disposed of. The GIS drawing engine needs to be able to change pen widths and
transform pens to properly scale styles.

The following works but you'll need to dispose of the pen yourself when you are done with it.

Pen MyPen = Pens.DarkGray.Clone() as Pen;
Pen MyBrish = Brushes.Red.Clone() as Brush;
style = UnscaledOutlinedFilledStyle(MyPen, MyBrush);

In short, I'd avoid using static objects that are managed by .Net. They may be convenient,
but allow little flexibility.

Issue #221 (Released): Map control changes cusor even when it does not have focus

Mon, 29 Dec 2008 12:02:26 GMT

Friday, December 19, 2008 at 8:43:24 AM by Ryan Dotson

When there is an active selection on a map (with the glowing behavior), if a popup window is displayed anywhere over the Map object, the cursor rapidly switches between an arrow and a crosshairs when moving over the client area of the popup window. This happens whether the Form is modal or modeless.

Note: The cursor still works in the Popup form, it is just a display issue.

Monday, December 29, 2008 at 10:02:16 AM by Jon Person

Hmm, it sounds like the cursor is being changed too agressively by the Map control. The cursor should only be changing when the Map control has focus. I wonder if somehow the control is receiving a mouse event? I'll create an app to display a Form over a Map control to try and repro the issue. Perhaps if we can remove code which sets the cursor when the Selection is redrawn, it can resolve this issue.

Monday, December 29, 2008 at 11:24:01 AM by Jon Person

Sure enough, in the decoration painting thread, there is a command to change the cursor. A new policy has been adopted to forbid the changing of cursors unless the code being executed is part of a mouse action. I'll have a build posted today once I have the new cursor behavior fully tested.

Monday, December 29, 2008 at 12:02:26 PM by Jon Person

I have a build in progress now which should solve the problem. The only non-mouse-event activity where the cursor was changed was when a Decoration was being redrawn (the Selection is a decoration as well). I've added code which will set the cursor ONLY if the "Focused" property is "True". The release should be up shortly. Can I get your feedback?

Issue #219 (Behavior Is By Design): MissingMethodException after upgrading GPS.NET

Thu, 18 Dec 2008 11:37:23 GMT

Wednesday, December 17, 2008 at 5:34:24 AM by Oliver Fink

I recently needed to upgrade and re-install my system (XP,VS.NET 2008,C#2.0 for PocketPC Windows Mobile 6 Professional), but GPS.NET 2.3.20 for NETCF 2.0 doesn't work anymore. When I deploy to a device and debug, I get the following exception:

"System.MissingMethodException was unhandled
Message: File or assembly name 'GeoFramework.Gps.PocketPC, Version=2.3.20.0, Culture=neutral, PublicKeyToken=3ED3CDF4FDDA3400', or one of its dependencies, was not found."

both GeoFramework.Gps.PocketPC.dll and GeoFramework.PocketPC.dll are deployed correctly to the device target directory.

Any ideas?

Wednesday, December 17, 2008 at 6:25:23 AM by Oliver Fink

oops, sorry - seems that deployment didn't update the components after all...

Thursday, December 18, 2008 at 11:37:23 AM by Jon Person

Hi Oliver, you are correct that even though you installed the latest version, the assemblies on the mobile device did not get overwritten. I believe this is because we recently found a better way to make our assemblies co-exist with several versions of Visual Studio installed at once. Older assemblies had a version of "2.0.3600.0" for example, whereas new assemblies have a version of "2.0.0.0." It's possible that Visual Studio saw these new assemblies as *older* since the version is smaller.

It sounds like you may have already resolved the issue by manually deleting the assemblies on your target device. This would force Visual Studio to redeploy assemblies from your desktop, which would resolve the issue.

Issue #216 (Behavior Is By Design): TypeLoadException on a Mobile Device after upgrading

Fri, 12 Dec 2008 12:35:21 GMT

Friday, December 12, 2008 at 5:09:11 AM by David Hanley

After installing the 8th December 2008 release of GPS.Net, I get the following error when trying to interactively debug a Windows Mobile 6.0 application:

File or assembly name 'GeoFramework.PocketPC, Version=1.4.7.0, Culture=neutral,
PublicKeyToken=3ED3CDF4FDDA3400', or one of its dependencies, was not found.

The error occurs after a delay of ~4-5 minutes just after the following line is added to the VS2008 Output window:

'GeoFrameTest.exe' (Managed): Loaded 'C:\Program Files\Microsoft.NET\SDK\CompactFramework\v3.5\Debugger\BCL\System.dll'

This application worked correctly before the 8th December 2008 release was applied. Any suggestions are most welcome as I'm banging my head of a wall with this one.

Thanks
David Hanley.

Friday, December 12, 2008 at 5:39:18 AM by David Hanley

Update - I seem to have resolved this issue as follows:

- Windows Mobile 6.0 Emulator - Hard Reset and redeploy of solution
- Physical device (Motorola MC75) - Clean and blank and redeploy of solution

Perhaps not an issue with GPS.Net assemblies?

Thanks
David.

Friday, December 12, 2008 at 12:35:21 PM by Jon Person

Hi David, I believe I know what originally caused this problem.

When GPS.NET was first released, we had no strategy to make assemblies for multiple versions of Visual Studio co-exist.  In other words, we wanted develoeprs to be able to have our assemblies show up in the "Add References" dialog, yet we had no clear idea on how to do this gracefully.  As a result, we used the Global Assembly Cache.  This introduced a problem, however, in which only one assembly with version "2.0.0" could exist.  As a result, we had to introduce a number which caused versions to be unique for different .NET platforms.  This is where the numbers "3600" and "50727" came from in versions such as "1.4.3600.7".

About a month ago, we finally solved this problem with the use of the registry.  The registry allowed us to specify assembly folders, places for Visual Studio to look.  This solved the problem wonderfully, and we no longer needed to have different version numbers for different platforms of an assembly.

Now, finally getting to your specific problem.  When you upgraded to the latest release, the version numbers of our assemblies changed.  They no longer had these other numbers in them.  After you upgraded, you may have had to re-add references or controls as a result.  Then, when you went to deploy your application, Visual Studio did NOT replace the assemblies on your mobile device.  As a result, a TypeLoadException would occur.

Your hard reset of the device effectively cleared out the deployment folder, allowing fresh assemblies to be deployed.  You can also solve this problem by deleting assemblies from the target folder on the mobile device.

At any rate, thanks for taking the time to report your solution to this issue.

Issue #146 (Released): ArgumentNullException when passing Null to EsriShapefile constructor

Mon, 08 Dec 2008 14:01:51 GMT

Thursday, September 04, 2008 at 11:39:42 AM by Jon Person

Developers can load geographic data sources into specific kinds of geographic objects. Custom point, line, and polygon types can be passed to an EsriShapefile constructor, like this:

EsriShapefile cities = new EsriShapefile(@”MyFile.shp”, typeof(MyLakeType), null, null);
EsriShapefile roads = new EsriShapefile(@”MyFile.shp”, null, typeof(MyRoadType), null);
EsriShapefile lakes = new EsriShapefile(@”MyFile.shp”, null, null, typeof(MyLakeType));

... however, an ArgumentNullException is being raised when a null value is specified. The correct behavior should be that null parameters are ignored, especially when the geographic data source has no such objects to create.

Monday, December 08, 2008 at 2:01:51 PM by Jon Person

The constructor will silently convert "null" into a default type so that geographic objects can be loaded. If the file truly contains no objects of that type, then they'll be ignored.

This specific issue turned out not to be a flaw inside of GIS.NET, but instead a flaw in a developer's code. When you create custom objects, certain constructors need to exist in your object before they will load properly. For example, if you inherit from Polygon, you must expose a constructor which accepts a List<Position> as a parameter so that the loader can construct your object. I've improved the exception to clearly explain what constructors are needed, including generating the actual C# code necessary to fix the error.

Issue #184 (Behavior Is By Design): New Event for NMEAInterpreter

Mon, 17 Nov 2008 17:03:17 GMT

Wednesday, November 05, 2008 at 7:47:11 AM by David Grimm

I need to store the SNR of each Satellite on each time for further calculations. To get the SNR Information I use the NMEAInterpreter from the toolbox. I store the actual SNR of each satellite in an array. Like follows: "signalToNoiseRatio(i) = NmeaInterpreter1.Satellites.Item(i).SignalToNoiseRatio"
To be able to store the values in real-time I would need a further public event on the NMEAInterpreter.
In the tutorial http://www.geoframeworks.com/Articles/WritingApps1_9.aspx you show the code of an NMEAInterpreter. There exists the following event "Public Event SatelliteReceived(ByVal pseudoRandomCode As Integer, _
ByVal azimuth As Integer, _
ByVal elevation As Integer, _
ByVal signalToNoiseRatio As Integer)"

Would it be possible to raise a similar event also in the dll version? The best solution would be to raise an event after an update of all GPGSA information. Not after each line, because the GPGSA can be spread over several lines. For example after each GPGSALine.

Monday, November 17, 2008 at 5:03:17 PM by Jon Person

Hmm, we do have some events such as SatelliteSignalChanged, would that do the trick? In other words, do you need to know when new data is available, even when a value hasn't actually changed? If so, then yes, we would need a brand new event to be added.

Issue #183 (Behavior Is By Design): Unable to automatically connect to GPS device in Toshiba G710

Mon, 17 Nov 2008 16:56:58 GMT

Wednesday, November 05, 2008 at 7:03:58 AM by Neil Andrews

Hi Jon
We recently acquired a Toshiba G710 smartphone from a partner to test and have been a little unsuccessful.

It turns out the device does not have the GPSID configured in way shape or form (I am currently in dicussions with Toshiba about this at minute). However I know that the device does have GPS and managed to find out that the device is on COM 3 Baqud 9600, but when I tell GPS.Net to detect devices it can not find the device. I have set Devices.AllowSharedGpsDeviceConnections to false and also set to Devices.IsSharedGpsDeviceAutomaticallyConfigured to false. The detection completes almost immediately, if I then check the SerialDevice array it has to devices in the list COM3 and COM 2 both at Baud 57600.

If I create a new SerialDevice and specify the port and baud rate of the device, and then get the HardwareStream then I can connect successfully and parse data.

Am I missing a key step somewhere here?

Thanks
Dan

Monday, November 17, 2008 at 4:56:58 PM by Jon Person

Hi Neil, my apologies for the delay!  I'm finally able to focus on the Issue Tracker directly again.  You're welcome to add me to Windows Live Messenger at support@geoframeworks.com to help improve response times moving forward.

It's possible that the Toshiba may either have NO GPSID present, or may be using a proprietary driver.  After the fiasco with HTC's custom GPSID driver, we were forced to re-tool GPS.NET to keep its paws off of the registry if any sign of a proprietary driver exists.

One thing which leaps out at me is the baud rate: 9600.  This baud rate is NOT checked by default by GPS.NET.  So, let's add 9600 to the list of baud rates tested.  We can do this with some code:

<pre>
using GeoFramework.IO;
using GeoFramework.IO.Serial;

Devices.SerialBaudRates.Add(BaudRate.Baud9600);

</pre>

... you could optimize this further by clearing out this entire collection and only adding the baud rates you actually use.

Issue #173 (Behavior Is By Design): Devices.CancelDetection doesn't appear to respond correctly

Mon, 17 Nov 2008 16:51:04 GMT

Tuesday, October 21, 2008 at 1:19:40 PM by Kathleen Lossau

We are experimenting with a cancellable detection path for GPS devices after calling Devices.Detect() and have observed the following:

Devices.CancelDetection() does not appear to stop GPS detection. We still see the Devices.DeviceDetectionAttempted event continue to occur long after calling the CancelDetection() method.

We also never see the Devices.DeviceDetectionCancelled event fire. (verified in the debugger by setting breakpoints appropriately - obviously there's not much code implemented here yet).

We do NOT see Devices.DeviceDetectionComplete fire - which is as expected here. But we need some way to know that device detection has really been cancelled and that the detection thread is really done, and it doesn't appear that there's a good way to do this.

Please advise. Code snippet follows.

Thanks,
Potomac Fusion Inc.

public PFIGSSUI()
        {
            InitializeComponent();

            InitializeDetectionListeners();
        }

        private void InitializeDetectionListeners()
        {
            Devices.BluetoothDeviceDetected += new DeviceEventHandler(Devices_BluetoothDeviceDetected);
            Devices.DeviceDetected += new DeviceEventHandler(Devices_DeviceDetected);
            Devices.DeviceDetectionAttempted += new DeviceEventHandler(Devices_DeviceDetectionAttempted);
            Devices.DeviceDetectionCompleted += new EventHandler(Devices_DeviceDetectionCompleted);
            Devices.DeviceDetectionCanceled += new DeviceEventHandler(Devices_DeviceDetectionCanceled);
            Devices.SerialDeviceDetected += new DeviceEventHandler(Devices_SerialDeviceDetected);
            Devices.UsbDeviceDetected += new DeviceEventHandler(Devices_UsbDeviceDetected);
        }

        void Devices_DeviceDetectionCanceled(object sender, DeviceEventArgs e)
        {
            throw new NotImplementedException();
        }

        void Devices_SerialDeviceDetected(object sender, DeviceEventArgs e)
        {
            throw new NotImplementedException();
        }

        void Devices_UsbDeviceDetected(object sender, DeviceEventArgs e)
        {
            throw new NotImplementedException();
        }

        void Devices_DeviceDetectionCompleted(object sender, EventArgs e)
        {
            setStateTextLabel("Completed GPS device search.");
            setActionTextLabel("");

            throw new NotImplementedException();

            // present listbox of GPS devices and ask them to pick one (if more than
            // one is found).
        }

        void Devices_DeviceDetectionAttempted(object sender, DeviceEventArgs e)
        {
            setActionTextLabel("Searching for GPS device on: " + e.Device.ToString());
        }

        private void setStateTextLabel(string stateText)
        {

            if (currentStateStatusLabel.InvokeRequired)
            {
                StringUpdateInvokeDelegate callback = new StringUpdateInvokeDelegate(setStateTextLabel);
                this.Invoke(callback, new object[] { stateText });
            }
            else
            {
                currentStateStatusLabel.Text = stateText;
            }
        }

        private void setActionTextLabel(string actionText)
        {

            if (currentActionStatusLabel.InvokeRequired)
            {
                StringUpdateInvokeDelegate callback = new StringUpdateInvokeDelegate(setActionTextLabel);
                this.Invoke(callback, new object[] { actionText });
            }
            else
            {
                currentActionStatusLabel.Text = actionText;
            }
        }

        void Devices_DeviceDetected(object sender, DeviceEventArgs e)
        {
            throw new NotImplementedException();
        }

        void Devices_BluetoothDeviceDetected(object sender, DeviceEventArgs e)
        {
            throw new NotImplementedException();
        }

        private void detectionButton_Click(object sender, EventArgs e)
        {
            // TODO: probably turn off the transmission if currently transmitting...

            if (detectingDevices)
            {
                // must be a cancel...
                detectionButton.Enabled = false;
                setStateTextLabel("Cancelling...");
                Devices.CancelDetection();
            }
            else
            {
                setStateTextLabel("Searching for GPS devices...");
                detectionButton.Text = "Cancel detection";
                detectingDevices = true;
                Devices.Detect();
            }
        }

Tuesday, November 11, 2008 at 1:37:05 PM by Kathleen Lossau

Any chance of getting this looked at? I'm entering a more critical phase for this project and would appreciate at least a diagnosis.

Monday, November 17, 2008 at 4:51:04 PM by Jon Person

Hi Kathleen, my apologies for the delays on this particular issue.  A recent web update pulled me away from GPS.NET issues, but I'm now back on track.  The CancelDetection method will attempt to go in and forcefully abort any thread involved with testing a device.  I wonder if one of these threads might possibly be stuck trying to open a port.

Can you give me some more information about the device in particular?  We might be able to attack this problem by optimizing detection to the point you don't have as much of a need to try and forcefully cancel detection.

You (and everyone else) are welcome to reach me directly via Windows Live Messenger at support@geoframeworks.com.  That should speed up response times for you, especially as your deadline approaches.

Issue #203 (Behavior Is By Design): How to Detect the Samsung Omnia SGH-i900

Thu, 04 Dec 2008 12:29:08 GMT

Tuesday, November 25, 2008 at 3:19:06 AM by Armando Rocha

When im trying detect serial device on Samsung OMNIA SGH-i900 its freeze in COM5 at 4800 baud. I can't connect to serial device, but i know that exist in COM3 at 4800 baud. Others GPS application use them.

Any sugestion?

Thanks.

Tuesday, November 25, 2008 at 10:51:25 AM by Jon Person

Hi Armando, it sounds like one of the ports GPS.NET is scanning is not meant to be opened.  This is rare, but it has been reported before.  There's a method called "AvoidSerialPort" in the GeoFramework.IO.Devices static class which we can use to avoid COM5:

<pre>
[C#]
using GeoFramework.IO;
using GeoFramework.IO.Serial;

void Configure()
{
     // Prevent COM5: from being opened during detection
     Devices.AvoidSerialPort(CommunicationPort.Com5);

     // Continue device detection
     Devices.Detect();
}
</pre>

... let's give this a try and see if that improves things for you.  We might also want to look at optimizing device detection by modifying the "GeoFramework.IO.Devices.SerialBaudRates" collection to contain only the baud rates of the devices you'll actually use.

Wednesday, November 26, 2008 at 6:40:26 AM by Armando Rocha

Hi Jon,

I avoided the Com5, like you said, but i still get the same problem in Com9 at 57600 Baud,
the detection hang.

What intrigues me, is that some times i can connet to Shared GPS Device on COM3: at 57600 Baud, but its very rare.

Thanks,
Armando

Wednesday, November 26, 2008 at 6:40:27 AM by Armando Rocha

Thursday, December 04, 2008 at 12:29:08 PM by Jon Person

Armando ended up resolving this issue over MSN Chat.  Strangely, we found that manual connections to the GPSID port (GPD1:) were working with a "SerialStream" object, yet the GPSID seemed to not be finding the device.  The registry structure appears to be different enough on this device to fool GPS.NET into avoiding the port.

We ended up manually registering the GPSID device to coerce GPS.NET into using it:

[C#]
Devices.RegisterGpsDevice(
    new SerialDevice("GPD1:", BaudRate.Baud115200),
    NmeaInterpreter.ProtocolName);

... this code forces GPS.NET to "detect" the program port (GPD1:), after which the Omina started working.

I have an export of Armando's registry so I can work that into the development of GPS.NET 3.0's GPSID functionality.

Issue #147 (Behavior Is By Design): How to connect to the Samsung Omina

Tue, 25 Nov 2008 11:04:54 GMT

Thursday, September 04, 2008 at 2:05:50 PM by Neil Andrews

I purchased the new Samsung Omnia today and ran the sample application to test the GPS functionality however GPS.Net was unable to locate the GPS receiver. I checked the configuration of the GPSID in the control panel all seemed to be ok there (program port GPD1, hardware port COM9 baud rate 4800). I checked the registry which all seemed to be configured ok , the only thing I noticed was that it appears to be using a custom dll for the GPS intermediate driver. I tested live search mobile and Google maps and both connected to GPS ok.

If there is any further information I can provide to help diagnose this please let me know.

Thursday, September 04, 2008 at 2:59:54 PM by Jon Person

Hi Neil, in the most recent build of GPS.NET, it will make no attempt to configure the GPSID if any proprietary driveer is in use. This was implemented because of problems no HTC devices which quite dramatically broke the standard registry key design found on typical Windows Mobile devices. So, for any PDA with a custom GPSID driver, it will be up to you and your end-users to ensure that all GPSID settings are correct.

Can you give me a bit more information on what happens in the GPS.NET example? It should at least be finding the GPSID and reporting it as a "Shared GPS Device (Serial Device on COM9: at 4800 baud)" if you click the "Detect" button. We might also check to make sure that the "Manage GPS Automatically" checkbox is checked in the third tab of the GPSID control panel.

Friday, September 05, 2008 at 1:17:43 AM by Neil Andrews

Hi Jon
When I run the sample and tell it to search for devices it doesn't even locate a device. Also the manage GPS checkbox is checked.
Its a weird one!

Friday, September 05, 2008 at 3:23:11 PM by Jon Person

Weird, not even the GPSID device?? Hah yeah, that blows me away. It suggests that not even the root-level GPSID registry keys are present. This is what GPS.NET looks for to confirm that a GPSID is installed. I think I may need a registry dump of this device's particular branch to see what it will take to get it supported.

This is good timing because the core architecture for GPS.NET 3.0 just started, and deep support for varying GPSID drivers is a top priority as it gets written.

Wednesday, September 10, 2008 at 11:23:16 AM by Neil Andrews

Sorry Jon just seen your response now. I will export the registry keys for the device tomorrow and send them through

Thursday, September 11, 2008 at 1:27:03 PM by Jon Person

Okay, that sounds great. Thanks for taking the time to do this, Neil!

Friday, October 03, 2008 at 5:47:46 AM by Neil Andrews

Hi Jon

Aplogies for the delay in getting back to you, our original unit had to be returned, I have managed to get my hands on another one so here is the registry info.

[HKEY_LOCAL_MACHINE\\System\CurrentControlSet\GPS Intermediate Driver]
"IsEnabled"=dword:1
"MaxLogFileSize"=dword:8000 (default 32768)
"OldLogFile"="\\GPSID_log.bak"
"CurrentLogFile"="\\GPSID_log.txt"

[HKEY_LOCAL_MACHINE\\System\CurrentControlSet\GPS Intermediate Driver\Multiplexer]
"DriverInterface"="COM5:"
"MaxBufferSize"=dword:4000 (default 16384)

[HKEY_LOCAL_MACHINE\\System\CurrentControlSet\GPS Intermediate Driver\Multiplexer\ActiveDevice]
"Index"=dword:5
"Prefix"="COM"
"Dll"="GPSIDRIL.dll"
"Context"=dword:QUI NON TOCCATE NIENTE!! lasciate il valore già presente.
"Flags"=dword:2
"Keep"=dword:1

[HKEY_LOCAL_MACHINE\\System\CurrentControlSet\GPS Intermediate Driver\Drivers]
"CurrentDriver"="Samsung GPS Hardware"

[HKEY_LOCAL_MACHINE\\System\CurrentControlSet\GPS Intermediate Driver\Drivers\Samsung GPS Hardware]
"Baud"=dword:4800
"CommPort"="COM9:"
"SleepOnNoData"=dword:100
"RetryWaitOnError"=dword:10000
"OutputBufferSize"=dword:4096
"InputBufferSize"=dword:4096
"FriendlyName"="Samsung GPS Card, version 1.0"
"InterfaceType"="COMM"

As I mentioned above the only thing I can see different is the fact they are using a custom dll.

thanks

Friday, October 10, 2008 at 11:40:42 AM by

Hi Jon,
is there already a solution for the omnia?

Thanks in advance Rolf

Monday, November 17, 2008 at 5:31:37 PM by Jon Person

Thanks for the registry information, Neil. I was pulled away from GPS support, but I'm now back on this issue.

Tuesday, November 25, 2008 at 11:04:54 AM by Jon Person

Neil, are you able to open a manual connection to COM5: at any baud rate? According to the registry settings you've sent me, this is the appropriate port. We can perform a manual connection using the "SerialStream" class, like this:

[C#]
using GeoFramework.IO.Serial;
using GeoFramework.Gps.Nmea;

SerialStream device = new SerialStream(CommunicationPort.Com5, BaudRate.Baud38400);
NmeaInterpreter interpreter = new NmeaInterpreter(device);

Issue #210 (Behavior Is By Design): TypeLoadException for PolygonF in GIS.NET 3.0

Mon, 08 Dec 2008 11:45:53 GMT

Thursday, December 04, 2008 at 7:46:27 AM by Yatin Patel

I m getting above error while running desktop example installed with gis 3.0, please help. Could not load type 'GeoFramework.Shapes.PolygonF' from assembly.

Please reply to ankit.patel@cyncorp.com as above email a/c yatin@cyncorp.com is not active anymore.

Monday, December 08, 2008 at 11:45:53 AM by Jon Person

This issue was resolved a few days ago, so downloading the latest installer will resolve the issue. Specifically, an error in the build script caused the GIS.NET 3 to not be built when it really should have. This has been resolved.

You can get the latest builds from this page: http://www.geoframeworks.com/DownloadProducts.aspx.

Issue #29 (Behavior Is By Design): Emulator returns empty values in Middle Eastern countries

Mon, 08 Dec 2008 11:43:26 GMT

Monday, May 19, 2008 at 1:08:31 AM by Bilal Ishtiaque

We are using an emulator to test the application and the coordinates received are somewhere in Ethiopia whereas we are sitting in Pakistan. Can we not get real values using emulator or is it an issue that needs to be resolved on your/our end?

We are using the following versions:

Package downloaded and installed from Geo Framework site:
GPS.Net 2.3 for All .NET Platforms ( GPS.Net 2.3.19 )

Libraries referenced in the project:
GeoFramework.PocketPC.dll 1.4.3600.6
GeoFramework.Gps.PocketPC.dll 2.3.3600.19

Monday, May 19, 2008 at 5:47:59 AM by Jon Person

I believe this issue may have to do with how the Emulator produces random Position objects. For the best results, a Random object should be re-used. Otherwise, the random values produced may not be so random. The GeoFramework Core 2.0 (shipping with GIS.NET 3.0) supoprts the "Position.Random(Random)" method to ensure better randomness. I'll look into this today (5/19) and see what's going on.

Friday, May 23, 2008 at 8:53:07 AM by Jon Person

Just an update: I've been busy with installer issues and the beta this week, but will start on this issue as soon as they are resolved.

Friday, June 20, 2008 at 3:08:47 PM by Jon Person

Hi Bilal, I'm now starting on this issue. Can you provide me with a sample coordinate in the region you're using, or (better yet) some source code you've used which triggers the error? This will help me recreate the issue and see what's going on which that hemisphere of the globe.

Monday, December 08, 2008 at 11:43:13 AM by Jon Person

A recent issue (#211) may explain this problem with incorrect values. The GPRMC, GPGLL, GPGGK and GPGGQ sentences were using the format "HHMM" instead of "HHHMM" to serialize Longitude. This would cause incorrect Longitudes. Issue #211 was fixed on 12/8/2008.

Monday, December 08, 2008 at 11:43:26 AM by Jon Person

Marked as "By Design" but this is an actual fix. The status prevents duplication in the change log.

Issue #211 (Released): Emulator produces incorrect Longitude for GPRMC, GPGLL, GPGGK, GPGGQ sentences

Mon, 08 Dec 2008 11:41:43 GMT

Sunday, December 07, 2008 at 2:09:16 PM by Brian Hoeschen

When emulating from a know data source, the longitude should be five characters (DDDMM) but for two digit longitudes, it doesn't include the leading zero.
expected value = -97.645
actual value = -976.45

Monday, December 08, 2008 at 11:35:11 AM by Jon Person

Brian, thanks for this report. Do you see this error in any particular sentence?

Monday, December 08, 2008 at 11:41:43 AM by Jon Person

I see the problem. Internally, the source code to serialize objects into an NMEA sentence was using the format "HHMM" for Longitude, which is not correct. The correct format should be "HHHMM".

This problem affects four sentences: GPRMC, GPGLL, GPGGK, GPGGQ. The format has been fixed for all four sentences and a build is now being posted.

Issue #207 (Released): PixelAt method returns incorrect value on Compact Framework

Tue, 02 Dec 2008 14:13:31 GMT

Monday, December 01, 2008 at 11:20:27 AM by Jon Person

The PixelAt method uses a Matrix object on the Desktop Framework to project, scale and translate a geographic or projected coordinate into a pixel coordinate. This method works fine on the desktop, but on the Compact Framework the values appear to be incorrect. It appears that the translate portion of the transform is not being applied.

Tuesday, December 02, 2008 at 2:13:20 PM by Jon Person

Phil implemented a fix to this, though the fix was not in the Matrix class as originally thought. The initialization sequence of events varies on the desktop vs. mobile devices, and this was the root of the problem. Phil implemented a fix which resolves the issue for the CF, and also improves initialization behavior for the desktop.

Tuesday, December 02, 2008 at 2:13:31 PM by Jon Person

Released 12/2/2008 at about noon (GMT-7)

Issue #209 (Released): Polygon mouse events not working with very small objects.

Mon, 01 Dec 2008 16:01:31 GMT

Monday, December 01, 2008 at 3:58:35 PM by Jon Person

Polygons in the GIS.NET 3.0 framework which are very small, do not seem to trigger any mouse events.

Monday, December 01, 2008 at 3:59:56 PM by Jon Person

This issue was traced back to flaws in GDI+ this afternoon. The GDI+ drawing subsystem assumes that all coordinates are pixel coordinates. As a result, internally, all shapes are converted to Integers before testing. So, if you have a square whose points are all less than 1.0, all hit testing attempts will return FALSE. This behavior is incorect.

Monday, December 01, 2008 at 4:00:53 PM by Jon Person

A function was implemented this afternoon which works around the GraphicsPath.IsVisible() method which was being used before today. The new function relies purely upon mathematics for hit testing; it does not care about pixels and it operates on float-point values.

Monday, December 01, 2008 at 4:01:31 PM by Jon Person

The new function is producing accurate results now, especially for small objects. Mouse events for Polygon objects have been restored, regardless of the size of the polygon.

Issue #208 (Released): LabeledPolygon objects using the Centroid text alignment have incorrect projected extents.

Mon, 01 Dec 2008 15:57:36 GMT

Monday, December 01, 2008 at 2:40:24 PM by Jon Person

When using LabeledPolygon objects whose Label alignment is "Centroid," the object does not receive mouse events.

Monday, December 01, 2008 at 2:40:43 PM by Jon Person

Upon further examination, the projected extent of these objects is grossly incorrect.

Monday, December 01, 2008 at 2:41:19 PM by Jon Person

Inside the LabeledPolygon.CalculateGraphicsPath method, the "textBounds" variable was not being updated to the adjusted extent of the GraphicsPath after it has been transformed.

Monday, December 01, 2008 at 3:57:36 PM by Jon Person

This bug is two-fold, but this portion of the issue has been resolved. A new issue will be posted for the remaining problem: polygon hit-testing.

Issue #206 (Released): PixelAt method to calculate the pixel location of geographic objects

Sat, 29 Nov 2008 12:08:06 GMT

Saturday, November 29, 2008 at 12:07:20 PM by Jon Person

A request was made for a new method called "PixelAt" which returns the pixel coordinate of a specified projected or geographic coordinate. This method would complement other similar methods such as "ProjectedAt" and "PositionAt"

Saturday, November 29, 2008 at 12:07:37 PM by Jon Person

The method was added on Thursday night and is now released.

Saturday, November 29, 2008 at 12:07:53 PM by Jon Person

A bug report was filed for unusual values from the new method.

Saturday, November 29, 2008 at 12:08:06 PM by Jon Person

The issue was resolved and a new build was posted on Friday morning.

Issue #201 (Assigned, Research in progress): Search with a Circle object

Fri, 21 Nov 2008 07:50:26 GMT

Friday, November 21, 2008 at 7:50:26 AM by Jean Bédard

Search function is not returning any result when passing a Circle object as a Polygon. It would be very useful to allow searching with a Circle for raduis search.

Issue #200 (Released): PositionCollection.Area property does not remove added points

Mon, 24 Nov 2008 11:48:21 GMT

Friday, November 21, 2008 at 2:03:27 AM by Mark Spitzer

When accessing the Area-property in the PositionCollection-class (and if the first and last points are not the same), a position is added to the PositionCollection to calculate the Area value.

But this last added position is not removed after calculation, so the PositionCollection fills up with unwanted position.

Monday, November 24, 2008 at 11:47:51 AM by Jon Person

The Area property needs to operate on a "closed" polygon. In this 1.0 framework, PositionCollection will temporarily add a Position to the list to ensure it's a closed polygon.

Monday, November 24, 2008 at 11:48:21 AM by Jon Person

A fix has been made to instead create a copy of the *entire* collection to protect the original contents. The area calculation is then performed on this collection.

Issue #202 (Released): Tileset causes a TypeLoadException when using EquidistantCylindrical projection.

Mon, 24 Nov 2008 11:44:31 GMT

Monday, November 24, 2008 at 11:39:24 AM by Jon Person

When attempting to load a Tileset on the Compact Framework, a TypeLoadException occurs if the tileset was using the EquidistantCylindricalProjection projection.

Monday, November 24, 2008 at 11:42:40 AM by Jon Person

As GeoFrameworks moves towards a common framework which works across multiple rendering platforms (GDI+, WPF, DirectX, Silverlight, etc.), some classes had to be moved to separate assemblies. This is a rare breaking change in the same major version people have been using, but we felt this rare exception was appropriate to help people be able to more easily transition their application to other platforms later on.

One such change was to move the EquidistantCylindricalProjection class, which is used very frequently, to the GeoFramework assembly. However, the TilesetConfiguration class was only designed to look in the GeoFramework.Geodesy assembly for projection types. This caused Tilesets using EquidistantCylindrical to break, as the class is no longer in this assembly.

Monday, November 24, 2008 at 11:44:31 AM by Jon Person

A change was made to TilesetConfiguration to now also look for projection objects in the GeoFramework assembly for projections. In the future, we'll need a static event added to TilesetConfiguration to help developers use Tileset with customized projection objects, as they will not be present in either of these assemblies. Phil?

Issue #197 (Behavior Is By Design): Licensing error with GPS.NET 2.0

Thu, 20 Nov 2008 13:13:26 GMT

Tuesday, November 18, 2008 at 10:14:28 PM by Piers Cockran

Our application runs fine on the development computer, but comes up with a registration web page after running the application when it is deployed to another computer.we when we deploy the application.

The DLL referneces are as follows:

    Reference Include="GeoFramework, Version=1.4.7.0, Culture=neutral, PublicKeyToken=3ed3cdf4fdda3400, processorArchitecture=MSIL" />
    Reference Include="GeoFramework.Gps, Version=2.3.50727.20, Culture=neutral, PublicKeyToken=3ed3cdf4fdda3400, processorArchitecture=x86">
      SpecificVersion>FalseSpecificVersion>
      HintPath>..\..\..\Program Files\GeoFrameworks\GPS.NET 2.0\Desktop Framework 3.5\GeoFramework.Gps.dllHintPath>
    Reference>
    Reference Include="GeoFramework.Gps.Controls, Version=1.3.0.0, Culture=neutral, PublicKeyToken=3ed3cdf4fdda3400, processorArchitecture=MSIL" />
    Reference Include="GeoFramework.Gps.Garmin, Version=1.2.50727.1, Culture=neutral, PublicKeyToken=3ed3cdf4fdda3400, processorArchitecture=x86">
      SpecificVersion>FalseSpecificVersion>
      HintPath>..\..\..\Program Files\GeoFrameworks\GPS.NET 2.0\Desktop Framework 3.5\GeoFramework.Gps.Garmin.dllHintPath>
    Reference>

I have put the following code in the AssemblyInf0.cs:

[License keys edited out]

What do I have to do to get this to work? I have some extreme time pressures on this one as our we have live customers waiting to test the program tomorrow morning Australian Eastern time (GMT +10 Hours).

Thursday, November 20, 2008 at 11:54:12 AM by Jon Person

Hi Piers, recent changes to our build system led to this problem today. Specifically, we merged DF20 and DF35 assemblies into a single assembly. However, the built assemblies were internally coded for one platform, not both. A build was released just now (11/20 12:53PM GMT-7) which resolves this issue. Downloading and installing the latest will resolve the issue.

Thursday, November 20, 2008 at 1:13:26 PM by Jon Person

Piers, I'm going to mark this as fixed since another user confirmed the issue. You can reach me on MSN Messenger directly at "support@geoframeworks.com" if you encounter anything else.

Issue #198 (Released): License Key error with GPS.NET 2.0

Thu, 20 Nov 2008 11:44:59 GMT

Thursday, November 20, 2008 at 9:51:49 AM by Alan Walters

After updating to the newest GPS.NET, every time I open project in VS2008 it sends me to the License page and closes VS. I have opened the AssemblyInfo.vb seperately to verify the keys and they are correct. Note the GPS.NET sample app will open.

Thursday, November 20, 2008 at 10:15:17 AM by Jon Person

Hi Alan, recent changes to the build system combined the licensing system of Desktop Framework 2.0 and Desktop Framework 3.5. This had the side-effect of breaking licensing for VS2005. A fix is now being tested and should be published within the hour.

Thursday, November 20, 2008 at 10:53:20 AM by Alan Walters

I am using VS2008 and 3.5 sp1

Thursday, November 20, 2008 at 11:31:26 AM by Jon Person

Thanks, Alan. I have a build in progress now and will test using your keys before it goes online.

Thursday, November 20, 2008 at 11:39:05 AM by Jon Person

I've confirmed your licenses keys are working. I am now testing the live build to ensure consistency.

Thursday, November 20, 2008 at 11:44:59 AM by Jon Person

Looks good. Alan, you can resolve this issue by downloading the latest build.

Issue #199 (Behavior Is By Design): Web site looks weird in Google Chrome

Thu, 20 Nov 2008 10:42:50 GMT

Thursday, November 20, 2008 at 10:41:08 AM by Jon Person

Google Chrome, which is currently in beta, has problems with any PNG image which uses partial transparency. This also includes CSS styles such as "opacity" which programmatically create transparency in web site elements. The latest release of the GeoFrameworks web site on November 16th vastly improves browser compatibility and compliance with CSS, but it also relies more heavily on PNG and transparency.

Thursday, November 20, 2008 at 10:42:50 AM by Jon Person

An issue has been reported with the Google Chrome team. Developers should remember that this browser is still in beta. Since we rely so heavily on partial transparency, and since Google may soon repair this bug, we're going to leave styles as they are instead of trying for a workaround for the whole web site. The new site still looks consistent in FireFox, IE7, IE8, and Opera. (Opera has its own problems with JavaScript, but that's another story.)

Issue #171 (Behavior Is By Design): "Keep me signed in for thirty days" does not work.

Mon, 17 Nov 2008 16:45:29 GMT

Thursday, October 16, 2008 at 11:52:43 AM by

Keep me signed in for thirty days feature if this web site during login does not work - I have to sign in every time.

Monday, November 17, 2008 at 4:45:29 PM by Jon Person

I believe there's a problem trying to make cookies that work both for SSL and non-SSL modes. At any rate, I appreciate the issue report and will work on improving that feature.

Issue #195 (Released): Refine text labeling for small scales.

Tue, 18 Nov 2008 13:35:24 GMT

Tuesday, November 18, 2008 at 1:35:24 PM by Phil Smith

Text style drawing at small scales (~1 meter per pixel) gets distorted. This is in most part due to floating point precision errors resulting from transforming projected coordinates. Small scale labels, such as street names, need to be drawn with much higher precision.

Issue #192 (Released): Map.PositionAt(int x, int y) returns invalid coodiantes (when map is rotated)

Tue, 18 Nov 2008 18:54:20 GMT

Tuesday, November 18, 2008 at 12:17:24 AM by Olle Pettersson

On Compact Framework,

If the Map's Rotation property is set to not zero we get invalid coordinates from the Map.PositionAt(int x, int y) method.

We are using the default Projection. if the map is unrotated, this is the return position:
DisplayMap.PositionAt(e.X, e.Y)
{34°41'02.4897"N,135°29'42.6045"E}
    _Latitude: {34°41'02.4897"N}
    _Longitude: {135°29'42.6045"E}
    IsEmpty: false
    Latitude: {34°41'02.4897"N}
    Longitude: {135°29'42.6045"E}

If the Map is rotated the return position is:
DisplayMap.PositionAt(e.X, e.Y)
{135°28'28.4632"S,034°41'25.3091"E}
    _Latitude: {135°28'28.4632"S}
    _Longitude: {034°41'25.3091"E}
    IsEmpty: false
    Latitude: {135°28'28.4632"S}
    Longitude: {034°41'25.3091"E}

e.X, e.Y are from a mouse click at the same location in the map (within around 100 meters)

Map.PostionAt() seems to work properly only for rotation of 0, 90, 180 and 270 degrees.

Tuesday, November 18, 2008 at 6:54:20 PM by Phil Smith

More revisions to the CF's implementation of the Matrix. Neo would be proud.

Issue #190 (Released): Label with Empty String causes System.DivideByZeroException

Tue, 18 Nov 2008 18:52:16 GMT

Monday, November 17, 2008 at 5:13:29 PM by Olle Pettersson

In the Sample for Compact Framework 3.5 that comes with the latest installer the Text property for the Airplane is set to String.Empty. this causes a System.DivideByZeroException to be thrown at runtime. Probably because the TextStyle tries to find the midpoint of the empty string.

This is the full exception:

System.DivideByZeroException was unhandled
  Message="DivideByZeroException"
  StackTrace:
       at GeoFramework.Drawing.Styles.TextStyle.GetTextGlyph(String text, Angle angle)
       at GeoFramework.Drawing.Styles.TextStyle.OnPaint(GraphicsContext context, String text, Angle alignment, RectangleF rectangle)
       at GeoFramework.Shapes.LabeledMarker.PaintImageWithText(GraphicsContext context)
       at GeoFramework.Shapes.GeographicPath.OnPaint(GraphicsContext context)
       at GeoFramework.Shapes.GeographicObject.InvokePaint(GraphicsContext context)
       at GeoFramework.Shapes.Layer.OnPaint(GraphicsContext context)
       at GeoFramework.Shapes.GeographicObject.InvokePaint(GraphicsContext context)
       at GeoFramework.Gis.Map.DrawDirect()
       at GeoFramework.Gis.Map.Repaint()
       at GeoFramework.Gis.Map.OnResize(EventArgs e)
       at System.Windows.Forms.Control.WnProc(WM wm, Int32 wParam, Int32 lParam)
       at System.Windows.Forms.Control._InternalWnProc(WM wm, Int32 wParam, Int32 lParam)
       at Microsoft.AGL.Forms.EVL.EnterMainLoop(IntPtr hwnMain)
       at System.Windows.Forms.Application.Run(Form fm)
       at SmartDeviceProject3.Program.Main()

Tuesday, November 18, 2008 at 6:52:16 PM by Phil Smith

Added a check for empty strings for CF versions

Issue #196 (Released): Out Of Memory exception reading particular ESRI Shapefiles.

Tue, 18 Nov 2008 13:39:33 GMT

Tuesday, November 18, 2008 at 1:38:58 PM by Phil Smith

the EsriShapeFile class does not properly handle NulShape record types when encountered in an esri shapefile. A single shapefile can only contain one record type or the NullShape type.

Tuesday, November 18, 2008 at 1:39:33 PM by Phil Smith

Added handling for NullShapes when encountered in an otherwise legitimately formatted ESRI Shapefile.

Issue #188 (Behavior Is By Design): Help with License Keys

Mon, 17 Nov 2008 17:00:09 GMT

Tuesday, November 11, 2008 at 11:12:08 PM by Scott Collingwood

I have placed the license data in the assemblyinfo.vb file and my app runs fine on my development machine however when I deploy it to another machine I get an exception and the trail license webpage opens?

Monday, November 17, 2008 at 5:00:09 PM by Jon Person

Hi Scott, my apologies for the delay. This problem is usually caused when a license key for one of the plug-ins is missing. Most often this is the "GeoFramework.Gps.Controls" assembly. When the error occurs, it should mention the name of the unlicensed assembly in the title of the message.

If it turns out to be a missing license key, let me know via email "jperson@geoframeworks.com" and I'll credit you a license key for this plug-in since I took so long to respond.

Issue #194 (Released): Clock Control: Unable to change the color of the numeric "Hours" label

Tue, 18 Nov 2008 09:56:11 GMT

Tuesday, November 18, 2008 at 9:55:35 AM by Jon Person

The Clock control exposes properties to help developers customize the look of user controls. However, for the Clock control, no property is available which allows for customization of the "Hours" numeric label.

Tuesday, November 18, 2008 at 9:56:11 AM by Jon Person

A property has been added called "ValueColor" which adds this functionality. This new property will be available both as part of GPS.NET 2.0, as well as in the "hybrid" assembly for GIS.NET 3.0.

Issue #193 (Released): New ScaledImageStyle causing OOM Exception (Compact Framework)

Tue, 18 Nov 2008 02:16:48 GMT

Tuesday, November 18, 2008 at 1:10:20 AM by Olle Pettersson

I downloaded an update to GIS.NET for the Compact Framework. We used the ScaledImageStyle with a fixed Size specified for our labels earlier. I suppose we should use ImageStyle for this purpose instead now.

But I found that if I keep on using the ScaledImageStyle I frequently get OutOfMemoryException after zooming in and out for a while. I am using a test application we have which is basically just a Form and a GeoFramework.Gis.Map with 100-200 Shapes and 10-20 ImageMarkers loaded into it.

This worked without problem before upgrading to the latest version of GIS.NET and our WinCe device has 256MB of physical memory so the process should have no problem allocating memory for itself.

Also if I look in the Stack Trace of the exception, it looks like a new bitmap object is being constructed each time the ImageStyle renders.

Exception:

System.OutOfMemoryException was unhandled
  Message="OutOfMemoryException"
  StackTrace:
       at Microsoft.AGL.Common.MISC.HandleAr(PAL_ERROR ar)
       at System.Drawing.Bitmap..ctor(Int32 width, Int32 height, PixelFormat format)
       at GeoFramework.Drawing.Styles.ImageStyle.OnPaint(GraphicsContext context, RectangleF rectangle)
       at GeoFramework.Drawing.Styles.ScaledImageStyle.OnPaint(GraphicsContext context, RectangleF rectangle)
       at GeoFramework.Drawing.Styles.ScaledImageStyle.OnPaint(GraphicsContext context, GraphicsPath path)
       at GeoFramework.Drawing.Styles.Style.InvokePaint(GraphicsContext context, GraphicsPath path)
       at GeoFramework.Shapes.GeographicPath.PaintExistingPath(GraphicsContext context)
       at GeoFramework.Shapes.GeographicPath.OnPaint(GraphicsContext context)
       at GeoFramework.Shapes.GeographicObject.InvokePaint(GraphicsContext context)
       at GeoFramework.Shapes.Layer.OnPaint(GraphicsContext context)
       at ZCT.GridManagement.ProjectedShapeLayer.OnPaint(GraphicsContext context)
       at GeoFramework.Shapes.GeographicObject.InvokePaint(GraphicsContext context)
       at GeoFramework.Shapes.Layer.OnPaint(GraphicsContext context)
       at GeoFramework.Shapes.GeographicObject.InvokePaint(GraphicsContext context)
       at GeoFramework.Gis.Map.DrawDirect()
       at GeoFramework.Gis.Map.Repaint()
       at GeoFramework.Gis.Map.Transpose(RectangleF projectedRectangle)
       at GeoFramework.Gis.Map.Zoom(Percent percent)
       at GeoFramework.Gis.Map.ZoomIn()
       at ProjectedMapViewerCF.Form1.plus_Click(Object sender, EventArgs e)
       at System.Windows.Forms.Control.OnClick(EventArgs e)
       at System.Windows.Forms.Button.OnClick(EventArgs e)
       at System.Windows.Forms.ButtonBase.WnProc(WM wm, Int32 wParam, Int32 lParam)
       at System.Windows.Forms.Control._InternalWnProc(WM wm, Int32 wParam, Int32 lParam)
       at Microsoft.AGL.Forms.EVL.EnterMainLoop(IntPtr hwnMain)
       at System.Windows.Forms.Application.Run(Form fm)
       at ProjectedMapViewerCF.Program.Main()

Tuesday, November 18, 2008 at 2:14:52 AM by Phil Smith

A change was made to defer to the base (ImageStyle) for drawing to take advantage of caching. However, it appears this led to more memory usage than intended. Changed the base so there's no caching of images in the CF.

Tuesday, November 18, 2008 at 2:16:48 AM by Olle Pettersson

I saw that in Issue#187 there was talk about adding Fixed Size Styles and changing the Behavior of ScaledImageStyle so this is probably being addressed right now.

At low zoom levels the ScaledImageStyles actually start to change size even if a fixed size specified. also if the map is rotated, the images change size.

I suppose this will all be taken care of with the new FixedSize Styles. When can we expect to see those in GIS.NET?

Issue #191 (Released): DbaseReader.GetString() returns name value regardless of ordinal.

Mon, 17 Nov 2008 18:07:20 GMT

Monday, November 17, 2008 at 6:07:01 PM by Jon Person

Calls made to the GetString method of the DbaseReader class would return the same value even if different column indeces were specified.

Monday, November 17, 2008 at 6:07:20 PM by Jon Person

The internal code for GetString was using the index of the "title column" instead of the parameter supplied. This is now fixed.

Issue #155 (Behavior Is By Design): Compact Framework Examples Can't Deploy. Tiles Use Up All the Storage.

Mon, 17 Nov 2008 17:40:09 GMT

Thursday, September 11, 2008 at 6:23:37 AM by

Hi,

We are doing some mobile device development in VS2005. The PDA we are using is running Windows Mobile 5. We are especially interested in the TileSet feature as this will hopefully give us the GIS performance we are looking for. Right now I am testing the compact framework 2.0 examples and receiving a strange error when deploying to the PDA. Firstly I want to confirm this sample does use the TileSet class (based on the Tiles folder with all the .png files). When debugging or deploying to Windows Mobile 5 Pocket PC Device I get the error "An existing connection was forcibly closed by the remote host." Any help would be greatly appreciated as we are hoping to make a purchasing decision soon.

Thursday, September 11, 2008 at 12:58:49 PM by Jon Person

Yes, that's right, the Tileset class is used on the Compact Framework. the major difference in behavior, however, is that Tilesets on the Compact Framework cannot generate new tiles, only open existing ones. What we intend for developers to do is copy the entire tile folder to a mobile device. Or, at the very least, copy the "_Tileset Configuration.xml" file along with at least a few tiles. I think some developers forget this configuration file, which explains why things don't load. But, this config file tells GIS.NET which map projection is used by the tileset, which ensures that any new information lines up properly with the tiles.

The "existing connection was closed forcibly" is a network error, so this doesn't seem like an error in our framework directly. The only time we make internet calls is when licensing fails. We attempt to open a browser to the free-trial licensing page to help developers quickly activate a trial and get back to their coding. I'm curious if you have keys specified in the AccemblyInfo?

Thursday, September 11, 2008 at 1:26:31 PM by Jon Person

I'd also like to point out that we have a free update being released soon which adds performance enhancements for both the desktop and mobile devices. Hopefully that'll be out before the 15th.

Friday, September 12, 2008 at 10:43:07 AM by

Thanks for your quick response. I do have the trial license keys in AssemblyInfo.cs. I finally got it to work by creating a new Windows Mobile 5 project in VS2005 and then copied everything from the original example to the new project. It runs nicely on the PDA.

Wednesday, October 22, 2008 at 3:19:21 AM by

I am experiencing the same problem as described by the original poster, when trying to deploy the (unchanged) .NET CF 2.0 example program on a Windows Mobile 6 device. My error message is localized into Swedish, but it is a literal translation of the error message posted above, "An existing connection was forcibly closed by the remote host.". The license keys are in the AssemblyInfo.cs and I have tried the solution the previous poster recommended with creating a new project and copying the example code into that. No success though. It should be noted that I am behind an extremely locked down proxy (government agencies... sigh), but this still shouldn't affect the communication with the mobile device via USB one should think.. Any suggestions as to what I might try next? I'm currently evaluating a number of GIS products for mobile devices for a possible project, and would very much like to be able to try your product as well. Thank you.

Karl Bengtsson

Wednesday, October 22, 2008 at 7:04:18 AM by

It turns out that this is in fact caused by the attempted deployment of the 600 or so tiles in the example program to the handheld unit, which seems to overwhelm it (or Visual Studio, I don't know which). Moving these files over to the deployment path on the device manually and removing them from the project solved the issue for me. I'm using Visual Studio 2005 and a TDS NOMAD.

Karl Bengtsson

Monday, November 17, 2008 at 5:40:09 PM by Jon Person

My apologies for the delay in handling this issue.  You (and everyone) are welcome to get ahold of me directly using Windows Live Messenger.  My support contact is "support@geoframeworks.com."

It sounds like the target device in some cases does not have the memory necessary to store all of the tiles.  We might reduce the number of tiles for future demos, but this might turn some developers off when they zoom in and the screen suddenly goes white (because no tiles exist).  It's a bittersweet trade-off.

I sure would like to see mobile devices leap forward in processing power so we don't have to fight extremely limited CPU and memory resources.  In fact, I bet anyone reading this would just as soon do away with the Compact Framework entirely and get some real power on a mobile device for a change.   My Nintendo has more power it seems.

Issue #136 (Behavior Is By Design): GPS.NET Support for Treo 800w?

Mon, 17 Nov 2008 17:17:07 GMT

Tuesday, August 26, 2008 at 1:18:10 PM by Tom Bulatewicz

Hello!

When I compile and run the example project (GeoFrameworks\GPS.NET 2.0\Compact Framework 3.5\PocketPC\Examplex\C#), it does not find the GPS on a Treo 800w.

Any thoughts?

Thanks!

Wednesday, September 03, 2008 at 8:13:39 AM by Tom Bulatewicz

I forgot to mention that other GPS apps run just fine.

Thursday, September 04, 2008 at 12:19:46 PM by Eric Renken

Anything happening with this bug? We are still having issues with it.

Thursday, September 04, 2008 at 1:12:45 PM by Jon Person

My apologies for the delays on getting an update to this issue. We're currently rearchitecting the communications functionality for GPS.NET for version 3.0 so it's causing a bit aof a backlog regarding devices. Let's see if we can track down the specific COM: port and baud rate used by the Treo 800W. If we can find this, then we'll be able to open a direct connection to the Treo and test for data. Do you have a technical specs document handy for this device? This is usually where such settings are described.

Once we find the settings, we can attempt a manual connection like this:

[C#]
using GeoFramework.IO.Serial;

SerialStream device = new SerialStream(CommunicationPort.Com_____, BaudRate.Baud_______);
NmeaInterpreter interpreter = new NmeaInterpreter(device);

... if you can post your settings that'll help me get to the bottom of this issue. In rare cases a device uses a non-standard baud rate which requires some extra code to get GPS.NET to pick up.

Sunday, September 07, 2008 at 12:42:50 PM by Tom Bulatewicz

Hi Jon. Thank you for your quick reply. The “GPS hardware port” in the GPS Settings is set to something called “Internal GPS device” and not set to one of the COM ports. It’s unusual in that in all other devices I’ve seen, there’s just a list of COM ports there, but this one has an extra item in the list that is not a COM port, and that’s the only one that works. If we set the hardware port to any other COM port in the list (0-9) the GPS does not work.

For our testing we’re using a simple app that just calls the gpsapi.dll functions directly (GPSOpenDevice(), etc), which, again, only works when the hardware port is set to the “Internal GPS device” item, but it does work. (it’s the sample project in Windows Mobile 6 SDK/Samples/CS/GPS).

Is there a way to tell the GeoFrameworks interpreter to just access the intermediate driver like this sample app does, which doesn’t appear to require figuring out the actual COM port?

Also, there’s no detailed information about the Treo800w available on Palm’s developer website. I’ve posted to their discussion board asking about the COM port and baud rate, but I am not hopeful of getting a reply. They’re having a webinar on the 10th dedicated to the 800w when I may be able to actually ask the Palm folks about it directly.

Friday, September 12, 2008 at 2:37:08 PM by Tom Bulatewicz

Hi Jon. The “Internal GPS Device” is actually in the “GPS hardware port” among the other COM ports (strange, huh?). Just to be clear, these are the settings inside of GPS Settings on the Treo 800w when the GPS is working:

GPS Settings:
Programs tab: GPS program port is set to GPD1
Hardware tab: GPS hardware port is set to “Internal GPS device” and the baud rate is grayed-out at 4800
Access tab: Manage GPS automatically is checked

Thanks for your help on this, we really appreciate it.

Friday, September 12, 2008 at 2:37:48 PM by Tom Bulatewicz

Hi Jon. I just watched Sprint/Palm’s webcast on the Treo800w. I asked them about the GPS COM port. They asked Palm directly and Palm said that the GPS is hooked into COM8, but interestingly if you set the “GPS hardware port” to COM8 instead of “Internal GPS device” the GPS doesn’t work. So apparently Palm doesn’t even know.

I posted to Palm’s developer forum and got an interesting reply. He said that you can find out which COM port each item in the “GPS hardware port” list actually hooks to. See the site:
http://msdn.microsoft.com/en-us/library/ms889972.aspx

When I look at what COM port the “Internal GPS device” is set to in the registry, it says that the name of the COM port (or what the reg entry calls the “CommPort”) is called “GPP0:”. For the other entries in this registry key, the COM ports are “COM9:” “COM8:” etc.

To test this, I modified our app to specifically use GPP0. (SerialDevice device = new SerialDevice("GPP0:", BaudRate.Baud4800);) but it still does not work.

Friday, October 24, 2008 at 7:03:53 AM by Nathan Ash

Hi All;

I am having the same issue... cannot get the C# example to work on Treo800W... did someone find a solution yet?

Tuesday, November 04, 2008 at 2:01:58 PM by Tom Bulatewicz

The C# example won't work. You need to:

1) Set the GPS program port (in Settings->GPS Manager) to GPD1
2) In your code, open that port specifically:
SerialDevice device = new SerialDevice("GPD1:", BaudRate.Baud4800);

Then have your interpreter object use that serial device and it'll work.

Monday, November 17, 2008 at 5:17:07 PM by Jon Person

Guys, you are great to post your workaround solution here.  I should credit your accounts for being helpful!

It appears that the Treo 800W is missing registry keys that GPS.NET normally looks for to identify the correct program port.  Specifically, GPS.NET looks for the following registry values:

<pre>
HKLM\System\CurrentControlSet\GPS Intermediate Driver\Multiplexer
               CommPort
               Baud
               InterfaceType          (should be "Comm")
</pre>

... if you're not using a proprietary GPSID driver, you can set the port like this:

GeoFramework.IO.Devices.SharedGpsDevice.SharedPortName = "GPD1:";

... if you're using a proprietary driver, this code will have no effect (as registry writes are forbidden in such cases)

Issue #170 (Cannot Reproduce): InvalidOperationException during Devices.Detection()

Mon, 17 Nov 2008 17:35:12 GMT

Thursday, October 16, 2008 at 11:07:18 AM by

Occasionally, I got an exception during detection of GPS devices:

System.InvalidOperationException: Kolekce byla upravena. Operace výctu pravdepodobne nebude spuštena.
v System.Collections.ArrayList.ArrayListEnumeratorSimple.MoveNext()
v GeoFramework.IO.Device.DetectThreadProc()

My humble translation of the exception message: Collection has been modified. Enumeration cannot be probably performed.

Monday, November 17, 2008 at 5:35:12 PM by Jon Person

Hmm, this error would suggest that the collection is being accessed by multiple threads at once. This is strange, since we do employ lock statements judiciously to prevent this sort of behavior. Are you making any calls which access properties in the Devices class while detection is in progress? That could cause this problem.

In GPS.NET version 3.0, this behavior will be improved because we've officialy declared the "foreach" statement as "evil for multithreading" and instead only use indexers.

Issue #169 (Behavior Is By Design): GeoFramework.IO.Device.GetInterpreter throws an ArgumentNullException exception

Mon, 17 Nov 2008 17:33:01 GMT

Thursday, October 16, 2008 at 10:29:52 AM by

System.ArgumentNullException was unhandled
  Message="Hodnota nemuže být NULL.\r\nNázev parametru: type"
  Source="mscorlib"
  ParamName="type"
  StackTrace:
       v System.Activator.CreateInstance(Type type, BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes)
       v GeoFramework.IO.Device.GetInterpreter()
       v TrackEditor.Import.WPageGPSLogs.OnSettingActive() v E:\devel\UniVET\MainApp\TrackEditor\Import\WPageGPSLogs.cs:rádek 46
       v Wizard.WizardPage.InvokeSettingActive() v E:\devel\UniVET\MainApp\Wizard\WizardPage.cs:rádek 130
       v Wizard.WizardSheet.SetActivePage(WizardPage newPage) v E:\devel\UniVET\MainApp\Wizard\WizardSheet.cs:rádek 293
       v Wizard.WizardSheet.PostChangePage(WizardPageEventArgs e) v E:\devel\UniVET\MainApp\Wizard\WizardSheet.cs:rádek 361
       v Wizard.WizardSheet.nextButton_Click(Object sender, EventArgs e) v E:\devel\UniVET\MainApp\Wizard\WizardSheet.cs:rádek 368
       v System.Windows.Forms.Control.OnClick(EventArgs e)
       v System.Windows.Forms.Button.OnClick(EventArgs e)
       v System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent)
       v System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
       v System.Windows.Forms.Control.WndProc(Message& m)
       v System.Windows.Forms.ButtonBase.WndProc(Message& m)
       v System.Windows.Forms.Button.WndProc(Message& m)
       v System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
       v System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
       v System.Windows.Forms.NativeWindow.DebuggableCallback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
       v System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG& msg)
       v System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(Int32 dwComponentID, Int32 reason, Int32 pvLoopData)
       v System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32 reason, ApplicationContext context)
       v System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32 reason, ApplicationContext context)
       v System.Windows.Forms.Application.Run(Form mainForm)
       v TrackEditor.Program.Main(String[] args) v E:\devel\UniVET\MainApp\TrackEditor\Program.cs:rádek 23
       v System.AppDomain._nExecuteAssembly(Assembly assembly, String[] args)
       v System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence assemblySecurity, String[] args)
       v Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
       v System.Threading.ThreadHelper.ThreadStart_Context(Object state)
       v System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
       v System.Threading.ThreadHelper.ThreadStart()

Monday, November 17, 2008 at 5:33:01 PM by Jon Person

Hmm, it looks like the call to CreateInstance is returning a null value. This would occur if the Device itself has not been identified as a GPS device. In these cases, the protocol is not known, and therefore the method doesn't know which type of object to create.

I suggest removing calls to this method entirely, and instead focus on using an NmeaInterpreter object with a "GpsStream" as its data source.

Issue #158 (Behavior Is By Design): GPS.NET 2.0 and GIS.NET 3.0 compact framework

Mon, 17 Nov 2008 17:27:41 GMT

Wednesday, September 17, 2008 at 10:55:03 AM by

Hi, I was wondering if closed issue #128 also applies to the compact framework.

For the GPS.NET compact framework example, I used the 3 references that were installed with GPS.NET 2.0 : GeoFramework.PocketPC (1.4.3600.6), GeoFramework.Gps.PocketPC (2.3.3600.20), GeoFramework.Gps.Controls.PocketPC (1.3.3600.0). This works fine.

GIS.NET 3.0 compact framework uses GeoFramework.PocketPC (2.0.3600.0). I tried using the Gps.PocketPC(2.4.3600.0) and Gps.Controls.PocketPC(1.4.3600.0) dlls that came with GIS.NET 3.0 compact framework but getting a MissingMethodException - File or assembly name 'GeoFramwork.Gps.PocketPC, Version=2.3.3600.20 .... or one of its dependencies, was not found.

Monday, November 17, 2008 at 5:27:41 PM by Jon Person

Hmm.  I believe this issue has already been resolved in more recent builds, but just to round out this issue:

Developers who are using both GIS.NET and GPS.NET together should use what we refer to as "hybrid" assemblies.  The hybrid assemblies have the exact same codebase as GPS.NET, except that it's compiled against GeoFramework 2.0.0 instead of 1.4.7.  Here's the steps to follow to use hybrid assemblies:

1) Close Visual Studio
2) Uninstall GPS.NET 2.0
3) Install GIS.NET 3.0 from the download page (http://www.geoframeworks.com/DownloadProducts.aspx)
4) Reload your project
5) Look for GPS.NET references and remove them
6) Add new references.  You'll find them in Add References dialog, and they're also in the same install folder as GIS.NET references.

... the GPS.NET hybrid will have a version of "2.4" (as of 11/17/08), and likewise the Control Toolbox will have a version of "1.4".  With these refs added, you can use GIS3 and GPS2 together, and drop the ref to GeoFramework 1.4.7 entirely.

Issue #179 (Behavior Is By Design): Trying to make tileset based on existing external data

Mon, 17 Nov 2008 17:08:02 GMT

Monday, October 27, 2008 at 6:02:51 AM by Peter van Rees

Hi,

We have been using our own system of tilesets in our pocketPC applications for a long time. These tilesets consists of a meta file describing the projected bounding box and the zoomlevel of each of the images (tiles), and the actual (gif) images. These are already projected to the correct local projection system.

Now I am trying to somehow port this functionality to GIS.NET. I thought I would start simple by just adding some picture shapes to a layer. Problem here was I couldn't figure out how to keep GIS.NET from projecting the already projected images, leaving me with pillow shaped images. I tried the IsProjectionLocked property, but that didn't do the job.

The next approach I took was inheriting from tileset, and in the constructor reading the whole metadata file in order to be able to serve the proper tile on request. Problem here is I have no idea what the zoomlevel and x,y parameters stand for in the overridable TileExists and RetrieveTile functions. I would have expected to be able to override the GetTileCoordinates and GetZoomlevel functions, in order to get in control of the zoomlevel and x,y parameters, but they are not declared overridable.

... long story, leading to the following questions:

- How do I prevent Gis.NET from re-projecting already projected shapes of type Picture?

- what do the zoomlevel and x,y parameters stand for in the tileset functions?

- can i get in charge of them?

- if so, what is the approach in determining the zoomlevel with only acces to the projectedrectangle, and not the pixelrectangle? (I would expect to determine the zoomlevel on a value like Distance/Pixel)

- What approach would you recommend for my particular situation?

Thanks,

Peter

Monday, November 17, 2008 at 5:08:02 PM by Jon Person

Hi Peter, hmm... the task of porting a custom Tileset to GIS.NET would be a bit tricky, at least from what I think. you see, we use a customized system to calculate "Tile Coordinates" for each tile, then use that mechanism to calculate the projected extent of any tile. To use a system like yours would probably not mesh well if, say, you were to inherit Tileset and design your own class. You could only do this if you could turn our tile coordinates back into your custom filename.

The worst-case scenario woud be that you have to inherit from Layer and Picture to create a custom Tileset and Tile class, respectively. Perhaps you can discuss this more with me on MSN? I'm using my old account again (support@geoframeworks.com).

Issue #157 (Behavior Is By Design): Help wth GFW and VS2008 toolbox ...

Thu, 18 Sep 2008 13:32:28 GMT

Sunday, September 14, 2008 at 6:48:07 PM by

HI,

I am currently evaluating your wonderful product.
I can run your product to see what it does.

However, as i am new to the MS programming
environment, I am having some difficulties trying
to use your product to create some trial projects.

From the VS 2008 documentation, I suspect that
you have used the Windows Form Designer to
create the various user interfaces, before adding
event handlers to the various GUI entities.

How can I get the GIS/GPS controls into the toolbox ?
(is this a right question to ask?) Seeing that zoomingform.cs
is a partial class, that is accompanied by a designer.cs
file, i suspect that there are corresponding gis/gps
toolbox controls i can drag and drop into the designer?

eg: the designer.cs form for zoomingform shows that
contains map1 defined as GeoFrameWork.GIS.Map.

how do i locate this control drag into the designer?

also, sometimes, when i open the examples, i can
see that there are gps controls, which implement
things like speedometer; sometimes i don't see them
in the toolbox?

Please help, as I/my-company is serious about
purchasing your product.

Thanks,
sam

Thursday, September 18, 2008 at 1:32:28 PM by Jon Person

Hi Sam, thanks for your feedback and detailed message.  Currently, the task of getting a control into the toolbox during an installer is complicated.  It involves using COM to launch the Visual Studio IDE, then programmatically create a project using a template, then accessing the Toolbox window.  We have a utility which performs these tasks but it is not 100% reliable given all the steps involved.

Thankfully, you can modify the toolbox by hand, and this is the only sure-fire way to get controls into the toolbox.  Here's how:

1) Open Visual Studio
2) Create a new project or open an existing project
3) Open a Form
4) Right-click anywhere inside of the Toolbox window, then select "Choose Items..."
5) A dialog will apear which lists all known controls.  Select the "Browse" tab.
6) Navigate to the GeoFramework install directory, typically "\Program Files\GeoFrameworks, LLC"
7) Navigate to the product, usually "GIS.NET 3.0" or "GPS.NET 2.0"
8) Now... select the .NET Framework your project uses.  "Compact Framework 3.5" for example, for VS2008 PDA projects.
9) Select the assembly containing the controls you want.

GeoFramework.Gps.dll - Contains the NmeaInterpreter control
GeoFramework.Gps.Controls.dll - Contains the SatelliteViewer, Altimeter, Compass, Speedometer, and SatelliteSignalBar
GeoFramework.Gis.dll - Contains the Map control

... assemblies for mobile devices are the same as above, but have ".PocketPC" in their name.  Select an assembly.

10) Click "OK" to close the toolbox dialog.  You will now see controls in the toolbox.  Keep in mind that you may have to scroll the toolbox to see the control.
11) Drag the control onto your form.

That's it.   Hopefully, in the future, Visual Studio will greatly simplify the task of programmatically adding controls, perhaps via the registry.  This will improve the installation experience for all component developers.

Issue #166 (Released): Merging Support for Visual Studio 2005 and 2008

Fri, 10 Oct 2008 18:25:35 GMT

Friday, October 10, 2008 at 6:25:35 PM by Jon Person

Two recent events have triggered a rather significant change in the architecture of GeoFrameworks software.  First, with the recent economic crisis on Wall Street in the USA, we are considering ways to do our part to stimulate the economy.  Second, we've discovered how to build assemblies which work in both VS2005 and VS2008.   We're still researching and testing this approach, but if we succeed, this will result in some significant changes:

1. Assemblies will no longer install to "Desktop Framework 2.0" or "Desktop Framework 3.5" but a single "Visual Studio 2005/2008" folder.
2. Version numbers on all assemblies will no longer contain a number identifying the target platform.  Currently, versions were "x.x.3600.x" for VS2005 and "x.x.50727.x" for VS2008.  This will change to more plain version numbers such as "2.0.0.0".
3. The licensing system will be modified so that all licensees for 2005 and/or 2008 will be able to use their license on both systems.  This will essentially be an automatic free upgrade.
4. The online shop will be modified to no longer sell licenses of 2005 and 2008 separately, but rather a joint license.

... again, these changes are still being tested, but developers should be prepared in advance for the change.  Worst case, developers may need to remove-and re-add form controls.  We'll try hard to make this upgrade as smooth and automatic as possible.

This change will not affect your source code whatsoever.  It will only affect references and possibly Form controls.

Issue #150 (Released): New Reduced Pricing for GIS.NET 3.0

Fri, 05 Sep 2008 15:13:28 GMT

Friday, September 05, 2008 at 3:13:28 PM by Jon Person

Prices for GIS.NET 3.0 have been reduced to make us more competitive in the industry. As a side-effect however, the original discount amount is now greater than the new pricing :) We've adjusted discounts for people to keep them competitive; any money paid in is now returned as a discount towards upgrading, and we'll likely continue this policy for all products moving forward. I know many customers are counting on the discount and I believe the new approach still honors existing customers with deep discounts even though things have been restructured.

In other news, a new RSS feed has been launched to help developers stay on top of pricing changes. This feed is updated in real-time and serves as a way to quickly notify people of changes. The new feed can be found via the shopping page (http://www.geoframeworks.com/shop) as well as directly here:

http://www.geoframeworks.com/ShoppingRSS.aspx

Issue #178 (Behavior Is By Design): Using a Tileset With a Cache

Thu, 13 Nov 2008 18:25:53 GMT

Friday, October 24, 2008 at 11:16:13 AM by

Hello,

After reading the Airplane example I am trying to follow the instructions to generate a Tileset on my desktop.

I am loading a GeoTiff into an image, then adding the GeoTiff to the set and a cache with a background.

No files are created in my tileset directory.

Also, I was forced to create a _Tileset Configuration.xml file and place it in that directory or it complained that this file was missing.

The documentation in the Airplane said this file would be generated.  I've searched through the GIS.net help documentation and can't find any info.

What am I doing wrong?

There are no exceptions while running this code, just nothing happens.

Image image = new Bitmap(@"C:\Projects\gpshdcp\courses\CT\RidgeField\RidgeFieldGolfCourse\RidgeFieldGolfCourse.tif");

            GeoTiff geoTiff =
                new GeoTiff(image);

            Tileset set = new Tileset(@"C:\Projects\gpshdcp\courses\CT\RidgeField\RidgeFieldGolfCourse\Tileset");

            string tileDirectory = set.TileDirectory;

            set.Add(geoTiff);
            set.Projection = geoTiff.Projection;

            Cache cache = new Cache();

            //Set background to dark green
            Background background = new Background();

            cache.Add(new Background());

           // cache.
            set.Add(cache);

Mike

Tuesday, October 28, 2008 at 7:59:30 AM by Peter van Rees

you add the cache to the set, i think you should do it the other way around:

cache.Add(set)
map.add(cache)

Thursday, November 13, 2008 at 6:25:53 PM by Jon Person

Thanks for the response, Peter.  I agree, the Cache object should be the "root" object in GIS.NET to get the best performance.

Cache cache = new Cache();
cache.Add(  [etc.]  );
cache.Add(  [etc.]  );
cache.Add(  [etc.]  );
map1.Add(cache);

Issue #186 (Behavior Is By Design): Device Detection on COM40

Mon, 17 Nov 2008 17:00:29 GMT

Tuesday, November 11, 2008 at 4:08:35 PM by Alan Walters

While using Holux Bluetooth GPS receivers the default com port assignment is COM40 - The device detection only goes to COM20.

It would be greatly appreciated if this could be expanded to go to COM40.

Friday, November 14, 2008 at 9:34:26 AM by Alan Walters

Jon helped me with this by informing about the setting:

GeoFramework.IO.Devices.MaximumSerialPortToScan = 40

and now it works great. Thanks Jon

Monday, November 17, 2008 at 5:00:29 PM by Jon Person

Thanks for following up on this with the solution, Alan!

Issue #189 (Released): Add an option to make a style always visaible, regardless of zoom.

Fri, 14 Nov 2008 15:16:37 GMT

Friday, November 14, 2008 at 3:16:37 PM by Phil Smith

An option to make a style always visible will be added to the framework. It is not certain whether or not this option will be available for all styles or just fixed size styles (like ScaledImageStyle)

Issue #187 (Released): Text handling for labeled controls undergoing some significant improvements.

Fri, 14 Nov 2008 15:10:52 GMT

Tuesday, November 11, 2008 at 6:49:14 PM by Phil Smith

Several issues regarding object labeling on both the desktop and compact frameworks have been raised recently. Some new styles will be available for driawing fixed size style (perhaps a name change is in order for the existing ScaledImageStyle, which seems to be somewhat inaccurate) FixedImageStyle, FixedMarkerStyle, and FixedTextStyle will be added to the GeoFramework.Drawing.Styles namespace, replacing the existing Scaled styles of the same types. Additional handling has been added to ensure labels remain aligned to their scaled objects. I expect the changes to be released soon.

Wednesday, November 12, 2008 at 6:38:26 AM by Jean Bédard

It would be great to have also the option to set "AlwaysVisible" to any of the scaled objects so that they are always visible on the map no matter what the zoom level is.

Friday, November 14, 2008 at 3:10:52 PM by Phil Smith

Severeal issues with scaled (fixed size) styles have been addressed. The main consideration was realigning scaled text with associated objects, even ScaledImageStyle objects, which in certain circumstances caused text to draw off screen due to inaccurate positioning.

The "AlwaysVisible" will be added as a separate issue.

Issue #180 (Released): GeographicRectangle.ToArray returns 8 positions

Tue, 11 Nov 2008 14:59:55 GMT

Tuesday, October 28, 2008 at 3:07:34 AM by Peter van Rees

GeographicRectangle.ToArray returns 8 positions, I would expect a rectangle to consist of 4 positions?

Tuesday, November 11, 2008 at 2:59:55 PM by Phil Smith

Updated the ToArray method to just return the corners of the recttangle.

Issue #185 (Released): ScaledImage Allows Images Smaller than the Minimum Size

Mon, 10 Nov 2008 21:36:31 GMT

Monday, November 10, 2008 at 5:58:46 PM by

I am trying to draw icons that do no scale.  ScaledImage appears to be what I need (though the name seems backwards).  When I attempt to provide a fixed size, or min/max sizes the icons still dissapear when I zoom out.  I tried it with the sample app (tracking airplanes).  I modified the AirplaneStyle:

    public class AirplaneStyle : ScaledImageStyle
    {
        public new static AirplaneStyle Default = new AirplaneStyle();

        internal AirplaneStyle()
            : base(Properties.Resources.Jet, new Size(100,100), new Size(200,200))
        { }
    }

I expected to see icons no smaller than 100x00 and no larger than 200x00 (sizes are huge for testing purposes!).  When I start the app, the icons are bigger than normal, but when I zoom out they keep getting smaller... smaller... and finally they dissapear.  What am I doing wrong?

Monday, November 10, 2008 at 9:36:31 PM by Phil Smith

Recent changes have been pushed for a new build. I've also verified the ScaledImageStyle behavior in the latest release is now working correctly

Issue #168 (Behavior Is By Design): Devices.CancelDetection Is Not Recommended to Improve Performance

Mon, 10 Nov 2008 12:01:48 GMT

Thursday, October 16, 2008 at 9:09:59 AM by

Hi,
I use Devices.CancelDetection() method. Sometimes, after this, there remains a process of my application in the system (MS XP) and it cannot be killed (!?). Then, if I start my application (or the example application), the detection of GPS does not work. (I am connecting a Garmin GPS in the Gramin binary protocol mode.)

Thursday, October 16, 2008 at 11:13:26 AM by

More info: I use only GarminBinaryInterpreter, i.e.

Devices.Interpreters.Clear();
Devices.Interpreters.Add(typeof(GeoFramework.Gps.Garmin.GarminBinaryInterpreter));

and Garmin eTrek GPS connected through Serial Port, which is connected to my computer through Serial -> USB cable.

Monday, November 10, 2008 at 12:01:48 PM by Jon Person

Hello, and my apologies for the delays.  This Presidential Election absorbed a lot of our attention the past two months.

CancelDetection is an aggressive method in the GPS.NET framework because it will fortcefully abort detection threads.  Specifically, an attempt is made to gracefully abort detection threads, after which Thread.Abort() is called to terminate detection.  The thing to keep in mind here is that GPS device detection involves several threads; in some cases as high as twenty!  As a result, it is far preferable to allow detection to complete on its own instead of trying to agressively cancel and restart detection.

The preferred approach to device detection is to *tune* detection instead of canceling it.  In the case of Garmin GPS devices, a baud rate of 9600 is typically used.  Changing the GeoFramework.IO.Devices.SerialBaudRates collection, for example, to have only the baud rates you actually use, can vastly improve detection speed.   Other properties in the Devices class can speed up detection.

For the fastest behavior, especially in a non-production environment, it is preferable to "pre-register" your GPS device using the GeoFramework.IO.Devices.RegisterGpsDevice() method.  This method effectively foolks GPs.NET into thinking it has already detected a device.  It can completely eliminate detection times.

Issue #182 (Released): Setting the Rotation proprty somtimes causes thread contention.

Fri, 31 Oct 2008 13:22:40 GMT

Friday, October 31, 2008 at 1:22:40 PM by Phil Smith

Setting the Rotation property throws InvalidOperation exceptions. Added object locking to prevent this.

Issue #181 (Released): Map.SuspendPaint method doesn't seem to work

Fri, 31 Oct 2008 13:17:40 GMT

Friday, October 31, 2008 at 12:04:54 PM by Peter van Rees

I am resetting the style on a few hundred polygons, which triggers a repaint for every polygon and is obviously very slow. I thought I could speed things up by calling SuspendPaint on the map before resetting the styles, but this doesn't seem to do anything.

I made a custom layer with a SuspendPaint method which blocks OnPaint and OnInvalidate and this does the job, which makes me think the SuspendPaint method on the map is not functioning?

Friday, October 31, 2008 at 1:17:40 PM by Phil Smith

The threading model for the Map control was changed to use separate threads, one for each map layer (Permanent, Movable and Decoration). Paint suspension at the time was overlooked, but has been refactored. A bug in the Rotation property setter that ocaisionally cause thread contention problems has also been fixed.

Issue #176 (Released): GIS Drawing srchitecture will be split out into a separate library for use by both GIS.NET 3.0 and the upcoming GPS.NET 3.0.

Thu, 23 Oct 2008 16:11:48 GMT

Thursday, October 23, 2008 at 4:11:48 PM by Phil Smith

The GeoFramrework.Drawing dll will be split into 2 libraries; GeoFramework.Shapes.dll and Geoframework,Drawing.dll. This will facilitate the use of the GIS.NET 3.0 drawing architechture in the upcoming GPS.NET 3.0. Current GIS.NET 3.0 developers will need to add a reference to the new GeoFramework.Shapes dll. No namespace or API changes will be made that would break existing code

Issue #177 (Behavior Is By Design): #175: only partly solved? How to make custom projection?

Fri, 24 Oct 2008 13:02:13 GMT

Friday, October 24, 2008 at 4:16:38 AM by Peter van Rees

I was reviewing the fix for issue #175. The Amersfoort.RDNew projection seems to work fine, but the Amersfoort.RDOld still seems to give the same results as it did before the fix?

One other thing:
I have a very accurate conversion routine from wgs84 to Amersfoort.RD and back. Would it be feasible to somehow inherit from Amersfoort.RDNew and only override the projection/deprojection functions? What functions should be overriden in this case?

Friday, October 24, 2008 at 1:02:13 PM by Phil Smith

I'm not certain RDOld is relevant here. It uses a different projection. Same projection type, different parameters. I wouldn't expect to get the same results from both. For you particular problem and the coordinate you supplied I used the RDNew projected system and the Variant2 transform:

            // A projected system is needed to conver to and from lat/lon coordinates
            ProjectedCoordinateSystem projectedSystemRD = Amersfoort.RDNew;

            // Many systems are shifted slightly due to the differences in ellipsoid shape/size from system to system
            // A coordinate system transform realigns coordinates from one system with the surface of another
            CoordinateSystemTransformation transformRDtoWGS84 = Amersfoort.Variant02;

            // A projected coordinate in the RD system
            ProjectedCoordinate coordRD = new ProjectedCoordinate(190250, 331177);

            // Deproject the coordinate to lat/lon
            Position positionRD = projectedSystemRD.Projection.ToPosition(coordRD);

            // PositionRD is a lat/lon coordinate in the RD system, it needs to be shifted to WGS84
            Position positionWGS84 = transformRDtoWGS84.ToWGS84(positionRD);

The expected result you supplied was 50°58'09,0887"N;005°53'20,4511"E
The rusult from the transfor above is "50°58'09.0884"N,005°53'20.4510"E"

The difference between RDOld and RDNew is significant enough that EPSG maintains separate system for each, therefore, one is correct and the other isn't. The same goes for the 2 variants of the ToWGS84 transform. I don't have any documentation to support which is right for your needs, I would need more information to make that assessment. However the comparative results suggest that the Amersfoort system is now working correctly.

You can create your own projection by inheriting from Projection and you can create your own coordinate system transform simply by creating a new instance of the CoordinateSystemTransform class.

Issue #175 (Released): Amersfoort coordinate systems employ the wrong projections

Thu, 23 Oct 2008 16:04:25 GMT

Thursday, October 23, 2008 at 4:04:25 PM by Phil Smith

The Amersfoort coordinate system was set up to use the Sterographic projection, but thsi is incorrect. An alternate ObliqueStereographic projection has been added and validated against test data.

Issue #172 (Released): Implement FromEPSGNumber on the CF version of Geodesy.NET

Fri, 17 Oct 2008 14:29:24 GMT

Friday, October 17, 2008 at 2:29:24 PM by Phil Smith

Implemented FromEPSGNumber methods for the ProjectedCoordinateSystem and CoordinateSystemTransfoem objects in Geodesy.NET for the compact framework.

Issue #80 (Released): Feature Request: Add TFW Support to GeoTiff Class

Fri, 17 Oct 2008 14:25:03 GMT

Wednesday, June 25, 2008 at 2:58:43 AM by Marcel Suter

I have been trying to import a georeferenced TIFF. However I have only naked TIF's with acompanying TFW's. It would be nice if this was supported too, additional to the fully-fleged TIFF's with metatags.

Since I have many files, this would be nice. (I am currently not aware of a tool that would automate this).

Wednesday, June 25, 2008 at 5:11:40 AM by Marcel Suter

I have now come across the tools geotifcp and listgeo from
http://www.remotesensing.org/geotiff/faq.html#What%20is%20TIFF%20format?

I have manually transformed my tifs and it works for me.

I seems that there is a code library. Why not using that to provide a GeoTiff class that accepts a TFW, a TIF and a projection and then creates a GeoTiff (either as file for importing or direcly on the fly for loading into a layer/map)

Wednesday, October 15, 2008 at 2:44:31 PM by Phil Smith

The documented GeoTiff writer methods have been implemented and re-enabled as well as added support for TIFF formats that GDI+ dooesn't seem to be able to decode. Let me know if you have further problems with any particulat GeoTiff image. psmith@geoframeworks.coim

Friday, October 17, 2008 at 2:25:03 PM by Phil Smith

...

Issue #86 (Released): Add Support for Writing ESRI Shapefiles

Fri, 17 Oct 2008 14:24:07 GMT

Monday, June 30, 2008 at 3:08:32 PM by Ted Macy

As much as I agree with your position that Shapefiles are a lousy format, in my industry, it is imperative that we be able to write shapefiles in order to exchange data with the software applications from our competitors. They are married to shapefiles, and it is critical that our customers be able to export data in a format that can be used by the software that their customers might be using.

Wednesday, July 02, 2008 at 12:37:07 PM by Jon Person

We decided to exclude the ability to write shapefiles for a couple of reasons.  First, we were receiving emails from customers complaining that our files would not load in their application.  Having no control or information over how each application treats shapefile content, we could only resort to a trial-and-error process to debug content.  Second, while ESRI is a very common and fast-loading format, it is prone to several design flaws.  For this reason we decided to nudge developers towards Geographic Markup Language, an XML standard for geospatial data which can be extended and can support any kind of data.

With enough votes here we can add shapefile support back in, albeit reluctantly.  If GIS developers can at least consider the advantages of moving towards a GML back-end and tile-set front end, then we can rest easier about supporting antiquated formats like ESRI.

So, it would be great if other developers out there can chime in on this issue!  If you'd like to see this support ressurrected, please add a comment here.

Thursday, July 31, 2008 at 4:33:17 AM by Olle Pettersson

TileSets are a good solution to rendering large detailed maps on a device but we see 2 problems that are keeping use from being using an image based TileSet solution at the moment.

(1) The way the tiles get rendered on a device does not look as sharp as when they were generated, is there a way to fix this?

(2) One major benefit we see with using vector data for rendering is that we get the ability to rotate our maps relatively easy. Is there no plans to use another format for the tiles like SVG? Otherwise we would have no choice but to go with shapefiles for this purpose.

Thursday, July 31, 2008 at 9:04:19 AM by Phil Smith

There's going to be some difference in rendering quality from the desktop to a device, that's just a fact of the technology. Tilesets are an option to provide speedy rendering of large datasets on a device. Shapefiles are still supported by GIS.NET 3.0 on devices and are the fastest option to load vector data. But there are no plans to write shapefiles at this time.

Rotation is also fully operational in the compact versions os GIS.NET 3.0 except for the rotation of imagery, which is rediculously slow compared to a desktop. However you should have no problem rotating vector data at all.

Friday, October 17, 2008 at 2:24:07 PM by Phil Smith

Basic support for writing shapefiles has ben implemented in GIS 3.0. See EsriShapefile.Save()

Issue #93 (Behavior Is By Design): GDI+ is Unable to Write GeoTIFF tags

Wed, 15 Oct 2008 14:51:43 GMT

Monday, July 07, 2008 at 3:40:00 PM by Phil Smith

Apparently GDI+ doesn't know to recalculate offsets after PropertyItems are added to the Image. PropertyInfo has no public constructor, so it's hard to tell what's really going on. If thre's some internal implementation that we don't know about. Looks like a custom tiff reader/writer will be needed.

Monday, July 07, 2008 at 4:57:29 PM by Jon Person

PropertyItem pi=(PropertyItem)Activator.CreateInstance(typeof(PropertyItem), true);

... and yes, GDI+ is horrible, awful, full of "Generic Error" bugs. Seriously, what programmer can sleep at night after writing "Generic error" in their code? But yeah a writer should be okay for the desktop for now.

Wednesday, October 15, 2008 at 2:51:43 PM by Phil Smith

Duplicate

Issue #167 (Released): MapInfo reader not handling Text records

Wed, 15 Oct 2008 08:07:11 GMT

Wednesday, October 15, 2008 at 8:07:11 AM by Phil Smith

Added default handling for text records in the MapInfo format.

Issue #160 (Released): Documented static methods Create and CreateTo missing from GeoTiff class!

Mon, 13 Oct 2008 13:42:31 GMT

Friday, September 19, 2008 at 2:05:27 PM by

I can't georeference raster images programmatically since the needed methods seem not to be there, contrary to the online documentation.

Tuesday, September 30, 2008 at 11:54:45 AM by Phil Smith

We were unable to implement geotiff encoding at the time GIS 3.0 was released, which is why they still appear in the documentation but were removed from the public API. GDI does not support saving image data with custom property items (which may be why there is no public constructor for the System.Drawing.Imaging.PropertyItem class) and also not all tiff files are recognized by GDI. We're in the process of incorporating a 3rd party image handling dll to accomidate the full implementation of GeoTiff that we had originally planned.

Monday, October 13, 2008 at 1:42:31 PM by Phil Smith

Full support for both reading and writing GeoTIFF imagry for the desktop framework is now available. The documented methods for creating GeoTIFF tagged images from images sources sith georeferencing information have been restored.

Issue #163 (Behavior Is By Design): Problems with Device Discovery on Trimble

Thu, 09 Oct 2008 21:48:48 GMT

Thursday, September 25, 2008 at 9:57:49 AM by Brendan Carroll

The following is my configuration:

WinXP sp2
VS .NET 2005
.NET 2.0 sp1
.NET 3.0 sp1
GPS.NET 2.0
Trimble ProXT
Bluetooth v4.00.22(D) Toshiba Stack

Referenced Assemblies:
GeoFramework.dll 1.4.3600.7
GeoFramework.Gps.Controls.dll 1.3.3600.0
GeoFramework.Gps.dll 2.3.3600.20
GeoFramework.Gps.Garmin.dll 1.2.3600.1

History:

I wrote a WinForms app a couple months back and everything was working as designed using bluetooth and NEMA. The GPS component would discover devices and recieve a NEMA signal and life was good. In fact, the app being used in the field on a toughbook and working. I recently went back to the app on my dev box and am unable to detect and recieve a signal. The Trimble unit is the same one originally used during dev and I'm able to use GPSController to connect to it via bluetooth and log output signals in NEMA format. However, when I try to run GPS.NET on my dev box it kicks off the bluetooth connection and the bluetooth icon changes but it never throws the device discover event and preceeds to cycle through all the ports. I look at the license object and everything checks out. I get the exact same result using the sample app provided by GF.

Thx,
-BC

Thursday, September 25, 2008 at 11:39:43 AM by Brendan Carroll

I discovered the issue. It was the Trimble not pushing a NEMA signal on the correct port. Once i connected via serial and reset NEMA to a Bluetooth port it worked. The trick seemed to be that the reconfig had to happen over a serial connection to take. I was trying to reset the Trimble using Bluetooth only.

Thursday, October 09, 2008 at 9:48:48 PM by Jon Person

Hi Brendan, nice work solving this issue, and thanks for taking the time to describe your solution! This helps us to code GPS.NET to behave more smoothly with all devices.

Issue #161 (Released): Program not running after upgrade

Thu, 09 Oct 2008 21:44:19 GMT

Sunday, September 21, 2008 at 6:58:44 AM by Martijn de Jong

Hi,

I just downloaded and installed the last version of GPS.NET.
After copying the three dll's (GeoFramework.PocketPC.dll, GeoFramework.Gps.PocketPC.dll and GeoFramework.Gps.Controls.PocketPC.dll) to my model, I did rebuild my complete solution in VS2008.
But when I try to run the program I get the following message: "Can't load type GeoFramework.Gps.Nmea.NmeaInterpreter from assembly GeoFramework.Gps.PocketPC, Version=2.3.50727.20, Culture=neutral, PublicKeyToken=3ED3CDF4FDDA3400.", from a System.MissingMethodException (I translated this from Dutch, so the message may be a little differnt in English).
Any idea what is going wrong?

Thanks in advance,
Alex Kwak
www.waarneming.nl

PS. Could you reply to alex@zoefzoek.nl, as info@waarneming.nl is not read by me.

Thursday, October 09, 2008 at 9:44:19 PM by Jon Person

Hi Alex, yes I'll reply to email regarding this issue. We recently made changes to the libraries which I believe caused this issue.

Until about two weeks ago, our build box was limited to building assemblies targeting the x86 platform only. We resolved the issue, and assemblies can now operate on both 32-bit and 64-bit machines. However, this broke the references and also invalidated form controls in the examples. A build is being posted now which resolves all of these issues.

Issue #165 (Released): Mouse events not firing without a base map loaded

Wed, 08 Oct 2008 10:37:35 GMT

Wednesday, October 08, 2008 at 10:37:35 AM by Phil Smith

Geographic object mouse events wern't firing properly when no items were found in the map control mouse position hit test after previously registering a mouse event because the method exited without processing the previously selected items. For instance, a single marker exists on a map, the mouse is moved over the marker, generating a MouseEnter and a MouseMove for the marker. When the mouse leaves the marker, no results are returned from the hit test and the processing of events was halted. Changed so that processing continues on previously signaled items.

Issue #162 (Released): Rotation not working at all on the CF

Mon, 22 Sep 2008 20:31:34 GMT

Monday, September 22, 2008 at 8:30:55 PM by Phil Smith

Per Olle Pettersson;

In the project one Shapefile is loaded into the map. The map can be rotated 90 degrees. The map shows nothing when rotated, only when the rotation angle is 0 degrees does the shapes show up again (press the “Rotate 90” button to rotate the map a full 360 degrees). Zooming to the projected or geographical extent of the shapefile when the map is rotated does not help.

Monday, September 22, 2008 at 8:31:34 PM by Phil Smith

There was an error in the rotation matrix calculation for the CF. It's working now.

Issue #159 (Released): Assemblies Won't Work Under 64-bit Processors

Thu, 18 Sep 2008 13:11:57 GMT

Thursday, September 18, 2008 at 1:11:57 PM by Jon Person

Due to a limitation of our build machines, we were only able to build assemblies targeting the 32-bit x86 processor architecture. This morning, however, this issue was resolved, and assemblies can now be run on both x86 and x64 processors. No specific optimizations have been made for each processor; we're just focusing on support at this point.

Issue #156 (Released): Significant Performance Improvements Added

Sat, 13 Sep 2008 17:04:30 GMT

Saturday, September 13, 2008 at 5:04:30 PM by Jon Person

The first phase of performance improvements has been successfully added to GIS.NET 3.0. This improvement drastically improves panning performance on both desktops and mobile devices. Developers do not need to make any code changes. The only change to consider is that Cache objects are no longer necessary in your code. In other words, you can (and should) now use a regular Layer object in your code; you'll still take advantage of performance improvements. You can still use a Cache object if you want, it just uses more memory than is really necessary.

Issue #148 (Released): Problem with Rotation on CF

Fri, 12 Sep 2008 14:55:29 GMT

Friday, September 05, 2008 at 1:03:51 AM by Olle Pettersson

In the latest release where map rotation is allowed in Compact Framework we are encountering 2 problems.

1) Whenever we call Map.Add(GeographicObject item) the map still throws an ArgumentOutOfRangeException saying that "Rotation is not supported in CF". This occurs even though we have set the AllowRotation property to true.

2) The map does not render as expected after rotation. This is a bit harder to troubleshot I guess. We are loading only shapefiles into the map (with some points styled with ScaledImageStyles with static size). When we change the Rotation property, the Map control does not render the shapes any more. The whole Map control just turns blue for some reason.

Also, when the map Rotation is set to not zero we tend to get weird values for the visible extent of the map if we pan the view around.

DisplayMap.VisibleExtent. then has values like:

"Upper Left 89°59'55.3962\"S,034°41'35.9008\"E, Upper Right 89°59'55.3962\"S,034°41'50.3813\"E, Lower Left 90°00'04.5966\"S,034°41'35.9008\"E, Lower Right 90°00'04.5966\"S,034°41'50.3813\"E"

The map starts out zoomed in to street level so after a few pans, it should not be this wide.

Friday, September 12, 2008 at 2:54:17 PM by Phil Smith

The AllowRotation property will allow you to both change the rotation and also add new image objects to the map after changing the rotation.

Friday, September 12, 2008 at 2:55:29 PM by Phil Smith

AllowRotation now allows image objects to be added to a map after setting the Rotation as well as setting the rotation after adding an image object

Issue #119 (Released): Add Ability to Synchronize Painting for All Movable/Permanent Objects

Fri, 12 Sep 2008 14:51:58 GMT

Wednesday, August 06, 2008 at 3:07:48 AM by Olle Pettersson

I have noticed that sometimes when panning the map around Movable Objects gets painted before the underlaying map has finished rendering. We subclass the Vehicle class for our user indicator and it looks a bit weird when we pan the map around.

I understand the the reason for this is that the Maps and Vehicle get rendered on different threads but is there no way to to tell if the application has to wait for the maps to get rendered first (after a Pan) or if the underlaying maps are already 'valid' (ex. updating a user icon with GPS positions)

Could there be a way to synchronize the rendering under circumstances like above when the maps have to be redrawn?

Thursday, September 04, 2008 at 2:56:41 PM by Jon Person

Phil is hard at work with an approach to synchronization like this. There's no estimate on it's release but it's his main focus right now.

Friday, September 12, 2008 at 2:51:58 PM by Phil Smith

User interaction now redraws the 3 map layers in sync.

Issue #152 (Released): Probelm Disposing of GeographicDataSources during loading (Compact Framework)

Fri, 12 Sep 2008 14:50:10 GMT

Tuesday, September 09, 2008 at 2:11:30 AM by Olle Pettersson

I am trying to Dispose of a GeographicDataSource that is still loading shapes from a ShapeFile. The problem is, if I try to call Dispose() on a the GeographicDataSource before all shapes have finished loading I get an ArgumentNullException from the tread loading the shapes.

System.ArgumentNullException was unhandled
  Message="The projection of a geographic object cannot be null.\r\n?? ?? ??: Projection"
  StackTrace:
    ??: GeoFramework.Shapes.GeographicObject.set_Projection(Projection value)
    ??: GeoFramework.Shapes.Layer.OnItemAdded(GeographicObject item)
    ??: GeoFramework.Shapes.IO.GeographicDataSource.SpeedLoad()
    ??: GeoFramework.Shapes.IO.GeographicDataSource.Load()
    ??: GeoFramework.Shapes.IO.GeographicDataSource.Load(Object chezburger)
    ??: System.Threading.ThreadPool.WorkItem.doWork(Object o)
    ??: System.Threading.Timer.ring()

In many cases the application crashes (without any exceptions thrown) if I try to call dispose while still loading shapes from file.

Friday, September 12, 2008 at 2:50:10 PM by Phil Smith

Changed the dispose behavior to clean up more touroughly if the loading thread i still active

Issue #154 (Behavior Is By Design): License initialization VS2008 .NET 3.5

Thu, 11 Sep 2008 13:08:43 GMT

Wednesday, September 10, 2008 at 1:54:13 PM by Jarrod Skulavik

I have placed the GUID registration number into my AssemblyInfo class, yet I continually recieve a message that my trial version has expired. I have paid for the GPS.NET toolkit and am using VS 2008 .NET 3.5. I have used the license assistant to no avail. Please advise. THANKS.

Thursday, September 11, 2008 at 1:08:43 PM by Jon Person

We resolved this issue over the phone. It turns out that the 2005 refs were added by accident, thus throwing an error since the keys were looking for 2008. Visual Studio 2008 has been known to automagically change binary references to what it believes to be a newer version. This same error is responsible for a change internally here a couple of months ago to switch to all binary references and to make sure "SpecificVersion" is "True" for each ref to prevent them from changing. Easy fix thankfully.

Issue #153 (Behavior Is By Design): Mouse Clicks always searches the map (Compact Framework)

Thu, 11 Sep 2008 12:24:56 GMT

Tuesday, September 09, 2008 at 5:57:44 PM by Olle Pettersson

I have found that the layers in the map are always searched on mouse clicks even though the Map.MouseClickAction is not set to Search.

I set the MouseClickAction to None, or Recenter

Then, if I add a custom layer to the map the Search(projectedPoint, results) method in this layer still gets called.

If I throw an Exception in the overridden Search method I get this stack trace:

       at SmartDeviceProject3.CustomLayer.Search(PointF projectedPoint, List`1 results)
       at GeoFramework.Shapes.Layer.Search(PointF projectedPoint, List`1 results)
       at GeoFramework.Gis.Map.Search(PointF projectedLocation)
       at GeoFramework.Gis.Map.OnMouseClickSearch(Object chezburger)
       at System.Threading.ThreadPool.WorkItem.doWork(Object o)
       at System.Threading.Timer.ring()

So the search is caused by the mouse click even though the mouse click action is not set to Search

Thursday, September 11, 2008 at 12:24:56 PM by Phil Smith

It's a default search for object events like clicking on a map feature. To disable this, set AllowObjectMouseEvents to false

Issue #149 (Released): Upgrading Does Not Update Assemblies in the Global Assembly Cache

Fri, 05 Sep 2008 10:28:45 GMT

Friday, September 05, 2008 at 10:27:48 AM by Jon Person

Due to a flaw in the installation software, the installer for GIS.NET 3.0 and GPS.NET 2.0 is not properly overwriting assemblies in the Global Assembly Cache. When version numbers are the same, assemblies are not installed.

Friday, September 05, 2008 at 10:28:45 AM by Jon Person

All GAC-related install scripts are being replaced with a custom install script which calls GACUTIL.EXE with options "/i" and "/f" to force assemblies to be installed into the GAC. This should also have the added benefit of reducing the size of installers.

Issue #98 (Behavior Is By Design): The GPS controls aren't updating themselves.

Thu, 04 Sep 2008 14:43:56 GMT

Thursday, July 10, 2008 at 9:19:50 PM by

Sorry, this is probably something really stupid. I am just trying out your product so I loaded the speedo and clock onto a simple form and deployed it to a wince 5.0 box with a gps. They load okay but niether the clock nor the speedo moves.

Saturday, July 12, 2008 at 11:54:53 AM by Jon Person

Ahh, the PocketPC. Developers are craving the ability to write hundreds of applications on these devices, but they are extremely limited on resources. As a result, any app which avoids multithreading or avoids code optimization will see poor performance. Now, when we designed the GPS controls, the main goal here was to show controls without taking over the GUI thread. In other words, GeoFrameworks has a policy that all of its components will succumb to the demands of the consuming application, and therefore use lower thread priorities. Properties such as "ThreadPriority" can be changed to give the control more CPU time, which will improve its responsiveness.

Let's try changing the ThreadPriority value to a higher amount for these controls. Also, the controls by default are designed to not tie into real-time GPS data. This lets developers use the controls without a license to GPS.NET. Let's set the "IsUsingRealTimeData" property to "True" on the controls in the Form's constructor. This should make the controls responsive for you.

Saturday, July 12, 2008 at 2:36:04 PM by Jon Person

I'm gonna keep this open for a few days. If there is no further feedback it will be marked as "Closed, By Design"

Saturday, July 12, 2008 at 4:50:10 PM by

Thanks for your suggestions. I took off the speedo and gave the clock the highest thread priority. And I changed the update interval to be 00:00:01 (not 100% sure what that does but it sounded relevant). And still no joy. I presume the red hand is supposed to sweep around. I took off the speedo in case it was gps problem - or does the clock also use the GPS?

Tuesday, July 22, 2008 at 3:07:41 PM by Jon Person

The clock can use GPS if it's set to Satellite-Derived Time. In that case it'll hook into Devices.UtcDateTimeChanged. We might also see if any other threads are eating up CPU. Mobile devices are very limited to begin with, so they're quite easy to bog down, even with mundane operations.

Thursday, September 04, 2008 at 2:43:56 PM by Jon Person

The Clock control (and all controls) hook into static events inside of the GeoFramework.IO.Devices class. Since the development of GIS.NET 3.0 started, however, we've identified some big areas of performance improvement. However, the architecture change is so significant that it will be quite a surgical operation for me to cleanly integrate into 2.0. There's a chance this may get tabled 'til GPS.NET 3.0. If you're maxing ThreadPriority, painting on separate threads, and avoiding modal child forms, then I think you've reached the limit of what GPS2 can do. We're hard at work on improvements however since GIS3 demands so much performance, and I promise to work those advances into GPS2 if at all possible.

Issue #112 (Behavior Is By Design): Example GPS.Net App Does Not Find GPS on Pharos

Thu, 04 Sep 2008 14:37:12 GMT

Friday, July 25, 2008 at 2:10:18 PM by Tom Bulatewicz

When I compile and run the example project (GeoFrameworks\GPS.NET 2.0\Compact Framework 3.5\PocketPC\Examplex\C#), it does not find the GPS on a Pharos 535.

The GPS unit on the Pharos 535 is wired to COM4 (and is shared with the IR port) but the example program detects it on COM8 and thus fails to read from it.

Other GPS utilities are able to find the GPS unit on COM4.

Do you know why it wouldn't be autodetecting the GPS?

Thanks!

Wednesday, August 13, 2008 at 6:35:57 PM by Jon Person

Hmm this is strange indeed. Are any other applications running at the time detection occurs? It might help for us to try and obtain a GPS NMEA data log. Also, let's see if we can figure out which baus rate is used by the Pharos 535. We excluded some baud rates from the automatic-detection process to speed it up. If the 535 uses an unorthadox baud rate, it would not get picked up. All NMEA-compliant GPS devices are required to support at least 4800 baud to be in compliance.

Tuesday, August 26, 2008 at 12:16:14 PM by Tom Bulatewicz

Thanks for the reply John. No other applications were running, and one thing to add to my previous post is that if I tell GeoFrameworks to use COM4, then it works fine (at a variety of baud rates).

More interesting is that we got a firmware update from Pharos for the 535 (due to other serious issues with the device) and after updating from 1.04 to 1.06 the auto-detection and whole sample app works great. So, I'm thinking it was a bug in their code, and not yours.

Thursday, September 04, 2008 at 2:37:12 PM by Jon Person

Ahh, okay, that's good to hear, especially regarding Pharos, which is my favorite manufacturer! I really appreciate the update.

Issue #131 (Behavior Is By Design): Problems Connecting to a Garmin USB GPS Device

Thu, 04 Sep 2008 14:36:00 GMT

Thursday, August 21, 2008 at 11:37:51 AM by

I am developing an application with geoframeworks.  I used to have a
Garmin bluetooth product that worked well, but I needed something with
faster update rates.  So I purchased the QStarz GPS, which updates
data at up to 5Hz and can connect to the computer with bluetooth or
USB.  My program still works if I use the bluetooth feature, but I
want to use the USB feature instead (works better when I switch to
5Hz), and it isn't working.  If I use the monitoring program that the
GPS brought, it works well, so I know that the device USB drivers are
working.  The GPS uses the NMEA 0183 (v.3.01) protocol and a baud rate
of 115,200.  I have verified in the device manager that the COM port
is correctly set.

I downloaded the trial version of the latest Geoframeworks, and when I
run the example program, it also cannot connect to my device when I
use the USB feature.  Now I'm out of ideas.  Can you suggest what to
try next?

Thanks in advance.

Thursday, September 04, 2008 at 2:36:00 PM by Jon Person

Hello, we've been phasing out Garmin USB support after numerous failed attempts to get new product information from Garmin regarding their Phase Output protocol. However, if you stick with NMEA and serial-based connections, we can use GPS.NET without having to use the Garmin plug-in at all. The best thing we can do here is to look into the USB-to-serial driver for your QStarz GPS. Let's see if we can locate good USB-to-serial drivers for the device. Once we get it accessible via a COM: port, GPS.NET can pick it up.

Issue #105 (Behavior Is By Design): Connection to GPS dropping out

Thu, 04 Sep 2008 14:33:55 GMT

Tuesday, July 15, 2008 at 3:42:43 PM by Gary Flux

Application written in C# .net CE 2.0 (VS 2005)

We have developed an application that uses GPS.NET 2.0, Geoframework.PockectPC.dll (version 1.4.3600.6) and GeoFramework.Gps.PocketOC.dll (version 2.3.3600.19). The application is now running on Windows Mobile 6.0 PDA's and has issues retaining or accessing the GPS data, while other apps such as OzyExplorer receive the data OK. Is there an upgrade for Mobile 6 pda's, or any upgrades to the dll's I need to apply?

The version of GeoFramework.dll in the Desktop Framework 2.0 directory is also 1.4.3600.6 not 1.4.7 as stated in the selection list above.

Also I raised an issue re my master form controls not showing on child forms when GeoFramework controls applied. I have never had an upgrade and the solution recommended did not work. This issued was closed as Expected Behaviour.

Tuesday, July 15, 2008 at 6:01:08 PM by Gary Flux

I have just downloaded the update on your site and am now running GeoFramework.PocketPC.dll (version 1.4.3600.7) and GeoframeworkGps.PocketPC.dll (version 2.3.3600.20) (GeoFramework.dll is 1.4.3600.7) .. are these the most up to date versions? Tried the solution to get the master form controls to show on the child forms, but this still has not been resolved.

Wednesday, July 16, 2008 at 1:53:28 PM by Gary Flux

Jon,
We have found that the connections are working much better now we are are using the new updated dll's (as mentioned above). I was reading through other issues that have been posted, and have increase the ThreadPriority, which has also increased the response. I think the users having other apps also retrieving GPS data was causing some of the problems we were experiencing.

Could you please confirm we are now using the most up to date dll's (outlined previously). If so, the only outstanding issue now is how to get the master form controls to show on the child forms when GIS.Net controls are being used on the master form (n.b. I am not talking about just the GIS.Net controls not showing, I mean any .net control, buttons, menu items, graphics, etc.) When the GIS.Net controls are removed from the master form, all the other controls then show on the child forms.

Thursday, September 04, 2008 at 2:33:55 PM by Jon Person

Hi Gary, yes 2.3.20 is the latest version of GPS.NET 2.0 and may be one of the last releases before GPS 3.0 is released. I've identified a bunch of performance issues which can be addressed with both the GPS interpreter and the rendering of DoubleBufferedControl, but it will require some significant rearchitecture in the code. Specifically, there are optimizations being implemented into GIS.NET 3.0 which can benefit GPS.NET 3 once it's out.

Unfortunately, we've exhausted the performance ideas I can come up with: increasing ThreadPriority, painting on separate threads, avoiding modal forms. Since the CF is so slow you can actually watch a TextBox draw, it's a big challenge to get responsive graphics. But, this is a high priority here and I expect to see a vast improvement over performnce when some R&D completes here.

Issue #97 (Cannot Reproduce): Issue on Retrieving GPS coordinates using GPS.NET 2.0

Tue, 22 Jul 2008 15:10:59 GMT

Thursday, July 10, 2008 at 12:02:04 AM by

Hi,
I am soma sekhar, working as senior software engineer at iConcept software services, hyderabad , india. We bought gps.net 2.0 from geoframeworks . we are using geoframeworks.pocketpc and geoframeworks.gps.pocketpc dll's in Visual studio .NET 2005 for capturing the GPS co-ordinates from GPS enabled PDA(HP ipaq 6965).It is working fine, it is taking around 10 to 15 seconds to sink with the satelites and give the coordinates. This PDA windows version is 5.0.

1) The issues which we are facing are, now we had migrated from HP ipaq 6965(Windows mobile 5.0 version) to HP ipaq 612(Windows Mobile 6.0 version). we are facing a problem in retrieving the coordinates , with the same logic what we had used in the old PDA.

The following is the piece of code which we are using to get the coordinates

NmeaInterpreter inter = NmeaInterpreter.FromSerialDevice(GeoFramework.IO.Serial.CommunicationPort.Com6, GeoFramework.IO.Serial.BaudRate.Baud115200);

inter.Start();

GeoFramework.Position pos = inter.Position;

string lat = pos.Latitude.ToString();
string lon = pos.Longitude.ToString();

inter.Stop();

It is taking around 5 to 10 minutes for getting the cordinates in HP ipaq 612 model.

2) Can u help me out with any better way of recieving the coordinates.
3) Does GPS.net 2.0 work well with windows mobile 6.0 version PDA's
4) Is there any latest version of this framework .

The main purpose of our application to recieve the coordinates, so please kindly help me out with this issue.

Soma sekhar Jalli
somu@conceptglobal.com
iConcept software services Pvt Ltd
Hyderabad
+919392929009
+919866097598
+914039122607

Friday, July 11, 2008 at 3:32:00 AM by

Hi,
I want to say another thing also, the HP ipaq 6965 model which i am using contains GPS reciever, where as hp ipaq 612 has an AGPS reciever.

Tuesday, July 22, 2008 at 3:10:59 PM by Jon Person

Hmm, a fix time of 10-15 seconds is not all that unusual for some GPS devices.  Some models, however, such as TomTom 's devices, are able to get consistent, almost suspiciously good fixes 10 feet from a window in under two seconds.

Regarding your code, everything looks healthy to me.  Perhaps you can email me a log file with some NMEA data? This will help me to look for any data errors and to determine the precision environment you're working in.  I can be reached directly at jperson@geoframeworks.com.

Latest versions of the framework are *always* found on our download page (http://www.geoframeworks.com/DownloadProducts.aspx).  There is also an RSS feed which updates whenever we post a new build.  With these feeds, you can be notified precisely when an update occurs, and use the Product Change Log RSS feed to determine whether the build is worth updating to.

Issue #109 (Cannot Reproduce): Exeception on GPS.NET 2.3.5000.18 on WM6.0 device

Thu, 04 Sep 2008 14:08:27 GMT

Thursday, July 17, 2008 at 5:30:00 PM by Gareth Oliver

Hi Support/Jon,

The background:
Customer is running WM5.0 devices, but needs to upgrade to WM6.0 due to manufacturer "end-of-life". Will be rolling out WM6.0 devices early 2009. My task is to investigate the impact to the mobile application on the new WM6.0 device.

My environment:
- Windows Mobile 6.0 PDA (HP iPAQ 212)
- MS Visual Studio 2003; application built in VB.NET
- GPS.NET for CF 1.0 (PPC) v2.3.5000.18
- I have installed CF 1.0sp3 onto the PDA
- The GPS receiver is an external CF unit, Haicom HI-303III

(My application uses some of the code provided in the example applications, as the application has very basic GPS receiving requirements)
www.
My constraints/limitations:
- The application cannot be upgraded to CF2.0, and therefore VS2005 (although this can be one of the recommendations if required)

My issue:
When testing the application through VS2003 in debug mode, I get the following error:

[An unhandled exception of type 'System.IndexOutOfRangeException' occurred in GeoFramework.Gps.PocketPC.dll]

This occurs when at line:

52: Private WithEvents Interpreter As New NmeaInterpreter

I've copied/attached the complete page of code.

Other tests I've tried:
- this application has been developed for, and successfully runs on, Windows Mobile 5.0 devices (Dell Axim x51v), using the same code/versions
- I installed CF1.0sp3 onto the WM6.0 device, with the same error
- I installed CF3.5 onto the WM6.0 device, with the same error

Regards,
Gareth

Wednesday, August 13, 2008 at 6:49:27 PM by Jon Person

Hi Gareth, is there some additional stack trace information available for this exception? I've looked at the source code to locate possible errors but it'd be easier to be able to look into specific methods.

Thursday, September 04, 2008 at 2:08:27 PM by Jon Person

Hi Gareth, I'll send you an email asking for a stack trace. Once we can get it it should be trivial for me to track this bug down.

Issue #145 (Behavior Is By Design): Interpreter.UtcDateTime returns an incorrect date/time

Thu, 04 Sep 2008 14:06:43 GMT

Thursday, September 04, 2008 at 6:22:52 AM by David Hanley

I have noticed that, on some occassions, a call to the Interpreter.UtcDateTime returns the following (the time varies but the date is the same):

Interpreter.UtcDateTime.ToString("dd MMM yyyy HH:mm:ss");
01 Jan 0001 13:11:07

The time is correct but the date is wrong.

This seems to occur when the first Interpreter_PositionReceived event is fired after a fix is obtained. The issue then resolves itself on subsequent Interpreter_PositionReceived events.

Any information on this would be appreciated.

Many thanks
David Hanley.

Thursday, September 04, 2008 at 2:06:43 PM by Jon Person

Hi David. GPS devices frequently start their clock at some arbitrary date such as January 1st from the time it is activated to the time a GPS satellite fix is acquired. Since GPS devices have no clock to rely on, their time will be incorrect until a fix is found. GPS.NET is caught in the middle of this behavior because during this time neither the local computer's date nor the satellite-derived date can be relied upon as accurate. So, this behavior is tough to work around. What I typically advise developers to do is check the IsFixed property to determine whether to trust UTC date/time values at all. This is also the approach used when IsClockSynchronizationEnabled is true; the local machine's clock is updated only when this property returns true.

Issue #142 (Cannot Reproduce): Error in points GIS 3.O Example

Tue, 02 Sep 2008 08:40:54 GMT

Monday, September 01, 2008 at 8:19:55 PM by

I was looking at adding markers form. Labelled markers did not show text initially as set to townSyle. Changed to CityStyle and then OK.
Unmarked Labels didnt show initially. Changed style to OutlineFilled Style and then they show.

Tuesday, September 02, 2008 at 6:48:15 AM by Jon Person

Hmm, can you tell me which version of Visual Studio you're using? I remember this sample was working, but I'm happy to check it again.

Tuesday, September 02, 2008 at 8:40:54 AM by Jon Person

The labeled markers are showing up just fine for me. Perhaps you could email us a screen shot of how it appears on your system? You can send the screen shot to jperson@geoframeworks.com.

Issue #144 (Released): MissingMethodException in Enum.ToObject

Tue, 02 Sep 2008 08:27:01 GMT

Tuesday, September 02, 2008 at 8:25:59 AM by Jon Person

On Compact Framework 1.0 applications, a MissingMethodException occurs in the GeoFramework.Gps assembly during a call to Enum.ToObject

Tuesday, September 02, 2008 at 8:27:01 AM by Jon Person

This is a strange exception, and is suggests that the version of mscorlib which we compile against somehow is missing Enum.ToObject(). With no further information to go on, our only recourse is to eliminate all calls to Enum.ToObject in the CF1 build of the assembly. This is now being built.

This error only occurs on CF1 applications.

Issue #143 (Released): Allow Rotation for Small Images on the Compact Framework

Tue, 02 Sep 2008 06:57:21 GMT

Tuesday, September 02, 2008 at 6:55:17 AM by Jon Person

By default, setting the Rotation property of a GIS3 Map control is not allowed. However, more advanced developers have suggested that rotation still be allowed in the case of smaller imagery. As a result, a property should be added to the map control for developers who understand the risk and will only rotate small images.

Tuesday, September 02, 2008 at 6:57:21 AM by Jon Person

A property called "AllowRotation" has been added to Compact Framework projects. This property is False by default to dissuade developers from attempting to rotate imagery without understanding the risks. For advanced developers who know they are only working with icon-sized imagery, this property can be set to True.

This property should never be set to True when working with larger imagery, because it will dramatically increase the time required to paint a map.

Issue #134 (Released): TileSet for large screen give OOM exceptions on Compact Framework

Fri, 29 Aug 2008 20:24:52 GMT

Monday, August 25, 2008 at 10:57:18 PM by Olle Pettersson

This issue relates to the other one I posted about TileSets that stop rendering in GIS.NET for CF

When they do render at higher resolutions we get OutOfMemoryExceptios pretty consistently.

If we reduce the size of the map to 240x320 pixels, we are ok (no OOM exceptions). The TileSet seems to use a lot of memory at higher resolutions.

Will this be addressed in the update to TileSets coming soon?

As a side note, our device has 256MB of RAM. However. it runs WinCE 5.0 which gives a running process an address space of only 32MB. But I think the CLR uses some tricks to get around this limit when allocating large objects (like bitmaps).

Friday, August 29, 2008 at 11:36:21 AM by Jon Person

We're currently refactoring the way bitmaps are rendered on the CF because Microsoft's managed solution is quite inefficient. Phil is now researching ways to bypass Graphics.DrawImage() entirely, and we hope to have this built in at a low level to developers automatically take advantage of optimizations, including when inheriting from the Picture or Tile class.

Friday, August 29, 2008 at 12:03:06 PM by Jon Person

A couple of memory leaks were resolved for Tileset.OnPaint() today, but they only affect generation of new tiles. I believe we'll need to tweak the default maximum # of tiles allowed in memory to a lwoer value.

Friday, August 29, 2008 at 4:30:26 PM by Jon Person

Memory management for Tilesets has been significantly improved for both desktops and mobile devices. Reclamation of memory is now a lot more agressive, disposing of tiles if the MaximumTilesInMemory limit has been reached. The maximum has been decreased down to about 16 for the compact framework to reduce OOM's.

This fix was done in the same branch as the new Asynchronous Tileset functionality, which is still being tested. But, tests so far are good and we hope to get this released within a few days.

Friday, August 29, 2008 at 8:24:52 PM by Jon Person

Olle, a build is being published now with *some* improvements which I believe will help you. Phil's still working on the low-level stuff but let's give this a try. Tileset had many performance tweaks today.

Issue #139 (Released): Tilesets are Now Asynchronous

Fri, 29 Aug 2008 16:36:25 GMT

Friday, August 29, 2008 at 4:36:25 PM by Jon Person

The Tileset class has been refactored to perform all, saving, loading, and generation of tiles on a separate thread.  This produces a behavior similar to Google Maps, where panning operations cause blank areas to appear for about a half second while tiles are retrieved from disk.  This new system is much more performant.  Additionally, generation of brand new tiles on desktop computers takes place on a separate thread.  This allows for panning and zooming operations which remain responsive.

Lastly, some changes were made to the Tileset class to make it easier to use with additional data sources:

1. A "GetZoomLevel(RectangleF)" method has been added which will return the most appropriate zoom level to display the specified projected rectangle of data.
2. A "GetTileCoordinates(ZoomLevel, RectangleF)" method has been added which returns a rectangle, in tile coordinates, of tiles which cover the specified projected area.  Developers could use this method to, for example, manually figure out which tiles to load from a data source.
3. The new "Generate" method will request that a single tile be created for a zoom level and tile x/y coordinate.  When called from within a loop, this method can be used to systematically generate an entire tileset.
4. The "RetrieveTile" "SaveTile" and "TileExists" methods were added to help developers manage tiles using foreign data sources, such as remote web sites.  Developers can now inherit from Tileset and override these methods to retrieve tiles from a custom data source.

... some testing remains but this issue will be marked as Fixed once testing has completed for all platforms.

Issue #140 (Released): MouseEnter/MouseLeve Events not Firing on Desktop

Fri, 29 Aug 2008 17:36:44 GMT

Friday, August 29, 2008 at 5:36:23 PM by Jon Person

An issue was discovered in a recent build to where the MouseEnter and MouseLeave events were not firing on the desktop. This was caused by a recent improvement made to add support for "Deploy to My Computer" modes for GIS.NET. If you don't know what DTMC is, it's a way to debug PocketPC apps on your desktop and it saves a LOT of time. You can hack VS to support it with these steps:

INSTRUCTIONS
1. In Visual Studio select Tools/Options, and then select Device Tools/Devices from the tree.
2. In the top combo box, select the platform that you want to add desktop deployment to. You’ll need to do this for each platform you want to use.
3. Select one of the devices, (it doesn’t matter which one) and click the Save As… button. Save as “My Computer”. If you’ve already done this for a platform, you’ll need to save subsequent devices with slightly different names (like “My Computer2”)
4. Close VS and open your %USERPROFILE%\Local Settings\Application Data\Microsoft\CoreCon\1.0\conman_ds_platform.xsl file in a text editor.
5. Find the <DEVICE …> element corresponding to the device you created and add the node (i.e. search for “My Computer” to find the correct node.)
<PROPERTY ID="IsDesktopDevice" Name="IsDesktopDevice">true</PROPERTY>
Place it right after the first <PROPERTYCONTAINER> tag.
6. Save conman_ds_platform.xsl and restart VS.

Friday, August 29, 2008 at 5:36:44 PM by Jon Person

MouseEnter/MouseLeave now fire properly. I rolled back the DTMC code and will revisit it later.

Issue #114 (Behavior Is By Design): No Nmea data received on Trimble GeoXM

Fri, 29 Aug 2008 16:37:47 GMT

Wednesday, July 30, 2008 at 10:34:09 AM by Matthew Fraser

I ran your sample application and it worked beautifully to detect my NMEA port on the Trimble GeoXM. However, I never get any positional data even thought satellites are detected etc.. If I leave your test app running and I launch the Software that ships with the Trimble and hit connect GPS everything start working fine in the test application. It's almost like the receiver doesn't get fully started. I get satellite info but the GGA sentence is always blank. Please help.

Wednesday, August 13, 2008 at 6:21:58 PM by Jon Person

We've continued this particular discussion via email instead of the Issue Tracker. But apparently the GeoXT won't communicate data unless it's own software is running. We're currently waiting on Trimble to explain if their device needs special commands to start transmitting data, or of the device can be configured to work with 3rd-party GPS software more readily.

Thursday, August 21, 2008 at 3:56:41 PM by Jon Person

Another customer reported this same problem, and we're learning more about this series of devices. Namely, that there is a configuration program which can hel pyou control which port is set to transmit NMEA data. It looks like the GeoXM can transmit NMEA data but only via a Bluetooth connection, typically COM7:. All of these devices ship with a "GPS Connector" utility:

1) Tap the Windows start button
2) Tap Settings
3) Tap Connections
4) Tap "GPS Connector"
5) Configure the port for NMEA output.

Thursday, August 21, 2008 at 3:58:43 PM by Jon Person

Information on the GPS COnnector can be found in the product spec PDF, found online here: http://trl.trimble.com/docushare/dsweb/Get/Document-360484/GeoExpl2005_110A_GSG.pdf. Thanks very much to Scott E. for sharing this information!

Thursday, August 28, 2008 at 10:16:37 AM by Jon Person

It may also be necessary to configure the GPS Intermediate Driver (GPSID) to use the NMEA port specified by the GPS Connector. One customer has reported successful connectivity once they assigned the correct port to the GPSID settings.

Friday, August 29, 2008 at 4:37:47 PM by Jon Person

Customers report success when following these steps using COM2:, the NMEA-compliant port.

Issue #132 (Behavior Is By Design): Latitude/Longitude Seem Inaccurate by Ten Miles

Fri, 29 Aug 2008 11:38:21 GMT

Friday, August 22, 2008 at 12:38:12 AM by

Hi,

I have created a simple tracking appication for PPC, however the GPS position information I out by around 10miles.

Can you tell me how i can ensure that the pos data is accurate as this application is being used to track vehicles.

Code below..

  Try
            If blnGPSStarted = False Then
                StartInt(gpsDevice)
            End If
            pos = interpreter.Position
            speed = interpreter.Speed
            direction = interpreter.Bearing
            'update position properties
            mlon = Latitude.ToDecimalDegrees(pos.Latitude.Hours, pos.Latitude.Minutes, pos.Latitude.Seconds)
            mlat = Longitude.ToDecimalDegrees(pos.Longitude.Hours, pos.Longitude.Minutes, pos.Longitude.Seconds)
            mspeed = speed.ToStatuteMilesPerHour
            mdrirection = direction.ToString
            mposdatetime = DateTime.Now.ToString
            If mlon > "" Then
                blnPostionValid = True
            End If
            Try
                If mlon = 0 Then
                    DetectGPS()
                End If
            Catch ex As Exception

            End Try
        Catch ex As Exception

        End Try

Regards

John

Friday, August 29, 2008 at 11:34:04 AM by Jon Person

This is currently being researched via email. I'll post an update here once a solution is found.

Friday, August 29, 2008 at 11:38:21 AM by Jon Person

One thing we can do is use the DecimalDegrees property instead of calling ToDecimalDegrees, like this:

Issue #137 (Behavior Is By Design): Exception: System.GC.Collect(Int32, System.GCCollectionMode)

Fri, 29 Aug 2008 11:32:36 GMT

Thursday, August 28, 2008 at 8:21:25 AM by

I try adding the key to the sample file and i still get an error.

Method dont found: 'Void System.GC.Collect(Int32, System.GCCollectionMode)'.

Friday, August 29, 2008 at 11:32:36 AM by Jon Person

This error is caused on systems which are running Visual Studio 2005 without Service Pack 1 installed. SP1 introduced some new GC features such as specifying GCCollectionMode, along with GCLatencyMode. You can upgrade to 2005SP1 from this URL, which will resolve the issue: http://www.microsoft.com/downloads/details.aspx?familyid=bb4a75ab-e2d4-4c96-b39d-37baf6b5b1dc&displaylang=en

Issue #125 (Released): Markers Render Slow on Compact Framework

Sun, 17 Aug 2008 15:52:04 GMT

Monday, August 11, 2008 at 2:29:09 AM by Olle Pettersson

We have encountered some problem when rendering markers on maps in GIS.NET 3.0 for Compact Framework. The problem is that it takes very long for markers to render them self on screen.

For instance, we load traffic lights that are points in a shapefile and style them using the ScaledImageStyle.

When the traffic light shapefile loads the constructor in our extended LabeldMarker class get called and we pass a a ScaledImageStyle for the maker:

public ZCTTrafficLight(Projection proj, Position pos)
: base(proj, _IconStyle, pos, _SignalSize) { }

_IconStyle is defined with a static size to prevent any scaling of the image:

private static ScaledImageStyle _IconStyle =
new ScaledImageStyle(ShobunshaIcons.signal, ShobunshaIcons.signal.Size);

The icons show up on the map but the map renders significantly slower when we add image icons to it. we load around 15 points in total, only around 5 are on screen at any one time.

We had the same experience when using normal markers too (circles with text), without any ScaledImageStyle. we used it for our POIs, we loaded close to 100 data points, with around 20 being in view on the screen at once.

To get around this problem las time we created a custom object that renders itself on screen using Graphics and pixel coordinates given by the GraphicsContext. that speed up rendering.

Now, I can use that same technique to render 20+ unscaled images at geological coordinates without any significant slowdown in rendering. how come that Markers render so slow? we would prefer to use the built in types rather than creating our own solution for this.

Monday, August 11, 2008 at 5:58:36 PM by Jon Person

Hi Olle, one thing that would really help performance and memory use is to use a *single* ScaledImageStype object and share that with many different Is this what you're doing currently?

Sunday, August 17, 2008 at 2:26:12 PM by Phil Smith

I'm still investigating the ScaledImageStyle. Not sure where the hang up there is. The generic Marker style would benifit from using the DrawEllipse function directly on the Graphics rather than calculating the curves on the fly. A performance issue with Marke extent calculation has been fixed, but will affect loading times only, not drawing at this time. More to come!

Sunday, August 17, 2008 at 3:52:04 PM by Phil Smith

Tthe regular marker problem is fixed now after using DrawEllipse internally instead of calculating the arcs on the fly.

Issue #121 (Released): Error on ProjectedBearingAt

Sun, 17 Aug 2008 11:30:16 GMT

Friday, August 08, 2008 at 10:40:34 AM by Ted Macy

I have a line with two positions.   I have exected these two lines of code:

    Azimuth bearing = _baseLine.BearingAt(0);
    Azimuth projectedBearing = _baseLine.ProjectedBearingAt(0);

The first line succeeds and is correct.   The second line fails with this error:

System.ArgumentOutOfRangeException was unhandled
  Message="The end index for the bearing of a line segment can only be calculated from the first point to the next-to-last point.\r\nParameter name: index"
  Source="GeoFramework.Drawing"
  ParamName="index"
  StackTrace:
       at GeoFramework.Shapes.GeographicList.ProjectedBearingAt(Int32 startIndex, Int32 endIndex)
       at GeoFramework.Shapes.GeographicList.ProjectedBearingAt(Int32 index)
       at MapShots.PocketSampler.Controls.mpnGridLayer.SnapGrid()

Thanks.

Wednesday, August 13, 2008 at 6:23:24 PM by Jon Person

This exception would be valid if the line contained 1 or less points, since 2 points are required to calculate a bearing. How many points were in the line?

Friday, August 15, 2008 at 11:30:52 AM by Ted Macy

As noted on the first line of my post :) My line has two positions. If I ask for line.Count, the response is 2.

Sunday, August 17, 2008 at 11:27:54 AM by Jon Person

hah sure enough. Alright, I'll have a closer look at that today.

Sunday, August 17, 2008 at 11:30:16 AM by Jon Person

The bounds-checking for ProjectedBearingAt was off by one. This is now resolved.

Issue #130 (Released): MovableItem updates not showing after a refresh.

Fri, 15 Aug 2008 13:55:55 GMT

Friday, August 15, 2008 at 1:45:00 PM by Phil Smith

Movable Items on a map aren't getting updated after the item "moves" or has data added to it.

Friday, August 15, 2008 at 1:47:35 PM by Phil Smith

Item extents we're not being recalculated causing them to be drawn in their original position. The data in objects was indeed changing and the refresh chain was getting all the way to the paint thread. But without the updated extents, objects were not being painted in ther original positions.

Friday, August 15, 2008 at 1:55:55 PM by Ted Macy

This is very good news. Thank you for digging into this one so quickly.

Issue #129 (Released): Map control not appearing in the toolbox

Thu, 14 Aug 2008 10:32:05 GMT

Thursday, August 14, 2008 at 10:31:48 AM by Jon Person

I am jealous of all of you :) because you don't need to experience the shocking quagmire that is Visual Studio Toolbox Integration. A bug was found this morning in the GIS.NET 3.0 installer where the Toolbox utility was not installing the Map control properly into VS2005 PocketPC projects, or any VS2008 project.

Thursday, August 14, 2008 at 10:32:05 AM by Jon Person

The installer issue has been resolved and is now being updated.

Issue #113 (Behavior Is By Design): GPS.NET Garmin Plug-In cannot detect 60CSX

Wed, 13 Aug 2008 18:20:25 GMT

Monday, July 28, 2008 at 12:11:10 PM by

I am attempting to use GPS.NET within Visual Studio 2005 to read data from a Garmin GPSmap 60Cx through a USB connection.

I have successfully installed the drivers from Garmin, and I can read the unit ID from the Garmin Trip & Waypoint Manager software, as well as from the command-line executable from the SDK that Garmin provides.

Using GPS.NET, however, it will not even detect the presence of a device. I have tried using Devices.Detect() and Devices.GetDeviceByProtocol(NmeaInterpreter.ProtocolName) as specified in the sample application, each without success.

I have also tried on two different computers, one running Windows XP SP2, and Windows XP Tablet PC Edition, again, without success.

We have purchased a license for both GPS.NET and the Garmin Protocols Plug-In.

Any assistance you can provide will be most appreciated.

Thank you.

Wednesday, August 13, 2008 at 6:20:25 PM by Jon Person

Unfortunately, we've dropped our Garmin plug-in due to a failure to maintain the product (measure sales against the amount of work required to maintain it).  Specifically, Garmin refuses to adopt what programmers refer to as a "standard" and they keep changing their protocol every 1-3 months.  As a result, anyone who decided to support Garmin's Phase Output protocol is committing to mandatory re-releases to support new devices.  On top of that, Garmin will not reveal the specific changes to their protocol until about one year after the device is released.

To avoid an onslaught of technical support both for us and for our customers, we've dropped Garmin until they do adopt a standard.  Developers are strongly encouraged to stick with the NMEA protocol in order to ensure connectivity.

Some Garmin devices do support both Garmin Phase Output along with NMEA.  This is the best alternative I can recommend for you right now.  If perhaps we can establish an inside-track to Garmin we might be able to stay on top of updates.  Right now it's not cost-effective.