Jump to content
Sign in to follow this  
Followers 7
dbased

Routes not working

Recommended Posts

 

Has the "Server Error in '/' Application. Queue empty." problem been reported to the GC.com maintainers?

 

I reported it and was told the development team is looking into it.

 

Is there anyone not having this problem? I would love to send them a few routes to process for me for a vacation next week. :rolleyes:

Share this post


Link to post

I successfully uploaded a route last week and got it to work. I used the Streets and Trips method on my FAQ here: www.markwell.us/route.htm

Share this post


Link to post

MONTHS later, and this problem has started for me too. I have had routes work one week and then return 0 results the next week.

 

The MOST annoying thing is that I cannot delete then from my "Uploaded Routes", so that is just getting fuller and fuller and very difficult to navigate.

 

Apparently, they're still "working on it"

Share this post


Link to post

Not only am I getting the "Queue empty" error for some route queries, but every time I attempt one that fails that way it takes an additional slot in my 40 maximum queries with "You have reached the maximum number of Pocket Queries for this account". Editing and running a query shouldn't take a new slot. So now I'm dead in the water with 9 dead pocket query slots. There is no way to delete a corrupt query because I get the "Queue empty" error before I can get to the DELETE button. Apparently there is a bug that is triggered by something explicite in the route klm file. For one of the route pocket queries that failed, I created a new route with the same klm file that looks good in GoogleEarth and the query created from that route fails the same with the "Queue empty" error. When I go back into the bad routes I notice that it says that they have 0 route turns. I examined the klm file in GoogleEarth and re-uploaded it before creating the final query that still fails. What is peculiar though, is that a preview run of the bad pocket queries return 482 or 487 caches consistently for the routes. I don't know if they are the right caches or not.

 

The "07 Reedsport-to-Astoria.kml" route and pocket queries are the same. It appears that there is some failure in processing the klm file into the route record which leaves the route record corrupt. Then that corruption leads to a pocket query failure and a corrupted pocket query record. Also of note is that saving the edit of a failed route pocket query takes a new slot in the query table. I don't have much to look at here, but if you don't retain a copy of the klm files I can email them to you.

 

I also noticed that when I delete the offending route, it remains in my list of routes not deleted. If I had access to the code and the databases, I would look at my two identical "05 Susanville-to-Medford.kml" routes, the klm that created them, and all the duplicate copies of my pocket query records with the same names.

 

It would be nice if you could delete my several "05 Susanville-to-Medford.kml" POCKET QUERIES and the two "07 Reedsport-to-Astoria.kml" POCKET QUERIES so that I could continue with my remaining "08 Astoria-to-Olympia.kml" and "09 Olympia-to-Home.kml" routes that I haven't tried to make into pocket queries yet. I'll schedule the good route pocket queries to run and I'll reserve the other existing 20 pocket query slots for my seventh world scan for that purpose and not get them tied up with my vacation route query problems.

 

Gary

aka Nudecacher

Share this post


Link to post

The "Queue empty" failure probably is a side effect of the real original failure that isn't visible.

 

Server Error in '/' Application.

 

Queue empty.

 

Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

 

Exception Details: System.InvalidOperationException: Queue empty.

 

Source Error:

 

An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.

 

Stack Trace:

 

[invalidOperationException: Queue empty.]

System.Collections.Queue.Dequeue() +105

Groundspeak.Web.UserRoutes.UserRoutePoints.EncodeSignedNumber(Decimal num) +269

Groundspeak.Web.UserRoutes.UserRoutePoints.EncodeLatLong() +240

Geocaching.UI.URQuery.ShowQueryInfo() +713

Geocaching.UI.URQuery.Page_UserLoggedIn(Object sender, EventArgs e) +782

Geocaching.UI.WebformBase.IsLoggedIn() +1307

Geocaching.UI.URQuery.Page_Load(Object sender, EventArgs e) +515

