Waze sued for allegedly stealing data from another navigation app
Well I’m not sure how much this had to do with Waze being owned by Google or not but PhantomAlert is suing Waze.
Before the advent of GPS and navigation apps, cartographers sneaked “paper towns” and “trap streets” into their maps—fake points of interest that they used to detect plagiarism. If someone copied their map, it would be easily identifiable through the inclusion of those locations. That same trick has found its way into modern-day mapping systems: A new lawsuit brought against Google and its traffic app Waze cites sham points of interest as evidence that the Google-owned service copied from a competitor’s database.
Apparently these two companies tried to make a deal before Google snapped up Waze and PhantomAlert is alleging that Waze used their database to “boost its profile”. One of the biggest concerns in the OpenStreetMap community is allowing these intentional mistakes into their database. Copyright Easter Eggs is well documented on the OSM website.
A Copyright Easter Egg, in terms of mapping, is a feature that is drawn in a distinctive way in order to help identify its original author. It may be a nonexistent, or slightly or heavily distorted, map feature, or its name may be wrongly or unusually spelt.
The supposed main purpose of such a feature is to strengthen the author’s case in a copyright dispute. If he can show that his own unique feature appears in the defendant’s work, it is easier to prove that the defendant’s work is a copy of his.
google_logo
Hey look, I got to use the new Google logo already!
Yea so if this is true, PhantomAlert has a pretty good idea that Waze stole their data and it could mean big trouble for Google. Having a closed database like this opens Waze up to these kinds of lawsuits because they are unable to have the community police the data. The big question is was this data imported into Waze intentionally or by accident. I don’t think the latter will get them off the hook but if there was intent it could be costly. We’ll have to see. The Waze byline about “outsmarting traffic, together” might not be too smart.
Rendering Spatial Data Without Having to Generalize Beforehand
Yesterday I posted about Chris Hogan’s walk-through of generalizing data in PostGIS to make it usable in a web app. Basically he went through the process of finding out what is the sweet spot of quality vs speed. But there are other ways to accomplish this. Mapbox happened to post about a new library called geojson-vt.
Let’s see if Mapbox GL JS can handle loading a 106 MB GeoJSON dataset of US ZIP code areas with 33,000+ features shaped by 5.4+ million points directly in the browser (without server support):
https://www.vimeo.com/137819760
Mapbox GL JS and GeoJSON-VT from Mapbox on Vimeo.
Wait, what?! A few seconds loading the data, and you can browse the whole data set smoothly and seamlessly. But how exactly does that work? Let’s find out
So that’s actually pretty amazing. We all know what GeoJSON does in the browser and how it impacts the speed of maps drawing. 100 MB+ data rendering so quickly? Impressive. Read the whole post to see how they do it and the details on how to start using it. The only limitation is that it requires mapbox-gl-js or
Mapbox Mobile[footnote]which is actually a big limitation if you think about it[/footnote]. UPDATE: Per Tom MacWright:
https://twitter.com/jamesmfee/status/639163210659041280
Mapbox-Graphic
Still this comes down to using tools that make your mapping products better. Maybe Mapbox does that cheaper and quicker than you could on your own. This kind of on-the-fly simplification is what we’ve all been asking for and Mapbox is really pushing the envelope. This could be what gets people to start using their platform.
Rendering Spatial Data Without Having to Generalize Beforehand
Yesterday I posted about Chris Hogan’s walk-through of generalizing data in PostGIS to make it usable in a web app. Basically he went through the process of finding out what is the sweet spot of quality vs speed. But there are other ways to accomplish this. Mapbox happened to post about a new library called geojson-vt.
Let’s see if Mapbox GL JS can handle loading a 106 MB GeoJSON dataset of US ZIP code areas with 33,000+ features shaped by 5.4+ million points directly in the browser (without server support):
https://www.vimeo.com/137819760
Mapbox GL JS and GeoJSON-VT from Mapbox on Vimeo.
Wait, what?! A few seconds loading the data, and you can browse the whole data set smoothly and seamlessly. But how exactly does that work? Let’s find out
So that’s actually pretty amazing. We all know what GeoJSON does in the browser and how it impacts the speed of maps drawing. 100 MB+ data rendering so quickly? Impressive. Read the whole post to see how they do it and the details on how to start using it. The only limitation is that it requires mapbox-gl-js or
Mapbox Mobile[footnote]which is actually a big limitation if you think about it[/footnote]. UPDATE: Per Tom MacWright:
https://twitter.com/jamesmfee/status/639163210659041280
Mapbox-Graphic
Still this comes down to using tools that make your mapping products better. Maybe Mapbox does that cheaper and quicker than you could on your own. This kind of on-the-fly simplification is what we’ve all been asking for and Mapbox is really pushing the envelope. This could be what gets people to start using their platform.
Google now offers pay-as-you-go for Google Maps API
Seriously right? About time! Most users of Google’s Maps API are caught between the free tier and the “I wish I had a business model to pay for the premium tier” pricing. But Google has figured this out and introduced a new way to pay for the Google Maps API.
Today we’re introducing a simple and flexible option for developers to instantly and easily scale with these Web Service APIs, by opening them up to pay-as-you-go purchasing via the Google Developers Console. In this new purchasing structure, the Google Maps Geocoding, Directions, Distance Matrix, Roads, Geolocation, Elevation, and Time Zone APIs remain free of charge for the first 2,500 requests per day, and developers may now simply pay $0.50 USD per 1,000 additional requests up to 100,000 requests per API per day. Developers requiring over 100,000 requests per day should contact us to purchase a premium licence.
This is huge because now you’ll know what you’re paying for the API rather than wait for that huge bill at the end of the month. Knowing what things are going to cost is key to building spatial applications. Provide your billing details and build away!
Google now offers pay-as-you-go for Google Maps API
Seriously right? About time! Most users of Google’s Maps API are caught between the free tier and the “I wish I had a business model to pay for the premium tier” pricing. But Google has figured this out and introduced a new way to pay for the Google Maps API.
Today we’re introducing a simple and flexible option for developers to instantly and easily scale with these Web Service APIs, by opening them up to pay-as-you-go purchasing via the Google Developers Console. In this new purchasing structure, the Google Maps Geocoding, Directions, Distance Matrix, Roads, Geolocation, Elevation, and Time Zone APIs remain free of charge for the first 2,500 requests per day, and developers may now simply pay $0.50 USD per 1,000 additional requests up to 100,000 requests per API per day. Developers requiring over 100,000 requests per day should contact us to purchase a premium licence.
This is huge because now you’ll know what you’re paying for the API rather than wait for that huge bill at the end of the month. Knowing what things are going to cost is key to building spatial applications. Provide your billing details and build away!
10 Years Ago on Spatially Adjusted - “Stop Putting Commercial Software in ESRI ArcScripts”
10 years ago this week Katrina had rolled in and there were lots of posts on Spatially Adjusted about Digital Globe and Google Maps imagery being updated for the flooding. But the post that caught my attention was this one on ArcScripts:
Can someone at ESRI please clean up the ArcScripts site? Plain as day on the ESRI ArcScripts upload page it says “Not for samples or demos of products sold at Web sites”. There are way too many products that are commercial in there and this latest one takes the cake. 15 days and then you have to buy it, what a joke. If you have to advertise, do it by buying ad space, not polluting the ArcScripts gallery. Geospatial Enterprises is off my list of companies I’ll deal with. XTools Pro 3.0 is also a commercial product that tries to get around by offering some free tools, but it too is just a demo. Someone over at ESRI needs to get serious about cleaning this junk up and off the ArcScripts.
I mean how shady was XTools Pro anyway? The original XTools on ArcView 3.x was open, free and a great tool. Then some guys basically rebranded it for ArcGIS Desktop and started charging money for it. Oh well, the madness of ArcScripts is over as well as the need for tools like XTools is over. Still funny to think this was how we shared scripts and applications back then. No Github or other platforms to help. Life was so hard back then and we didn’t realize it!