Any latitude outside +/- 90 degrees is obviously suspect.

I understand that and I'm looking for a solution for it.

I'll try to break it down even better.

As I mentioned, I made a function that generates the Lat, Lon position for the weather in OWM.

It seems strange to me when I run the simulator for my project that I get via

I would need the location when starting the App to be:

null, null,

only when I start an activity in the SIM, I get the current Lat, Lon position and everything works correctly.

What I want to do is that if the Lat and Lon position is for example 180.0000, then let me see the alert "GPS?" on the watch display.

This doesn't work for me, or if it is possible to fix my function so that the Lat, Lon location is null when running in the Sim, that would also be a good solution for me and I can move on. So far I'm stuck and I don't know how to correctly tell the function that the location value Lat, Lon = 180.000000 is wrong...

My function to get position for weather:

module LocationOWM {
	
(:background)
function CurrentLocation() 
{
     var positionInfo = Position.getInfo().position;
     var quality = Position.getInfo().accuracy;
     
     if (positionInfo == null) 
     {
     
     var activityInfo = Activity.getActivityInfo();

      if (activityInfo != null) 
      {
      
      positionInfo = activityInfo.currentLocation;
      quality = activityInfo.currentLocationAccuracy;
      }
    }

     if (positionInfo != null && quality > Position.QUALITY_NOT_AVAILABLE) 
     {

     var lat  = positionInfo.toDegrees()[0];
     var lon = positionInfo.toDegrees()[1];
     Application.Storage.setValue("Lon",lon);
     Application.Storage.setValue("Lat",lat); 
      
      
      System.println("location " + lat + ", " + lon + " quality : " + quality);
    }
   }
  }

The feature I'm trying to say is that the Lat, Lon position is incorrect for the weather and the user needs to run an activity on the watch:

if ($.LocationOWM.CurrentLocation() == null)
{
dc.setColor(Graphics.COLOR_RED, Graphics.COLOR_TRANSPARENT);
dc.drawText(x_pos, y_pos, Graphics.FONT_XTINY, "GPS?", Graphics.TEXT_JUSTIFY_CENTER);
return;
}

hi,

in your function CurrentLocation at line 25:

var lat = positionInfo.toDegrees()[0];
var lon = positionInfo.toDegrees()[1];

if ((lat==180.0000&&lat=180.0000)||(lat==0.0000&&lat=0.0000)){return null;}

check also for 0 lat lon since on many real device, in case of indoor activity, 0,0 can be returned.

forums.garmin.com/.../currentlocation-returns-bad-value

Thanks, I'll try it. I didn't know this was already addressed on the Garmin forum. I'll leave my post unchanged, including the code, hopefully it will help someone too.

One thing to note, is quality/accuracy works differently in the sim than on a real device.  In the sim, it's a setting (Set GPS Quality).  On a real device, quality/accuracy changes based on the GPS signal.

I first ran into this about 8 years back when a friend sent me the fit file from an Ultra he did.  About 2 hours in, turns out the course went through a tunnel for a few minutes and GPS was lost.

When I played back the fit in the sim, and since quality/accuracy didn't change at the point GPS was lost, I had him leaving the course and jumping way north of the north pole, only to return to the course a few minutes later.  In addition to quality/accuracy, I added a check for valid lat/lon.  Like I said, this only happens in the sim, but can happens when playing back any fit file where there is a GPS drop out

Lat >90 or <-90, lon>180 or <-180 if I recall.

Actually, here's the actual code:

					var latLon = actInfo.currentLocation.toDegrees();
					//this is for bad data in the sim
					if(latLon[0]<=90 && latLon[0]>=-90 && latLon[1]!=180 && latLon[1]!=-180) {

var locPos = Position.getInfo();
var locAcc = locPos.accuracy;
locPos = locPos.position.toRadians() as Array<Double>;
var locLat = locPos[0] as Double;
var locLong = locPos[1] as Double;

if (locAcc > 0 && !(locLat == 0.0d && locLong == 0.0d) && locLat < 1.5708d && locLong < 3.14159d) {

Because the trig functions take radians (if you want to calculate distance, sunrise/sunset, etc), you can save yourself some code space and execution time and work in radians. This checks for the real but unlikely case where you are exactly at the intersection of the prime meridian and the equator, and the other impossible case where you are beyond the poles. Also, some people will say to make sure that getInfo doesn't return any null parts, I haven't seen that on a real device. What I can say is that on a Fenix 7x even when the GPS is off you will still be getting a location from your phone, but the location accuracy will be 1, last known. I don't know what other watches exhibit this behavior.