System.Web.UI.Control.OnLoad(EventArgs e) +67

System.Web.UI.Control.LoadRecursive() +35

System.Web.UI.Page.ProcessRequestMain() +750

Share this post


Link to post

There is no way to delete a corrupt query because I get the "Queue empty" error before I can get to the DELETE button.

 

Actually, you can delete the faulty Pocket Queries okay, but not the Uploaded Routes! To delete the PQs, tick them on the PQ list and click on the trash can at the bottom of the list. Should give you some more space.

 

As you say, it is a nuisane not being able to delete Existing routes though.

Share this post


Link to post

There is no way to delete a corrupt query because I get the "Queue empty" error before I can get to the DELETE button.

 

Actually, you can delete the faulty Pocket Queries okay, but not the Uploaded Routes! To delete the PQs, tick them on the PQ list and click on the trash can at the bottom of the list. Should give you some more space.

 

As you say, it is a nuisane not being able to delete Existing routes though.

 

Oh, thanks. Yes.

 

Nudecacher

Share this post


Link to post

There is no way to delete a corrupt query because I get the "Queue empty" error before I can get to the DELETE button.

 

Actually, you can delete the faulty Pocket Queries okay, but not the Uploaded Routes! To delete the PQs, tick them on the PQ list and click on the trash can at the bottom of the list. Should give you some more space.

 

As you say, it is a nuisane not being able to delete Existing routes though.

 

Oh, thanks. Yes.

 

Nudecacher

 

Oh, and this is very strange. The preview for the failed route pocket queries' maps give caches on the intended routes. So the failure is after the route pocket query is actually created successfully, something to do with the post creation processing.

 

Nudecacher

Share this post


Link to post

Ok, with respect to the other problem of the route pocket query map being wrong, I have an example in my "trip13 Richland-to-Boise 1.1mi GC10A9 463" query. The map on the route pocket query page shows the route having the last half chopped off and a huge jump to San Diago and then a brief route continuing to L.A. So there's some sort of a problem with the list of route turns that's given to google map. It's like the route turns are stored in multiple records and the continuation from one to the next is corrupt or retrieved incorrectly.

 

My "trip13 Richland-to-Boise 1.1mi GC10A9 463" route pocket query does a similiar thing, it starts out okey, but then takes a jump up by about .5 degree and then continues as if it is using relative position points. The rest of the route is the right shape, but offset. Come to think of it, the Richland-to-Boise one above is also a verticle offset, just much larger. It's final tail is mirror of what would be correct without the offset, so maybe there isn't anything to this theory.

 

Don't know if my observations are a help, but perhaps the details will allow replication of the problems.

 

Nudecacher

Share this post


Link to post

Ok, another related one. When I go to my "Caches along a Route" "Find User Routes near your trip" page, I have three pages of route links. When I click on the ">>" or other page navigation buttons or numbers, sometimes I get an error like the "queue empty" error. This one isn't recreatable, as it is ok if retried, like an uninitialized variable type problem that shows intermittently. I've gotten it a number of times this afternoon, but I wasn't paying enough attention to capture the error page. I'll watch for it again.

 

Nudecacher

Share this post


Link to post

Okay, I'm not sure where to put this. I used someone's route of "Eugene to Portland, Oregon" for a PQ. It created 5 PQ's for me all of them "Eugene to Portland, Oregon" and now I can't get rid of them, because they give me an error message. I will post the message for each one, on the other hand they all say the same thing. I am using Foxfire, and running XP. I'm not sure of what other information you want.

 

I only need one in my Queue, not five. Please help :D

___________________________________________________________________

Server Error in '/' Application.

 

Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

 

Exception Details: System.InvalidOperationException: Queue empty.

 

Source Error: An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.

 

Stack Trace:

[invalidOperationException: Queue empty.]

System.Collections.Queue.Dequeue() +105

Groundspeak.Web.UserRoutes.UserRoutePoints.EncodeSignedNumber(Decimal num) +269

