Google Earth Enterprise...

I have been using Google Earth Enterprise for a while- mostly from a consulting/developer/support role, not as someone that keeps a system running on a day to day basis. I also have to be careful with what I can and can't say about these things due to various agreements under which I am signed up.

Thus, it is cool to see someone who is a daily user blogging about it on a regular basis.

A recent post over there was asking about differences between working with GEE, versus other server GIS applications.

One point that I would add as a difference that takes a while for people that have a lot of experience in the ESRI world is that the build process is quite extensive. It takes quite a large amount of CPU cycles and disk space to build the base map data into the database- hence the reason for building the base data on some kind of weekly or greater frequency. (You use KML for stuff that changes frequently.) The payoff for this increased build time is the remarkable performance that users experience with the Google Earth application. Everything is really well precalculated for display, so you end up with a great user experience, at the cost of a not insignificant amount of labor on the back end to keep things moving. Still, it is something a lot of customers have taken some time to get their heads around, because they are used to expecting real time data in the base map. It's a very interesting architectural tradeoff analysis.

Data Monopoly, but open n-grams

I know people in the GIS community have been talking about the Digital Globe data deal with Google for a while, but it is interesting to see it begin to intersect with Tim O'Reilly's Open Data concept... One thought- at least when Google licenses data they show it to you- when the govt gets its hands on things. Still, an exclusive license on data does sound somewhat monopolistic. Will a future Google anti-trust case be fought over data?

"....portions of DigitalGlobe's imagery data has been licensed by Google for exclusive use in Google Earth/Maps.

...reminding us of Tim's argument that Data is the next Intel Inside -- a source of competitive advantage. The question is of course whether this competitive advantage should be granted for exclusive use or whether the data itself will eventually be regulated by anti-competition laws."

The killer advantage of Google Earth is the data. It's a great application, but the cheap data is key.

