Trip planning on Android phone turned off for now
onebusaway.org
onebusaway.org
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).
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.
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.
Modifying your query, I get 563 results: https://query.wikidata.org/#SELECT%20DISTINCT%20%3Fschool%20...
Conclusion: it depends on how you count.
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 .
}This makes OSM data a non-starter in most serious business 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).
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
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]
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).
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.
Maybe something like: One Bus Away trip planning sunk by Google API Monetization
This is the code, not particularly helpful: https://github.com/OneBusAway/onebusaway-android/blob/7b63b3...
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...
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.
> 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...
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.
https://www.geekwire.com/2015/onebusaway-creator-brings-seat...
OneBusAway should cut off Google’s data feed in return; it would only be fair to.
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.
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.
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?
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'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.
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.
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'.
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.