Abe announced the availability of hotfix 3 for zigGIS 2.0.5. From the announcement:
Hotfix 3 fixes an issue that prevented point layers from being
editable; it also includes all prior hotfixes. The hotfix is a free
upgrade and is highly recommended for all users. Please go to
http://pub.obtusesoft.com > My Order. After logging in you’ll see a
link to the patch.
Abe is working hard on version 3.0 but obviously is continuing to support 2.x as well. Improvements include a new provider model which will better enable support for other data sources. A roadmap should be available soon.
Shortly after my previous post, about browsing and downloading data from GeoCommons, hit the wires, I got quite a few back-channel requests for the code. I sent it out via e-mail to a number of people and then posted it via DropBox. I have finally gotten around to posting it up on Google Code, making things much more manageable. It is now available here.
I have made a few updates since the original post. Some were administrative but were functional. They are:
1. The code was updated to replace SharpZipLib with DotNetZip for handling zip files.
2. The code now attempts to identify the default KML handler on the user’s system and pass KML directly to it for previewing.
3. The user now gets a wait cursor when the tool is processing downloads and such. This should make it a little more usable.
4. The code headers had been pasted in from SharpMap and I missed some references to SharpMap in the text. Those have been corrected.
Anyway, thanks for all the interest. It sort of caught me off guard but at least the code is more accessible now. I’ve got a few more updates planned so this should streamline things.
UPDATE: The code for this post is available at the bottom of the page.
I have been doing a lot of development with the ESRI Silverlight API recently. One of the requirements of my project is to be able to dynamically add KML data at runtime. The incorporation of KML was handled for us through one of the ESRI samples on the resource center so we pretty much just had to integrate that code and test against our use cases. For testing, I typically reached out to GeoCommons since any data set available there can be streamed as KML.
Obviously, this is not my first exposure to GeoCommons but, when discussing it, I found that many of the analysts I spoke with were not aware of it and did not use it much. So I decided to tackle developing a simple ArcMap extension to allow a user to search GeoCommons and then download/add data to ArcMap without the need to manually download, unzip and add the data themselves. Continue reading “Importing Data From GeoCommons Into ArcMap”
Updated: This demo application now running here. I will update this demo periodically, as time permits, so keep checking back.
At the 2010 ESRI Federal User Conference, WeoGeo announced the availability of a toolbar for interacting with WeoGeo Market and private libraries from within ArcMap. This, combined with Dan Dye’s series of posts showing how to use the WeoGeo REST API with Python got me thinking about how easy it would be to integrate with ESRI’s clients for the ArcGIS Server REST API. All of my clients (it seems) are using the Silverlight API these days so I am spending a lot of time with it and decided to use it as my testbed.
My goal was simple, I wanted to browse the WeoGeo Market for any data sets in the current map extent, be able to select one from a list, and have its preview image display in the proper location on my Silverlight map. Continue reading “Browsing WeoGeo Market Using the ESRI Silverlight API”
The MapWindow open-source project will be holding its first-ever user conference from March 31 to April 2, 2010 in Orlando, Florida. Aside from being a great milestone for MapWindow, it is also being billed as a “coming out party” for MapWindow 6, its first native .NET version.
For those of you who are not familiar with MapWindow, it is and open-source (MPL 1.1) mapping library (think SharpMap or MapObjects) for use in developing applications, managed by the Geospatial Software Lab at Idaho State University. Although its desktop application and some geoprocessing tools have been written in .NET (VB.NET and C# respectively) for some time, the main library has been a 32-bit ActiveX control written in C++. At version 6, it will finally be fully .NET.
I had used MapWindow a little bit some years ago but haven’t recently due to its ActiveX structure. I will definitely add it to my (ever-growing) list of things to check out now that it’s been ported.
Following up on my post a few months back about GeoJSON and SharpMap; here is the code to the converter as it stands so far. I have mentioned recently that things have been pretty busy at work so I have progressed on this more slowly than I had wished. I have yet to insert code to handle CRS but I thought it would be better to post something than nothing.
Basically, I just had to do some modifications to Morten’s original code for handling WKT. It was pretty straightforward owing mainly to the quality of Morten’s code. So here it is. Enjoy… Continue reading “Writing GeoJSON from SharpMap, Part 1.5”
It has been quite a while since I last blogged. The holidays are always a busy time of year with family a friends and work has been somewhat busy as well. We established a new presence in Colorado Springs (I’ll be traveling there at the end of January). Additionally, I’ve been busy with project work and have recently begun spend part time on a customer site. So, the blog has been squeezed a little.
The thing I really like about it is the portability. You can basically drop a couple of DLLs and go. Additionally, SpatiaLite has strong support for many spatial operations so it can be a fairly robust analysis back-end. These two attributes raise a lot of possibilities for mobile applications. I have done some mobile development work with PostGIS (okay, the platforms were fairly heavy but they were in vehicles that rolled around) and it worked well but SpatiaLite might ease some of those “in the field” workflows, especially the delivery of relevant basemap information.
With regard to SharpMap, it looks like SpatiaLite provider is under way for 2.0. I am doing my own for 0.9 because it helps me get more comfortable with SpatiaLite. Once I am finished, I’ll be happy to share my code but you may want to take a look at what’s being implemented with 2.0. It’s fairly elegant.
Also of interest, the SpatiaLite Users Google Group.
Update: the code for SharpMap 2.0 is currently located here.