Monday, August 16, 2010

Israel's Critial Security Needs for a Viable Peace

Well, before Israel withdrew from the Gaza strip, I was not opposed to the withdrawal. It was IMO, worth the risk. Evidently, not only did it not work, it backfired... Who is to say that the Palestinian regime, a regime that is barely hanging in by its fingernails, will not fall and be replaced by Hamas/Jihad/Al-Qaida, just as it did in the Gaza strip? And this time, Israel cannot take many risks. Here is why:

Sunday, August 15, 2010

Garmin 62s track sampling most often vs 1 yard

First let me say that although these tracks were taken using the 62s, I believe that the sampling would be quite similar in the 60csx, Oregon, Dakota and Colorado as they have the same track sampling options and use the same or a very similar algorithm for that purpose.


The cyan track is set at the most often sampling rate, in auto mode. The red track is set on 1 yard, distance. These were made during a K9 training, searching for divers under water. Each pass was for a different dog. THe difference is obvious, you want precision in the track, chose the sampling rate by distance, 1 yard.

I certainly cannot see the boat, a very nice FD inflatable boar, making an angular pass like in the cyan track. Below are two screen dumps directly from the 62s:


















Now I also checked elevation profiles, as elevation was one point that was fixed in the latest beta and on the water, the elevation should be quite the same. Unfortunately, I did not set my GPS to barometric altitude, so that point was not checked. Yet look at the differences:











The cyan track (most often sampling) is on the left, the red track, 1 yard sampling is on the right. The water was not flat, just little waves, no white caps, wind about 5-10mph.

I will stay with my setting for track, 5 yards sampling on land, 1 yard on the water.

Thursday, August 12, 2010

Funny and cute: Tagging black bears in Algonquin Park, Canada

Altitude reporting on the Garmin GPSMAP 62s

As usual, click on the picture to see a larger version thereof. At first glance, the elevation graph seems to confirm that pressing a button on the 62s causes altitude spikes to be registered. Well, first, this is untouched data, as displayed by TopoFusionPro. At the start, I know I did set the tracking to be on, so I did press buttons and there is a slight, 10ft, loss of altitude whereas I'm in the parking lot. I don't know what caused the next two humps and depression between them but I did touch buttons around the 1.0 mark and the change there is not spectacular. I can't find a reason for any other spikes but the last one, when I was saving my track. 20 ft difference or so, I just eyeballed it, did not look at the actual track elevation numbers.

Do I want Garmin to look into it, perhaps fix it? Of course. But does it really matter to me for Search and Rescue purposes? Frankly, without others talking about it, I would not have noticed it, as I rarely even look at altitude. I rarely, if ever reset the barometer as altitude is of little consequence to me. My legs are good at telling me whether I'm going up or down and I can read the map (on the GPS or on paper).

The GPS graph shows altitudes between 320 to 370 ft, quite acceptable for my use.

Google Translate!

As a linguist, I find this amazing. An innovative idea, what else would you expect from Google, and mega computer power making it work. And while the results are not perfect and human touch is often needed, by now, I'd say any translation I would do, will certainly begin on a Google Translate base, then add the human touch to make it better.