Google has lots of data. In one of my previous jobs in computational linguistics- we would have had a lot of fun with their release of n-gram data *really it's 1,146,580,664 5-grams. I have been quite impressed with Google's statistical machine translation... I am looking forward to what they do with information extraction. Hey- at least the data is free. (And it's not the personal data AOL is giving out. Poor old AOL...trying so hard to get "with it". bye!)

Ruby Cookbook, Joel, Google, LISP, Stu, Scripting

[long linky post...] I've reading/trying out the Ruby Cookbook this week. It's pretty amazing, and keeps getting in the way of the boring parts of my life, like the rest of my todo list. 850+ pages of cool stuff. Just the list of things you can do on the "Offical Unofficial Site" should give you a good idea of what it is capable of...

My KML Builder script keeps getting better and better- I am feeling confident enough now to build a GML script...okay, not that good yet. For the unitiated, Builder is a cool library that lets you write XML like this:

x.date {
x.year "2006"
x.month "01"
x.day "01"
}

which makes:

<date>
<year>2006</year>
<month>01</month>
<day>01</day>
</date>

The guy who wrote Builder, Jim W., it got the idea from Groovy, the Java scripting language, which has something quite similar. Fortunately not patented... Anyway, while the above example is really simple, just having it in idiomatic Ruby makes a lot of other cool things possible.

Speaking of things possible, Joel S. just wrote an interesting article which has pointed out some of the cool features of JavaScript (and ActionScript!), amongst other languages that treat Functions as Real Things. It's kind of like function pointers, but more flexible.

One of the upshots of this that Joel points out is that this kind of knowledge is required to understand things like Google's MapReduce (nothing to do with Cartography, btw)- which is why he is dismayed that Java is the instructional programming language of choice at the university level. Hey Joel- at least it's not PASCAL and Modula-2, not that I don't have a soft spot for TurboPascal. I know we can't all go to MIT and learn LISP, but maybe we should, now that this is available... I am thinking about recommending this to every developer in my company, am I nuts?

On that note, as Stu Halloway pointed out in a Ruby class that I scheduled for my company and my clients this week- Ruby is getting close to meeting Paul Graham's ideal programming language that has all of the nine ideas of LISP. By the way, Stu is an amazing instructor. If there is something that he knows about that you want to know about, I would make all efforts to get him to teach it to you. His knowledge of subjects is quite deep- and he brings all of that depth to the surface.

So, what does it all mean? We are approaching VB for the Web- Dabble DB is hot stuff, as is Rails, of course. We are are figuring out the basic operations of the current technology wave. It is getting to the point where the code that you actually need to write is potentially expressed in the language of the business- aka Domain Specific Languages, DSLs. Was the Arc/Info command line a DSL for GIS?

I spent all of this time trying learn "the right way to do things", which was about formalism and complexity, and now I am back to striving towards simplicity and writing things in scripting languages. The subtitle of the Ruby Cookbok? Recipes for Object-Oriented Scripting. My life is getting easier. Is it getting so easy that I am going to be redundant? This is how not to get outsourced- learn about what the mission you support is really trying to do- this technology stuff is going to be in the box soon! (hahahaha)

It's also about marketing yourself. I don't have much of a brand yet. Anyone want to write a book on Google Earth with me?

Information Week on Flex...

Charles Babcock in Information Week wrote a horrible article on Flex2 last month that I just got around to reading...I love the use of the word "cranky" in relation to JavaScript. I have heard about cranky developers- but the language has always seemed rather good natured to me, although I can't say the same of the IE engine it runs in. The bit about the proprietary version of the international standard is also nice- reminds me of J++.

....Flex 2 implements a new version of the Flash scripting language, ActionScript 3.0, a proprietary version of the international standard EcmaScript. ActionScript competes with Ajax' notoriously cranky JavaScript and surpasses it when it comes object-oriented behavior...

And then they drag Mr. Raad into the debate- where he bluntly displays his view on the whole static vs. dynamic typing debate. I like Pragmatic Dave Thomas' thought on the matter- "once code hits the network, all typing is dynamic."

"ActionScript is a much more powerful language," said Mansour Raad, chief architect for a unit of ESRI, the supplier of geographic system services and software. ActionScript in its third version traps programming errors and enforces variable typing, which lead to clearer runtime results and avoids some tampering exposures. JavaScript, in comparison, "is kind of strange and loose. It let's you do anything you want and continues on its merry way."

Mr. Babcock didn't interview the pragmatic one, of course. But then, he's got think of the advertising dollars.

Don't get me wrong- I think the Flash player is very cool, and a good thing overall- see AFLAX, the various JS wrappers, using it to do XML parsing, etc. I think adding ActionScript and Adobe's XML variant into the development mix makes it not something I would want to do. I wouldn't touch the server side stuff.

I also like seeing Flash inside of an html container, interacting with the page. Having your whole app be a .swf seems silly. I think we should see more widgets like Adobe's cool charting widget- and less of the rest of it.

Flex2 is a zombie technology

And by zombie I mean- it's already dead, even if it looks like it's walking around, propelled by force of vivid marketing campaigns while feeding on the brains of gullible programmers. If people want to make use of Flash- this is the best way to be doing it- wrap it in JavaScript.
Ajaxian JSSoundKit: Super-Easy Sound API.
JSSoundKit wraps the Flash Sound object, making it easy to incorporate sound into your Ajax apps. Really easy, in fact:
var mysound = new Sound();
mysound.loadSound("http://www.archive.org/download/Behind/SyncFilmicoBehind.mp3", true);
mysound.setVolume(30);

The server side pieces of Flex are useless- there are a number of general purpose web application frameworks that do everything it does, and don't lock you in to Adobe server side technology. The ability to take advantage of the widely installed (although with a great variety in versions, if my web stats are to be believed) Flash plugin is best when it is an optional thing.

I have seen some very nice looking interfaces done with Flash- but in reality I see it as nothing more than a good widget provider. Their server side story just doesn't resonate for anyone doing .Net, J2EE, Python, PHP, Ruby etc. (with the possible exception of un-reformed ColdFusion developers and those doing COBOL on Rails). We've come such a long way to get nice URL addressable content (aka web services) in web applications- let's not give it up for some fancy widgets that come with the trojan horse of a clunky server side communication piece. I am making a pact with anyone that's willing to listen- don't learn Action Script: friends don't let friends do MXML.

I don't know where this rant leaves OpenLaszlo and such things, but I have a feeling these guys should start selling easily integrated widgets and stop building web application frameworks.

Dealing with Meaninglessness

For all the coders out there, Coding Horror has picked up a great theme- Separating Programming Sheep from Non-Programming Goats. Some blokes from Middlesex U have devised a test (descibed in this paper [pdf]) that is strongly correlated with programming ability. Their interpretation is that the ability to create a mental model of basically meaningless rules is what allows people to grasp three primary "hurdles" of comp sci: "assignment and sequence, recursion and iteration, and concurrency".

Having a philosophical bent, I can see this extending beyond programming. It's not just an ability to deal with meaningless symbols and rules, it's also the willingness to deal with these things that makes people capable of making computers do things. I used to see this as a kind of patience, the kind of patience that lets you use early versions of products, or old ones, but looking at it in terms of the ability and inclination to focus on pure abstractions.

Having been a TA for introductory c++ courses at university- it was obvious that some people were going to take a long, long time to get the basics. But the problem is, programming is generally not one of those things where you learn something, and then do it. You have to keep figuring out things again and again, so if you aren't good at learning it, you probably won't be good at doing it. You can't study your way to the top...

Porting Google Earth to Linux

FLOSS Weekly with Chris DiBona | TWiT.TV

This podcast with Ryan Gordon has some pretty cool bits where he talks about his work with Google porting Earth to Linux., as well about being a game developer porting things to Linux. I think it is pretty amazing how they were able to do this, this guy's whole approach to porting to Linux is something special. It's amazing that he can deal with all of the oddities of the Win32 API...

Why don't all podcasts come with transcripts?

Making a Rails server, parsing KML in JS

If you are doing Rails, this is a pretty good way of doing it (Mongrel+Apache+Capistrano). Fast and stable...


I had to bail out on the Cartographer plugin because doing stuff like:

<%= gmap(:mapname=>"my_map", :width=>"50", :height=>"120") %>

<%= gmap(:width=>"500", :height=>"500", :type=>:satellite, :point=>[-122.14944, 37.441944]) %>

just isn't enough easier for me. I kept having to look at the generated JavaScript, since there was stuff I just had to tag in there. I did finally start parsing my own KML in there with the GXml parser, however, it's definitely faster to just generate JSON on the server side if you are doing anything with a lot of data. However, the capability to parse a fair subset of KML is worthwhile, so I am not throwing it away just yet.

GIS discussions....

Ogle Earth: A blog about Google Earth. « GIS: What's there to talk about? »

I think the fact that many of people's posts are just kind of newsy contributes to my lack of interest in commenting on their site. There's a certain amount odiscussionon that can happen around facts, but most discussion is about opinions and analysis.

I find discussions where people are just slamming other products/people/companies/technologies particularly tiresome, but there's a lot more respect in the GIS community. For example, while Stefan writes about Google Earth, he doesn't spend a lot time trying to talk down World Wind and Microsoft and ESRI. On the other hand, the most attention I tend to get is when I say something negative about something, like whining about the unnecessary complexities and oversights of GML..

Another aspect is the trackback concept.I wishsh it worked better in Blogger so that I could just add a post to the discussion on my own blog and have the link show up on theirs.Damnmn those spammers.

A couple of Ruby/Rails GIS notes

I am adding some simple GIS stuff into my Rails app today.

Cartographer: Google Maps Helpers for Ruby on Rails looks like a pretty good plugin to add a map into your codebase. I'll see how it goes...

The MetaCarta Geoparser API has also been wrapped by the robot co-op guys. I am really liking the approach taken by the new MetaCarta Labs stuff. In particular, I like the REST over SOAP approach. The number of lines of code required for SOAP is just ridiculous in proportion to the benefit gained. One of my guys was working with their SOAP interface this morning, and while SOAP4R's WSDL2RB script is the way to go (it's kind of like AXIS for Ruby)...it's just not necessary for what we're doing.

I am sorta disappointed that the KML support for Google Maps requires a public website to host the KML so that it can be parsed out on their server. I guess it's just too much to process in the JavaScript?