Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

end of Grib is dispayed as "Land Error" #246

Open
dominig opened this issue May 9, 2019 · 6 comments
Open

end of Grib is dispayed as "Land Error" #246

dominig opened this issue May 9, 2019 · 6 comments

Comments

@dominig
Copy link

dominig commented May 9, 2019

If the grib duration does not cover the tme required for the route, the error message is "land error" while is should be something like "no more data in Grib" or "Grib duration too short"

@rgleason
Copy link
Contributor

rgleason commented May 9, 2019

How about "Grib duration too short, turn on Climatology"?

@dominig
Copy link
Author

dominig commented May 9, 2019

If you active climatology it keeps going until the end, but climatology data in Biscay Bay or in the English Channel is of no real value, so I always turn it off.
A clean error message is useful. Arpege GRIBS provides better data than GFS in those areas but are limited to 3 days, what can not always cover all routes options.

@rgleason
Copy link
Contributor

rgleason commented May 9, 2019

Ok, so perhaps "Grib duration too short"

Or if the error happens to be from the beginning, where Grib time range does not match route start.

Trying to generalize , "Grib time is out of range of route start or finish" ?
I wonder if this can be tested without going through all the calcs, probably not.

It gets complicated when climatology is run at the beginning and then the grib starts.
There are many conditions.

Also related to #193
UI Signal (triangle) on Optimal Route when grib data runs out. #193

@rgleason
Copy link
Contributor

rgleason commented May 9, 2019

Weather_routing.cpp Line 1903 and afterwards

else
  if(routemapoverlay->Running())
      State = _("Computing...");
  else {
      if(routemapoverlay->Finished()) {
          if(routemapoverlay->ReachedDestination())
              State = _("Complete");
          else {
              State = _T("");
              if(routemapoverlay->GribFailed()) {
                  State += _("Grib");
                  State += _T(": ");
              }
              if(routemapoverlay->PolarFailed()) {
                  State += _("Polar");
                  State += _T(": ");
              }
              if(routemapoverlay->NoData()) {
                  State += _("No Data");
                  State += _T(": ");
              }
              if(routemapoverlay->LandCrossing()) {
                  State += _("Land");
                  State += _T(": ");
              }
              if(routemapoverlay->BoundaryCrossing()) {
                  State += _("Boundary");
                  State += _T(": ");
              }

              State += _("Failed");
          }
      } else {

So what is if(routemapoverlay->LandCrossing()) {

Not sure where "Land Error" comes from yet. Maybe there needs to be a new condition test in routemapoverlay.cpp?

@did-g
Copy link
Contributor

did-g commented May 17, 2019

Hi,
PR 239 should correct some bogus errors but in this case WR is probably right, it's just not intuitive and not very useful, we need to find a better way.

In your case it's likely that:

  • some tested routes fail because they cross land.
  • some tested routes fail because grib data is missing.
    If one route succeeds these errors are discarded and everything is fine, but the status has no idea if one error is more relevant than others and it reports all of them.

Not sure info is easily available for adding a UI symbol.

@rgleason
Copy link
Contributor

rgleason commented May 17, 2019

Then perhaps, there should be multiple messages for all of them? I know how in-determinant these failure reports are. We only seem to know what the problem "was" once we get it working.

Is the plugin divided into logical parts for failures?

  1. Configuration (Necessary settings are missing or incorrect, no polar, no start, no finish, outside of default max/mins)
  2. Computation (did not complete or calc is too long, etc)
  3. Climatology Data (data not found, bad data, missing data, Hit Limit: data not complete for that pos)
  4. Grib Data (data not found, bad data, missing data, Hit Limit: data not available for that pos)
  5. Polar Data (data not found, bad data, missing data, Hiit Limit: data not available for that wind angle or speed)
  6. Land Data (data not found, bad data, missing data, Hit Limit: hitting or crossing land)

Have any of these 5 failures (1,2,3,4,5.6) report at the Failure line if they are triggered?
Is there some other way to do it?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants