Google Here Never Was

Indoor mapping is the white whale of our Spatial IT industry.  We’re always reading about how our smartphones will lead us to the best deals or how I can find the specific nail I need in Home Depot without having to ask anyone or walk down every aisle.  They key to all this is essentially iBeacon.

You can search Google News for all the latest excitement on the concept but essentially it is a way for your phone to know where things are and for the vendors to know where you phone is through Bluetooth.  Imagine walking into a store and getting alerts about your favorite beer being on sale and then the ability to navigate directly there.  Sexy right?  Plus we’ve been anticipating this happening for years.  Except

Google was set to launch a new product that added context to one of its most successful apps, Google Maps. But earlier this year, it was shut down by Alphabet CEO Larry Page, according to people familiar with the project.

Google Here worked by sending a notification to a smartphone user’s lock screen within five seconds of their entering a partner’s location. If the user clicked on the notification, a full screen HTLM5 “app” experience would launch. Google Here would know when to send the notification via Google Maps and beacons placed in the stores of participating partners. Google planned to supply the beacons to partners for the launch, according to the document. The experience could also be found by going to the Google Maps app.

Exactly what we though everyone wanted.  In testing the application was deemed too invasive and Google feared no retailers would sign up.  That’s right, Google didn’t think could get their partners to install cheap beacons in their stores AND they feared they were too big brother.  Seems weird doesn’t it, if there is one company that can get companies to spend money on ads, it is Google.  And since when did Google ever think pushing ads on us was “invasive”?

The magic about Google Here (Here as in not Here that was owned by Nokia) was that you didn’t need an app running for it to work.  Think about that for a minute, ads would appear on your phone based on where you where and you didn’t need to opt in to get them.  Now we see why Google was very concerned that Here was going to get a large backlash.  Being able to push ads on users would have been something they really could have sold well to companies, I’m not sure there would be any fear of companies not wanting to push ads on us.

Beacons are still very important to Google. Their Eddystone project talks about lots of uses of beacons but not for ad delivery.  Clearly there was feedback on this project and it jolted Google out of their normal sell more ads business model.  I think beacons will be very valuable as they start appearing in more areas, but I for one don’t need to get an ad for fabric softener every time I walk into a Target.

Chris Hogan on PostGIS generalization

Says Chris:

I am working on a project that needs to display all the neighborhood polygons in Baltimore City at one time. The file is relatively detailed… which mean that tons of unnecessary polygon nodes are being sent from the backend, when, at the zoom level and the level of detail the map users need, the high level of detail is a total waste.

While there are some great hosted options to serve up complex GeoJSON, most of the time it is better served (no pun intended) to simplify your data.  Unless you’re surveying or involved with some sort of lawyer, even a bit of generalization is a good idea with online mapping.  Chris does a great job showing how you can modify the tolerance to get your results to look great and save lots of bandwidth.  If you’re a generalization newbie, you should read his example and get a better understanding of how it works.

And if you’re an Esri user, the same concepts can be used in their stack as well.

.

GIS and Git

Yesterday I had a long post about GIS and version control.  I mentioned Git in the article saying how maybe in the future Git would work with GIS files.  A couple of people mentioned an article written by Gretchen Peterson titled, “Huge increase in shareability by combining Git and QGIS”.

This isn’t the version control you’re looking for…

Gretchen does a great job showing how you can manage GIS projects with Git and I encourage everyone to read it.  But keep in mind it isn’t version control how I was talking.  Git doesn’t understand shapefiles and other binary GIS files.  It will show that a shapefile was updated, but it won’t show what you updated in it, nor will it help reconcile updates.  Gretchen is using Git to help her share projects with others which it does a great job.  But it isn’t geodata version control and she outlines that clearly in the post.

We all would love to see Github support shapefiles, but I seriously doubt it will ever happen.   For how you can use Github and GeoJSON files which isn’t half bad.