Is it true that using full country name in free-form text address will gain better "Relevance" scoring as compared to using CountryISO3 code?
In one of the example that I observed.
Case with country iso3 : Flat 1 Church Road, Liverpool, L37 8B,GBR
"Relevance": 0.88,
"MatchLevel": "houseNumber",
"MatchQuality": {
"Country": 1.0,
"City": 1.0,
"Street": [
1.0
],
"HouseNumber": 1.0,
"PostalCode": 0.98
},
Case with full country name : Flat 1 Church Road, Liverpool, L37 8B,united kingdom
"Relevance": 0.91,
"MatchLevel": "houseNumber",
"MatchQuality": {
"Country": 1.0,
"City": 1.0,
"Street": [
1.0
],
"HouseNumber": 1.0,
"PostalCode": 0.98
},
Relevance of the Geocoder API is explained below:
Relevance is a precentage value ranging from 0 to 1 representing the percentage of the input that matches the returned address. "1" means that all input tokens were matched and there was no typo or any other difference.
If the input query contains any additional information – name of the person, phone number or a hint to ring twice – the relevance will be low, but the address returned may be correct.
Low relevance may indicate that the Geocoder API was not able to match some relevant part of the address in the input query.
To separate the above cases one may look at match quality of the fields. These values show how well each of the address elements (e.g. street, city, country etc.) in the results matched to the input that was provided. If all the fields that are important for addressing in the country were matched with high match quality, one can assume that relevance is low because of the additional non-address information. And the result is still highly confident.
https://developer.here.com/documentation/geocoder/dev_guide/topics/scoring.html
Related
in our company we are using Celigo middleware to get orders from eshop (US branch) into our accounting system (EU HQ).
They are using kinda tricky field mapping process between these two systems, if you want to use conditions or any other function they are using handlebars: https://docs.celigo.com/hc/en-us/articles/360039326071-Handlebars-helper-reference link to their documentation with basic helpers, etc.
I come into situation when I want to do sum of tax rates but only when tax amount is greater than zero... For instance, you can have four different tax rates in US, however for shipping only two-three of them are applied, but in the payload all four are available so I want to filter out rates with zero amount.
origin handlebar without conditions:
{{#if shipping_lines_1.price}}
{{multiply
(sum shipping_lines_1.tax_lines.[0].rate
shipping_lines_1.tax_lines.[1].rate
shipping_lines_1.tax_lines.[2].rate
shipping_lines_1.tax_lines.[3].rate)
100}}
{{/if}}
part of the payload regarding "shipping_lines":
{"shipping_lines_1":
{"id": 1111111111,"carrier_identifier": null,"code": "Standard Shipping","delivery_category": null,"discounted_price": "8.90","discounted_price_set": {"shop_money": {"amount": "8.90","currency_code": "USD"},"presentment_money": {"amount": "8.90","currency_code": "USD"}},"phone": null,"price": "8.90","price_set": {"shop_money": {"amount": "8.90","currency_code": "USD"},"presentment_money": {"amount": "8.90","currency_code": "USD"}},"requested_fulfillment_service_id": null,"source": "shopify","title": "Standard Shipping",
"tax_lines": [
{"price": 0.09,
"price_set": {"shop_money": {"amount": "0.09","currency_code": "USD"},"presentment_money": {"amount": "0.09","currency_code": "USD"}},
"rate": 0.0625,
"title": "IL STATE TAX"},
{"price": 0.00,
"price_set": {"shop_money": {"amount": "0.00","currency_code": "USD"},"presentment_money": {"amount": "0.00","currency_code": "USD"}},
"rate": 0,
"title": "IL COUNTY TAX"},
{"price": 0.00,
"price_set": {"shop_money": {"amount": "0.00","currency_code": "USD"},"presentment_money": {"amount": "0.00","currency_code": "USD"}},
"rate": 0.01,
"title": "IL CITY TAX"},
{"price": 0.07,
"price_set": {"shop_money": {"amount": 0.07,"currency_code": "USD"},"presentment_money": {"amount": "0.07","currency_code": "USD"}},
"rate": 0.0075,
"title": "IL SPECIAL TAX"}],
"discount_allocations": []
}}
as you can see the tax code with a name "IL CITY TAX" has rate 0.01 however amount is zero, which leads into miscalculation in the accounting system when imported shipping tax rate is 8% instead of 7%
So I've added conditions to check tax amount/price at the first place and then do sum of rates when tax amount is greater than zero (in their system 0 or 0.00 is considered as falsy as well when you use #if):
{{#if shipping_lines_1.price}}
{{multiply
(sum
({{#if shipping_lines_1.tax_lines.[0].price}}{{shipping_lines_1.tax_lines.[0].rate}}{{else}}0{{/if}})
({{#if shipping_lines_1.tax_lines.[1].price}}{{shipping_lines_1.tax_lines.[1].rate}}{{else}}0{{/if}})
({{#if shipping_lines_1.tax_lines.[2].price}}{{shipping_lines_1.tax_lines.[2].rate}}{{else}}0{{/if}})
({{#if shipping_lines_1.tax_lines.[3].price}}{{shipping_lines_1.tax_lines.[3].rate}}{{else}}0{{/if}})
)100
}}
{{else}}0{{/if}}
Unfortunately, I always get an error: " Could not compile handle bar ... Parse error on line 4 ... Expecting 'ID', 'STRING', 'NUMBER', 'BOOLEAN', 'UNDEFINED', 'NULL', 'DATA', got 'OPEN_BLOCK'"
The "sum" and "multiply" helpers/functions are already implemented in the middleware system as per documentation attached above. AFAIK I am not able to register any additional helpers, however I was testing in on http://tryhandlebarsjs.com/ with following registered helpers:
Handlebars.registerHelper("multiply",function(a, b) {
return Number(a) * Number(b);
});
Handlebars.registerHelper("sum", function() {
var args = [].concat.apply([], arguments);
var len = args.length;
var sum = 0;
while (len--) {
if (!isNaN(args[len])) {
sum += Number(args[len]);
}
}
return sum;
});
My question here is: is there any Handlebars limitation, am I dumb I don't see missing parenthesis, should I take other approach for sum function or anything else?
Do you have any ideas for handlebars to correct the issue, please?
Thank you in advance.
Handlebars does not support nesting mustache expressions within each other. So {{multiply... {{#if... is simply not valid. The problem you are encountering is a good example of why a templating language, which is used for formatting output, should not be used for performing business logic, as it is doing with the tax calculation in your example.
Truly, I think the most correct solution would be to abandon the sum and multiply Handlebars helpers and perform the tax calculation in JavaScript and pass the result to Handlebars to format.
If, for some reason, this is not an option, and you absolutely must perform this calculation in the template, then you will need to write a custom helper that takes three arguments and, if the first is truthy, returns the second, else returns the third.
The helper would be quite simple:
Handlebars.registerHelper("ifThenElse", function (condition, ifTrue, ifFalse) {
return condition ? ifTrue : ifFalse;
});
You would then use the helper in your template as a Handlebars Subexpression, which allows you to nest helpers:
{{#if shipping_lines_1.price}}
{{multiply
(sum
(ifThenElse shipping_lines_1.tax_lines.[0].price shipping_lines_1.tax_lines.[0].rate 0)
(ifThenElse shipping_lines_1.tax_lines.[1].price shipping_lines_1.tax_lines.[1].rate 0)
(ifThenElse shipping_lines_1.tax_lines.[2].price shipping_lines_1.tax_lines.[2].rate 0)
(ifThenElse shipping_lines_1.tax_lines.[3].price shipping_lines_1.tax_lines.[3].rate 0)
)
100
}}
{{/if}}
I have created a fiddle for reference.
Request: https://reverse.geocoder.api.here.com/6.2/reversegeocode.json?app_id=APP_ID&app_code=APP_CODE&mode=retrieveAreas&prox=35.1377685%2C33.9196697%2C1000&language=en&gen=9
Replace these two by actual values: APP_ID, APP_CODE
This is response:
{
"Response":{
"MetaInfo":{
"Timestamp":"2019-05-06T10:31:19.317+0000"
},
"View":[
{
"_type":"SearchResultsViewType",
"ViewId":0,
"Result":[
{
"Relevance":1.0,
"Distance":-1092.5,
"Direction":149.7,
"MatchLevel":"city",
"MatchQuality":{
"Country":1.0,
"County":1.0,
"City":1.0,
"PostalCode":1.0
},
"Location":{
"LocationId":"NT_iVkNRSYU-2l2WyhtuOg9TB",
"LocationType":"area",
"DisplayPosition":{
"Latitude":35.13116,
"Longitude":33.9244
},
"MapView":{
"TopLeft":{
"Latitude":35.16061,
"Longitude":33.88137
},
"BottomRight":{
"Latitude":35.08291,
"Longitude":33.95569
}
},
"Address":{
"Label":"Karakol, Turkish-Cypriot Administered Area",
"Country":"NCY",
"County":"Famagusta",
"City":"Karakol",
"PostalCode":"99450",
"AdditionalData":[
{
"value":"Turkish-Cypriot Administered Area",
"key":"CountryName"
},
{
"value":"Famagusta",
"key":"CountyName"
}
]
},
"MapReference":{
"ReferenceId":"970895970",
"MapId":"UEAM19108",
"MapVersion":"Q1/2019",
"MapReleaseDate":"2019-04-15",
"SideOfStreet":"neither",
"CountryId":"26569036",
"CountyId":"26569038",
"CityId":"26571374"
}
}
}
]
}
]
}
}
See "Country" field:
"Country":"NCY",
As you can see, country code is NCY. I'm trying to find what country uses that 3-letter code and I can't find it anywhere on the internet.
https://www.worldatlas.com/aatlas/ctycodes.htm
It looks like this is some API issue and it returns wrong country code.
As there is no official answer from HERE, I'll give at least some background info.
NCY is probably a non ISO 3166-1-alpha-3 code that represents Northern Cyprus.
Cyprus is a complicated case, with Greece and Turkey claiming influence. I remember 4 zones modeled, a Greek part, a Turkish part, the UN controlled demilitarized zone in between and a British military base.
You can read more at https://en.wikipedia.org/wiki/Cyprus#Administrative_divisions
I'll go a step further and say this should be filed as a bug, for two reasons.
According to the API Reference, the Address object type is as follow (emphasis mine):
Label Assembled address value for displaying purposes.
Country ISO 3166-alpha-3 country code
[...]
As you noticed, and this is the first reason of why it is a bug, NCY is not a valid ISO 3166-alpha-3 country code
Furthermore, your request does not contain the politicalview query parameter, which allows to deal with disputed territories: for exemple, Crimea would be returned as part of Russia if politicalview=RUS is in the request. If politicalview is not specified, the API assumes the "international view".
However, and this is the second reason, the so-called "Turkish Republic of North Cyprus" is recognized only by Turkey. It does not make sense to return a country code other than CYP, except when politicalview=TUR is specified in the request.
I am working with HERE geocoder and found a case where the city returned is wrong if we add a particular district name in the searchtext parameter.
This is the example request:
https://geocoder.api.here.com/6.2/geocode.json?app_id=...&app_code=...&searchtext=Centro,Campos%20dos%20Goytacazes,RJ,Brazil
And this is the significant parts of the response:
{
_type: "SearchResultsViewType",
ViewId: 0,
Result: [
{
Relevance: 1,
MatchLevel: "district",
MatchQuality: {
Country: 1,
State: 1,
City: 1,
District: 1
},
Location: {
...
Address: {
Label: "Centro, Nova Iguaçu, RJ, Brasil",
Country: "BRA",
State: "RJ",
City: "Nova Iguaçu",
District: "Centro",
PostalCode: "26052-060",
...
}
As you can see, the MatchQuality.City is 1, but the City returned is wrong ("Nova Iguaçu" instead of "Campos dos Goytacazes").
It seems the district "Centro" is being taken from another city, but the matchQuality says the city matched correctly (!)
Trying the same request without the district name returns the correct city in the Address:
Request:
https://geocoder.api.here.com/6.2/geocode.json?app_id=...&app_code=...&searchtext=Campos%20dos%20Goytacazes,RJ,Brazil
Response:
{
_type: "SearchResultsViewType",
ViewId: 0,
Result: [
{
Relevance: 1,
MatchLevel: "city",
MatchQuality: {
Country: 1,
State: 1,
City: 1
},
Location: {
...
Address: {
Label: "Campos dos Goytacazes, RJ, Brasil",
Country: "BRA",
State: "RJ",
City: "Campos dos Goytacazes",
PostalCode: "28010-550",
...
}
Thanks!
The matchLevel clearly states for the first request as 'district' which means it exactly matched 'Centro' as a district and fetch the details of that district(the city, country etc it belongs to).
searchtext request attribute is a free form text and matchquality in the response doesn't provide the quality of the values provided in it. Matchquality returns 1 for country,state and city since they have matched them exactly for the Centro district.
If you need matchquality to exactly say the relevance for the city you have provided then you should explicitly mention city attribute in the request.
See https://developer.here.com/documentation/geocoder/topics/resource-geocode.html for the entire list of request attributes possible.
Hope this helps!
city
xs:string A country specific mapping is required. Example,
USA: City
Germany: Gemeinde
country
xs:string, exact match Specify the country or list of countries using
the country code (3 bytes, ISO 3166-1-alpha-3) or the country name.
This is a strict filter. Results are restricted to the specified
country or countries.
Note: To avoid ambiguity we recommend to specify the country with the
3-letter ISO code and not with the spelled out country name. With
names there is a higher risk of misspells and also not all language
translations for all countries are supported.
I want to receive a dollar amount in my utterance. So, for example, if I ask Alexa:
Send $100.51 to Kroger.
(pronounced, One hundred dollars and fifty one cents) I want to receive the value 100.51 in a proper slot.
I have tried searching and I defined my utterance slots like this:
"slots": [
{
"name": "Amount",
"type": "AMAZON.NUMBER"
}
]
But on JSON input I only get this result:
"slots": {
"Amount": {
"name": "Amount",
"value": "?"
}
}
How can I make Alexa accepts currency values?
I'm a bit confused by what you wrote in your last sentence and the code, but I'll confirm that there is no built-in intent or slot for handling currency.
So, you'll have to do it manually using AMAZON.NUMBER slot type as you seem to be trying.
I would imagine that you will want to create utterences with two AMAZON.NUMBER slots - one for dollars and one for cents.
Easy, make a custom slot and just use $10.11, $.03, and $1003.84 as the sample's. It will work as currency now, accepting users dollars and cents utterances and converting them to a dollar $XX.XX format.
A beginner's question about freebase:
I am looking for the imdb id of a movie called "O". If I use the searchbox on the freebase.com website and constrain the search by type to all:/film/film, then I get a high quality result with the best match on top:
http://www.freebase.com/search?query=o&lang=en&all=%2Ffilm%2Ffilm&scoring=entity&prefixed=true
But this does not include the imdb id. When I try to recreate and refine this search using the query editor, I can't figure out how to do a "general query". The best I could come up with was doing a fuzzy name search like this:
[{
"type": "/film/film",
"name": null,
"name~=": "o",
"imdb_id": [],
"rottentomatoes_id": []
}]
The result contains exactly the information I want, but the movie "O" is only the 12th result in the list, buried under lots of nonsense:
http://www.freebase.com/query?lang=%2Flang%2Fen&q=[{%22type%22%3A%22%2Ffilm%2Ffilm%22%2C%22name%22%3Anull%2C%22name~%3D%22%3A%22o%22%2C%22imdb_id%22%3A[]%2C%22rottentomatoes_id%22%3A[]}]
How can I improve the quality of my result? What special magic does the "?query=o" use that "name~=":"o" does not have?
When you use query=o, freebase does some smart sorting of the results, display exact matches first, followed by less exact matches.
With your query name ~= o you are not searching for movies with name "O", but for movies that contain "O" in their names (the ~= operator). If you want to search for a specific movie title, then specify the exact name:
[{
"type": "/film/film",
"name": "o",
"imdb_id": [],
"rottentomatoes_id": []
}]
This will result in output:
{
"result": [{
"imdb_id": [
"tt0184791"
],
"name": "O",
"type": "/film/film",
"rottentomatoes_id": [
"o"
]
}]
}
If Search gives you the topic that you want, why not just use the output parameter to add the IMDB ID (or whatever else you want) to the output that you request it return?