I'm trying to build a form that lets a user enter an address as easily as possible.
The way I had it before is you would choose a country, and then a list of provinces/states is populated, you choose one of those, and then type the name of the city.
However, I think this could be made easier. A lot of apps (ex. Facebook events) allow you to just type the name of the city, and then the country/province can be inferred, so I'm trying to build something like that.
I live in BC, Canada, so I'm starting with that. Looking on Wikipedia, there are a number of "cities" that are left out, such as Delta, which is a fairly big region over here. It should probably be included in the list, because in colloquial conversations, people usually say I live in "Delta" or something, even though it's not really a city. So maybe I should actually use municipalities which seem to be a superset of the cities.
But then we've left out places like Ladner, which is actually a sub-region of Delta, but now I'm worried I'm getting too specific?
Thoughts?
Also, this is just Canada. I have to include the United States as well. I'm not sure if the states are divided up quite the same way, how fine-grained should I go there, fellow Americans?
If you were trying to get the weather, or time, or trying to look up a location, and were presented with a form, how fine-grained would you expect it to recognize?
As an American, all I usually care about is City and State. Maybe an option to omit the city and fill in County/Region like you were talking about above would be appropriate, as not everyone lives near enough to a city to really claim to be from there. The only issue is you'd have to keep track of all of these in your database, and keep them updated. I'm not really sure how to go about that.
For the United States, check out the USPS City State File. This will never get all the common place names, but should cover most incorporated cities, townships, municipalities, etc (and a few unincorporated places as well).
Related
I'm trying to find out which are the main tourist attractions in a city or country, I found this Google website called Things to Do (link) that does exactly what I want. I trying to get this data with Google Maps API, but I haven't being able to find these results anyhow.
I'm using Paris as an example because clearly first place most be Eiffel Tower and the web I mentioned says so. I'm using calling https://maps.googleapis.com/maps/api/place/textsearch/json?query=paris+point+of+interest&rankby=prominence but I don't even get Eiffel Tower in the 60 results the API returns.
Someone have some experience trying to do something similar or knows what maybe my problem?
I've been playing around with something similar and I don't think it's particularly easy to get sensible results with the Places API.
As far as I can tell the rankBy option you're using only applies to the nearbysearch endpoint. See the documentation here. However that type of search is based on specific coordinates with the radius limited to 50km. That's fine for local or specific city searches but not so much for wider regions and countries.
The point+of+interest textsearch query you're using isn't too bad but the quality of the results is mixed and seem to get worse the wider the search area you use. For example, if you use query=australia+point+of+interest the top result looks to be the Principality Stadium in Cardiff, UK.
So far the best search criteria I've found covering city and country regions is with things+to+do as part of the query instead, e.g. https://maps.googleapis.com/maps/api/place/textsearch/json?query=things+to+do+paris
The top results for that include Arc de Triomphe, Sacre Coeur, Champ de Mars, Louvre Museum and Eiffel Tower which is a bit more like what you'd expect. The textsearch endpoint doesn't have any sorting available but if you look at enough results you might be able to sort yourself based on something like the rating and user_ratings_total fields in the response.
I am building a small application for an english speaking client in Japan. As part of the app, users need to be able to enter their address. Unfortunately, I can't find any reference for how addresses are usually handled in an online form.
I know that there are different combinations of wards/prefectures/cities; do these all usually have their own field in a database? Is it standard for all of that to go into a general "city" type of field? What's the standard UI for this sort of thing?
The Universal Postal Union has compiled info on address formats in different countries. See also an unofficial guide to postal addresses.
But as a rule, internationalization of software typically means that for postal addresses, you avoid imposing any specific format. Instead, you would use a free-form text input area, of sufficient size. There are often many forms of addresses used in a country (and Japan is no exception), and normally you need not enforce any specific format – instead, you expect people to know their own address and how to enter it so that postal services can understand it.
it depends on what you have to do with the address:
if you have to:
check for obligatory fields
validate fields, or
query for city, prefecture, postal code, etc.
then you should use separate fields. UI: a form with text-inputs (and maybe even menus).
do not use more fields than necessary, so if you don't have any of the mentioned needs, just use a text-field (UI: textarea).
The first part of a Japanese address is easy: Todofuken will either be 2 or 3 characters, followed by either "都","道","府" or "県". Where it gets tricky is the rest of the address since smaller areas don't always divide their cities neatly.
What I've seen to make this easier is using the postal code to render the address. The bad news is that I haven't seen any of this in Ruby but I have seen it in other languages so hopefully this will help.
This site is only in Japanese, but maybe you can download the code and check it out:
http://www.kawa.net/works/ajax/ajaxzip2/ajaxzip2.html
There's also this add-in for Excel that converts addresses. The code may be helpful to you:
http://office.microsoft.com/ja-jp/excel-help/HP010077514.aspx
Hope this helps.
Many things can have phone numbers and addresses. . . people, places, etc. You want phone numbers and addresses to have the same functionality, format and validation whether it is a phone number or address for a person or a place etc.
Is it going to far to create a phone number class, and an address class, and use them in those objects that have phone numbers and addresses?
My question goes to other properties as well that could be reuseable across diverse objects.
Yes, you can go too far and this is borderline. I tend to draw the line at the point where it becomes cumbersome to treat things as more than a string, or another already defined class/type.
If you need to somehow manipulate phone numbers (by, for example, separating them into area code and other bits) or addresses (number, street, city, country and so forth) then, yes, consider making them objects.
I rarely do anything with phone numbers or addresses other than store and display them, in which case they're fine as strings without having to have their own dedicated class. For addresses, I don't even impose a separation based on parts (except maybe the zipcode), preferring free-format entry so as to not annoy those with addresses of a format I don't know about.
Going the reductio ad absurdum route, you could also objectify the characters that make up your phone number but that would be silly.
I think it would be perfectly acceptable. A well designed class will allow you to reuse it in many different projects. If you have many projects that could use this sort of functionality, using an object is the perfect way to ensure that your code is reusable and portable. The extensibility and the potential for you to extend the functionality of your class to handle anything phone number/address related would be unmatched by a set of functions or once off code you rewrite over and over.
In the end it's your call, personally I think it would fall under good practice though.
You need an Entity Class and Address Class.
Entity can be person, place, organisation, coffee shop kinda, whereas Address can capture Phone number, emailid, Lat/Long kinda stuff.
Keeping Entity and Address will help you across diverse objects.
and having many to many relation ship among entity and address would help, having loose coupling wud help on long run.
Lately we've started getting issues with outdated countries / regions list being presented to users of our web-application.
We currently have a few DB tables to store localized country names along with their regions (states). However as the planet goes, that list is in constant evolution and it's proving to be a pain to maintain as some regions are deleted, some merged - existing data needs to be updated all the time.
What are, if any exist, the best practices when it come to dealing with multi-locale countries/regions list?
Is there a place or a standard in place? I know of ISO 3166, but their list isn't exactly DB friendly ... plus it's not fully localized.
An ideal solution would simply allow us to "sync" to it? Preferably in multiple language. The solution would preferably be free or subscription based with an historic of what changed so we could update our data (aka tblAddress)
Thanks!
geonames is pretty accurate in this respect, and they update regularly.
http://www.geonames.org/export/
There is no such thing. This is a political issue, which you can only solve in the context of your own application. Deciding to use ISO 3166 could be the easiest to defend. I know of issues with at least:
China/Taiwan
Israel/Palestine
China/Tibet
Greece/Macedonia
The ISO lists here are DB friendly, though they only include short names and codes.
This one looks very good: Multiple languages, update option, database independent file format for import, countries/regions/cities information, and some other features you might use or not.
And it's quite affordable if you need it for only one server.
You can try CLDR
http://cldr.unicode.org/
This set of data is maintained by the Unicode organization. It is updated regularly and the data is versioned so it is easy for you to manage the state of your list.
Hy! you can find a free dump of all countries with their respective continents https://gist.github.com/kamermans/1441495, its much easy to use.just download the dump & upload in your data base.
Well, wait, do you just want an up-to-date list of countries? Or do you need to know that Country X has split into Country Y and Country Z? Because I'm not aware of any automated way to get the latter. Even updates to the ISO databases are distributed as PDFs (you're on your own for implementing the change)
The EU maintains data about Local Administrative Units (LAUs) which can be downloaded as hierarchical XLS files in several languages.
United Nations Statistics Division, Standard country or area codes for statistical use (M49).
Look for "Search and Download: Full View" on page left. That leads here.
Groups countries by continent, sub-continental region, Least Developed Countries, and so on.
If you cannot import the excel version, note that the csv has unquoted" fields and a comma in one country name that will bust your import ("Bonaire, Sint Eustatius and Saba"). Perhaps open it first in LibreOffice or whatever, fix the broken country name and shunt its other right-most columns back into place. Then set all cells to type Text, saveAs csv with [Edit Filter Settings] checked [x] in the saveAs dialog, and make sure string delimiter is set to ", as it should be by default.
I am designing a contact management system and have come across an interesting issue regarding modeling geographic locations in a consistent way. I would like to be able to record locations associated with a particular person (mailing address(es) for work, school, home, etc.) My thought is to create a table of locales such as the following:
Locales (ID, LocationName, ParentID) where autonomous locations (such as countries, e.g. USA) are parents of themselves. This way I can have an arbitrarily deep nesting of 'political units' (COUNTRY > STATE > CITY or COUNTRY > STATE > CITY > UNIVERSITY). Some queries will necessarily involve recursion.
I would appreciate any other recommendations or perhaps advice regarding predictable issues that I am likely to encounter with such a scheme.
You might want to have a look at Freebase.com as a site that's had some open discussion about what a "location" means and what it means when a location is included in another. These sorts of questions can generate a lot of discussion.
For example, there is the obvious "geographic nesting", but there are less obvious logical nestings. For example, in a strictly geographic sense, Vatican City is nested within Italy. But it's not nested politically. Similarly, if your user is located in a research center that belongs to a university, but isn't located on the University's property, do you model that relationship or not?
Sounds like a good approach to me. The one thing that I'm not clear on when reading you post is what "parents of themselves" means - if this is to indicate that the locale does not have a parent, you're better off using null than the ID of itself.
I think you might be overthinking this. There's a reason most systems just store addresses and maybe a table of countries. Here are some things to look out for:
Would an address in the Bronx include the borough as a level in the hierarchy? Would an address in an unincorporated area eliminate the "city" level of the hierarchy? How do you model an address within a university vs an address that's not within one? You'll end up with a ragged hierarchy which will force you to traverse the tree every time you need to display an address in your application. If you have an "address book" page the performance hit could be significant.
I'm not sure that you even have just one hierarchy. Brown University has facilities in Providence, RI and Bristol, RI. The only clean solution would be to have a double hierarchy with two campuses that each belong to their respective cities in one hierarchy but that both belong to Brown University on the other hierarchy. (A university is fundamentally unlike a political region. You shouldn't really mix them.)
What about zip codes? Some zip codes encompass multiple towns, other times a city is broken into multiple zip codes. And (rarely) some zip codes even cross state lines. (According to Wikipedia, at least...)
How will you enter the data? Building out the database by parsing conventionally-formatted addresses can be difficult when you take into account vanity addresses, alternate names for certain streets, different international formats, etc. And I think that entering every address hierarchically would be a PITA.
It sounds like you're trying to model the entire world in your application. Do you really want or need to maintain a table that could conceivable contain every city, state, province, postal code, and country in the world? (Or at least every one where you know somebody?) The only thing I can think of that this scheme would buy you is proximity, but if that's what you want I'd just store state and country separately (and maybe the zip code) and add latitude and longitude data from Google.
Sorry for the extreme pessimism, but I've gone down that road myself. It's logically beautiful and elegant, but it doesn't work so well in practice.
Here's a suggestion for a pretty flexible schema. An immediate warning: it could be too flexible/complex for what you actually need
Location
(LocationID, LocationName)
-- Basic building block
LocationGroup
(LocationGroupID, LocationGroupName, ParentLocationGroupID)
-- This can effective encapsulate multiple hierarchies. You have one root node and then you can create multiple independent branches. E.g. you can split by state first and then create several sub-hierarchies e.g. ZIP/city/xxxx
LocationGroupLocation
(LocationID, LocationGroupID)
-- Here's how you link Location with one or more hierarchies. E.g. you can link your house to a ZIP, as well as a City... What you need to implement is a constraint that you should not be able to link up a location with any two hierarchies where one of them is a parent of the other (as the relationship is already implicit).
I would think carefully about this since it may not be a necessary feature.
Why not just use a text field and let users type in an address?
Remember the KISS principle (Keep It Simple, Stupid).
I agree with the other posts that you need to be very careful here about your requirements. Location can become a tricky issue and this is why GIS systems are so complicted.
If you are sure you just need a basic heirarchy structure, I have the following suggestions:
I support the previous comment that root level items should not have themselves as the parent. Root level items should have a null value for the parent. Always be careful about putting data into a field that has no meaning (i.e. "special" value to represent no data). This practice is rarely necessarily and way overused in the devleoper community.
Consider XPath / XML. This is Something to consider for bother recording the heirarchy structure, and for processing / parsing the data at retrieval. If you are using MSSQL Server, the XPath expressions in select statements are perfect for tasks such as returning the full location/heirarchy path of a record as the code is simple and the results are fast.
For Geographic locations you may wish to resolve an address to a Latitude, Longitude array (perhaps using Google maps etc.) to calculate proximities etc.. For Geopolitical nesting ... I'd go with the KISS response.
If you really want to model it, perhaps you need the types to be more generic ... Country -> State -> County -> Borough -> Locality -> City -> Suburb -> Street or PO Box -> Number -> -> Appartment etc. -> Institution (University or Employer) -> Division -> Subdivision-1 -> subdivision-n ... Are you sure you can't do KISS?
I'm modeling an apps for global users and I have the same problems, but I think that this approach could already be in use in many enterprise. But why this problem don't have an universal solution? Or, has this problem one best solution that can be the start point or anybody in the world need think in a solution for it since beginnig?
In IT, we are making the same things any times and in many places, unfortunately. For exemplo, who are not have made more than one user, customer or product's database? And the worst, all enterprise in the world has made it. I think that could have universal solutions for universal problems.