Groundspeak.Web.UserRoutes.UserRoutePoints.EncodeLatLong() +240

Geocaching.UI.URQuery.ShowQueryInfo() +717

Geocaching.UI.URQuery.Page_UserLoggedIn(Object sender, EventArgs e) +783

Geocaching.UI.WebformBase.IsLoggedIn() +1326

Geocaching.UI.URQuery.Page_Load(Object sender, EventArgs e) +515

System.Web.UI.Control.OnLoad(EventArgs e) +67

System.Web.UI.Control.LoadRecursive() +35

System.Web.UI.Page.ProcessRequestMain() +750

 

Version Information: Microsoft .NET Framework Version:1.1.4322.2407; ASP.NET Version:1.1.4322.2407

Share this post


Link to post

Never mind, I got rid of them... :D

 

Okay, I'm not sure where to put this. I used someone's route of "Eugene to Portland, Oregon" for a PQ. It created 5 PQ's for me all of them "Eugene to Portland, Oregon" and now I can't get rid of them, because they give me an error message. I will post the message for each one, on the other hand they all say the same thing. I am using Foxfire, and running XP. I'm not sure of what other information you want.

 

I only need one in my Queue, not five. Please help :D

___________________________________________________________________

Server Error in '/' Application.

 

Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

 

Exception Details: System.InvalidOperationException: Queue empty.

 

Source Error: An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.

 

Stack Trace:

[invalidOperationException: Queue empty.]

System.Collections.Queue.Dequeue() +105

Groundspeak.Web.UserRoutes.UserRoutePoints.EncodeSignedNumber(Decimal num) +269

Groundspeak.Web.UserRoutes.UserRoutePoints.EncodeLatLong() +240

Geocaching.UI.URQuery.ShowQueryInfo() +717

Geocaching.UI.URQuery.Page_UserLoggedIn(Object sender, EventArgs e) +783

Geocaching.UI.WebformBase.IsLoggedIn() +1326

Geocaching.UI.URQuery.Page_Load(Object sender, EventArgs e) +515

System.Web.UI.Control.OnLoad(EventArgs e) +67

System.Web.UI.Control.LoadRecursive() +35

System.Web.UI.Page.ProcessRequestMain() +750

 

Version Information: Microsoft .NET Framework Version:1.1.4322.2407; ASP.NET Version:1.1.4322.2407

Share this post


Link to post

Never mind, I got rid of them... :)

 

 

How did you get rid of them? I am having the same problem. Some of my cache along a route I deleted with no problem, but I have two that I can not edit or delete. I'm thinking the original route used wasn't mine, but I am not 100% sure of that.

Share this post


Link to post

Ok, I have some more information to solve the problems that I had with the pocket queries along a route. I'm getting ready to go on a 2000 mile road trip, and I was collecting caches both along the routes and in several larger areas. I broke the route (and alternates) into manageable chunks, mostly to force google earth to take the desired routes. My google earth subscription has expired so I didn't have a way to add intermediate waypoints on a route. I just broke the route up into chunks where google earth followed the correct roads.

 

Well, I ended up with 14 routes to create pocket queries from. Of the 14, I had two that failed and the other 12 worked as one would expect. Even the failed pocket queries gave me the caches I wanted though.

 

Next I put my pocket query results into a trip GSAK database on my laptop. There are just over 8000 caches in the database. That's too many to load into the GPS's and pocket PC at a time, so I wanted to be able to load all of the devices from the laptop with smaller files during the trip. I thought that using the route search feature on GSAK with the 14 routes I had created from google earth would be cool, but the format of the kml files needed to be converted to the text files with GSAK's arc points. I used my nifty programmer skills with the trusty old unix vi editor global change commands to manually convert the klm files to appropriate txt type files. Then I ran my unix wc (word count) on the results.

 

