It’s been a quiet month-and-a-half here on the blog, mostly owing to an abundance of project tasks. I recently started a short-term project to help one of my Federal customers extend data source support for an application they have been developing. This customer is technically a new one but the project team is made up of government developers that I have worked with on a few other projects so there is a great deal of familiarity.
The application, which has been under development for some time, is written in .Net and make use of the open-source (MIT) GMap.NET mapping library. The application features a desktop version running in Windows and a mobile version running on Android tablets. The .Net back end works seamlessly on both through the use of Xamarin, although I have not had the chance to get my hands dirty with that yet due to limits on Xamarin licenses and available Android devices. To its credit, GMap.NET seems to work fairly well in both environments.
Continue reading “Data, Apps, and Maps”
It’s great news that the government shutdown is finally over. Many of our colleagues across the geospatial industry can now report back to work, ending a another stressful period for them. During the shutdown, many stepped up to try and fill the gap left by shuttered government web sites that would normally distribute geospatial data.
Continue reading “WeoGeo: Now With GeoJSON”
A few weeks ago, my company announced the availability of the first beta version of WeoGeo Tools for ArcGIS. Unlike the previous version, which opened a separate browser window, this new release allows a user to order a data set from WeoGeo Market or a library from inside ArcMap.
One of the challenges was enabling data set previews. If you browse data sets using the WeoGeo online tool, you can get an idea of what the data set contains by using the data set preview images supplied by the data set provider.
When we developed the first version of WeoGeo Tools for WeoGeo, they used kamap to create preview tiles for data sets. This was accomplished by used either one of two desktop tools: the weoapp (command line) or gWeoApp (GUI). The first version of WeoGeo Tools used the weoapp in the background to create tiles when uploading data. Continue reading “Using BruTile and MapsUI to Enable WeoGeo Previews”
I generally try to keep my blog separate from my daily work life in that I usually don’t directly blog about the projects on which I am working. I’m going to deviate from that today to make a couple of announcements.
It’s been a while now, but you may recall that, about a year ago, WeoGeo announced the availability of WeoGeo Tools for ArcGIS. It was an ArcGIS Desktop extension that integrated the ability browse data sets on WeoGeo Market or hosted libraries as well as providing the ability to upload your data directly from ArcMap.
My first bit of news is that my company, Zekiah Technologies, produced that extension for WeoGeo. We did not announce it at the time because the original plan was for WeoGeo to support it after it was released. That arrangement has continued to the present. Continue reading “Announcing WeoGeo Tools for ArcGIS”
One of my goals for 2011 was to sharpen my Python skills. As if on cue, WeoGeo puts out a Python wrapper for their RESTful API. It can be found here. The good news is that I now have a familiar problem set to sink my teeth into. The bad news (for me) is that it’s so easy to use it’s probably not going to do much for my Python skills.
The wrapper addresses the full WeoGeo API (Datasets, Jobs, Events, etc.) so it exposes pretty much everything you can through through the WeoGeo SaaS. For example, here is a very simple browse operation:
Continue reading “Getting Started With a Python Wrapper For the WeoGeo API”
Things have been a bit hectic the last few weeks and that’s left little time for blogging. Quite a bit has happened so I thought I’d do a little round-up (if for no other reason than to clear my own head).
In no particular order:
Steve Coast to Microsoft (I told you it had been a while) – Firstly, congratulations to Steve (#sincerity). Secondly, this clearly is the final proof that crowd-sourced data in general, and OpenStreetMaps (sic) in particular, has no real value when compared to “authoritative” data sources (#sarcasm).
Google Fusion Tables – The only real problem at this point is the size limitation but, otherwise, this will be a game-changer for storing and sharing data. In its current form, it’s already fairly easy to push your data up and expose it through Google’s APIs. It’ll be interesting to see if it gets easier. Support for spatial queries hints at some analytical capability, too. Speaking of which…
Analytics in GeoCommons – This is one to watch. They are debuting a new function each day on their blog. FortiusOne builds their platform API-first, UI-second so everything they are showing should be exposed through their APIs. This will be a huge step in moving cloud-based geospatial technology from the “bit-bucket” stage to having a more complete workflow on the cloud infrastructure.
Continue reading “Ten-Second Tidy”
I spent the vast majority of my time at the 2010 ESRI User Conference working the Zekiah/Arc2Earth booth. That was fun as I got meet/reconnect with a lot of people but I didn’t see much of the conference itself. As a result, I haven’t really blogged it.
ESRI continued with the “cloud ready” theme that was rolled out at the Federal User Conference but with more details about how they are moving to “the cloud.” This generated a lot of buzz amongst many of the attendees from what I could tell. One of the big new features of Arc2Earth v3 (disclaimer: my company is an Arc2Earth reseller) is Cloud Services. As a result, we had a banner in our booth that had the word “cloud” on it, prompting lots of people to stop. Continue reading “Clouds”