Chris Spagnuolo has a survey up to figure out the level of agile adoption in the GIS world. It didn’t take me long to fill the survey out and you can help a fellow blogger out by taking 2-3 minutes to fill it out.
Category: Thoughts
-
GIS Blog in multiple languages
Thanks to reader “KipterUh” my blog now has a translator available to convert my rants into many other languages. Click on the flag on the sidebar that matches the language you want to read my blog in and enjoy. What is nice about the translator is that you can bookmark the links so my blog is always available in your language.
Sorry it took me so long to do this, it was much easier than I thought.
James was a language dummy
-
ArcGIS Server Javascript API Example
ESRI has posted an example of the Javascript API on their blog:
Today, we just want to talk a bit about the new ArcGIS JavaScript and REST APIs. We built this new JavaScript API because many of you have asked for a simple way to share your GIS data and tools over the internet. Here is an example built on top of the ArcGIS JavaScript API.
Of course you’ll probably “view source” on the page to see what is up as I did. I see they used the Google Chart API for the charting as was noted on their blog page. A simple application for sure, but definitely a step in the right direction from what we are used to using on the ArcGIS Server platform.
Taking orders for HTTP Goodness Thongs for the DevSummit
More: Digging deeper into the example we can see the url to the map layer: SuperTuesdaySample with all its metadata and supported operations. If you click on query you see an HTML form. Pretty slick. If you click on the breadcrumbs at the top you can see the service description as well as its supported interfaces (REST or SOAP) and supported operations (Export Map Image, identify, find and Generate KML. All well thought out and very well done. Alas the help and the API Reference links do not work at the top of the page, but I really like what I see here. We’ll have to wait until they show us more, but I am impressed.
Update 2: Sean appears to have been doing the same thing as me, but as always he sounds smarter when talking about it. Check his thoughts out.
-
Frugosapalooza 2008 – Denver
I’ve made my reservations to visit Denver, CO to Frugosapalooza 2008 on Tuesday February 19th at Forest Room 5. Should be great hooking up with everyone in Colorado I have yet to meet yet and see some of the interesting things folks are doing with Open Source. I know Sean will be there with some sort of Python thing (what else from him right?) and Peter Batty will demo his latest project. I’m pumped to see everyone and get out of the Bermuda Triangle of GIS; Phoenix, AZ.
We’ll be sitting in a circle passing python scripts around
-
Bringing Open Source GIS into an “ESRI Shop”
I don’t like the term “ESRI Shop”. Both open source developers and ESRI developers use it as an excuse one way or another. Just because you are running ArcMap or ArcGIS Server, doesn’t mean that you can’t explore open source GIS software and in fact you might be surprised how it makes your ESRI ArcGIS software even better.
A couple months ago, one of my clients asked me how they could bring KML into their ArcGIS Desktop maps. We’ve been through this before so I won’t detail my feelings on the subject, but ArcMap cannot read KML without some help. We looked at a couple different solutions and FeatureServer seemed to be a perfect fit for what they wanted. They’ve got people digitizing points/lines/polygons in Google Earth pro and getting that data into their SDE databases needed to be easier. Then another client wanted to digitize polygons inside ArcGIS Server, but they couldn’t afford a license for ArcGIS Server. Again FeatureServer seemed to be a great choice, coupled with OpenLayers. The idea seemed to come together at that point. Use OpenLayers to allow people to create and use FeatureServer as the translator to move the data between KML, GML, PostGIS and eventually ArcSDE. The idea is to let folks use the tools they are most comfortable with, whether it be ArcMap, Google Earth, or any OGC complaint application.
Now the concept sounded perfect but we ran into some problems. First off ArcMap still couldn’t read KML without help (and I could not be assured that an extension would be installed on ever workstation) so GML sounded like the perfect solution. ArcGIS Desktop can read “GML Simple Features”, but what FeatureServer was giving out was more complicated. You could read the GML from FeatureServer with Data Interop extension, but without it, ArcMap gave an error. Thanks to Christopher Schmidt, we were able figure out the schema for the ArcGIS GML “format” and any data that was digitized in OpenLayers could be downloaded as GML and viewed in ArcMap. That was huge because now you can view any features in OpenLayers, Google Earth and ArcMap which is exactly what they wanted.
What is really important to understand here is this was all done with open source software (FeatureServer, OpenLayers, PostGIS) and was developed quicker than an ArcGIS Server application could have been done. Christopher was obviously a huge help and the prototype couldn’t have been developed without him figuring out how to get FeatureServer to interop with ArcGIS. There is no overhead involved and no licensing fees/maintenance that needs to be paid.
Having a group of GIS techs digitizing PDF maps that people have marked up is not cost effective for anyone. Having people remotely digitize features and be able to work with them in PostGIS, Google Earth, ArcGIS and just about any OGC complaint application is very powerful. It really comes down to using open source to make everyones job easier and doing much more than you could before with much less money. When you take out the maintenance and the licensing of server software, you can focus your money directly on the problem and solution.
The next step is to get FeatureServer to write directly to ArcSDE (or as we now call it ArcGIS Server Enterprise). That way there is no importing of GML (or any other data layers) into your ESRI workflows. FeatureServer takes care of everything and you just interact with you spatial database like you always have. I’ve heard that OGR support for ArcSDE write is on its way so that will open FeatureServer up to many more folks.
That brings up a huge issues for many folks. How do I get my ArcSDE datasets out to the public so they can use them? Imagine FeatureServer just sitting there offering up KML, GML, WFS, GeoJSON, OpenStreetMap .OSM for all to use. I love this approach to getting data in and out of ArcSDE; quick, easy, cheap and it just works.
BRILLIANT!
-
ESRI Podcast – 2008 Developer Summit — Building Mash-ups Using the ArcGIS Server JavaScript API
OK here is the other part of the ArcGIS Server 9.3 release that most of us will be interested in; the Javascript API. Jeremy Bartley and Jayant Sai talk a little about the Javascript API in their podcast. Much like the RESTful API Podcast, there isn’t much meat here, but at least you can get an overview of what the Javascript APIs will be. Remember from the RESTful API Podcast, there will be Javascript Extenters for Virtual Earth or Google Maps and ESRI own Javascript API. One thing that was refreshing to here ESRI say is that the general public isn’t interested in toolbars and all the heavy WebADF junk, but lightweight modern mapping sites. Could we be ready to turn the corner here with ArcGIS Server development?
-
Dave Bouwman releases the ArcGIS Server Virtual Earth Tile Server
Dave Bouwman has cleaned up his AGS Virtual Earth Tile Server and has posted the code.
- HttpHandler (.ashx)that responds to Tile requests from Virtual Earth
- Supports multiple layers/map services through the same handler
- ArcGIS Server Tile Provider uses the AGS SOAP API (fast!)
- Projects the data – can be used with any ArcGIS Server map service
- Extensible design allows for additional Tile Providers – i.e. ArcIMS, Image Server
- Extensible design allows for additional storage providers – i.e. Amazon S3, DBMS
- Easy to use – just edit the web.config file
Dave hopes to add providers for both WMS and ArcIMS services. Some of the history behind why this project was developed can be found in a blog post from a couple weeks ago.
This is why a RESTful API is so important to development of ArcGIS Server. Rather than being tied down to the WebADF, you can start using ArcGIS Server in ways that we haven’t before. Just because you are the ESRI Server Stack shouldn’t limit you to using only the ESRI ADFs. We’ll be seeing more about this in the next few weeks running up to the DevSummit from many folks as we start getting organized with ESRI ArcGIS Server community development. If you use .NET with ArcGIS Server, get involved with ArcDeveloper.net.
-
Command line or graphical workflow editors
Matt Perry wonders if command line is a dying art. He lists automation, repeatability, documentability, accessibility, and accuracy as factors to consider in using command line tools over their GUI counterparts.
All the factors Matt considered for command line over GUI can be addressed if you use diagramming software. ESRI’s Model Builder and Safe’s FME Workbench both can solve all those problems and even allow you to better visualize what you are trying to accomplish. As someone who cut his teeth on ArcInfo 5, I find the Model Builder and Workbench refreshing and make be a better analyst. Being able to redirect to the visualizer and see what my output will be before running my model allows me to be more productive, rather than have multiple versions of output sitting in a folder.
Update: Better title, was “Command line or diagramming software”
-
ESRI Podcast – ArcGIS Server REST API
I’m sure this is just a coincidence, but ESRI actually posted a discussion of the REST API for ArcGIS Server. In addition they hit on the three Javascript APIs that they will also release with the REST API; ESRI Javascript API using Dojo, Extender Javascript Library for Google Maps and Extender Javascript Library for Virtual Earth. There isn’t too much depth here but at least we can get an idea where they are going with REST and ArcGIS Server 9.3.
Thanks Rachel
-
WebADF – Put up or shut up
So we all hate at least parts of the WebADF but complaining about it won’t do anything. Dave says it is time for us to do something about it. I agree, bitching about software is therapeutic, but it doesn’t help any of us get our work done. Dave, Doron and Matt have all blogged about where we should be thinking of going on this.
Dave thinks we can create our own REST API before ESRI gets around to releasing their own API (sorry Sean, I have to use API here given the context).
There’s not really a whole lot to it if it’s designed correctly. Heck if nothing else we can use what has been done on FeatureServer.org as a road map. Suppose we cook up a server object extension (SOE) that can do all the low-level stuff in raw ArcObjects. Then we write a httphandler that can take the requests, parse the Urls and make calls back to the SOE. If we but the JSON/GEORSS/KML/whatever conversion in the SOE, we’re very light-weight on the DCOM stuff, and can get away with little to no ADF. And if we run this all directly on the ArcGIS Server box, we’re good in terms of licensing.
I like the simplicity of this. Use existing work such as FeatureServer and add back into that community and grow our own ArcGIS Server community. Matt goes one step further and outlines what this RESTful interface would look like.
So what is the next step. We can wait until the DevSummit to see what ESRI has cooked up with their RESTful attempt but I know many people are so frustrated waiting at least this long for even a peak at it we might as we create our own. It backs into where I was talking about before, long lead times with ESRI Server software puts implementors in bad spots. Still I think we should wait the month and a half to see what they’ve come up with and it makes sense to have a meetup at the DevSummit to talk about what we want to do moving forward. We can also have an IRC channel running for those who want to take part in the discussion, but can’t make it to Palm Springs. I just want to develop ArcGIS Server applications using Javascript, don’t you?
Sound like a plan?
UPDATE : Matt says that I should know that ESRI will fail and we should forge ahead ourselves. Frankly I’ve not seen a thing about the ESRI REST API so I guess he is probably right. They can’t even give us a taste of the thing so as far as we should be concerned it doesn’t exist. He’s got no argument from me. Lets move forward on this then. Anyone game other than Dave, Matt, Doron and me want to step up?