Slashdot Mirror
Google Maps API Becomes 'More Difficult and Expensive' (govtech.com)
Government Technology reports:
On July 16, Google Maps is going to make it more difficult and expensive to use its API, which could make custom maps that rely on the service less sustainable or even unfeasible for the people who made them... First, Google Maps is requiring all projects to have an official API key in order to work. If a user doesn't have a key, the quality of the map will likely be reduced, or it could simply stop working. Second, API keys will only work if they are attached to somebody's credit card. Google will charge that card if users exceed a certain number of API requests, which is different for different services. Google will provide users a free $200 credit toward those costs each month...
There are a couple places where the changes might have more of an impact. One is in the civic hacking space, where people often work with government data to create niche projects that aim for low costs, or are free so that as many people as possible can use them... "I think that's what scares people a little bit, it certainly scares me, this thought of having this API out there and not knowing how many people are going to use it," said Derek Eder, founder of the civic tech company DataMade. "I don't want to suddenly get a bill for $1,000."
There's at least three Open Source alternatives, and Geoawesomeness.com lists nine more.
Slashdot reader Jiri_Komarek also points out that Google's move was good news for its competitor, MapTiler. "Since Google announced the pricing change the number of our users increased by 200%," said Petr Pridal, head of the MapTiler team. "We expect more people to come as they get their first bill from Google."
There are a couple places where the changes might have more of an impact. One is in the civic hacking space, where people often work with government data to create niche projects that aim for low costs, or are free so that as many people as possible can use them... "I think that's what scares people a little bit, it certainly scares me, this thought of having this API out there and not knowing how many people are going to use it," said Derek Eder, founder of the civic tech company DataMade. "I don't want to suddenly get a bill for $1,000."
There's at least three Open Source alternatives, and Geoawesomeness.com lists nine more.
Slashdot reader Jiri_Komarek also points out that Google's move was good news for its competitor, MapTiler. "Since Google announced the pricing change the number of our users increased by 200%," said Petr Pridal, head of the MapTiler team. "We expect more people to come as they get their first bill from Google."
I salute Google's desire to migrate their users to open-source mapping alternatives. They're not just paying lip service to the idea, they're putting their money where their mouth is.
Or foot, anyway...
Once you kill off all the map competitors, its only natural you would then raise prices.
Turns out nobody actually likes ads and Google needs new ways to make money.
Is anyone really surprised?
Provide the service, either free or inexpensively for many years until everyone is depending on it, then start billing.
The same thing has happened with Twitter and its API, which is becoming a fuckton more expensive in a month or so. It's important to remember, whenever you use a resource, no matter what it is, that is provided for free or way below what its market value would be, that eventually that will change, and to be ready for that.
The only positive thing about this is that this may push more people towards Openstreetmap.
After years of faithful map overlay on the local public University's weather map had to be replaced because of this shift by Google. https://atmos.washington.edu/w...
I recently started getting pop-ups from YouTube, requesting me to sign-up for an "Ad-free YouTube experience." You guessed it right; yes, they wanted a credit card while signing up.
Then I later learnt that to get an enhanced YouTube, (one in which video remains visible even as I scroll through comments), I needed to provide a credit card.
Google are becoming greedy, and I don not like it very much.
I was about to learn GoogleMaps for a community project I have been thinking about. Since it won't generate revenue but will generate lots of hits on mobile and desktop users this means my plans to learn more about the GoogleMap API are out the Window.
BingMaps and MapQuest look very unprofessional but shit. Damn it
http://saveie6.com/
And where are you now?
-=This sig has nothing to do with my comment. Move along now=-
A) You don't let things get down to a single source for your data
B) You don't let that single source get too big
.
== WolfriderV6 == I'm willing to admit that *I just might* be wrong... Are you??
If you're relying on a service someone is providing you for free, and your project is complex, you should have at least two layers or modules in your project. Whatever the big chunks are, business logic , UI, data - whatever your big chunk of work is, separate that from the vendor. Maybe use a maps library that connects your data and logic to Google maps. Then you can switch to any other mapping system by only updating the library.
If you're using a ridiculously expensive solution from a vendor like Oracle, you should have at least two layers or modules in your project. Whatever the big chunks are, business logic , UI, data - whatever your big chunk of work is, separate that from the vendor. Maybe use a database layer that connects your data and logic to Oracle database. Then you can switch to any other database, including a much cheaper one, by only updating the database layer.
No matter how much you're paying, or not paying, it's a mistake to intertwine a lot of your work with any external project. Even if you control both projects, close coupling is normally a bad idea. One project will eventually become "legacy" and you'll want to use the X code with some new Y. So they should interact only through well-defined interfaces, and preferably that interface should be implemented as a distinct interface layer which can be replaced or rewritten.
A case in point is two products we develop at work. The same company runs both. I work on the internal engine, a different team does the UI. It was decided the UI should call upon not only out engine, but other things too. The interface is being changed from SOAP to REST*. Fortunately, we put all of our SOAP stuff in a dedicated SOAP module, so we can switch and not touch 99% of our code. We just replace the SOAP module with a REST module and we're done.
* Not actual REST, as in RESTful. Really we're just putting the parameters in the query string and calling it REST. People who actually understand REST architecture would laugh at us.
+1 Funny (if I only had mod points)
for things that aren't inherently profitable (e.g. the "civic hacking" space) you need to have the government run it. Just like we do with the Post Office. A universal map system seems useful enough to me that we'd do that, but hey, what do I know?
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
You don't have to worry about an unexpected bill if you set your account quota to not exceed the free service. It's annoying that isn't configured that way by default or more obvious to do, but it's not that hard and I've already done it.
This space intentionally left blank
That's nice, but there's a specific problem with trying "too hard" to decouple the database (EVEN IF you're using DAOs) when using Oracle or MySQL: both databases effectively force you to use strategies for optimal (or even merely ACCEPTABLE) performance that tend to be mutually-exclusive. Just about the hardest thing you can DO is take an application that works well with Oracle & port it to MySQL... or vice-versa. It's a literal *nightmare*.
Fifteen years ago, I worked for a startup that had an app almost ready for customers. We got venture-capital funding, and the new CEO's first decree was that we had to switch to Oracle to impress the next round of investors. It almost sank the company. Seemingly every single thing we'd done to make the app run well with MySQL broke horribly under Oracle.
Admittedly, InnoDB, maturation of MySQL itself, and the ANSI-compliance it picked up a few years later probably improved things... but ONLY if you limit yourself to ANSI-approved SQL from the start. It's still very possible to optimize a database in MySQL-specific ways that will bite you badly if you ever try to switch to another database. And frankly, if you can get acceptable performance from MySQL *without* deviating from ANSI-approved SQL, there's probably no sane REASON to switch to another DB.
In other words, the things MySQL practically forces you to do to get far enough to HAVE to change databases to escape some bottleneck will eventually fuck you horribly when you actually go to do it.. DAO-abstraction or not.
Would you hardcode user interface code into your database, things like "radio button color=orange" or "textfield length=16", in your database procedures? Of course not. So why in the world would you hardcode SQL code into your application? That's actually just as crazy, though more common.
For most any moderate to large application, it's a good idea to have at least these layers, which communicate through well-defined interfaces:
UI - Design this as though it will be replaced by a web UI, or an app, or something else. Because it probably will be. This layer is only what's visible on the user's screen.
Business logic - this is where you have code that makes sure you can't sell an item you no longer stock, etc. It defines which operations can and can't happen, under which conditions, and in which order - regardless of which UI is trying to do it. Compliance rules are a sub-module here.
AAA - authorization, authentication, and accounting sits close to the business logic layer, controlling who can do what to what.
Data operations (CRUD) - this layer creates, reads, updates, and deletes items from the database. It doesn't have the business logic. Business logic is the layer above. All this layer does is add, remove, update, and delete operations that have *already* been approved and ordered by the logic layer. This is pretty much just simple INSERT, DELETE, etc statements. It can be implemented as stored procedures. As you mentioned, ANSI SQL should be preferred when it makes sense, to avoid being tied to one specific version of one specific RDBMS.
I write SQL code that is specific to a certain vendor - in my stored procedures. Our company rule is that SQL is not allowed in any application, or anything other than a stored procedure, period. If and when we switch to MariaDB. MySQL, or Postgres, I only have to touch my sprocs, and only those where I had a good reason to not use ANSI SQL. I shouldn't have to look at the business rules or application logic, those are separate layers.
Ps for a larger application or system, it's likely some logic / rules apply to the subject of the application (roughly, the data) while others are application-specific. If there is a chance other applications may someday operate on the same items, it can make sense to split domain logic from application logic.
An example - "students may not receive a diploma until their bill is paid". That's domain logic, it doesn't matter which application is trying to print or mail the diploma. "No more than two copies of the diploma may be printed" is application logic, it's not inherent to the subject entities, but rather applies only to this application.
I just looked at my billing account and it says I have $23K transition credit. I'm guessing that's what they plan on charging me every month or so.
I'm assuming the new pricing goes into effect midnight on 7/16 California time, can anyone verify that? I'm going to be scrambling until then.
I think the Esri map looks better. Oh well Google.
-- I have a private email server in my basement.
They haven't killed competitors.
I can actually understand why they did something like this, although I would have suggested a rate limit on a 'free' tier instead.
An example is, I heard a complaint from a city public transport agency. They had a phone app using this, and were railing against the new charges.
Turns out their app, which people have open for planning routes, and sitting waiting for busses/trains/etc, is written insanely and was re-requesting EVERYTHING
every 5 seconds while the app was running, so they were generating millions of API calls, to service a few thousand users...
They were trying to make a big public fuss about this, claiming google was evil. Perhaps they should just fix their damn app.
Of course the new solution isnt great either, a rate controlled free tier would be sensible, plus clear ways to limit your total exposure.
But I suspect there are a hell of a lot of maps API 'apps' that are just as retarded, and that the traffic/cost has become huge enough that they decided to do something.
OMG GUYS!!!! WE SLASHDOTTED IT!!!! WE DID IT!!!!!!
How many YEARS has it been since we could to this?
WE ARE SLASHDOT. WE ARE LEGION. WE RISE ONCE MORE!!!!!*
*When pointed to .edu sites with no cloudflare- or AWS-like services to mirror them.
Velociraptor = Distiraptor / Timeraptor
Killed the competition? Nah.
I noticed that one of the sites, Vice? Engadget?... listed Google alternatives and couldn't offer anything for maps but 'OpenStreetMaps'. He didn't even list "Here" Maps, despite having the best navigation and best offline apps.
Maps.here.com is my goto for mapping, and it has an API:
https://developer.here.com/
It's owned by German car makers and was the former Nokia maps. It is readable, so you can actually see the streets on the map on a screen instead of everything being white on beige. It works, is up to date and fast.
But more to the point, its not Google and doesn't add to their pile of private data for sale.
It's not easy, but fortunately you wouldn't be the first to do it. Others have done it, documented the process, published tips and tricks, and even scripts for it.
MySQL can even federate to different types of RDMS, so you can migrate one table at a time.
>Just getting the data out of the old database and into the new could take hours and hours and hours.
Just like copying files to a new server, or any bulk data transfer, here's a tip to minimize downtime. Copy over the data while the old system is running. It's okay if that takes hours or days; the old system is up. Then copy over the changes that happened in those hours - that'll take minutes. Then shut off the old system and start copying over the changes that occurred in the last few minutes. That'll take maybe 60 seconds to copy over. Then turn on the new system. All the data is synced up with 60 seconds of down time.
Again, it's a tough problem, but it's a *solved* problem. Others have figured out how to to do it and how NOT to do it, and already scripted a lot of it for you.
The government does just fine when two conditions are met:
a. The contract isn't just handed out to somebody's brother in law. Independent watchdog groups can, well, watch for this. And it's also a problem for private businesses too, btw.
b. One of the parties (who shall go nameless) isn't actively trying to sabotage things by either underfunding or by allowing the contract holder to skip out on doing the actual work. This is what happened with the Obamacare website launches. Eventually the contractors were called to task, some were fired, and the sites started working just fine.
tl;dr: If you put people in charge of gov't who don't think gov't works don't be surprised when gov't doesn't work. It's like putting a young earth creationist in charge of your fossil dating research. It ends badly.
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
Look around for who can do maps. A gov, another project, another brand. Be ready to swap over to any of them for when an ad company starts to set up a new price structure.
Domestic spying is now "Benign Information Gathering"
Given how self-confident and satisfied were Tim Cook and Apple teams when Apple Maps was released 6 years ago [ they even got rid of the Google Maps app ] while it was a bugged, inaccurate and feature-lacking disaster, I wouldn't rejoice too soon.
Slashdot, fix the reply notifications... You won't get away with it...
Keys are tied to a domain. They only work on pages served from that domain.
Serioualy, 1 out of 5 because:
1: You can't see fuck all in daytime outside - a place where you're quite likely to be using a MAP ffs. The contrast is abysmal, everything is light pastels, what kind of utter fucking moron says yeah, that's a good idea for a map. (yes I have a bright screen, but sunshine is much brighter).
2: Google uses street codes instead of road names, people in my country don't use these codes anywhere other than on motorways and large A-roads. The streets here have the road names at the end of most roads, they do not say shit like B2673.
3: Roads without code don't show names at all without a lot of faffing about zooming in and out and panning until you (sometimes) find the name. It's a complete waste of time.
4: Google deliberately never ever remembers anywhere you ever went in any useful way, sure I expect they actually remember everywhere you went and store that forever. Stick in a postcode, close the app, open the app 10 seconds later, stick in the very same post code and Google Maps has a memory worse than a dead geriatric.
5: Searching for locations can be piss-poor slow and will happily fail. It's pretty obvious google doesn't like people using it's service for free, the more you use it, the slower it gets and fuck you if you're not using the latest version of google maps or android.
6: It crashes often. About 1 in 5 times for me.
7: A new one, shitty annoying notifications - Adverts for things you pass on the map. The last thing you want when your navigating is your phone having random notifications, I've wasted time on several occasions pulling over to make sure it's nothing important, thanks google you arseholes. I did manage to turn these off (I think).
8: Extraneous bandwidth killing unwanted map features you can't turn off, IE 3D buildings. I don't need that.
9: That's just off of the top of my head, there's no doubt more.
Waterfox - a Firefox fork with legacy extension support, security updates and better privacy by default.
They now want a photo of your drivers license.
I don't mind the credit card because I've been using the product in a commercial service. But the drivers license is too far. I've stopped including a map with the data service.
Openstreetmap, it turns out is not "open", even more restrictive for commercial use.
Google wants, needs to push people in directions to meet the needs of their advertising revenue. If just anyone can add really useful information, that breaks the model. That model is also more responsible than Facebook and others, for the widening gap between political viewpoints. Get people, through the echo chamber, to be more divided and you have easier demographic divisions to market to.
-- I ignore anonymous replies to my comments and postings.
Indeed. Caching is not a new concept.
I have a locator system I built for a client. They have many companies they work with (around 4000 just in the US) to provide sales and service for their products.
As locations are added or modified it uses the Google Maps API to verify the address and get latitude & longitude points and store them in a database.
When a user on the public website looks for locations around them, they type in their address/city/zip code and it then plots the locations on a map and provides a list of locations below the map, and calculates orders them by proximity.
We implemented caching on the public side so if the same city or zip code (but not specific addresses) are searched we already have the reference point to calculate against.
With caching we currently get around 4500 queries a day, I suspect it would be around double that without caching.
How is a little university weather map even coming close to hitting the limits on the API?
I've done some pretty significant databases, both for government agencies and private sector. You can keep hard-coding SQL right into your PHP, mixed in with your UI code, if you want to.
If you prefer your systems be able to be portable between not only different RDMSs, but even just different UI modules working on the same data, look at how Moodle does it, for example. Moodle works with many different database systems. Moodle modules (application code) calls functions like "lookup_student". They don't hardcode a select statement everywhere that the logic or UI needs data. In turn, "lookup_student" calls âget_db_record()". It's get _db_record() that differs a bit between MySql, posgres, MS-sql, etc.