We need to display meta information (e.g, address, name) on our site for various venues like bars, restaurants, and theaters.
Ideally, users would type in the name of a venue, along with zip code, and we present the closest matches.
Which APIs have people used for similar geolocation purposes? What are the pros and cons of each?
Our basic research yielded a few options (listed in title and below). We're curious to hear how others have deployed these APIs and which ones are ultimately in use.
Fwix API: http://developers.fwix.com/
Zumigo
Does Facebook plan on offering a Places API eventually that could accomplish this?
Thanks!
Facebook Places is based on Factual. You can use Factual's API which is pretty good (and still free, I think?)
http://www.factual.com/topic/local
You can also use unauthenticated Foursquare as a straight places database. The data is of uneven quality since it's crowdsourced, but I find it generally good. It's free to a certain API limit, but I think the paid tier is negotiated.
https://developer.foursquare.com/
I briefly looked at Google Places but didn't like it because of all the restrictions on how you have to display results (Google wants their ad revenue).
It's been a long time since this question was asked but a quick update on answers for other people.
This post, right now at least, will not go into great detail about each service but merely lists them:
http://wiki.developer.factual.com/w/page/12298852/start
http://developer.yp.com
http://www.yelp.com/developers/documentation
https://developer.foursquare.com/
http://code.google.com/apis/maps/documentation/places/
http://developers.facebook.com/docs/reference/api/
https://simplegeo.com/docs/api-endpoints/simplegeo-context
http://www.citygridmedia.com/developer/
http://fwix.com/developer_tools
http://localeze.com/
They each have their pros and cons (i.e. Google Places only allows 20 results per query, Foursquare and Facebook Places have semi-unreliable results) which can be explained a bit more in detail, although not entirely, in the following link. http://www.quora.com/What-are-the-pros-and-cons-of-each-Places-API
For my own project I ended up deciding to go with Factual's API since there are no restrictions on what you do with the data (one of the only ToS' that I've read in its entirety). Factual has a pretty reliable API, which as a user of the API you may update, modify, or flag rows of the data. Facebook Places bases their data on Factual's, just another fact to shed some perspective.
Hope I can be of help to any future searchers.
This is not a complete answer, because I havn't compared the given geolocation API, but there is also the Google Places API, which solves a similiar problem like the other APIs.
One thing about SimpleGeo: The Location API of SimpleGeo supports mainly US (and Canada?) based locations. The last time I checked, my home country Germany doesn't has many known locations.
Comparison between places data APIs is tough to keep up to date, with the fast past of the space, and with acquisitions like SimpleGeo and HyperPublic changing the landscape quickly.
So I'll just throw in CityGrids perspective as of February 2012. CityGrid provides 18M US places, allowing up to 10M requests per month for developers (publishers) at no charge.
You can search using a wide range of "what" and "where" (Cities, Neighborhoods, Zip Codes, Metro Areas, Addresses, Intersections) searches including latlong. We have rich data for each place including images, videos, reviews, offers, etc.
CityGrid also has a developer revenue sharing program where we'll pay you to display some places as well as large mobile and web advertising network.
You can also query Places via the CityGrid API using Factual, Foursquare and other places providers places and venue IDs. We aggregate data from several places data providers through our system.
Website: http://developer.citygridmedia.com/
Related
I've been updating and moving my massage business website to Wordpress. During SEO process I interested and decided to include some structured data but I'm bit confused how to do it properly. I'm going to test that stuff first on my current site.
I'm going to present information with JSON-LD and I've been reading alot of schema-org manuals and blog posts about the schemas, still they are bit vaque to me.
How much data should I provide?
I still would like to present list of services we provide and price range by currency/min/maxPrice and persons data who are working there (name, profession, phone).
Would it be wise to put that data in the <head>-section of every page?
Or just specific data to page that they relate to like staff info to "Contact Us" page and service list to "Services" page?
Is there any penalty or down sides to have all that data on every page?
How do I present personal courses that every person has taken or other studies?
How do I present those services?
Can business under that HealthAndBeautyBusiness handle 3 phone numbers with names or should I just put contact info under person's data?
Does it matter in which order I present that data?
The more data you provide, the better
Better to be specific, otherwise it could be interpreted as spam. The structured data should be closely related to the content of the page itself
You mean the employees? You could use the employee property and the alumniOf properties but that doesn't match it very well. I think such data is a bit too detailed to be described at the moment - I would omit it for the time being
List them as offers, see makesOffer property
I would limit it to 1 number
The order doesn't matter
In the future try to split your questions, would be much easier to answer them that way.
I'm going to present information with JSON-LD and I've been reading alot of schema-org manuals and blog posts about the schemas, still they are bit vaque to me.
In regards to this statement. If I were you, and I'm not, therefore I can only assume you are just learning about technologies such as json-ld and how they relate to the bigger picture that is the Semantic Web also known as Web 3.0.
It sounds like you are on the right track I would suggest additionally reading articles relating to api's as well as the http request life cycle.
-Happy Coding
I am creating an inventory app currently for iPhone using Parse for companies to keep track of all of their tools, supplies, inventory. Now I'd like to allow for the user/company when adding a new item to their database for them to have the option to search from a pre-made database of items such as for a construction company when adding a simple Dewalt Drill Battery to their inventory would search the pre-made database for "Dewalt #DC9096 18V XRP 2.4A Battery" or an office would search for pencils by brand/serial number/name. I am looking for a simple way to make a database or even a table containing multiple brands products including their prices, product specifications, website for ordering more, company website, warranty phone number, etc... I have considered parsing all of the retail websites for information but don't know the legalities behind it and if the websites change then I'd need to update code. If there is ANY (easier/better) way to do this then assistance or direction would be great!
Thanks always
I would not go down the route of trying to parse websites, that will be a huge pain in the neck and impossible to maintain unless you have extensive resources (and as you mention it probably violates most site's terms of service anyway). Your best bet would be to hook into existing product databases via an API, such as Google's Search API for shopping, or maybe Amazon's API. Here's where you can start if you wanted to use Google:
https://developers.google.com/shopping-search/
Hopefully that gets you going in the right direction.
Edit: Here's a list of a lot more shopping APIs that could be good options:
http://www.programmableweb.com/apis/directory/1?apicat=Shopping
If you did find yourself needing to parse many different vendor websites (we'd call this "screen scraping") and you have the legal right to do so, you should use a tool like SelectorGadget to get your XPaths, it's much faster, easier and less error-prone than doing it by hand.
If you're doing more than a couple websites, though, you'll probably find that you'll have to update the scraping rules pretty often, it definitely won't be a set-and-forget operation.
We are developing an application that utilizes several of the supported place types in the Google Places API. But, we have noticed that the supported type, restaurant code, is different from the restaurant info you would find at the bottom page of a Google page on a smart phone. Example; the restaurant info given from a smart phone provides restaurant details and location. The one listed in Google Places API does not show the same info. Please inform us how we can obtain the codes for the same info that’s provided on the Google page from a smart phone. Is it free or part of a premium deal with Google? Thanks, and I hope this is clear.
Arthur
The Google Places database is different from Google Maps.
I'd imagine that at some point, Google would unite the two.
You could match by lat/long & name. This would probably work for at least half the time. The other half means the name & lat/long from both databased maybe a little different.
More specifically, what factors determine the priorities they assign in response to a given query? I'm looking for answers that address numerous scenarios including queries that...
Specify the "type" of result (objects such as users, posts, pages, etc. or connections like friendships, likes, tags, etc.),
Have authentication tokens as well as ones that don't.
Have conditionals such as "since" and "until."
Don't even specify a type, such as this search for the word query.
I am actually working on an app that uses /search to search places and I use a bit of all scenarios. I couldn't write down a specific order they appear in and to be honest I highly doubt it's something as easy.
I'm 99% sure it works like the Search in Facebook does, using the user data to bring up the most relevant results. I live in Ireland for 2 years now, but while testing the app I constantly receive search results from Romania and actually close to my Hometown, which are relevant to me.
Regarding your observations, Facebook's algorithms might take into account the source of the request as well - which would be good, means it only improves as your app gets more users.
While brainstorming about six years ago, I had what I thought was a great idea: in the future there could be webservice standards and DTDs that effectively turn the web into a decentralized knowledgebase. I listed several areas where I thought this could be applied, one of which was:
For making data avail. directly from a business's website: open hours, locations, and contact phone numbers. Suggest a web service standard by which businesses have a standard URL extended off the main (base) URL for there website, at which is located a webservice. That webservice as well has a standardized set of services for downloading a list of their locations, contact telephone numbers, and business hours.
It's interesting looking back at these notes now since this is not how things have evolved. Instead of businesses putting this information on only their website then letting any search engine or other data aggregator to crawl it, they are updating it separately on their website, their Facebook page, and Google Maps. Facebook and Google Maps, due to their popularity, have become the solution to the problem I though my idea would solve.
Is the way things are better than the way I thought they could be? If so then why doesn't my idea fit the reality? If not then what's holding my idea back from being realized?
A lot of this information is available via APIs, that doesn't mean that it doesn't get put other places as well, through a variety of means. For example, a company may expose information via an API, and their Facebook app might use that API to populate a Facebook page.
Also, various microformats are in use that encapsulate some of this information.
The biggest obstacle is agreeing on what meta-information should be exposed, how it should be exposed, and how it should be accessed.