In a conversation turn the caller is asked for the address of their destination. A few response examples:
I'm heading to 123 Lombard Street.
I'll be at 2210 third Ave.
I should be arriving to 44 Cross Terrace about 3:00 this afternoon.
Is it possible to isolate and extract the the address portion of the users response:
123 Lombard Street
2210 third Ave.
44 Cross Terrace
I'm looking for advice, best practices on whether this extraction can be accomplished using intents and entities to locate the numeric portion, and (street, Ave, Terrace) portions and wild-card what's in between (Lombard, third., Cross) or will application code be required to locate and extract the address portion.
If any additional information is required I'll be happy to provide on request.
A strategy could be to use the system entity #sys-number to point to the beginning of your referenced address snippets. The metadata for each found entity holds the location information (begin / end in the input string). From there you would need to search the input string for anything not in your specific "address vocabulary".
You could add your adress vocabulary (street, road, terrace, avenue plus the synonyms) as entities. The range from smallest entity position to highest could be extracted and then used to normalize the address.
The extraction and some processing can be done inside the conversation service, but you likely need to have outside logic to normalize the found address snippets to what you need.
This blog entry about tips & tricks for building chatbots has some useful stuff and links to a repository with some detailed examples of processing entities and variables.
Related
Problem: I want to tell if the access road to an US address includes dirt or paved road(like if it is in a remote area without proper road). If it is a dirty road we charge more to the customer for delivery.
In technical terms - The input is going to be a house address and I need to find out if the way to it involves dirt road.
I am ok with making multiple calls to get the complete information. What steps do I need to take?
In general, you will probably need two steps:
Use HERE Routing API to calculate the route between the two locations. It will return the path information.
Get the road attribute from one of the following content sources, such as Map Attribute API, Road Physical Attributes in HERE Map Content.
The HERE api seems really picky about what is uses for the q parameter in API calls. According to the documentation you can use a street address, partial address, name of place, etc (documentation: https://developer.here.com/documentation/places/topics/free-text-search.html)
Im trying to take an address and return the name of the store, building, business at that location (a few million of these) In some cases I have a human typed name of the place at the address but this can be quite messy and inaccurate in a lot of cases so Im trying not to use this information. Address however Im quite confident in.
in summary Im trying to provide here with an input like "15300 Cedar Ave, Apple Valley, MN 55124" and output "Best Buy"
Here seems to be really finicky on what your q input is..
When I put in the address and geocode info, Best Buy doesn’t appear on the results list
q=15300 Cedar Ave, Apple Valley, MN 55124
in=44.7287,-93.2147;r=800
https://places.demo.api.here.com/places/v1/discover/search?q=15300+Cedar+Ave%2C+Apple+Valley%2C+MN+55124&in=44.7287%2C-93.2147%3Br%3D800&Accept-Language=en-US%2Cen%3Bq%3D0.9&app_id=DemoAppId01082013GAL&app_code=AJKnXv84fjrb0KIHawS0Tg
Based on this Im thinking maybe this info just isnt in here's database, but when I run this query which includes best buy in the search it finds it right away at the correct address!!
q=best buy 15300 Cedar Ave, Apple Valley, MN 55124
in=44.7287,-93.2147;r=800
https://places.demo.api.here.com/places/v1/discover/search?q=best+buy+15300+Cedar+Ave%2C+Apple+Valley%2C+MN+55124&in=44.7287%2C-93.2147%3Br%3D800&Accept-Language=en-US%2Cen%3Bq%3D0.9&app_id=DemoAppId01082013GAL&app_code=AJKnXv84fjrb0KIHawS0Tg
It seems like a no-brainer to me that HERE would use the q value as an address search but that doesnt always appear to be the case. Looking for guidance on how to make this smarter
if the point of interest(POI) needs to be searched by specific address, then q is significant for fetching the records. As the API will fetch only those records which have those keywords in that area.
if POIs need to be searched at specific lat-long and around defined meter range, then q is not significant.
https://places.demo.api.here.com/places/v1/discover/around?in=44.7287%2C-93.2147%3Br%3D800&Accept-Language=en-US%2Cen%3Bq%3D0.9&app_id=DemoAppId01082013GAL&app_code=AJKnXv84fjrb0KIHawS0Tg
Is it mandatory for you to pass address all the time, or lat-long can also work ?
I am modelling a conversation in Watson conversation. The conversation is around the facilities available at airports. I have configured airport names as an entity and have added variations of airport names as synonyms and have kept the IATA code for the airport as the entity value. For example, Schiphol airport in Amsterdam looks like the below
I have turned on fuzzy matching on this entity so that I can catch typos people will make when they try to say Schiphol or Amsterdam. However, Watson is now capturing the word am in the below sentence as this entity
I am wondering if there is wifi in schiphol airport?
How do I stop Watson from fuzzy matching on the entity value but only do it on synonyms?
I don't think it's possible to enable Fuzzy matching on synonyms only, at the moment. I see a couple of "easy" workarounds.
Option 1: Leverage Watson's confidence level.
If you place <? entities ?> within your node's response and test it in the Try it out panel, you'll notice that each detected entity has a confidence level associated with it. This is Watson's confidence level in the entity, expressed as a float ranging from 0 to 1.
When testing it with your entity value and synonyms, I got 90% confidence (i.e., 0.9) for amsterdaam but only 70% for am.
So assuming these numbers hold for you, you could use entities[0].confidence > 0.7 as the condition in your node to decide when to assign the airport to a context variable and when to ask for clarification from the user in the response.
You might have to do some testing to see if you can find a confidence level value that works reasonably well as a threshold for your #airport entity values and their common misspellings.
Option 2: Use two entities
#airport-code: Use the airport code for the value, no synonyms, and no fuzzy matching enabled.
#airport-name: Use the airport name for the value, various synonyms including city, and fuzzy matching enabled.
Depending on how your chatbot works, this might be an acceptable compromise or complicate too much your logic.
I'll give you an example. If your $airport context variable will work whether AMS or Amsterdam Airport Schiphol is stored, this solution solves the problem for you as is. If not, there is an extra step before you can assign the value to the $airport context variable. Namely, you may need to implement a lookup to retrieve the airport code for the given airport name.
Hi every one i am working on asp.net web routing. I need same url pattern without any constraints.
i need following multiple URL pattern.
"CountryRoute","{country_name}" "~/country.aspx" => www.abc.com/australia/
"PageRoute","{page_url}" "~/page.aspx" => www.abc.com/contact_us/
"keywordRoute","{keyword_url}" "~/keyword.aspx" => www.abc.com/keywordName/
i can't apply any constraints.
You can't have one common URL for two different resources (without magic, that is). That's like suggesting one road could take you to two different places.
You know that en URL is kind of the address of a web page, right? Consider the similar properties in comparison with a real address of a real house; It would be OK to have two addresses for one house, but if two different houses had the same address (in the same town, county, country etc.) then how would the postman be able to tell which house a certain letter should be delivered to?
If you wanted to, you could build your own route handling but that wouldn't change the fact that at one point or another you need to do the job of the postman and identify some unique feature of the request or its context, that points towards one resource or the other. It could be the querystring, a session object, whether the call was made from a computer i China or Germany or whatever -- you need to decide what makes sense in your case. "Both link going to different destination page but URL are same", as you wrote in your answer to my comment, does not.
Why is it that no type is returned when the address component is an Indian
Reservation? It is just returned as shown below, and because there is no type, it causes an error when trying to geocode addresses that return an Indian Reservation.
<address_component>
<long_name>Hopi Indian Reservation</long_name>
<short_name>Hopi Indian Reservation</short_name>
</address_component>
Example addreses:
HWY 160 & HWY 264
Tuba City, AZ 86045
OR
HWY 160 & HWY 163
Kayenta, AZ 86033
I guess the documentation about Address Component Types is a bit too subtle as to (not mentioning) the fact that there is no guarantee that the types[] array will always contain something, or that hese types may also be returned within address_components[] arrays ... or may not.
Your example reproduces this behavior pretty well:
http://maps.googleapis.com/maps/api/geocode/json?sensor=false&address=Hopi%20Indian%20Reservation
The types[] array is empty for the first result and its first address component.
Short term, I think your (and everybody's) code should be ready to accept empty types[] arrays. Long term, I'd agree it'd be better to give every result at least one type. For the specific case of indian reservations, I've no idea which one (if any) of the available ones would make sense. Maybe one of...
political indicates a political entity. Usually, this type indicates a polygon of some civil administration.
colloquial_area indicates a commonly-used alternative name for the entity.
park indicates a named park.
point_of_interest indicates a named point of interest. Typically, these "POI"s are prominent local entities that don't easily fit in another category such as "Empire State Building" or "Statue of Liberty."
If anyone has a clear idea how to classify these in the available Address Component Types, please file a feature request for the Geocoding API ;)