We have a list of address, And trying to get coordinates of them using server side script.
Due to limitation of google map api(2500 query per 24 hour), We move to bing map REST api.
But when we are calling API its not giving the coordinates, While google map api returning the correct coordinates.
Please tell me what i am doing wrong?
Here is the sample call
http://dev.virtualearth.net/REST/v1/Locations?query=A+Beka+Acadamdy,2303+Maravilla,Lompoc,CA,93436,&incl=queryParse&key=MY_API_KEY
if I replace everything with %20 in address then still its not returning data
http://dev.virtualearth.net/REST/v1/Locations?query=A%20Beka%20Acadamdy%202303%20Maravilla%20Lompoc%20CA%2093436&incl=queryParse&key=MY_API_KEY
Another URL is
http://dev.virtualearth.net/REST/v1/Locations?query=103+Black+Men+of+the+Bay+Area+Community,3403+Malcolm+Avenue,Oakland,CA,94607-1407,&incl=queryParse&key=MY_API_KEY
We also tried with this
https://msdn.microsoft.com/en-us/library/ff817004.aspx#sectionToggle6
But sometimes we don't know the country, That's why its not working correctly.
A couple of things to change. First, drop the name of the location, you only need the street address.
So geocoding "2303 Maravilla, Lompoc, CA, 93436" will work.
Secondly, it looks like you are escaping the query value rather than encoding it. Escaping isn't as good as encoding and will result in some queries failing all together. For example if a query had "first & Main" in it, escaping it would not escape the ampersand which would make everything after it a new URL parameter which would likely either cause an error or mean your query is just for "first". By encoding it the ampersand would be changed to %26. This is documented in the best practices here: https://msdn.microsoft.com/en-us/library/dn894107.aspx
By encoding your query parameter your address will look like this:
"2303%20Maravilla,%20Lompoc,%20CA,%2093436"
Related
I want to find out the changed files between two given commits/branches/tags using the Bitbucket Rest API.
I tried to use the diff command from here
curl -u USER:PASSWORD https://REPO-URL/rest/api/latest/projects/PROJECT/repos/REPO/compare/diff?from=COMMITHASH1&to=COMMITHASH2
where CAPITAL words are place holders for actual values I cannot post here.
The result of the request is always something like
The command "to" is spelled wrong or cannot be found
(the original result is in German, so that might be the translation).
However, if I switch the query parameters like .../diff?to=...&from=..., it says that the command from is unknown. I also tried other similar diff queries like .../compare/changes?from=...&to=... or .../diff?since=...&until=..., but the result was similar as mentioned above. Also giving branch names instead of commit-hashs showed no result.
Therefore, my assumption was that the second query parameter cannot be handled correctly by the API.
Other basic queries on the API like .../branches work fine, so authentication or whatever is no problem.
What am I doing wrong? Do I need to wrap the commit-hashs into "" or something like that?
Thank you very much!
PS: As the repository is commercially used, I cannot give you the actual url, user or password to try for yourself.
I need to use the Bing Maps API to check if a UK postcode (Not sure how different it is for other countries) is valid.
It seems that I can put any nonsense into the field for postcode and I still get a response.
E.G. http://dev.virtualearth.net/REST/v1/Locations/GB/aregsfdgsdfgsdfgdsf?key=BINGMAPSKEYHERE
Gives a result that has a lat and long of 53.9438323974609, -2.55055809020996 in the "point" field, despite that clearly not being a valid postcode.
Is there a way that I can simply test the validity of a postcode?
If you look at the response object for your request you will see a matchCode value. This indicates if the match it is good or not. In this case it says "UpHierarchy" which indicates that it didn't find the exact result so it when up the address hierarchy until it found a result. The result being returned is for the United Kingdom. Additionally, the results also have an entityType value which tells you the type location that was found. In this case it says CountryRegion. You want an entityType value of "PostalCode". By checking these two values you can determine if the returned result is a postal code or not. More details on the geocode response object is documented here: https://msdn.microsoft.com/en-us/library/ff701725.aspx
One thing I would highlight is that the URL format you are using is a bit of a legacy one and isn't as accurate as passing in a single string query (i.e. &q=YOURQUERY). This is highlighted in the best practices docs. If you are using .NET, I hiehgly recommend using the Bing Maps .NET REST toolkit. It makes things really easy and implements best practices for you.
I'm writing app using Google custom search engine.
I received my search engine ID XXXXXXXX219143826571:7h9XXXXXXX (most interesting part bold).
Now I'm trying to use NSURLQueryItem to embed my ID into URL by using:
let params = ["cx" : engineID,...]
...
components.queryItems = parameters.map {
NSURLQueryItem(name: String($0), value: String($1))
}
It should percentage escape item to XXXXXXXX219143826571%3A7h9XXXXXXX (This value I'm getting when using Google APIs explorer while testing, it shows url dress that was used). It is not doing it. I'm getting url without escaping, no changes. If I use escaped string as engine ID in this mapping, I'm getting escaped string XXXXXXXX219143826571%253A7h9XXXXXXX (additional '25' is added to query).
Can someone tell me how to fix it? I don't want to use String and then convert it to URL by NSURL(string: str)!. It is not elegant.
Edit:
I'm using app Info.plist to save ID and I retrieve it by calling:
String(NSBundle.mainBundle().objectForInfoDictionaryKey("ApiKey")!)
Colons are allows in the query part of a URL string. There should be no need to escape them.
Strictly speaking, the only things that absolutely have to be encoded in that part of a URL are ampersands, hash marks (#), and (assuming you're doing a GET query with form encoding) equals signs. However, question marks in theory may cause problems, slashes are technically not allowed (but work just fine), and semicolons are technically allowed (but again, work in practice).
Colons, AFAIK, only have special meaning in the context of paths (if the OS treats it as a path separator) and in that it separates the scheme (protocol) from the rest of the URL.
So don't worry about the colon being unencoded unless the Google API barfs for some reason.
I am attempting to preview a track via the 7digital api. I have utilised the reference app to test the endpoint here:-
http://7digital.github.io/oauth-reference-page/
I have specified what I consider to be the correct format query, as in:-
http://previews.7digital.com/clip/8514023?oauth_consumer_key=MY_KEY&country=gb&oauth_nonce=221946762&oauth_signature_method=HMAC-SHA1&oauth_timestamp=1456932878&oauth_version=1.0&oauth_signature=c5GBrJvxPIf2Kci24pq1qD31U%2Bs%3D
and yet, regardless of what parameters I enter I always get an invalid signature as a response. I have also incorporated this into my javascript code using the same oauth signature library as the reference page and yet still get the same invalid signature returned.
Could someone please shed some light on what I may be doing incorrectly?
Thanks.
I was able to sign it using:
url = http://previews.7digital.com/clip/8514023
valid consumer key & consumer secret
field 'country' = 'GB'
Your query strings parameters look a bit out of order. For OAuth the base string, used to sign, is meant to be in alphabetical order, so country would be first in this case. Once generated it doesn't matter the order in the final request, but the above tool applies them back in the same order (so country is first).
Can you make sure there aren't any spaces around your key/secret? It doesn't appear to strip white space.
If you have more specific problems it may be best to get in touch with 7digital directly - https://groups.google.com/forum/#!forum/7digital-api
Why is it when I request some postcodes from Bing maps I get an incorrect coordinates
http://dev.virtualearth.net/REST/v1/Locations?postalCode=IM1+1LD&countryRegion=GB&o=xml&key=MY_BING_KEY
While when I request it using this I get the correct ones
http://dev.virtualearth.net/REST/v1/Locations?postalCode=IM1&1LD&countryRegion=GB&o=xml&key=MY_BING_KEY
i.e. when I send IM1+1LD as a postalcode incorrect results are returned, while sending IM1&1LD returns the correct results in the response.
The + indicates your are escaping rather than encoding your query. The plus should be %20 instead. Also, in the UK postal codes are a special case. I recommend searching for them using a query search instead like this: http://dev.virtualearth.net/REST/v1/Locations?q=IM1%201LD&o=xml&key=YOUR_KEY
You can find additional tips on use the REST services here: https://blogs.bing.com/maps/2013/02/14/bing-maps-rest-service-tips-tricks