Let's keep photography and mapping mashable
Many people have suggested that I submit some of my many aerial photos to Google Earth. I'd love to do that, but after looking at the instructions for adding photos, especially the "acceptance policy", I have to wonder if it's worth the effort, or even the Right Thing To Do.
First, I have to upload photos into Paroramio, which was bought by Google earlier this year.. Since I've already uploaded 17,310 photos into my Flickr account, I'm not in the mood to do that again, least of all into a silo'd service — which Panoramio appears to be, while Flickr is not... at least not as much as Panoramio.
Thanks to Flickr's openness, every one of my many photo sets on Flickr is also usable in a complementary service provided by Tabblo. That's why every one of my tabblos (montages) are composed of shots I've already uploaded to my Flickr account.
I love that Tabblo and Flickr both recognize that the online photo marketplace is bigger than both of them, that the photos in their archives are the property of their contributors, and that those photos should be under those contributors' control. Open APIs such as Flickr's allow users (or customers) to move photos form one service to another, on an as-needed basis. In the argot of the Identity Gang, the customer gets to federate his or her own photographs between different photo services. (Federation is a kind of sharing with the user's or customer's permission.)
But Google Earth appears to be forcing me to upload to Panoramio, if I'd like my photos to appear in Google Earth.
Now, in an ideal world — that is, one where the Net is truly symmetrical, peer-to-peer and end-to-end — I would rather do the federating myself, from my own photo archive, with my own APIs. That way I could federate selected photos to Flickr, Tabblo, Panoramio and whomever else I please. In fact, that would probably make things easier for everybody. But that's a VRM (vendor relationship management) grace we don't enjoy yet. In the absence of that, we need more open APIs between services such as these, so customers' photos can be shared at the vendor-to-vendor level.
Then there's the "acceptable use" business. Panoramio says "not selected" photos include thirteen bulleted items, including "Underwater or aerial photos similar to the satellite images from Google Maps". Well, most of the images I'd like to submit are taken from airplanes, at heights ranging from runway level to 40,000 feet. None are from the heights enjoyed by satellites, and very few are shot straight down, in the manner of satellite photos, since they're shot looking out the windows of passenger planes. Still, the rule says similar to. What is that?
I could go to the trouble of setting up a Panoramio account and try my luck after a few uploads, but I don't want to waste what little time I have. That's one thing I love about Flickr. The labor and time involved in posting and commenting on photos is very low. Tabblo has also made it very easy to assemble montages of photos, and to print them out in various ways. I'd like to see Panoramio and Google Earth operate in the same market-friendly mash-em-up way.
Maybe they do and I don't know it. Ya'll can help me with that.
Meanwhile, the photo/mapping market is a (literally) moving one for me. Specifically, I'd like to geotag every photo I take that's within sight of GPS satellites. I have two Garmin handheld GPSes and two little portable bluetooth GPS receivers that can transmit raw data to devices that know what to do with it. Far as I can tell, those do not include my Canon 30D digital SLR. They do include some Sony Cybershot cameras, however. I know that because somebody loaned me a Sony GPS-CS1, which is built to use only where Windows and Sony proprietary silos intersect, so it's useless to me. But still, its existence points the way toward geotagging of everything that might require it.
The politics of APIs are are not easy or uncomplicated. (Follow that last link to visit one example.) But I would think that services built on Linux and other open components — as are Flickr and Tabblo (haven't checked on Panoramio yet) — would veer strategically toward making photography and mapping as mashable as possible. I'd like to encourage that.
So I'll stop there and let the rest of you fill me in on what's open, what's not and where you think the whole photo/mapping market needs to go as the technologies of both increasingly intersect and overlap.
Doc Searls is Senior Editor of Linux Journal
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Tech Tip: Really Simple HTTP Server with Python
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Doing for User Space What We Did for Kernel Space
- Rogue Wave Software's Zend Server
- Returning Values from Bash Functions
- Google's SwiftShader Released
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide