Bounding Rectangles - A Case for Something Better

It’s 2015. Almost 2016. And the best we can do to show the extent of a data set is a bounding rectangle?  By their very nature bounding rectangles are not particularly helpful, especially for geographic footprints that are not at all a rectangle. 

Anyone who has searched for, generated metadata for, published, or tried to download geographic data has run into the bounding rectangle.  It is usually displayed in a rather small, set to the side, unusable map graphic. It certainly seems that in this day and age we could do more than that. 

The Alexandria Digital Library Project is almost 20 years old (http://legacy.alexandria.ucsb.edu).  This project described a gazetteer for geospatial data that would use a real footprint as a location index that could be embedded in any number of applications. 

What if we could select a basic set of geopolitical boundaries to register our data and the inset map would actually show the boundary of the state, county, city, or park that the data was describing or contained within.  Granted there might be issues in finding an agreeable boundary to use for a city especially with changing annexations and de-annexations and in many parts of the world the boundaries of countries are changing and evolving.  But clearly we should be able to do better than a bounding rectangle.

Maybe we could even develop a method for using a real map to search for available geospatial data. 

Imagine if the Geographic Names Information System (GNIS) (http://geonames.usgs.gov/) had more than a point for each name? What if there was also a polygon of the area covered by that name?

While it is relatively simple to link lists of names or point locations to Census geography, shouldn’t it be routine to identify the footprint of published data by the actual data extent?  This could be extended to symbolize the footprint by the date last updated and the data steward or data publisher. 

Maybe it’s time to start thinking outside the bounding rectangle box.

AGOL Maps and Applications

The difference between web maps and applications (maps and apps) puzzled me at first but a little more exploring on the AGOL site has demystified this a bit.

The web map is just as it sounds, it is a base map with a set of layers that can be seen through a ArcGIS.com viewer or ArcGIS Explorer, provided you have shared the map service and the web map.

An application on the server side, on AGOL in this case, packages the map and adds some functionality and look and feel to the web map.  It also creates a single URL to the map and the added functionality so it is much easier to share and view.  The AGOL application can be viewed in any browser. 

It’s fairly easy to wrap an AGOL web map into an application.

Open the web map in AGOL and open the share option.  The share gives you a URL that links directly to the AGOL map viewer that you can share with people to view the map and the code for adding the map to an existing web site.  But you can also select Make a Web Application and chose from about 24 basic web application templates.  I have tried several of these web applications including the basic viewer, the social media, editing, and a few of the story telling web applications.  Most of the applications are configurable to some extent.

Here is a link to the state parcel stewardship that will open in the AGOL viewer 

and here is that same map in a basic viewer web application

Both links connect to maps with the same content; they are just wrapped differently.

The real deal with applications is mobile applications.  For these applications you don’t have to do anything on the server side other than have the web maps configured to be shared or edited, depending on your application.  The mobile application connects to the URL for the web map and the work is done on the mobile side.  There are some catches.  For the data collection application, I did set up a separate service so the edits would be made on a copy of the feature service and not on my original service. Also the data on the AGOL service has to be structured and configured so the mobile application recognizes the data fields.

There are a few remaining glitches.  If you are publishing a viewer to a data set that is updating frequently and you want to track status or updates on your desktop and push the updates to AGOL, make sure your services are all “awake”, sometimes there is a lag between when the service is over ridden and when the changes are reflected in updates. Another way to handle this is to do the edits on the AGOL site and then users will see changes more quickly.  You have to be wise about how you manage the sharing on the services and viewer if you want to have a few people edit the data but have everyone see the results. 

AGOL is not likely to replace your existing ArcGIS Server, but it can lighten the load.  It is a good place to set up some quick data publishing, to set up some relatively static views of the data, experiment with new or proposed data or map services, set up a story map about your organization, use web services for data collection within a defined organization, and to learn how web services work. 

There are emerging capabilities.  Such as using drop box to link to content or possibility to link to data downloads, additional templates and application offerings, expanded analysis tools like buffer and data summaries and analysis, and the ability to track credit consumption for each tool. 

The AGOL experience takes a little getting used to but it is a relatively painless way to gain familiarity with web publishing, web and feature services, and providing access to map content.  This is also a good way to gain familiarity with the use of web applications and available templates

AGOL, Web Services, and Mashups

My next foray with Arc GIS Online is to explore some the available web services that can be added to AGOL and how they might be used.  Many of the maps and web services I work with are national status maps or inventories.  The search for available services started when I wanted to add labels on county polygons for one of my web applications.

Web Services Terms

Skip this section if web services are second nature to you.  Some of the nuances among these terms are important to understand for AGOL.  WMS is a Web Map Service.  This is a completed map provided with symbology and scale visibilities, essentially providing an image of the map.  Within AGOL a single web service may have multiple layers that can be turned on and off, and have customized popups.  In AGOL these are added as A WMS OGC Web Service.

WFS is a Web Feature Service.  This service provides the actual features, not a map image of them.  Features can be analyzed, downloaded, added to a desktop canvas, and are typically provided in an extensible markup language (XML) for geography (GML).  This means the definitions of the features are provided and the features can be added to a variety of software platforms.  AGOL does not have the capability to add WFS, but links to the WFS for a feature could be added to the customized popup, if you wanted to provide information on the WFS address.

REST or RESTful Services is a Representational State Transfer (did that clarify the term?) and this is another standard or architecture for providing access to web served data and services.  In AGOL these services are added as ArcGIS Server Web Service.  The transparency and visibility ranges (minimum and maximum display scale) can be configured for Restful Services in AGOL.

Services

There are many WMS, WFS, and REST Service available to supplement your AGOL map.  I did a web search from my browser, but there is also a search engine within the AGOL map to find available services. 

These are fairly easy to add to any map, just add data from the web and select the type of service.  The service adds fairly quickly, if you pick the right type.  After the service appears on your map, click on the service in the details information on the map viewer and the layers within that service can be added and configured individually. 

Since county labels were my first requirement I started with Tiger Web. http://tigerweb.geo.census.gov/tigerwebmain/TIGERweb_wms.html

This WMS had exactly what I needed for state and county labels as well as American Indian Areas with labels.  School districts and federal congressional districts are also available along with many of the Census geography features. This service provides a lot of rich Census content as well and it is an easy way to display place names and geography with some population information.  The geography and the labels are offered separately and the labels scale nicely.  The WFS services on Tiger Web are really helpful to view your current Census geography with your local data sets on an ArcGIS desktop map canvas as well.  No need to download and re-project the Census geography files.  This is for desktop, not AGOL.

The National Map Web Services is another fairly easily navigated web site to find services. http://viewer.nationalmap.gov/example/services.html

This site has a good variety of imagery, elevation, and federally managed data sets available as WMS and WFS.  All of the links worked and the data added as advertised.

There are a lot of map and feature service available at the federal Geospatial Platform.  Finding the available WMS and WFS services is not particularly obvious at this site but a search for WMS found 26 results on the Geoplatform and 1,043 harvested items.  However, many of these did not work as advertised, some had data in them some did not, some were web services and some were viewers only, but it’s a start.  Many states also have some excellent web services.  Montana and Arkansas are two states I have used.

It is interesting to add the same data from different web service sources and see the differences in the representations.  State, county, and city boundaries have a variety of representations and all seem to be sourced differently.  I suspect as the use of the web services because more accepted there will more reliance in single authoritative representations of commonly used layers.

My first foray with ArcGIS Online

Now that the dust has settled and AGOL is almost old hat, it must be time to give a roll.  I started with a relatively simple idea for a web map and thought this would be a test and I know a lot of you are making the same start, because I see lots of maps on AGOL with names like test, test1, map1, first day, try this, etc.  

A few disclaimers, I am reasonably well versed in ArcGIS, working knowledge of spreadsheets but I don’t live there, extensive database knowledge, moderately knowledgeable about web map pages, although Karen and Jason do my heavy lifting, abandoned my inhouse server about 6 months ago, and moderately skeptical about service credits. Lindsay and Ken provided tips and tricks and debugging for some of my more stupid mistakes.  After about 16 hours, not all of it productive time, here are a few things I learned that might save you some time.

False Step 1 - Do not take your great looking desk top mxd with all of the symbology, layer files, and base maps that you use for your local analysis and editing and just push it to AGOL.  The idea that you can “simply” publish any mxd to an AGOL web page is sort of true, but this results in a lot of lost time for a really bad looking, under performing web map that you really didn’t want to use as a web product anyway.

Good Step 1 - Take the time to really get into your AGOL account.  Get your profile set up, establish the groups you want, add the icons, think about the key words, you are going to be using them a lot, so get a list you like.  Thinking time and image and icon prep is all worth it.  It might take you a few hours to get a good base established but it is time well spent.  Think about the pattern and style for user logins, they will be using them more than you think and should follow some pattern you can quickly recall.

Good Step 2 - Design an mxd for a web map, not your desktop but a web map, what do you want to show or not show what will be the information about that layer that you will want to see.  This took a bit to think through and had several false starts but I didn’t want to start with a template, for this experience I wanted to see what it looked like starting from scratch, or nearly so.

False Step 2 - Yep, the projection thing, seems like 100 years ago we were arm wrestling projections and coordinate systems and datums.  So now we are at the Web Mercator Auxiliary Sphere 2, or whatever, and yes you do use the project command or project tool, seems like the good ole days.  Of course you could “simply” geocode your data, but again I wanted to take my data and put it on AGOL. 

False Step 3 - Project your data BEFORE you build the mxd.  If you build an mxd, then project data, and relink your mxd to the newly projected data, some how the attributes never get to the AGOL site.  Sequence is important here, sort of like putting the targets down before the airplane flies over.

Good Step 3 - Fix all of the errors reported in the Analyze step.  Sure some of them are listed as minor or low level or insignificant, don’t believe it, they are checked for a reason and they will bite you at some point, just fix them.

Good Step 4 - Save at every opportunity.  You cannot save frequently enough.  Configure the pop up, save the pop up, save the map.  Change the transparency, save the map. Change the edit properties, save the map. And save the pop up information somewhere, even though you cannot actually cut and paste into the pop up configuration window, at least you will know what you did. And save the map again just to be sure.

False Step 4 - Don’t worry about how the html or web links are going to look, you can’t really change them anyway and the AGOL does a reasonable job of adding the “more info” link in the pop up, although it does not recognize ftp sites as web links and you cannot insert a field name into the custom configured link. 

Good Step 5 - Overwrite the service when you update the data.  Yes, you can do some editing to the data on the AGOL site, but then your desktop data is out of date. Just update it on the desktop and republish. The “overwrite service” option works pretty well, just remember that after you do overwrite, you have to re-share the feature service; I spent too much time “debugging” that.

In the end, I think the AGOL is a good deal.  I consumed 3 service credits messing around with multiple uploads and false starts, but learned a lot.  Check it out http://bit.ly/141df5V.

I sense that one of the primary audiences for the AGOL will be the non-traditional GIS types who might have used Google fusion or some other quick web map tool, so my next experiments will be to see how simple the csv and Excel format are to use and to use the story map templates to build a web page.  I am curious how this experience will fit with my Google publishing experience.