As many cities are known by their common/popular names like Madras is still used to search instead of chennai, same for gurgaon. I have cityindex where I have stored documents containing city info, I wan't to search for documents based on their common names. What should be the best approach for the same ?
Related
For country and state, there are ISO numbers. With City, there is not.
Method 1:
Store in one column:
[Country ISO]-[State ISO]-[City Name]
Method 2:
Store in 3 separate columns.
Also, how to handle city names if there is no unique identifier?
First and foremost, three separate columns to keep your data. If you want to create a unique identifier, the easiest way would be giving a random 3-10 digit code depending on the size of your data set. However, I would suggest concatenating [country-code]-[state-code]-[code] if you have a small data set and if you want human readability to a certain point. code can be several things. Here are some ideas:
of course a random id or even a database row id
licence plate number/code if there is for a city
phone area code of the city or the code of the center
same logic may apply to zip codes
combination of latitude and longitude of the city center up to certain degree
Here are also more references that can be used:
ISO 3166 is a country codes. In there you can find codes for states or cities depending on the country.
As mentioned IATA has both Airport and City codes list but they are hard to obtain.
UN Location list is a good mention but it can be difficult to gather the levels of differentiation, like the airport code or city code or a borough code can be on the same list, but eventually the UN/LOCODE must be unique. (Airport codes are used for ICAO, similar to IATA but not the same)
there are several data sets out there like OpenTravelData or GeoNames that can be used for start but may require digging and converting. They provide unique codes for locations. And many others can be found.
Bonus:
I would suggest checking Schema.org's City Schema and other Place Schemas for a conscious setup.
Here's the challenge. Users want to be able to create filters based on N-criteria and the criteria being used for the filter is a fluid heirarchy. To simplify it, let's use two hierarchies that the user could select from:
All Territories
Europe
UK
France
Americas
US
Canada
Mexico
Media
Music
Downloads
CDs
Movies
Streaming
DVD
Objects would have a table of tags associated with them. The ObjectsTags table would contain an indicator as two which type of data the tag is linked to
The issue is that user would want to select and group the tags they want to filter by. So they might want Movies in Europe so they would select those three tags as a single grouped filter. It's easy enough to get a filter based on those three tags that says:
Any object that has a tag of: (All Territories OR Europe OR UK or FRANCE) AND (All Media OR Movies OR DVD OR Streaming). The challenge is that I need to support any number of new hierarchies that might be needed and any level of filters, since a user could also want a filter that returns everything from that filter as well as all of the CDs in the US.
Is there any new feature in SQL Server that would be better suited for handling this type of a where clause in a performant way?
You are either going to have to create your where clause dynamically, or you will pre-create the SQL using a where clause similar to the following:
where country = coalesce(p_country, country)
and media = coalesce(p_media, medias)
and music = coalesce(p_music, music)
The really cool part of this statement? Your performance will be the
worst that it can possibly be.
I recommend creating a dynamic statement with the specific conditions you need.
I'm trying to use Solr to re-rank document results based relevance to the user searching. For example, if I search joann*this could return documents where the Name field is anything from joanna to joanne. What I'm trying to do is to return documents that match on certain attributes that I have as well-- this could be something like us both having the field Location = "NYC".
So my question is two fold- is there a way to grab and handle a users information when they are making a query and also is there a way to re-rank based on these additional field values? Would this look more like writing some code or just an expanded query?
it looks to me like you are talking about functionality that Query Reranking exactly provides. Did you check that out?
I am performing a query using Google Places API to search for local restaurants
https://maps.googleapis.com/maps/api/place/nearbysearch/json?location=..lat,..lon&radius=..radius&type=restaurant&key=..key
However, I am receiving a lot of results for locations that are not primarily restaurants, for example:
Popular hotels with restaurants
Food delivery services
Night clubs
Department stores with dining
etc.
Ideally I would like to restrict my query to only a few types or prohibit certain types by query. Otherwise I would need to do this manually or find another service.
Just add the city name as a prefix in the search string. It will only give the search suggestions in which the user is searching.
eg, pass "NewYork" as a prefix in your search string, now type any word, it will only give you results for NewYork city restaurant, cafes, places, etc
As part of addresses I am storing in my SQL database country codes (e.g. US, DE,...). I then have another table (with two columns) in my database which translates the country codes to the English language names of the respective countries.
If I want to make the site multi-language, I could expand this translation table adding country names in other languages than English.
I was wondering if there is another method which does not involve modification of the database, e.g. using gettext to translate the English country names?
The typical way to handle this is to change the table structure to have three columns, instead of two:
Language
CounryCode
FullName
Whenever you query the database, you would provide the current language.
You then have to change your code to include the additional language key in any queries.
Depending on how you are going to keep track of the current language, you would also use a view or user defined function.
You don't want to use automated translation, since the name of a country like "China" could turn into the equivalent of "porcelain".