Friday, August 17, 2012

"Old" FDGC XML Metadata Format Translator

If there is anyone left out there that is handcuffed to the following as we are:

1.  The need to author and publish FGDC metadata
2.  A workflow that supports the "old" FGDC xml format in ArcCatalog
3.  The need to display that in a human readable format (HTML)

This post is for you.  I recently wrote a simple Add-in for ArcCatalog that translates the "old" or "classic" FDGC Metadata XML Format to classic html or FAQ html.  Basically, it is the same functionality that was offered in 9.3.  For most folks, this tool may be unneeded given the new metadata framework in ArcGIS 10 but if you are still using the "old" workflow and FGDC metadata editor, this will be helpful given that the ArcGIS 10 export does not have translators for the old FDGC XML format.



For installation, simply follow the instructions in the ArcGIS Desktop help system for installing and using Add-ins.

 

Tuesday, October 18, 2011

Mobile Web Maps with OpenLayers and jQuery: A Tutorial

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.

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:

Friday, May 13, 2011

Sexier Posters and Poster Sessions Using Zoomify and QR Codes

This isn't a typical post for this blog but working with geologists gives me opportunities to geek out on even classic information delivery mediums.  This means trying to make posters even sexy.  Thats right, posters (they still do those at earth science events and conferences).  I give the crew of geoscientists I work with alot of credit.  At least they are creating posters digitally and not using scissors and glue like a 3rd grade science project as it once was done once upon a time.



Anyway, I have ran across a couple of interesting techniques to help make posters at least a little more usable.  The first isn't earth shattering.  For our agency, delivering information and products to the public is a major requirement and delivering posters that scientists have presented at various conference poster sessions is part of this.  Typically, we provide a thumbnail and a link to the entire poster in PDF format for users to download and print on their own.  However, a typical use case is for users to just "have a look" at the poster or preview it directly online.  Doing this with full resolution PDFs or low resolution images is problematic but with the use of a product called Zoomify, we are able to provide users with the ability to zoom-in, pan and share the posters we post online interactively.  Here are some examples of how we have used Zoomify for our online posters presentations.

There is a free version of the product that does about 80 percent of what you might need along with upgrades for purchase that allow you full control to the component via its ActionScript API (it does need Flash to run).

The second technique to share is a little more modern I guess.  Still not earth shattering but a little more techie.  I'm sure you have seen these around:
If not, this is an example of a QR code.  Basically, it is a matrix barcode that can be read by barcode readers and smart phones.  They can be used to encode information like telephone numbers or URI's.  In our case, they make an interesting addition to a standard, hardcopy poster.  Imagine encoding a link to a manuscript, online map, or even a database that relates to information summarized on a poster.  Perhaps even encoding contact information such as your telephone number that can be digitally captured by viewers of your poster and added directly to their contact list on their phone, all done using QR codes.  Here is an example of a QR code embedded next to a figure from a post that links to a data download website related to the figure.


Tuesday, March 8, 2011

The 2011 ESRI Developers Summit Really Blew

I arrived on Monday with some flair. Evidently, I was the first flight to land (12:30pm local) after some really crazy winds. I was in seat 2A and the lady in front of me barfed on arrival (God Love her).  Luckily, it was at the end of the flight.



I landed, got my car and was engulfed in the craziest sandstorm ever. The next day, the main feeders from the highway to downtown were closed as I tried to make my way to the convention center for the plenary (I like to stay in Palm Desert), so I used the interior city streets which sucked. This years Developer's Summit really blew so far.

However, things changed upon my arrival to the convention center (well actually before).  First, the weather could not have been better.  Clear, sunny, warm and no wind.  Next, the plenary was really good (here is the 1st part of it) which has not been the case for several years of attendance at various Developer's Summits, user group gatherings, as well as UCs.  What was striking this time was that this was the largest attendance ever for a Developer's Summit where 50% of the attendees were new and largely international.

Secondly, the vibe was SEXY.  I can't put my finger on it but I have been to dozens of ESRI sponsored events and this one was just cooler. I guess the seating is part of it, but I think it is something more as well.  The lunch on the first day was yummy too.

Technology wise, its time to get mobile.  I am kind of old-school and have forced myself to re-invent and re-brand as needed and this years Summit represents another milestone for that.  I hearken back to these times in my career...
  • Arc/Info command line to ArcView 3.x
  • AML to Avenue
  • ArcX to Arc 8
  • ArcIMS to ArcGIS Server
  • you get the idea
While change is part of the game, I think ESRI has done a good job this year at the Developer's Summit to not get crazy with the "you need too.." and is still speaking to the user community.  While web and mobile is the latest and greatest, data (geodatabases) and good old fashioned GIS analysis (models) has been part of the discussion as well.

Given this need to change, I  focused on mobile tech sessions mostly as well as chatted with the alot of the engineers from the various product teams.  The tech sessions were great.  I especially want to lift up the "Choosing the best mobile platform" tech session.  I liked this session because it addressed real business issues.  Most tech sessions show a demo with code, but this session had larger relevance that is often missed in most tech sessions.

Anyhow, nice show this year!

Monday, February 28, 2011

