I just noticed the "The KML Handbook: Geographic Visualization for the Web" by Josie Wernecke is out on Safari Rough Cuts. It looks like it has some interesting tips, not really a programming book per se, more of an expanded version of Google's documentation. The subtitle is interesting to me- "for the Web". A couple of years ago it would have just been for Google Earth, but KML is on its way to becoming the new shapefile. Next I want JSON.
We need a few more "can do it all" types at our company. I struggle with how to list these positions, because not all of the skills are required, but we need a few specializing generalists or generalizing specialists or what have you. I read "Hiring Technical People" (the book and the blog), but it's still not easy. Anyway- we are still making our stock plan available to people hired in 2008, so if you know anyone that is looking...we've got a smart team. If anyone wants to point out obvious errors or inconsistencies in the technology laundry list, it would be greatly appreciated, as I don't know all of this stuff.
GIS Integration Engineer
Duties to include: Integration and testing of a cutting edge commercial imagery / video storage product into various types of commercial tools and custom government software. This includes integrating an encoder for various data types and integration of the viewers also. The work will involve working with customer site representatives to analyze and product the solutions to interface the software together. This could involve using the products c API, Scripting languages, WMS, Java or .Net wrappers. If you are a hard core geospatial person with minimal programming experience or a expert generalist programmer with a little geospatial experience and/or a solid math background, please apply.
We are looking for people with some subset of these skills:
GIS, Imagery analysis, c and c integration, Java, .Net, SQL and database programming, Python, Perl, Unix Shell Scripting, Windows and Unix Installation packages
OGC standards (WMS, WCS, WFS), PCI Geomatica, ERDAS, ESRI, ITT, GDAL, OSSIM, RemoteView, Imagine, FalconView, SocetSet, Warp, Manipulation of commercial imagery, IKONOS, QuickBird, NTM, Aerial and Aerial Video feeds,file types such as GeoPDF, GeoTIFF, NITF, JPEG2000, pix, Shapefiles, MPEG and other video formats, NTM, Calculus or Trig, Orthorectification, Programmer on Unix variants and/or Windows
Pretty big round for uLocate. Famous for providing support for Flagr, the mobile version of MapQuest etc.
I tried to download the new Where (how much did that domain name cost?) app to my phone, but it's not supported as of yet...
Their mobile technology is sorta cool- going for the whole write once run anywhere thing for mobile apps with an xml style application definition. A location specific version of something like mFoundry. Of course, when they don't support your phone, it's a little harder to buy into that concept.
Anyway, XML as a programming language? Just because it worked sorta okay for HTML doesn't mean there aren't better ways to do it- especially when you are talking applications.
For work purposes I am currently carrying two phones- a Blackberry and a Palm 650. I like both of these OSes, although the Palm OS does crash quite a bit. I've also been testing a couple of mobile GIS applications running on Windows Mobile 5. We're trying to figure out where to go next with it- RIM, Symbian, Linux (iPhone), etc.
While I like RIM and Palm OS, with a edge to RIM, Windows Mobile is completely unappealing to me. The main plus from a development standpoint is that it is relatively standard across devices. However, this is easily eclipsed by the usability, the memory consumption, and the way in which closing most programs doesn't close them- it just hides them. The stability varies pretty widely across devices, but it's about on the level of Palm OS.
I am still waiting for the mobile OS that implements virtual memory paging (with an SD card as the pagefile holder). It might be slower, but the RAM is so easily consumed in simple apps, it would enable a variety of applications that just don't work now. I know, you just have to wait a couple of years and it will all change, but right now it's a very tough decision if you want to figure out which mobile OS to develop on.
Now, some might say- why not just do mobile friendly web applications versus applications? For a lot of applications, you need more interactivity than the limited browsers on the phone provide. For others, the constant lag is the impediment. Overall, it's an area of potential, but limited to only the simplest applications today.
However, the mobile device is where some of the virtual machine technologies can really come to bear. In particular, Java Mobile Edition is pretty widely available, even if the apps look as out of place as they often do in Desktop OS land. So, you can do a Java app and get a reasonable percentage of phones to work, although they all seem to implement slightly different profiles.
Now we have the Apollo, Silverlight, JavaFX model of what are in reality enhanced web browsers that build UIs out of things other than HTML. JavaFX mobile is one picture of how things could go in that direction, where the environment could provide all of the basic phone functions, in addition to providing a decent programming environment for content delivery. Of course, I am not sure how much of that is really one thing, or if it's a set of technologies that Sun is lumping under one banner.
Anyway- let's say I have an opportunity to port one of these mobile GIS apps to a platform or OS- which way should I go?
