47 comments

[ 2.8 ms ] story [ 154 ms ] thread
> ... thanks to Brian Ferris, who created the popular OneBusAway app before being hired by Google in 2011.

https://www.geekwire.com/2015/onebusaway-creator-brings-seat...

That OneBusAway existed first and provided its technology to Google makes this all the more obnoxiously arrogant, but that’s to be expected from Google these days.

OneBusAway should cut off Google’s data feed in return; it would only be fair to.

OneBusAway doesn't provide data to Google and presumably never did (I don't know and the article doesn't say); the data is provided by the bus service. Both OneBusAway and Google consume it.
Obviously the parent meant that the transit providers should do this, since they also use OBA.

More generally, in the same way IXs have peering arrangements for traffic, there could be peering arrangements between data owners (e.g. bus location providers) and location API providers like Google.

This is wrong on so many levels. This is anti competitive behavior. Google built their business by scraping data from other websites.
They're asking for this API access for free whereas most customers have to pay. I am not sure Google would cut off API access if they were willing to pay.

My experience with the Places API is that it is terrible. We used to use it for our Internet signup form, and there was no way to restrict the address autocompletion to addresses. So people would hedge a little and only type the street, which Google considers a "place", but obviously we don't know if we have availability on a long street or not (it was a per-building service), so we returned "unavailable" when really the answer was "there is no way we can tell you whether or not there's service there". We looked at some OSM-based solutions and those were just as bad. So I have the feeling that there is some opportunity for a competitor here, perhaps that will be their next project.

They could show ads to pay for the API usage. I'd be ok with that. After all, it's not free for Google to host its service. Somebody has to pay, and Google really doesn't have an obligation to make it free.
The bus companies could provide a free tier of data to Google, like one bus line, and after that Google Maps users would have to watch bus company ads for 30 seconds if they wanted to know where the bus was. After all, it costs money to track all those busses.
A lot of cities don't have any transit timetables at all on Google Maps, let alone realtime bus tracking, simply because the bus company considers it's timetables to be copyright, and wants licensing money to use them commercially, which Google is unwilling to pay.

Those cities usually have local route planning apps, of various levels of craptastic-ness. When travelling round the world, trying to figure out which app is good for local public transit is always on my checklist next to 'buy local data sim' and 'figure out which currency they use here and what the exchange rate is'.

That is Google using their network effect to reap the cash, they know everyone has Maps installed.

If the metro transport companies weren't so dumb and greedy they would pool their dev resources more, but I think they get suckered by signing contracts for outsourced app dev where they don't get IP rights, because that company is planning to sell the same code to 10 different customers. It usually gets tied up with the payments system (like Oyster/Octopus etc) and the morass of legacy embedded equipment.

If metro companies could act collectively they could make transit data available with an API key, which would at least allow better apps.

Can someone change the title to put some context in? As it is, it does not summarize the key issue here.

Maybe something like: One Bus Away trip planning sunk by Google API Monetization

2.3M trips / 7300 users / 30 days is more than 10 trips per day.

When I took the bus in DC, each trip was 45-75 minutes long (12 mile route, during peak traffic) not counting wait times. Zero transfers.

Who has time for 10 bus trips, plus wait times, per day?

“Planned” vs “taken”.

I usually plan trips through several different routes when I don’t know the route, and maybe take one trip. I don’t need an app to plan routes for my daily commute.

It says that's how many trips were "planned", not taken.

It's an interesting UI study to see how many trips were planned vs. taken, though. When I use Google Maps to plan a trip, the leave/arrive times are usually wrong, so I have to adjust those. It's kind of a pain to type in a time, so I hit the "+ 30 minutes" button a bunch of times until I get to the desired time. So if this is a trip for 6 hours later today, that's going to be 12 trips planned vs. 1 taken.

Don't depend on Google's APIs. Please use OpenStreetMap data with (and contribute to) OpenMapTiles, OpenTripPlanner, Pelias geocoding etc.
So I've tried to use OpenStreetMap but it's hard to ditch the business directory that Google Maps has built in. Are you aware of any open source / crowd sourced directory of physical businesses? It seems like such a thing could exist but I don't know what all is out there.
> Are you aware of any open source / crowd sourced directory of physical businesses

Yep that's OpenStreetMap! You could use Pelias for geocoding, OSM for the data. Why not offer for users to add the business to OSM if it doesn't exist?

I think Foursquare also has a directory, I'm not sure what their costs are though (and closed of course).

Having investigated the use of OpenStreetMap data in the past year, I have to say that it's still disappointing and not complete enough to be used as a serious solution.

If I look at university nodes that have a website in France I find 241 unique values which represents less than 10% of the total amount.

Typically, there is no perfect data source and their applicability depends on your use cases. OpenStreetMap is first about streets, then (geometries of) buildings, POIs etc. An attribute like website information has not been high on the use cases that the community has but I think this is getting better with more use and especially the integration with Wikidata.

In Wikidata, I can currently get 563 results for institutes of higher education in France with website information: https://query.wikidata.org/#SELECT%20DISTINCT%20%3Fschool%20...

EDIT: Applied the fix by yorwba to get more results.

You need to add an asterisk after wdt:P279, otherwise the query only finds instances of direct subclasses of Q38723. On the other hand, I didn't think to filter only for those that have an associated website. (See sibling comment.)

Modifying your query, I get 563 results: https://query.wikidata.org/#SELECT%20DISTINCT%20%3Fschool%20...

Conclusion: it depends on how you count.