Tips and Tricks With PERL for NON-PERL Types

I have been working on an integration/data management project for managing geophysical well logs in an E&P environment and I hope to post a blog about that shortly but the basic jist is that we have all kinds of geologic data located all over our file system and need some way of finding that data and integrating systems that use it such as a GIS and other E&P systems (well master, seismic systems, PPDM, Petra and Geographix, etc). The first step was to perform an inventory of the files on our network and, to me, there isn't anything better for file level management/text parsing than good old PERL. Here are a few gems I found that I think are worth sharing. Be aware that this is a total hack so please don't take offense all of you PERL purists. 

Example 1:  Here is a handy way to iterate through a file system and do something to each record. $startpath is the file system directory and the second line is where you can perform a filter. In this case, I am filtering out paths that contain snapshot which is related to our backup solution.

Example 2: Opening up zip archives and do something with the contents.

Example 3: Get local time in and nicer format.

Wednesday, September 29, 2010

Participating with OneGeology: Experience, Lessons Learned and Other Tidbits

I recently had the opportunity to "stand up" a WMS representing a 1:5,000,000 scale geologic map of North America for integration into a platform called OneGeology.




OneGeology, whos mission statement is to:

"Make web-accessible the best available geological map data worldwide at a scale of about 1: 1 million, as a geological survey contribution to the International Year of Planet Earth." (see: http://onegeology.org/what_is/mission.html)

 aims to:
  • create dynamic digital geological map data for the world.
  • make existing geological map data accessible in whatever digital format is available in each country. The target scale is 1:1 million but the project will be pragmatic and accept a range of scales and the best available data.
  • transfer know-how to those who need it, adopting an approach that recognises that different nations have differing abilities to participate.
  • the initiative is truly multilateral and multinational and will be carried out under the umbrella of several global organisations.   (see:  http://onegeology.org/what_is/objective.html)

The process for contributing to this worthy effort was pretty interesting and I wanted to share this experience a bit.

To begin with, the map we were submitting was actually a replacement for an existing geologic map of North America which only covered the southern portion.  The previous WMS was served using Map Server while our new one was being powered with ArcGIS Server 9.3.1.  This was quite the test for AGS given the outstanding performance of Map Server with regard to WMS serving.  In an effort to boost performance without doing a bunch of map authoring and data processing, we performed a couple of interesting tricks that I outlined in some detail in a previous post.

Basically, participation with the OneGeology platform can occur at several tiers, each basically correlated to functionality.  Our participation was of the first tier, that being simply contributing a WMS.  This experience was not trivial.  Even though WMS is technically a "standard," there is still enough wiggle in the spec that a specific implementation is needed to ensure interoperability.  The folks at OneGeology have done a outstanding job with this and have documented, in detail, requirements for how WMS services need to be configured for integration into their system.  Our specific instances are here:

http://certmapper.cr.usgs.gov/arcgis/rest/services/one_geology_wms/USGS_Geologic_Map_of_North_America/MapServer -- raster one

http://certmapper.cr.usgs.gov/arcgis/rest/services/one_geology_wms/USGS_Geologic_Map_of_North_America_GFI/MapServer -- vector one for getFeatureInfo requests only

And finally the portal.  It is a really nice application and serves as a great demonstration of "mashing up" distributed data services that originate throughout the globe.  It is really pretty astonishing, given the wide range of participating organizations.
OneGeology Portal Depicting Geologic Map of North America






Tuesday, September 7, 2010

WMS GetFeatureInfo Request Rewrite with Apache mod_rewrite (ArcGIS Server, Performance)

We had an interesting issue to deal with with regard to a WMS getFeatureInfo request with a particular WMS webmap service using ArcGIS server.  This issue had to due with performance.  The map service was of the Geologic Map of North America which contained very complicated geometries, cartography, etc so you can image the performance of dynamically generating images for WMS getMap requests from this bad boy.
View of Geologic Map of North America WMS Service in GAIA 3.4

We could have done a whole bunch of data processing such as scale dependent rendering, generalizing layers, etc (which would have been the right thing to do) but didn't really have the time or resources to do so.  Another solution you may be thinking was to cache the service but I am not convinced that ArcGIS Server caches work for WMS getMap requests given the bounding box geometry for the getMap requests are dynamic and may not match the scale and dimensions of the cache but that should be left to an entirely different discussion.

The next best thing was to rasterize the data and basically serve getMap requests based on a rasterized version of the data (in the map document itself).  This helped with performance dramatically but introduced a new issue.  Given that is was based on rasterized data, attribute data was now absent eliminating the ability to serve getFeatureInfo requests.  Our solution for this was to simply serve getFeatureInfo requests with a different service than that which serviced getMap requests.  Two services responding to different requests.  The WMS getCapabilities spec implements this capability by allowing you to simply specify an alternative OnlineResource xlink:type="" value for getFeatureInfo requests.  This works great for most clients but some don't adhere to this so we were forced to forward getFeatureInfo requests made to the original WMS service (containing the rasterized version of the data) to the new service.  Given this scenario, the base URI's for each service were:

http://certmapper.cr.usgs.gov/arcgis/rest/services/one_geology_wms/USGS_Geologic_Map_of_North_America/MapServer -- raster one

http://certmapper.cr.usgs.gov/arcgis/rest/services/one_geology_wms/USGS_Geologic_Map_of_North_America_GFI/MapServer -- vector one for getFeatureInfo requests only

To do this, we used apache mod_rewrite.  Now apache mod_rewrite is not for the faint of heart.  It is powerful but takes some time to work through.  Oh, and get your favorite regular expression cheatsheet ready because you will need it.

Anyway, here is the syntax we used to solve our problem:
The RewriteCond statement sets the stage.  In limits the scope of the following RewriteRule.  In this case, it looks for a query string variable that contains a value of "GetFeatureInfo" (we had to do some pattern matching stuff to account for caps or nocaps and to make is more explicit but that is too much for this post).  The RewriteRule then matches the first statement and replaces it with the second.  In our case, it tries to match:

/arcgis/services/one_geology_wms/USGS_Geologic_Map_of_North_America/MapServer/WMSServer 

and replace it with

http://certmapper.cr.usgs.gov/arcgis/services/one_geology_wms/USGS_Geologic_Map_of_North_America_GFI/MapServer/WMSServer. 

We actually used regular expression stuff to match it but this does the same thing and is easier to understand.  The final thing you will notice is the [P] modifier.  The replacement statement is actually mapped to a local file system location.  In our case, we needed to forward explicitly to a reverse proxy server so a fully qualified URI with the [P] does this.

Thanks to @GISBrett and @jasonbirch for suggestions and moral support on coming up with this solution :-)

Tuesday, June 29, 2010

ArcGIS Server JavaScript API For Beginners: Populating DOJO FilteringSelect

The more I work with it, the more I like it, that is, the ArcGIS Server JavaScript API.  It has some real funkyness that is hard to get use to at first (loose or no typing, dynamic nature, callbacks, etc) but once you get going, it is pretty slick.  Given this, I am going put up a few posts in the coming weeks that illustrate very simple samples that I think are useful.  These aren't elegant, OO examples, just examples so all JS pros out there will probably find these post of little use.  They are based on the ArcGIS Server JavaScript API 2.0 (and ArcGIS 10).

Generally speaking, usability is often the single most important factor dictating the success or failure of your geoweb application. Make it simple and fool proof and guide the user through the workflow or task. If they get confused, you have failed. One component that can be used to help accomplish this is a pre-populated drop-down/search box that auto-completes. DOJO, the toolkit that the ArcGIS Server JavaScript API is built on, provides a lot of nice components for doing just this. One of these is dijit.form.FilteringSelect. It does a lot of cool stuff which assist in fool proof usability, much more that what is mentioned here. This post addresses how to populate a FilteringSelect dijit with the results of a query, in this case, the query of an ArcGIS Server map service layer’s field value. It is assumed that you know the very basics of using the ArcGIS Server JavaScript API, if not, have a look.

Instantiating a FilteringSelect dijit can be done declaratively or programmatically. In this case, we will declare it:

<body class="tundra">
    <input dojoType="dijit.form.FilteringSelect"
           id="lineid"
           searchAttr="name"
           name="widgetName"
           onChange="doSomething(this.value)">
</body>



where the id attribute is used to identify the component in the document, the onChange attribute defines the event handler when the component is changed and the searchAttr attribute, well, we will discuss that later. Remember to define your component before declaring it using dojo.require("dijit.form.FilteringSelect"). Now that the component has been declared, lets populate it. A best practice for initializing web maps along with selected stuff that goes along with them (such as our FilteringSelect component) is to define a function that is called when the the page is loaded. This is handled nicely using the dojo.addOnLoad() function. Something like:



    //Our main initialization function, called at just the right time
    function init () {
        //Create your query
        var queryTask = new esri.tasks.QueryTask(<query task rest endpoint>);
        //set the onComplete event handler, in this case, when the query is complete, call initLineID,
        //production code would handle handle the error callback as well
        dojo.connect(queryTask, "onComplete", initLineID);
       
        //build and execute your query
        var query = new esri.tasks.Query();
        query.outFields = [<name of the field you want>];
        query.text = "all";
        query.returnGeometry = true;
        queryTask.execute(query);

     }
     
     dojo.addOnLoad(init);


In the snippet above, we are basically building a query task and executing it.  For details on the queryTask works, have a look at the queryTask object (everything is an object is JS, another kind of weird thing to get use to).

Now the good stuff, populating the FilteringSelect component.  We first need to bind the completion event of the query to some logic that will populate the FilteringSelect component.  This is done using a handy little dojo function:

     dojo.connect(queryTask, "onComplete", initLineID);

which basically says once the queryTask fires the onComplete event, take the results and run with them in a function called initLineID.  Here is initLineID:

function initLineID(features) {
        var lineIdObjects = [];
        dojo.forEach(features.features, function(feature) {
            lineIdObjects.push({"name": feature.attributes.field_name});;
        });
       
        //Build the appropriate data object for our data component
        var data = {
              "identifier": "name",
              "items": lineIdObjects
        }
       
        //bind the data object to the datastore
        var lineDataStore = new dojo.data.ItemFileReadStore({data: data});
   
        //bind the data store to the FilteringSelect component
        dijit.byId("lineid").store = lineDataStore;
     }


Basically, we take the queryTask results, in this case referred to as "features" and refactor them into a ItemFileReadStore which is then bound to the FilteringSelect component.  Most of the UI components in DOJO work best consuming data from one of the DOJO data stores, in this case we are using the ItemFileReadStore.  ItemFileReadStores basically house JSON data formatted in a specific way.  Unfortunately, direct REST requests made to the ArcGIS Server Rest API don't return JSON formatted in this way which would have made things very easy but we will leave that for another time.

Because of this, we basically need to refactor our queryTask's returned features in a way that the ItemFileReadStore likes (see, "Reading JSON Data with DOJO").  We do this by creating an array object and populating it by stepping through each queryTask feature and adding it to the array as a name/value pair (one of the ItemFileReadStore format requirements).  We then build a generic object called "data" with 2 properties, "identifier" and "items".  The identifier property tells the ItemFileReadStore what handle to look for in the name/value pairs collection (our array).  In our case, we named each result record "name."  The second property called "items" is assigned our array.  Upon completion of this generic data object, we then simply bind it to the ItemFileReadStore using some named property.  In this case, we are calling it "data" as well.  Our final step is to find our FilteringSelect component in the document using the dojo.byId function and to assign its store property the ItemFileReadStore we created.  Thats it...

One final note on what I skipped earlier.  Remember that we assigned each of our queryTask feature values a attribute name called "name" and assigned our required "identifier" property and value of  "name" as well:
   
        var lineIdObjects = [];
        dojo.forEach(features.features, function(feature) {
            lineIdObjects.push({"name": feature.attributes.field_name});;
        });
       
        //Build the appropriate data object for our data component
        var data = {
              "identifier": "name",
              "items": lineIdObjects
        }


this is the handle that is used by the FilteringSelect component to find where to look for the data.  We tell the FilteringSelect component where to look for the data values using the searchAttr attribute:

    <body class="tundra">
    <input dojoType="dijit.form.FilteringSelect"
           id="lineid"
           searchAttr="name"
           name="widgetName"
           onChange="doSomething(this.value)">
     </body>


You can download this sample here



Wednesday, April 7, 2010

Twitter Use For Geo Pros: The Good and the Bad

I have used Twitter for about a year now and have 225 followers. I started using it in a professional capacity, trying to learn from and connect with people in the geosphere. I work in a technical capacity professionally but don't really consider myself a bleeding edge techie or a gadget for gadget sack kind of person. Basically, what can help me do my job better. Anyhow, after a year of use, I feel I am credibly positioned to give a critique on its effectiveness and usefulness for geopros.

I have tried to keep my opinions truly objective. I have received a fare amount of grief by a variety of people in my life regarding its use. My "traditional" colleagues think I'm nuts. Others just don't understand. My favorite line is "What's with this Twitter crap". My wife quivers each time that annoying Tweetdeck chirp chatters from my laptop sitting in my home office (make sure to turn that off). Given this disclosure, here is my take:

The Good
  1. If you want to learn about stuff fast, Twitter is the best. Anything, I mean anything, that you may be interested in, is posted to Twitter first. Here's the trick, you have to follow the right people (and finding those people can be easy I guess) . Examples of this stuff includes:
    • The latest release of your favorite software,
    • What colleagues are up to (that very instant)
    • What people are saying at any given public venue (conferences, press conferences, etc...)
    • Attending events such as conferences remotely
    • What's new with... (you name it)
    • Personal opinions about... (you name it)
  2. What government agencies are up to: The current federal administration has embraced social media which has resonated with many state and local governments. Using Twitter is a good way to keep track of what is going on within your government.
  3. Support: I recently posted a question to Twitter about a problem I was having with ArcGIS Server. An expert engineer (thanks @keyurva) working for ESRI, replied instantly to help. I can't imagine how long it would have taken via a formal incident request.
  4. Networking: I have virtually met a number of people that I never would have met otherwise. In some cases, these virtual relationships have lead to real ones. An example relates to my part-time role as a faculty member at a local University. Using Twitter, I was able to pursue a potential guest lecture from a great individual (thanks @agup). In addition, staying connected is much easier and quicker, granted without alot of detail but in a networking setting, it is better than the alternative.
  5. Data Mining: I use TweetDeck which is a pretty good tool (UberTwitter remotely). With TweetDeck, I can mine a tone of info with little effort. I swear I am observing the Matrix:-).
