Thanks for the response.
We are using a unique AppId !
We can successfully issue the first request and get a valid response
<?xml version="1.0" ?>
- <!-- ws01.search.re2.yahoo.com compressed Fri Dec 7 05:07:36 PST 2007
but when we try to issues the next gws.maps.... stuff, we get the
We can see from our statistics on request, that the first couple of
days we could issues 3000-5000 request a day, but suddenly after a
couple of days, we were banned/got error 999. The first ban/error came
after still just 3300 request over a period of 24hours. Now we get
banned 2-3 times a day, a after maybe 200-400 request. The ban period
is around 2-3 hours. We can also see that during a pan period on the
production environment/IP, we can still make request/get images from
another environment/IP, so the ban is IP oriented.
We are puzzled about the numbers, but after some further investigation
we have discovered that the ban is coming after requesting maybe
90-120 request during a 5 minutes period. I have difficulties
regarding this as a high volume solution for a peak period. Depending
on how Yahoo interprets its 50.000 rate/ip/day, just simple time
oriented math would give you 2083 request/hour, or 521 request/15
minutes, but I mean, who would count like that.
I still suspect that we experience some kind of protection mechanism
fro Yahoos side, but am not sure how to interpret or even get off this
Would be nice to hear if anybody has been able to implement solutions,
where they request 1000s of images and their peak request number.
It would be extremely sad to abondon the Yahoo approach, because of
the current ban mechanism etc.
Thanks in advance.
--- In email@example.com, "Alan Brown" <adbrown@...> wrote:
> The first question would be - are you using a unique AppId, not the
> Also - you say you like the topographical map images . the MapImage web
> service returns a URL that does not have topographical details - are you
> modifying the URL so it doesn't use
> http://gws.maps.yahoo.com/mapImage ?
> Is your problem regarding the proxy service returning the URL - or
> from using the returned URL to get a map image?
> From: firstname.lastname@example.org [mailto:email@example.com] On
> Of john.valore
> Sent: Thursday, December 06, 2007 10:58 AM
> To: firstname.lastname@example.org
> Subject: [yws-maps] Receive 999 error message when requesting images
> MAPS IMAGE API
> I work as a GIS export for a Danish mobile operator, Telia Denmark. We
> have just launched an application on the internet, hat can display
> 2G/3G coverage maps on top of Yahoo Maps.
> We collect the Yahoo Maps using the MAPS IMAGE API :
> yahoo.com/maps/rest/V1/mapImage.html, and it works
> great and the topographical maps are of very good quality.
> We have now during the initial days of launch discovered some serious
> issues with the request of Maps. We are far from using the 50.000
> daily request pr. IP (highest in the latest 4 days were app. 4500),
> but it appears that we periodical get banned from making request and
> get an 999 error message.
> Sorry, Unable to process request at this time -- error 999.
> Unfortunately we are unable to process your request at this time.
> This error is usually temporary. Please try again later.
> If you continue to experience this error, it may be caused by one of
> the following:
> We are banned for some time (1-2 hours) and then we can start request
> images again. We have done some research on the @ and it could appear
> that we are being banned by some kind of bandwidth restriction system,
> like mentioned here :
> As the current number of request and their intensity is very low, we
> are very puzzled that we get this ban. Can anyone help us understand
> why this happening and if possible tell us if there is a way around
> this ?
> We hope for a quick answer because the current situation is not good
> (were banned out 3 times today and have only made app.. 1200 request).
> Hope to hear from somebody soon
> John Valore, GIS expert at Telia Danmark
> john.valore@ <mailto:john.valore%40teliasonera.com> teliasonera.com
> [Non-text portions of this message have been removed]