I’m not sure why they feel the need for such a list rather than work with existing job posting sites, but I guess this has to do more with tackling “low hanging fruit” and avoiding writing case studies for migrating to FOSS4G which one would think would be a higher priority for OSGeo. It will be interesting to see if this Jobs list actually gets some good jobs or becomes full of job spam.
OSGeo efficiency rivals that of the Galactic Senate
I’m traveling this week to the hinterlands of Arizona for some marketing so posting will be very light, but Paul is filling in very nicely with some of the points that needed to be addressed from the discussion last week. He’s got a great point about skills already existing for using open source software:
PostGIS: Already worked with Oracle Spatial or ArcSDE’s “new” spatial SQL feature? You already know PostGIS.
Mapserver: Learn the .map file and you are good to go. No harder than picking up enough AXL to be useful. Budget a couple days of learning time.
Geoserver: Point and click through the interface. Do you known enough to deploy a WAR into production? If you installed ArcIMS, you already do.
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.
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.
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.
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
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.
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”