The Bad
  1. Continuity: I have followed alot of people who have been great but, eventually abandon their Twitter persona. I can relate to this because it takes a bit of work to continue posting, you have to buy in a bit. Also, it is easy to think this is the coolest thing when you start and then that thought fades. You fire up your account and tweet like crazy and then your.....tweets.......start............to..............slow...................down................................until...
  2. I will be honest here, it is a bit narcissistic and it can kind of turn into a popularity contest if you let it. "How many followers can I get." It shouldn't be about this but we are all human. We need validation. However, if you are tweeting from your kids birthday party, the dinner table, or tweet more that lets say 15 or maybe 20 times a day (I would say less but...), you might want to lay off. Just my opinion. (Quick tip: if you want alot of followers, just tweet about different stuff, sports, religion, hobbies, politics, etc).
  3. Data Mining: This is a benefit and a curse. While there is alot of data and information to mine and some tools do a better job than others, alot of it is still nonsense.
  4. There are many more people within professional circles not using it than are. Sure within some communities (techies, developers, etc) the use is higher but I was recently at the ESRI PUG conference and during the plenary, the presenter asked who was using Twitter. I would estimate the maybe 10% of the crowd of 1200 attendees raised their hands. Just one anecdotal example.
  5. It seems to be lacking in security. I have noticed a few accounts I follow have been "defaced." 3 out of 225 is pretty bad.
  6. Is this going to continue? Whats next? Am I wasting my time? I'm not in tune with the future of Social Networking so I will leave that up to those who are.
