I want to use the USPS API https://www.usps.com/business/web-tools-apis/address-information-api.htm for correcting addresses typed into our application.
Specifically, I will add a little button next to the address that will allow the user send the typed address to the service and then confirm that that the returned address is the one they would like to replace it with.
I have seen other websites do this and I like it because the user has control over inserting errant addresses returned by USPS. [I am not saying that the USPS data is bad; the likely scenario is that the entered address is so bad the USPS guessed wrong].
Anyway, I am looking at the response sample for the verify service:
I am observing that only one guess at the real address is returned. Other services I have seen return multiple so the user can pick the best one.
Is there an option on the USPS API that will return multiple guesses for a single address?
Note: the Address ID='0' is for sending multiple addresses and being able to sort it out in the returned data.
The address you input contained the suite number (STE K) so there is no ambiguity with the result. It is a "precise match". If you remove the "STE K" from the input address, the response will contain a ZIP + 4, but the DPV parameters will indicate that the match is a "default match". This type of match occurs with high rises and apartment complexes, where there is a main street address which has a "default" ZIP+4, but there is frequently a better "precise" response if an apartment or suite identifier is provided. The precise response will typically have a different +4 and carrier route than the default response.
Related
I posted the following Feature Request to the azure-sdk, but not sure if that was the correct place for getting a response, so reposting here.
https://github.com/Azure/azure-sdk-for-net/issues/20764
When processing a document against a custom trained model, when a value is present but not able to be translated (such as a signature), would it be possible to include something in the response to identify it as having a value though it wasn't able to be processed?
The specific use case is that our client needs to know that a document was signed by the parties involved. Without this feature, someone will be required to manually review thousands of document images per week to verify that they have been signed. In testing we have found that very few signatures are being translated any way, so the string response is coming back as null.
Thank you,
Rich
For Form Recognizer when a value is not detected although it is present it will be extracted as Null as Form Recognizer is not aware that a value exists it did not detect it. In case of signature this is usually due to the signature being unreadable and just a scribble.
I need to make search input element using Google API and I need to have only towns and addresses listed, and not places. Also, once a user click the town/address in the search list, I need to grab the coordinates because I need them for calling internal Search API. Which Google API do you recommend me to use? I found couple solutions such as Geocoding and Place Autocomplete. Thank you!
The types parameter for the google Place Autocomplete search is what you're looking for, specifically using the address type and (cities) type collection.
I also highly recommend the react-geosuggest library if you want something pre-made to accomplish this as you can pass those as parameters and style it yourself.
<Geosuggest
types={['address', '(cities)']}
onSuggestSelect={this.onSuggestSelect}
/>
types allows you to limit to addresses and cities and onSuggestSelect allows you to access the addresses details.
EDIT
After looking through the docs a little more I discovered that you can only specify one option for the types parameter:
You may restrict results from a Place Autocomplete request to be of a
certain type by passing a types parameter. The parameter specifies a
type or a type collection, as listed in the supported types below. If
nothing is specified, all types are returned. In general only a single
type is allowed. The exception is that you can safely mix the geocode
and establishment types, but note that this will have the same effect
as specifying no types.
source: https://developers.google.com/places/web-service/autocomplete#place_types
So out of the following options
geocode instructs the Place Autocomplete service to return only geocoding results, rather than business results. Generally, you use this request to disambiguate results where the location specified may be indeterminate.
address instructs the Place Autocomplete service to return only geocoding results with a precise address. Generally, you use this request when you know the user will be looking for a fully specified address.
establishment instructs the Place Autocomplete service to return only business results.
the (regions) type collection instructs the Places service to return any result matching the following types:
locality
sublocality
postal_code
country
administrative_area_level_1
administrative_area_level_2
the (cities) type collection instructs the Places service to return results that match locality or administrative_area_level_3.
I would say your best option would either be address, (cities), or (regions) depending on how specific you need the output to be.
I am developing an app and everything is working good. One condition are there where I have set the utterances but if user is speaking something else, I am throwing it to the fallbackIntent. One of my utterance is {name} so user can speak any name. But I have define range of name as well that user is allowed only these names. So my problem is if the user is choosing defined names, everything working great and if user said something else like what is weather of chicago, it is going to fallbackIntent as well but the issue is if user speak some name which is not in the list, then too it is coming into defined intent. What i want that if user speak something which is correct but not in my defined name then too redirect it to the fallbackIntent. Is there any way I can call intent in giving condition? I am using php.
When you define a custom slot, Alexa take it's values as samples. So values which are not in the slot-value-list will also be passed to you. And with respect your intent, those slot values are valid, hence that intent is triggered.
The solution is to validate the slot values at your backend and return an appropriate response.
In your case, if u get any other names other than those you have defined, respond back with an error or give FallbackIntent's response.
When you create a custom slot type, a key concept to understand is
that this is training data for Alexa’s NLP (natural language
processing). The values you provide are NOT a strict enum or array
that limit what the user can say. This has two implications
1) words and phrases not in your slot values will be passed to you,
2) your code needs to perform any validation you require if what’s
said is unknown.
iOS 6.0 has added a couple of new instance methods to the class GKTurnBasedMatch. I am not sure how to use them:
acceptInviteWithCompletionHandler
declineInviteWithCompletionHandler
Are they supposed to be used in response to receiving a turn-based match invite? Turn-based match invites are received through the GKTurnBasedEventHandlerDelegate protocol method: handleInviteFromGameCenter.
- (void) handleInviteFromGameCenter:(NSArray *)playersToInvite
handleInviteFromGameCenter does not provide a GKTurnBasedMatch instance to use for the purposes of accepting or declining. Consequently I do not know how to use them in response to an invite.
The only methods that provide GKTurnBasedMatch instances are:
+ loadMatchesWithCompletionHandler
+ findMatchForRequest:withCompletionHandler
I am not sure why I would use acceptInviteWithCompletionHandler on the results of loadMatchesWithCompletionHandler, because they are matches I am already participating in.
I am not sure why I would use either of them with findMatchForRequest:withCompletionHandler, because this is being called to find a match. Am I supposed to accept the match after finding it?
<- Update ->
I have found one use for declineInviteWithCompletionHandler. If a user requests to delete a match they have not taken a turn in, I call declineInviteWithCompletionHandler. This way they are not recorded as having quit the match.
When a player has not yet taken a turn, their GKTurnBasedParticipant.lastTurnDate is null
If a user requests to play a match (that I have displayed in a list using loadMatchesWithCompletionHandler) and if the local player has not taken a turn in the match, I am calling acceptInviteWithCompletionHandler, before I display the match to the player. I'm not sure if this is necessary, it just seemed like the right thing to do.
How can I fetch the avatars of all the contacts in a user's XMPP/Jabber roster?
I have previously asked this question, and while implementing the <presence> handler, I noticed that the presence items my app receives are of the form:
<presence to="me" from="contact">
...some other stuff here...
<x xmlns="vcard-temp:x:update"><photo>3FB991AA97D7701C21EAFE65FB866E4BFF1B927C</photo></x>
</presence>
The 3FB991AA97D7701C21EAFE65FB866E4BFF1B927C part looks like a SHA hash to me, but how can I get the actual avatar of the user in question?
vCard-based Avatars are specified in XEP-0153. You are correct that the photo element contains a SHA1 hash. Request the vCard of the person that sent you the hash:
<iq to='juliet#capulet.com'
type='get'
id='vc2'>
<vCard xmlns='vcard-temp'/>
</iq>
And fish the photo out of the response:
<iq to='romeo#montague.net/orchard'
type='result'
id='vc2'>
<vCard xmlns='vcard-temp'>
<PHOTO>
<TYPE>image/jpeg</TYPE>
<BINVAL>
Base64-encoded-avatar-file-here!
</BINVAL>
</PHOTO>
</vCard>
</iq>
You MUST cache based on that if you're going to use this protocol, and you'll really want to throttle how often you ask for avatars when you start up (particularly the first time a user logs in). Grabbing bajillions of avatars in a short amount of time will likely get you rate-limited by your server otherwise.
Also, be very careful about calculating your SHA1 hash. I've seen several clients that aren't terribly careful, who end up in an endless loop re-requesting the same avatar over and over.
I suggest negative-caching if you request an avatar and it doesn't match the hash you expect; cache the fact that you aren't going to get an answer for that hash, and don't ask for it again next time. The sender's SHA1 logic is likely wrong in some interesting way, and it's not going to get better the next time you ask.
Finally, some clients are written to try asking the sender's server for vCard data using XEP-0054 first as XEP-0153 says, then fall back on asking the sender's client directly by sending an IQ get for the vCard to the sender's full JID (user#domain/resource). Be prepared to deal with those requests on the sender's side.