I recently helped host a training session sponsored by GITA Rocky Mountain Chapter introducing various OpenSource Geo packages including PostGIS, GeoServer and OpenLayers with Cliff Inbau. I have been doing a bit of work refactoring some web maps for mobile friendliness and thought it would be worth sharing some of my musings with OpenLayers and jQuery. I had worked with jQuery a fare amount but hadn't touched OpenLayers. My interest in playing with it came from a talk given by Tory Alford entitled "GIS for the Mobile Web" which is worth looking at. Below you will find my deck and the hands-on tutorials. They haven't been vetted all that well but would welcome any feedback.
Showing posts with label Javascript. Show all posts
Showing posts with label Javascript. Show all posts
Tuesday, October 18, 2011
Friday, June 24, 2011
A Real Life Geoprocessing Service In Action (ArcGIS Server 10)
As I have mentioned before, I'm an oldschool GIS guy. Because of this, I have a hard time embracing "secular" web mapping toolkits. Its kind of like the old days. Yes, you can use GIS to just make maps but it is really about the data and analytic capabilities. So translated into the geoweb, yes there are all kinds of toolkits to make webmaps but very few that expose the richness of the data and provide real analytic capabilities. That is why a recent project I was lucky enough to be apart of was so exciting. Web enabling rich GIS capabilities via a simple user interface and user experience using ArcGIS Server's Geoprocessing service.
The application is really simple, basically allowing users to dynamically calculate the amount of in-place oil shale amounts. We have kind of been calling it the oil shale calculator. However, the science and methodology for assessing the oil shale resources in the first place was far more complex and something that I can't take credit for but would like to acknowledge those who did (Johnson, R.C., Brownfield, M.E., and Mercier, T.J., (U.S. Geological Survey Oil Shale Assessment Team)). Have a look at it if you are interested.
But for the sake of this post, the result of this work (at least the part that was used for this application) was basically a raster with gallons of in-place oil shale resources per cell and a model implementing the zonal stats function for doing the dynamic calculations (nice work Tracey!). Here is the geoprocessing model.
Pretty simple really. Basically, two input parameters. A user defined polygon and the raster containing oil shale values. The output being a sum based on the zonal statistics function. This was actually modeled after one of the AGS samples. When implementing this model, we ran into what I consider a bug. First, the literature suggests that you can store the output table in memory(ArcGIS 10 only). However, we found this was not the case. We were forced to use a physical file system location, basically the scratch disk (bad: output table=in_memory\results, good: output table=%scratchworkspace%\oilshale.dbf).
The application itself was pretty simple as well. Have a look. One gotcha we ran into here was that basically the REST API endpoint for this service actually expects 2 input parameters, not just one as is suggested by its Services Directory page. The missing parameter that is actually required is the zone field parameter. We called ours id. You can view the page source of the app to see how we manually included this parameter but a preview is below:
But for the sake of this post, the result of this work (at least the part that was used for this application) was basically a raster with gallons of in-place oil shale resources per cell and a model implementing the zonal stats function for doing the dynamic calculations (nice work Tracey!). Here is the geoprocessing model.
The application itself was pretty simple as well. Have a look. One gotcha we ran into here was that basically the REST API endpoint for this service actually expects 2 input parameters, not just one as is suggested by its Services Directory page. The missing parameter that is actually required is the zone field parameter. We called ours id. You can view the page source of the app to see how we manually included this parameter but a preview is below:
Thursday, February 12, 2009
JS vs Flex ArcGIS Server Sample Viewers
In recent weeks, ESRI has released 2 versions of a sample viewer application based on both their latest development platforms, the JS platform (released January 2009) and the Flex platform (released November 2008, updated February 2009). They both look and function similarly out of the box. Each features a icon oriented navigation bar based on various functional classes including maps, navigation, tools and resources. They both use REST based ArcGIS Server services both dynamically generated and cached very easily (although I was able to add ArcIMS Service Support to the Flex version without much hassle). Each features some pretty nice design patterns which allow developers to worry less about core functionality. Custom functions are implemented as "widgets" which function independently of the software core.
After tinkering with the Flex application for a few weeks and having a look at the JS version, I have a few impressions to share. First, they both use design patterns (Container Event Bus and Dependence Injection) that help decouple core functionality from custom functionality and really make it easy to extend. The flex viewer, based on Adobe's Opensource Flex 3.2 platform is very sexy and alleviates many cross-browser compatibility issues because of its required Flash plugin. Recently released as an opensource project, Flex offers a rich user experience with flashy graphical displays and fluid GUI performance. However, it requires an specific IDE based on the Eclipse IDE called Flex Builder which is rather pricey (ranging from $200.00 - $700.00). I have had the fortune of getting the IDE and have begun some "widget building" myself and have found it to be quite easy. I was able to construct a simple Map Navigation Widget in just a few days without any prior Flex development experience.
While I haven't tinkered as much with the JS version, my initial impression is that it is also very slick and does not require a plugin. However, it's sex appeal is lacking a bit compared to the Flex version and it sounds as if (based on comments from the sample download blog) that it has some issues in IE 7.
After tinkering with the Flex application for a few weeks and having a look at the JS version, I have a few impressions to share. First, they both use design patterns (Container Event Bus and Dependence Injection) that help decouple core functionality from custom functionality and really make it easy to extend. The flex viewer, based on Adobe's Opensource Flex 3.2 platform is very sexy and alleviates many cross-browser compatibility issues because of its required Flash plugin. Recently released as an opensource project, Flex offers a rich user experience with flashy graphical displays and fluid GUI performance. However, it requires an specific IDE based on the Eclipse IDE called Flex Builder which is rather pricey (ranging from $200.00 - $700.00). I have had the fortune of getting the IDE and have begun some "widget building" myself and have found it to be quite easy. I was able to construct a simple Map Navigation Widget in just a few days without any prior Flex development experience.
While I haven't tinkered as much with the JS version, my initial impression is that it is also very slick and does not require a plugin. However, it's sex appeal is lacking a bit compared to the Flex version and it sounds as if (based on comments from the sample download blog) that it has some issues in IE 7.
Subscribe to:
Posts (Atom)