P.S. I said I was going to try and keep this objective but I can't help myself. For professional networking, Twitter and LinkedIn are great but to me, FB is cramming a square peg into a round hole. I can't stand the FB UI and think it is best left to "Johnny just cut his first tooth" and "I just made the biggest..."

Monday, March 1, 2010

Using ArcGIS Explorer (900) for Presentations

I recently had the opportunity to present at the 2010 ESRI Petroleum User's Group (PUG) meeting in Houston. My talk was nothing earth-shattering, basically just a intro/tour of the work our team had been doing the previous year. My time-slot was short, 25 minutes with 5 minutes of Q & A. This was fine with me. Given my short attention span and propensity towards ADD behaviors, I actually prefer quick talks. Faced with this and the fact that my talk didn't contain much factual information, I wanted to try something a bit different standard slides. Although I hadn't worked with ArcGIS Explorer (AGX) much, I remembered hearing the ability within build 900 to perform some short of slide show so thought I would give it a try. The global nature of the materials I wanted to present also lended itself nicely to this platform.


ArcGIS Explorer Build 900

The process to do this is was pretty simple. The workflow is basically to:
  1. Stylize layers in either ArcMap or ArcGlobe (for 3D stuff).
  2. Build an AGX project
  3. Navigate to various "views" and capture "slides"
  4. Place titles on "slides" if desired
  5. Activate the show by simply hitting the go button.