I noticed that there were more than the stated maximum of 500 points in all but one of my klm files. Apparently the geocaching.com limit on the number of points is not working correctly. It looks like all of the files with 2000 or less points work fine and routes with over 2000 have the failure. It looks like the route/pocket query code doesn't properly check for the number of points that it is given and then has overflows later in the code sequence.

 

I don't have access to the actual code and I could be all wet here, but I thought it could be helpful to the lackeys to point out my observation. Thanks for putting up with me.

 

Gary

Nudecacher

Share this post


Link to post

I found that the 500 node limit was never enforced from the very beginning that this feature was made available. Neither is the 500 mile limit. I believe that those are guidelines to keep folks using the feature in a "reasonable manner" (my words).

 

It does seem that the number of nodes is involved in the problem, but I have always kept my routes under 300 nodes and I have seen plenty of times where the system does not like a particular route that had less than 300 points.

 

If you want to try those same routes and force them to be under 500, then run the kml file through GSPbabel and use the "simplify" feature.

 

I have come to suspect that the issue may be with the line of coordinates in the kml file. If you open the file with a text editor, you will note that all the coordinate data are on one line and that for each node 20 to 23 characters are used. I think what is happening is that when this line is very long (whatever that means) the software has an issue with it and either looses track of which characters have been processed or inserts a line-break in the data.

 

All in all, I would say that the shorter the route, the better the chance of having it work.

Share this post


Link to post

I found that the 500 node limit was never enforced from the very beginning that this feature was made available. Neither is the 500 mile limit. I believe that those are guidelines to keep folks using the feature in a "reasonable manner" (my words).

 

It does seem that the number of nodes is involved in the problem, but I have always kept my routes under 300 nodes and I have seen plenty of times where the system does not like a particular route that had less than 300 points.

 

If you want to try those same routes and force them to be under 500, then run the kml file through GSPbabel and use the "simplify" feature.

 

I have come to suspect that the issue may be with the line of coordinates in the kml file. If you open the file with a text editor, you will note that all the coordinate data are on one line and that for each node 20 to 23 characters are used. I think what is happening is that when this line is very long (whatever that means) the software has an issue with it and either looses track of which characters have been processed or inserts a line-break in the data.

 

All in all, I would say that the shorter the route, the better the chance of having it work.

 

I thought that the processing of the KML file was where the problem was too, but now I think that is not the case. I examined my KML files more closely and noticed that sometimes the route is represented by more than one line of coordinates, with the ending point of one repeated as the beginning point of the next. While this may lead to the incorrect maps displayed and which links produce errors, it doesn't seem to affect the caches returned by pocket querys built from the routes. Also these end points from multiple lines are not the locations where the displayed maps take funny jogs if you compare the displayed route map with the original kml file displayed in google earth zooming in closely in each to see details.

 

There are two pieces of evidence that I have figured out now that leads to the conclusion that the original parsing of the KML actually works correctly: (1) pocket queries of routes with problems still produce the correct set of caches, even routes that show 0 route turns on the route information page, (2) the "Create GPX of Route" gives a gpx file with a simplified route when it works and this simplified route actually corresponds to the original kml route when displayed with it in google earth, even though the map displays of routes have wild errors of where the route is.

 

I suspect that the 500 point limit may apply to the number of points on the simplified route, as all of my route information pages show much smaller number of "route turns". The number of "route turns" listed on the Route Information page corresponds to the number of points returned in the "Create GPX of Route" file.

 

It's starting to look like there might be at least three representations of a route, the original kml file, the simplified route that is returned by "Create GPX of Route", and the actual route used by the pocket query to return results. I would think that the last two would be the same thing, but I get pocket query results when the simplified route shows zero points.

 

More later if I get to it, this is an interesting puzzle.

 

Gary

Nudecacher

Share this post


Link to post
Guest
This topic is now closed to further replies.
Sign in to follow this  
Followers 7

×
×
  • Create New...