Thanks for noticing and fixing my bug!
Are you sure there are more than 2410 universities in France? Running the SPARQL query below at https://query.wikidata.org/#SELECT%20%28count%28DISTINCT%20%... , I get 218 French universities with a Wikidata item (which usually means there's a corresponding Wikipedia article) but for "higher education institution" I get 675: https://query.wikidata.org/#SELECT%20%28count%28DISTINCT%20%...

Query:

  SELECT (count(DISTINCT ?school) AS ?count)
  WHERE
  {
    # find instances of subclasses of university Q3918 (use Q38723 for higher education institution)
    ?school wdt:P31/wdt:P279* wd:Q3918 .

    # in France
    ?school wdt:P17 wd:Q142 .
  }
It varies a lot by location. Some places are kept up to date by contributors and some aren't.
The chicken and egg problem is that OSM will be as good as the data it gets, and the data it gets will increase as people use it as a serious solution and contribute where they find it inadequate.
Sure, but companies have the money to contribute a subscription but not time, because the later is incredibly more expensive for them.

This makes OSM data a non-starter in most serious business use cases.

So do you think OSM servers are free to run and won't have to be paid for?
OSM source data is not the same thing as infrastructure owned by OSM Foundation. You can self host maps based on OSM with much flexibility (Though Mapbox is easier to use and now has easy-to-grasp pricing that also doesn't discriminate use cases).

Yeah, freeriders are a problem for OSMF raster map tile servers, but there is now no excuse not to use any of the above two solutions (self hosting or 3rd party APIs).

OSM is data, not servers, which is why a number of companies use OSM data and give you the ability to pay them to use their servers. Thunderforest, for instance.

But the point is that you can use the same data they use to make your own tile server if you like. And if you update the OSM data we will all benefit

If you don't need street-level geocoding, the GeoNames [0] project providers their data free of charge (attribution required). It provides city and district level data, which is suitable for tasks such as displaying the location name of photos or rental listings.

Self plug: I wrote a Node library a few years ago to use this data offline. It builds a SQLite database, which is small enough to be suitable for embedding into applications. [1]

[0] http://download.geonames.org/export/dump/readme.txt

[1] https://github.com/lucaspiller/offline-geocoder

This seems like a reasonable place to ask this: Is there an alternative available to Google Places Text Search? E.g., I provide a query that's something like "hardware stores" and a location and I get back a list of hardware stores within the location?

As far as I can tell, the geocoding APIs from stuff like MapBox or Pelias aren't intended for this use case (more like finding a specific hardware store).

At least Nominatim can answer such queries, for example: https://nominatim.openstreetmap.org/search.php?q=hardware+st...

I don't think it would be difficult to implement in Pelias either considering that it already has the necessary data and can search for results closest to a given point or within an area.

We at NetToolKit have implemented arnath's requested functionality using OpenStreetMap data (demo available at https://www.nettoolkit.com/geo/autocomplete). The problem that we have found is that while some categories have great coverage (e.g. restaurants in Portland), many categories do not (e.g. gas stations). Assembling this data is expensive, and hence either the data is available via well-capitalized players (e.g. Facebook Places Search: https://developers.facebook.com/docs/places/web/search/) and/or are expensive to use (e.g. Foursquare).
I think Foursquare offer pretty much exactly that. They pivoted a while ago to focus on B2B location API stuff.
Didn't they just recently pivot to doing place reviews instead of check-ins?
I got a presentation by Google on API management last week and was surprised that someone thought they'd be a good example on the subject.
What’s ironic is that Google enforced a rule that Apple hasn’t had for over eight years but people still falsely accuse Apple of having....
Not quite; Google's rule is you can't _use their APIs_ to create a product substantially similar to Google's products.
Almost anything you write for Android will be using at least some of their APIs.

When the policy was in affect back in 2010 for Apple, I remember a good podcast player was pulled. It used Apple’s open API to their podcast directory. FWIW, anyone on any platform now can use Apple’s podcast directory to build their own podcast app without paying Apple a dime.

I'm not sure what API they are using. The cheapest Places SDK API call is a plain autocomplete and it's still $2.27 per thousand requests. https://cloud.google.com/maps-platform/pricing/sheet/. They say it would cost $1000/mo, but then there are 2.3 million requests in the past 30 days, which would be $5221/mo using the $2.27 price. I guess there could be a volume discount but they don't mention it.

This is the code, not particularly helpful: https://github.com/OneBusAway/onebusaway-android/blob/7b63b3...

(comment deleted)
Google offers Volume pricing for the Geocoder service above 500,000 monthly requests.

https://developers.google.com/maps/documentation/geocoding/u...

The geocoding API is also the most expensive at $5/1000req normally.

I think this is the Geocoding code?

https://github.com/OneBusAway/onebusaway-android/blob/8eeda8...

The Geocoding API is free on Android: https://stackoverflow.com/questions/8218764/android-geocoder...

Presumably Google would like to change this at some point but it'll be difficult since it's built into Android proper rather than the Play SDK or similar.

Those results are from 2011-2013, it is no longer free as of July 29, 2019. [0]

> To translate points-of-interest names (e.g. “Airport”) and addresses (e.g., “1234 Anywhere Dr.”), the team selected the Google Places SDK, which was free to use for Android apps.

> In 2019, Google decided to start charging for use of the Places SDK on Android – a cost of around $35 per day (around $1000 per month). We pleaded our case to Google and were directed to apply to the Google for Nonprofits program

[0] https://developers.google.com/places/android-sdk/usage-and-b...

So isn't this what we want? For Google to charge for services instead of funding them with our data? Or is the surprise here about just how much it costs to run these services?
But with Google it’s both ways: they want the money and still will collect / sell your data.
>instead of funding them with our data?

What gives you the impression that they're going to stop profiting off our data? If anything, this is them double-dipping. We get the worst of both worlds.