The Cool
  • Wow factor provided by the geobrowser platform, especially to non-geo audiences.
  • Super easy to do, very intuitive workflow.
  • From a presentation flow persepective, the platform allows for a nice, smooth talk with soft transitions.
  • Informative media, not a boring slide of text or some dopey picture from istock.
  • Features can be identified, both to the data layer's attribute table or hyperlink field
The Not Very Cool
  • Because it is so easy, it isn't very feature rich. Aside from being able to add titles, there really isn't any way to annotate your slides
  • It is pretty buggy. The identify functionality works about 90% of the time, guaranteed to not work when it really counts.
  • Identify only works on "data layers" but not references created by layer files. This is problematic because you need to use layer files for rich symbology (from ArcGlobe). The work around for this is to add the layer as a data layer, make it 100% transparent, then add it with the desired symbology (using the layer file) for viewing.
Results



















Tuesday, September 15, 2009

Comprehensive Look at the Geoweb (Part 3 and 4)

The the story continues... I have been off and on the buzzword "Geoweb" for several years. I am now back on it so I set out to try and take a real look at the Geoweb, at least for the sake of academics. The term is bantered about a bunch and we all have our own take on what it really is. My goal was to try to comprehensively define the geoweb based on well documented patterns, models and architectures that currently exist within the web (part 1 and part 2 of this 4 part series) as well as from a purely organic perspective. Here are the slides that were used for this discussion. I can post my lectures as well if anyone is interested.



In summary, I came up with what I think is a very nice analogy in an attempt to somehow concisely define the Geoweb. I use the analog of an ecosystem defined as:

“An ecosystem is a natural unit consisting of all plants, animals and micro-organisms (biotic factors) in an area functioning together with all of the physical (abiotic) factors of the environment. Ecosystems can be permanent or temporary. An ecosystem is a unit of interdependent organisms which share the same habitat. Ecosystems usually form a number of food webs…” (Ecosystem, 2009)

Using this, we can begin to crosswalk components of the geoweb to the notion of an ecosystem. The geoweb as a unit of something finite, is composed of biotic and abiotic factions. Biotic factors including users, participants, perceptions (top-down vs. bottom-up), change and usability. Abiotic factors such as architectures, standards, formats, specs, platforms, etc... There are a number of relationships that exist between these factors, each with their own microprocesses but all interdependent in varying ways. Finally, portions of the the geoweb are permanent and some are temporary, depending on all of the factors (and their associated relationships) listed above.

If nothing else, have a look at the references cited section at the end of the slides. It includes alot of great materials from many leaders in the community that are worthwhile having a look at.


Ecosystem. (2009, August 26). In Wikipedia, The Free Encyclopedia. Retrieved 17:10, August 26, 2009, from http://en.wikipedia.org/w/index.php?title=Ecosystem&oldid=310197121

