I am using google place to retrieve address, and somehow we want the street(route in google terminology) to be separated into street name and street type. We also want the street type to match an existing column in database.
But things get difficult when google place sometimes use XXXX Street and some times XXXX st
For instance, this is a typical google address
{
administrative_area_level_1: ['short_name', 'VIC'],
locality: ['long_name', 'Carlton'],
postal_code: ['long_name', '3053'],
route: ['long_name', 'Canada Ln'],
street_number: ['short_name', '12'],
subpremise: ['short_name', '13']
}
But it always shows Canada Lane in the suggestion box.
And sometimes even worse when the abbreviation does not match my local data model. For instance we use la instead of ln for short of lane.
It will be appreciated if anyone could tell me where to find a list of street type (and abbreviation) used by google API. Or Is there a way to disable the abbreviation option?
Sounds like you're after "street suffixes". These are complicated.
Not only they change across countries and languages, even within the same country and language they can be used in different ways; abbreviations can have multiple meanings: "St" can be "Street" of "Saint"; abbreviations are used or not depending on subtle rules that also change from place to place.
Same goes for cardinal points (North, South, East, West) that are parts of road / street names: "North St" or "N 11st Street"? It's complicated.
If you already have a good amount of addresses, and you only care about addresses in English, you could take the last word from each street name as the suffix. When matching to your own data, allow for abbreviations when matching, rather than trying to expand them.
For instance, don't try to expand "Canada La" into "Canada Lane" so that it matches "Lane". Instead, expand "Lane" into ["Lane", "La", "Ln"] and match suffixes to all values.
Then you'd need a strategy for "collisions", abbreviations that can mean 2+ suffixes. These seem to be rare, I can't remember any ("St" isn't, because "Saint" isn't a suffix) and USPS' http://pe.usps.gov/text/pub28/28apc_002.htm doesn't seem to have any.
Related
We've implemented the $match operation for patient that takes FHIR parameters with the search criteria. How should this search work when the patient resource in the parameters contains multiple given names? We don't see anything in FHIR that speaks to this. Our best guess is that we treat it as an OR when trying to match on given names in our system.
We do see that composite parameters can be used in the query string as AND or OR, but not sure how this equates when using the $match operation.
$match is intrinsically a 'fuzzy' search. Different servers will implement it differently. Many will allow for alternate spellings, common short names (e.g. 'Dick' for 'Richard'), etc. They may also allow for transposition of month and day and all sorts of similar data entry errors. The 'closeness' of the match is reflected in the score the match is given. It's entirely possible get back a match candidate that doesn't match any of the given names exactly if the score on other elements is high enough.
So technically, I think SEARCH works this way:
AND
/Patient?givenname=John&givenname=Jacob&givenname=Jingerheimer
The above is an AND clause. There is (can be) a person named with multiple given names "John", "Jacob", "Jingerheimer".
Now I realize SEARCH and MATCH are 2 different operations.
But they are loosely related.
But Patient-Matching is an "art". Be careful, a "false positive" (with a high "score") is/could-be a very big deal.
But as mentioned from Lloyd....you have a little more flexibility with your implementation of $match.
I have worked on 2 different "teams".
One team, we never let "out the door" anything that was below a 80% match-score. (How you determine a match-score is a deeper discussion).
Another team, we made $match work with a "IF you give me enough information to find a SINGLE match, I'll give it to you" .. but if not, tell people "not enough info to match a single".
Patient Matching is HARD. Do not let anyone tell you different.
at HIMSS and other events..when people show a demo of moving data, I always ask "how did you match this single person on this side.....as it is that person on the other side?"
As in "without patient matching...alot of work-flows fall a part at the get go"
Side note, I actually reported a bug with the MS-FHIR-Server (which the team fixed very quickly) (for SEARCH) here:
https://github.com/microsoft/fhir-server/issues/760
"name": [
{
"use": "official",
"family": "Kirk",
"given": [
"James",
"Tiberious"
]
},
Sidenote:
The Hapi-Fhir object to represent this is "ca.uhn.fhir.rest.param.TokenAndListParam"
Sidenote:
There is a feature request for Patient Match on the Ms-Fhir-Server github page:
https://github.com/microsoft/fhir-server/issues/943
I want to localize phrases like "Places in {country name}" where the country name is dynamically obtained (e.g. by -[NSLocale localizedStringForCountryCode:]).
The problem is that for some country names, an article must be prepended:
Places in the United States (en)
Sometimes in plural form, male or female, capitalized or not:
Lugares en los estados unidos (es)
Lugares en las Maldivas (es)
The article might even have to be declined according to the casus (nominative, dative etc) of the country name in the phrase:
Orte in der Schweiz (de)
Wir fahren in die Schweiz (de for "we go to Switzerland")
Or we even might might a different preposition:
Orte auf den Malediven (de, using "auf" instead of "in" because the Maldives are islands)
Is there either a library or a good set of rules (e.g. regular expression based) that one could use to accomplish this?
While I'm primarily searching for an iOS solution, I'm open to port any solution from other platforms.
This problem is best solved by avoiding it altogether: localise the entire phrases, and key them by the ISO country code.
The reason is that the rules are complex, not necessarily regular, and differ from language to language. Take Russian for example, where the country name itself (as opposed to just a preposition) has to be modified based on the casus in which the word appears in the sentence — I assume the same holds for various other Slavic languages.
This call https://maps.googleapis.com/maps/api/place/autocomplete/xml?input=qqqqqqq (plus your key) returns addresses like 'qqqqqqqqqq, Florida, USA' and 'qqqqqqqqqqqqqqqqqqqqqqqq - Luizote de Freitas, Uberlândia - State of Minas Gerais, Brazil'. I understand that QQQ might be a valid name, but qqqqqqqqqqqqqqqqqqqqqqqq? And it works the same way for any sequence of repeating letters or numbers.
Ok, let's say this is google having bad data. But how to explain results for 'www': 'Best Buy, Middlesex Turnpike, Burlington, MA, USA', 'Acton Toyota of Littleton, Great Road, Littleton, MA, USA'? I do not see any sane correlation between 'www' and the results.
You can see similar behaviour in google maps, so it's not just autocomplete API.
Any theories?
When I execute request https://maps.googleapis.com/maps/api/place/autocomplete/json?input=www&key=MY_API_KEY from my location I get really weird predictions as well
Montpellier, France (place ID ChIJsZ3dJQevthIRAuiUKHRWh60, type locality)
Berlin, Germany (place ID ChIJAVkDPzdOqEcRcDteW0YgIQQ, type locality)
Hamburg, Germany (place ID ChIJuRMYfoNhsUcRoDrWe_I9JgQ, type locality)
Munich, Germany (place ID ChIJ2V-Mo_l1nkcRfZixfUq4DAE, type locality)
Vienna, Austria (place ID ChIJn8o2UZ4HbUcRRluiUYrlwv0, type locality)
Note all of them have locality type, and indeed it smells like a bug, because I cannot see how on earth the text 'www' might match these predictions. Apparently, something is broken on Google backend and leads to the strange behavior in places autocomplete.
I can confirm that I can see this problem on Google Maps web site as well
At this point I believe the best option for us is sending a feedback to Google Maps team and hope they will fix it soon.
I have a problem, and besides it sounds trivial, it's not simple (for me) to find a straight forward, scalable and performatic solution. I have one input text where the website user can search for locations.
Today the location can be a city, a address in a city or a neighborhood in a city, and the user must separate the address or the neighborhood from the city using a comma, then it's easy for me to split the string and find if the first block is a address, a neighborhood or a city. If the user fails to fill the input with all the needed information, putting a address without a city, and I match more than a street with the same name, we show all the locations for him to choose the correct one.
Using the search log we find out that most of the users don't use the comma, even with all the tool tips pointing how to use the location search (thx google :p).
So, a new requirement for the location search is needed, to accept non comma separated addresses, like:
1. "5th Avenue"
2. "Manhattan"
3. "New York"
4. "5th Avenue Manhattan"
5. "5th Avenue Manhattan New York"
6. "Manhattan New York"
7. "5th Avenue New York"
But I can't find a way to find the meaning of each block or a dynamic way to make this work. Ie, if I get a string like "New Yok", "new" can be a address, and "york" can be a city.
My question is, is there some kind of technique or framework to achieve what I need or I will need to work my way in a algorithm (based on the number of words, commas, etc) to do that specifically?
Edit1:
Because I use SQL Server, I'm thinking about full text search multiple columns search, doing a exact match before and a non exact later. But I think some incomplete addresses will return thousands of rows.
Isn't the key that specificity decreases from left to right? That is, the right-most semantic element (whether "New York" or "Manhattan") is always the least-specific (if it's a Borough, then we don't have to worry about City, if it's a Street, we don't have to worry about Borough, etc.)
So reverse the tokens and recurse through, seeking either a complete hit ("Manhattan") or a keyword ("Avenue", "Street", "New") that indicates either the beginning or end of a semantic element. So after a pass, you might have:
"5th Avenue" -> TOKEN STREET_END_TOKEN
"Manhattan" -> BOROUGH
"New York" -> COMPOUND_BEGIN_TOKEN TOKEN
"5th Avenue Manhattan" -> TOKEN STREET_END_TOKEN BOROUGH
"5th Avenue Manhattan New York" -> TOKEN STREET_END_TOKEN BOROUGH COMPOUND_BEGIN_TOKEN TOKEN
"Manhattan New York" -> BOROUGH COMPOUND_BEGIN_TOKEN TOKEN
"5th Avenue New York" -> TOKEN STREET_END_TOKEN COMPOUND_BEGIN_TOKEN TOKEN
Which ought to give you enough to pattern-match against.
UPDATE:
OK, to expand on the general strategy:
Step 1 : Generate a pattern of the query structure by identifying keywords ("Manhattan"), and semantically-meaningful ("Street", "Avenue") or grammatically-significant ("New", "Saint") tokens.
Step 2: Match the generated pattern against a set of templates -- "* BOROUGH *" -> (Street) (BOROUGH) (City)", "* STREET_END_TOKEN" -> (Street name) (Street type), etc.
Step 3: The result of Step 2 ought to give you a sense of what kind of query you're dealing with. You'll have to apply domain rules at that point (if you know the complete query is TOKEN STREET_END_TOKEN then you know "Well, this is a query that just specifies a street" and you have to apply whatever rule is appropriate (grab the locale of their browser? Use their query history to guess which neighborhood and city? etc.)
iPhone has a pretty good telephone number splitting function, for example:
Singapore mobile: +65 9852 4135
Singapore resident line: +65 6325 6524
China mobile: +86 135-6952-3685
China resident line: +86 10-65236528
HongKong: +886 956-238-82
USA: +1 (732) 865-3286
Notice the nice features here:
- the splitting of country code, area code, and the rest is automatic;
- the delimiter is also nicely adopted to different countries, e.g. "()", "-" and space.
Note the parsing logic is doable to me, however, I don't know where to get the knowledge of most countries' telephone number format.
where could i found such knowledge, or an open source code that implemented it?
You can get similar functionality with the libphonenumber code library.
Interestingly enough, you cannot use an NSNumberFormatter for this, but you can write your own custom class for it. Just create a new class, set properties such as countryCode, areaCode and number, and then create a method that formats the number based on the countryCode.
Here's a great example: http://the-lost-beauty.blogspot.com/2010/01/locale-sensitive-phone-number.html
As an aside: a friend told me about a gigantic regular expression he had to maintain that could pick telephone numbers out of intercepted communications from hundreds of countries around the world. It was very non-trivial.
Thankfully your problem is easier, as you can just have a table with the per-country formats:
format[usa] = "+d (ddd) ddd-dddd";
format[hk] = "+ddd ddd-ddd-dd";
format[china_mobile] = "+dd ddd-dddd-dddd";
...
Then when you're printing, you simply output one digit from the phone number string in each d spot as needed. This assumes you know the country, which is a safe enough assumption for telephone devices -- pick "default" formats for the few surrounding countries.
Since some countries have different formats with different lengths you might need to store your table with additional information:
format[germany][10] = "..."
format[germany][11] = "....."