Queries > KML and GoogleMaps not working?

[SUBYDAZZ]

I tried to download one of my GCA queries in the GoogleMaps format and also .kml for Google Earth, but there's nothing in it and the file is waaay smaller than it used to be, is there an issue here? Other queries I have appear to work fine.

I have made it a Public Query for the time being:

NSW unfound and available - SUBYDAZZ (Public Query)

Is there a limit to the number of results it can give?

[CraigRat]

Ouch, something is broken there!

I'll look when I get home (unless c@w beats me to it)

[caughtatwork]

I tried to download one of my GCA queries in the GoogleMaps format and also .kml for Google Earth, but there's nothing in it and the file is waaay smaller than it used to be, is there an issue here? Other queries I have appear to work fine.

I have made it a Public Query for the time being:

NSW unfound and available - SUBYDAZZ (Public Query)

Is there a limit to the number of results it can give?

Yes, when it runs out of memory.
Try and reduce the number to return to say 100 and then try 500.
That should make it work again.

[caughtatwork]

Now that I'm home with access to the DB, your query returns 5000 caches. Too many dude.

We don't set a limit on a number of caches to return but 5000 drains the memory and boom!

I've reset it to 500 and it works fine now.

[underadar]

I haven't used the queries for a month or so, but I notice now the kml file is so much larger as it returns a whole bunch of linestring gumph for each cache.....can we get rid of that? It appears to draw a little circle around the cache point....and I don't really see the point of that.

Even a 100 cache query no comes in at over 1MB, it used to be less than 200kb....

Thanks,
Mark.

[CraigRat]

Could we make the prox circles a selectable option?

[caughtatwork]

I haven't used the queries for a month or so, but I notice now the kml file is so much larger as it returns a whole bunch of linestring gumph for each cache.....can we get rid of that? It appears to draw a little circle around the cache point....and I don't really see the point of that.

Even a 100 cache query no comes in at over 1MB, it used to be less than 200kb....

Thanks,
Mark.

The point of it was to be able to see what / if any other caches were within 161m of the place you were looking at for hiding a cache.

It should be, by default, not visible when you get the KML file as visibility is set to 0 (off).

The additional download size could be a concern, so if I get a moment tonight, I'll add a widget to MyQuery to include / not include proximity markings in the KML files with the default not include.

[SUBYDAZZ]

OK, it used to work fine as I haven't changed that 5000 result option since I invented it, however, with the number of caches growing daily I guess it has been returning more and more results as time goes by..

From memory the last time I ran it successfully as a .kml file it returned 2300 or so results and the .kml was only around 600k, so what has made it so big all of a sudden?

[caughtatwork]

Probably the new proximity co-ords.
I'm making them optional (default off) tonight.
I'll be back shortly.

[caughtatwork]

OK, proximity markers is your Query is now optional, defaulted to off. Sorry about that.

[underadar]

Nice work...waay too efficient!

There's still a defacto limit on cache numbers, I guess due to the load on the link to some server somewhere, but the query return is sorted by published date so I only need to get the most recent anyway...

Thanks for the quick work,
Mark.

[ideology]

yeah, sorry, we've limited the memory that each php process can use so as not to chew up all the memory on the server.