Monday, August 31, 2009

Tips and Tricks For the Geo Soloist

Imagine this scenario, a well educated, highly trained GIS/Geo professional is working for a small organization (county, environmental consulting, NGO, small federal agency, startup etc). Characteristics of such an organization typically include small budgets, pressure to maximize ROI of the organizations geospatial infrastructure, minimal resources (few people), you get the idea. This person is faced with meeting internal needs, typically required to perform the geoanalyses aligned with the organization's fundamental business processes ("I need a map off...") and is also tasked with presenting the valuable collection of geospatial products the small organization produces to the world. This professional is also commonly faced with requests from management that are typically articulated with something like:

"Hey GeoPro, I saw this great something or other at a business luncheon today, can we do that with our stuff."

If this scenario sounds familiar, you may be a Geo Soloist. Generally speaking, a Geo Soloist works completely independently of the rest of the business process and are seen by other professionals within the organization as the "technology guy/gal" or "web guy/gal" or "GIS guy/gal." They work in professional cultures that really don't understand the Geo trade, and typically work closely with non-Geo specialists such as scientists or engineers. A Geo Soloist can be thought of as a "jack of all trades" a "master of none" or a "polymath," commonly required to play the role of GIS analyst, business analyst, project manager, developer, DBA and evangelist, depending on the current project's needs or the issue of the day.

Italian polymath Leonardo da Vinci, scientist, mathematician, engineer, inventor, anatomist, painter, sculptor, architect, botanist, musician and writer.

The role of Geo Soloist is not for the faint of heart. It can be challenging and frustrating in that it requires compromises, minimized expectations, and can be disadvantageous. However, it is also a gift. It provides the opportunity to tackle a wide range of problems, provides a wide spectrum of experiences, and fosters resourcefulness, agility and ingenuity.

Serving as a Geo Soloist for many years, I have come up with a manifesto or set of rules to live by that I wanted to share. Many of these are interrelated and this list is not comprehensive but hopefully you will find something that rings home to you. They are in not particular order.
  1. Don't start from scratch: There are good "starting points" where someone else has done much of the legwork. An example of this might be some of the sample web map applications that ESRI provides for their new API's.
  2. Maximize documentation efficiency: This does not mean "do as little as possible." A Geo Soloist is typically working independently so documentation needs to serve their needs only (one benefit of not working in a group, say a team of developers). The other issue is that robust or extensive documentation takes time and requires maintenance given rapid changes. Maintenance also requires alot of time, something that is precious to all of us but especially to a Soloist. Documentation is important, just keep it relevant.
  3. Simplicity: Keep things simple. Workflows, expectations, requirements, everything. This concept should be a no-brainer but gets lost somehow. Make it your primary goal. Keep is part of every discussion.
  4. Don't get caught in a worm burrows. It is easy to do so be aware when you begin digging. Use well established patterns. Copy success stories and tweek as needed.
  5. Stay away from the bleeding edge: Use well established best practices and standards (when appropriate). Follow what the industry is doing and monitor grassroots efforts. Keep yourself educated about where the bleeding edge is and take a couple of steps back from it.
  6. Pillage: Use resources that are already available. There are so many great resources and given the vibrant, collaborative, brother/sisterhood we work in within the geospatial community, realize that someone has probably already done what you are trying to do and they are probably willing to share.
  7. Be resourceful: Student internships, collaborative funding relationships, cooperative agreements.
  8. Embrace the vacuum: This is counter intuitive to most of my other suggestions but exists in a different plane, more closely aligned to day-to-day workflows. We are taught to not work in a vacuum. I agree, but when you are working by yourself (at least as it relates to your immediate trade), trying to meet the needs of your immediate stakeholders, productivity can be very high if you do it your way. The vacuum can be a tool that lowers barriers. An example might be trying to over-collaborate (if there is such a thing) with those who are not specialists in our trade. Don't ask for permission, just do it.
  9. Be aware: Make sure you are aware of what is going on in the industry. Pick and choose patterns, best practices, standards etc. established by leaders in our community. Social networking tools such as Twitter are a great was to stay connected and informed. Be in touch with industry "buzz." Subscribe to leading industry blog sites that are relevant to your work.
  10. Manage the managers: Be sure to sell the concepts, but you are the ONE. Don't oversell but don't undersell. Manage expectations but don't underestimate your capabilities.
  11. Stay Agile: Embrace change, position yourself to manage change. Don't rest on what you know or what you are comfortable with. Don't be afraid of stepping outside your comfort zone. While the Agile process is typically thought of as a software development method, it expresses concepts that can be extended into all aspects of technology management. Have a look at it.
  12. Never stop learning: This should go without saying but it takes effort. We work on a platform that is like quicksand, ever-changing and it can swallow us up if we aren't nimble. The learning process doesn't have to be formal, simply read one blog a day or tackle 1 chapter in that nasty SQL book this week...then another next week....then another.
If you have others please let me know. In addition, I would like to pose a question to all of the GeoPros out there: Is the skillset/work experience of a Geosoloist (jack of all trades) desirable from the perspective of potential employers or is specialization?



For those of you who have been following my blog, don't worry, I haven't forgotten about parts 3 and 4, just taking more effort than first thought.

Friday, August 14, 2009

Web 2.0 and the Geoweb Part 2: Web 2.0 Patterns

Building upon part 1 of this series of lectures slides, part 2 actually examines (albeit at a pretty high level) well documented Web 2.0 patterns active in the Geoweb. Once again, the primary source of my research related to Web 2.0 patterns comes from Web 2.o Architectures by James Governor and et.al among others. Future lectures (parts 3 and 4) will comprehensively examine the Geoweb, using these Web2.0 patterns as a foundation as well as concepts examined by Geoweb experts related to usability, formats, discovery, architecture, etc....

Parts 3 and 4: Comprehensive look at the Geoweb

Wednesday, August 12, 2009

Web 2.0 and the Geoweb Part 1: Web 2.0 Examples

As I have mentioned earlier, I am ramping up for the upcoming semester and am feverishly prepping. My course, "Introduction To the Geoweb" is part of the Master of Engineering/GIS offered at the University of Colorado at Denver.

In the coming weeks, I intend to share materials I will be presenting to my students to all of you in hopes of getting some constructive feedback from the experts--YOU! I won't be sharing everything, just some selected materials that I think can benefit from some "participatory lecture development" if there is such a thing. I will also be citing much of the work that many of you have contributed so your feedback is critical.

The collection of materials I intend to share is tentatively termed "Web2.0 and the Geoweb." My hope during this series of lectures is to expose students to well documented Web 2.0 patterns and examples as a foundation for further exploration of the Geoweb. Some have suggested that a detailed look at web architectures and http are warranted before this discussion. Rest assured, the students will be prepared for these more advanced concepts.

The primary source of my research related to Web 2.0 patterns and examples comes from Web 2.o Architectures by James Governor and others. It is a good piece, articulating web2.0 patterns in a formal way and has worked nicely for foundational discovery. I have also incorporated materials from several additional sources that have proven adequate.

The story I hope to weave reads something like this: the Geoweb (which I think I can fully embrace) has roots, much of which can be described using well document Web 2.0 patterns. These patterns are best described using real world examples which can then be articulated formally using a standard method of description. This framework then serves as the foundation for further discussions mapping these patterns and subsequent reference models and architectures to Geoweb concepts, some of which have been stewing for some time and others which have emerged recently.

With that said, part 1 of 4 (or maybe 5) slides follow. These are subject to change which goes without saying. Be aware that these are lecture slides so there is a fair amount of text. Students get a little "bent without bullets."

I will be posting my recorded lectures as well. Continue to Part 2: Web 2.0 Patterns.

Friday, August 7, 2009

Back On The Geoweb Bandwagon

I am officially on the Geoweb bandwagon! I think this is the third time I have declared this in recent years, admittedly a bit premature in my previous attempts but I'm all in this time. The Geoweb has finally come of age. To give you some context, I have been a part-time instructor for several years now, teaching a number of GIS courses in the Master of Engineering Program (GIS) at the University of Colorado @ Denver. My favorite course over the years has been my web GIS course. While the most challenging given the ever changing landscape in this area, it is where my interest lies. The problem has been, what the heck do I call this course.

I have been following the Geoweb09 activities this year remotely and have had the opportunity to attend a couple of times, even dating back to its previous form, GML days. The term "Geoweb" and its numerous incarnations (Geospatial Web) have been bantered about for a few years, mostly in the context of this gathering. A couple of years ago, I actually called my course "Introduction to the Geoweb" but struggled with the label given the immaturity of the platform. Web2.0 stuff was just kicking in and my perception until recently was that the Geoweb was nothing more than some neogeos throwing up markers on a Google Map with little or no appreciation, knowledge, etc. of traditional (and very important) GIS concepts such as spatial relationships (topologies), projections, spatial analysis, etc. In addition, given my old-school roots in GIS, not having "GIS" in the course title was like having a marg without Grand Marnier--it worked and it was still decent but just wasn't right. Needless to say, I backtracked. So over the next couple of years, my labels for the course included "Introduction to Distributed GIS" and "Introduction to Internet GIS."

Those days are over now. The course is now officially recalled "Introduction to The Geoweb." This corny personal journey mimics that maturation process of the Geoweb itself. We all knew it was there and wanted to embrace it, but a few chips had to fall before we could really do so. The Geoweb is now walking. In fact, it is more like a toddler who can really move but who is a bit unpredictable.

I have been researching a number of great materials related to the Geoweb, much of which has been coming out of the Geoweb conference, and other materials which have been around for awhile. Based on these sources, I hope to develop a comprehensive look at the Geoweb that I will be sharing this semester with my students. I also plan to post these materials for some "crowd sourced lecture development" (if there is such a thing) as well so stay tuned.

Monday, July 6, 2009

ArcGIS Server Sample Flex Viewer: TwitterFeedWidget



I have been thinking about how Twitter could be used to enhance the capabilities/user experience of a web mapping system and came op with some decent stories. The first would be providing users with access to a feed dedicated to the application which contains information about it including updates, news, changes, downtimes, etc. The second would be users who wish to perform searches of Twitter content that may be related to the map and eventually, overlaying geolocated Tweets onto the map. These (and the fact that I just wanted to poke around the Twitter API) gave me enough of an excuse to start messing with the Twitter API. I ended up with a simple little widget that allows users to search for tweets within a specified geographic location, in this case, a circle. Nothing earth shattering but still maybe somewhat useful. Before giving you some of the nuts and bolts of this, I want to be sure and reference the materials I used:

Some Details on how it works.
It is really pretty simple. The user is able to draw a circle on the map and any tweets that originated from within that location based on the Twitter user's location property are returned as an ATOM Feed. The processes uses the Twitter API geocode parameter where a lat, long and radius of a circle are needed. The widget obtains the lat, long, and radius values from the circle tool. I added a coordinate transformation function to the Circle Tool component to convert the distance units (radius of the circle) to miles from decimal degrees. I used the Great Circle Distance Formula. The ATOM feed is parsed using the Flex XMLSyndication package and is validated using the Flex CoreLib Utility Package (see links above).

Proxy Server
As with any application making cross-domain asynchronous data requests, a proxy server is needed to "fool" the browser security settings. Flex has a nice framework for bypassing this. If the feed host contains a crossdomain.xml file that allows cross-domain access, you are good to go. However, Twitter locks this down (Twitter crossdomain.xml). I have included a proxy server implemented in Java within the package. It is NOT PRODUCTION quality but will get you started. There are other implementations that are easier out there. Have a look at the resources I sited for some other examples.

Known Issues and Limitations
Simply put, there are several limitations with this that make it, lets say, less than production quality. I hope to rectify these soon. These include:
  • I haven't tested the feed results very well. The widget catches feeds that are empty which is good but the way I did this is kind of sloppy. I won't go into it here but if you have questions, I can elaborate.
  • The coordinate transformation for the distance units (radius conversion from DD to miles) I am using is very rough but good enough for this use.
  • It doesn't play very nicely with the map action and map navigation state of the Sample Flex Viewer (SFV). Given that the draw circle component wasn't designed for use with the SFV, it isn't integrated very well with the event driven model the SFV uses. Not to say it isn't a nice component because it is. Using it in the Sample Flex Viewer is just a bit of a stretch. There are alot of issues with this but from a use perspective, users have to keep clicking on the draw circle tool after each use and then state defaults back to the default map navigation (pan). Another problem is if the user trys to change the map action or map navigation state (by selecting another component that does so), during the middle of component use, bad things happen. One of the reasons for this is that I didn't want to make changes to the core by adding custom events, etc. However, I am hopeful that I can improve this without making changes to the core and will look into it.
  • Improvement can be made to the tweet results listing (links to profile, user timeline, etc...).
  • Alot of other testing needs to occur as well. Just running out of time right now.

Wednesday, July 1, 2009

Keeping Your Grass Green (with little water)

This is an odd post and intended for all of you who follow this and aren't geogeeks (sorry nerds but this might interest you as well). This advise is for people with Kentucky Bluegrass lawns (Colorado). So many people have asked me how I keep my grass so healthy and claim I water like crazy. In fact, I am a huge conservationist and try to minimize waste. I promise I have only watered 3 times this year (as of July 1st, 2009). Here is a pic.

Granted, it was a wet Spring for us but I am certain these techniques still apply. Here is the secret:

  • First, assuming you have a lawn with a good foundation and good drainage (nice organics) and it is established, you need to fertilize. This is critical. I use all organic fertilizers. Once a month (more like 1 1/2 months), I apply:
    ---2 parts Richlawn Turffood Pro
    ---1 part Revive granules (kind of expensive but critical)

    I mix these up and apply with a standard spreader. I will leave the amounts to you based or your square footage. It is also critical that you apply the Fall season version of Richlawn in October.
  • Secondly, please mulch. Most modern mowers can mulch. If you don't have one, get one. Bagging grass is a tragedy. You are filling landfills with unneeded waste and the mulch actually helps the sod maintain hydration and ensures that it requires less fertilizer given that you are replenishing the nutrients. One issue is that you will have to mow more often (maybe twice a week if the grass is growing crazy). You can't mulch if your grass is too long.
  • Finally, you must integrate organic material into the subsurface before you lay sod. This is hard to do if you already have a mature landscape but worth mentioning. This means rototilling at least 4 inches of nice organic material into the crappy clay (Typical in Colorado).
That is about it. A couple of items worth mentioning: First, you will have to do this for a couple of years before your lawn responds, don't expect it to respond overnight. You need to train it. Secondly, don't water too much. Kentucky Bluegrass is very drought tolerant if you let it be. If you water too much, it will use the water. Stress it a bit.

Thursday, June 18, 2009

Webmap of US Oil and Gas Production

The USGS Energy Resources Program recently upgraded the US Oil and Gas Production map service for use in their new web mapping platform called Envision which is based on the ArcGIS Server Sample Flex Viewer. The ERP is actively updating the system to deliver all legacy map services and has recently upgraded the US Oil and Gas Production map (By Laura R.N. Biewick USGS DDS 69-q)