Surveying, Mapping and GIS

Since joining EPA I've been engaged in a wide variety of projects and efforts - one which we are currently getting out the door is an upgraded mapper for EPA projects funded by the American Recovery and Reinvestment Act (ARRA), otherwise known as Stimulus or the Recovery Act.

The major categories of projects receiving EPA funding via ARRA include Superfund Hazardous Waste Cleanup, Leaking Underground Storage Tanks, Clean Water State Revolving Fund (typically wastewater treatment), Drinking Water State Revolving Fund (potable water), National Clean Diesel Campaign, and Brownfields.

 The idea was to provide more granular data across the various programs where EPA has been getting ARRA funding to projects.

The mapper reports on a quarterly basis, in concert with the ARRA reporting requirements, and was built on the ESRI Flex API. As a quick overview, it shows statewide figures, as choropleth map, with summary tables:

Visitors can click on the menu to view awards by program category, or to view all awards, for example:


The pushpins indicating awards can then be selected, and info boxes will pop up with the details. In the example below, we asked the mapper to show "Chelsea, MA" and turned on Clean Diesel awards, and clicking on the map pin, we get the goods, two awards for Chelsea (note, spelling of "Collabrative" comes directly from the database):


This application should improve transparency, with the direct intent of showing tangible benefit to users in showing what's going on right at the community level. As for lessons learned, the technology was far less of a challenge than the learning curve of how government works, and navigating my way through various EPA offices and stakeholders and gaining their acceptance and participation. My many thanks to all those who helped out.

Since joining a federal agency and becoming a national program manager of a federal IT investment, I have been navigating various things like Capital Planning and Investment Control (CPIC), Line of Business (LoB) initiatives, Federal Enterprise Architecture (FEA), and other pieces – there is certainly no shortage of process and documentation required throughout the lifecycle as systems are planned, designed, built, maintained and decommissioned. However, for all of its compliance documentation, metrics and matrices, I still think there are a number of core disconnects.

CPIC and LoB initiatives should inform on investments, and align investments. One area where I see inadequate trackability is in mission support. Each and every IT investment should be able to map to a matrix of mission drivers – such as Agency Strategic Plan elements, such as stated priorities and core initiatives within the agency, such as specific laws and mandates which the Agency is charged with carrying out. In turn, these mappings can be aggregated and examined for alignment. If for example, if the mission objective is to assess the impact of a specific activity on a population, then there is now opportunity to understand how many IT investments relate to that assessment, and one can then get any potentially disparate and disconnected activities aligned and harmonized, to leverage each, take advantage of opportunities to share things like data, models and infrastructure instead of having stovepiped activities where each party reinvents the wheel independently of the next.

Additionally, functional components should be mapped to as well. For example, data requirements, modeling requirements, geodata hosting and web services needs, and so on. These can help to inform on infrastructure investments – for example, being able to build a robust, shared, scalable environment with load balancing and fault tolerance instead of having a series of fragile, disconnected stovepipes with no scalability or fault tolerance. It can help toward paradigm shifts like leveraging cloud capacity and other types of things which can provide cost savings – which can then hopefully be driven toward innovation and new development, rather than more stovepipes and reinventing of the wheel.

As I have a background which straddles many disciplines, when I hear “Enterprise Architecture” it conceptually still goes back to old-school, bricks-and-mortar architecture, where a building is built from a blueprint.

Consider the enterprise as a house. You have several different rooms in it, serving different functions, yet for it to function effectively as a house, the work of the architect is to draft up the elements that bring it all together into a functional, cohesive whole. That means, the structural members to support the second floor as it is placed on the first floor, that means the stairs and corridors needed to connect the rooms, that means the placement of the rooms, to give them doors and windows to daylight where needed, the arrangement of them relative to each other and to the corridors and stairs, to ensure good flows where needed, the wiring to provide light, power and communications, the plumbing to bring water to and from where it’s needed, the HVAC systems to regulate heat and cold, and so on.

Yet, for all the talk in IT EA communities, most organizations largely still function as a series of disconnected, disjointed rooms. The EA effort should serve as the master blueprint. It needs to be informed by those who need each room, but in turn also needs to inform on how everything connects and how things flow from one room to the next, and where the wiring and plumbing is, and how to connect things and create meaningful flows, relationships and functionalities. For the developer, Enterprise Architecture should inform Solution Architecture, and where gaps are identified, that should in turn go back and inform Enterprise Architecture. The loops need to be closed. All of these things, FEA, CPIC, LoB and others, need to move beyond paperwork and compliance exercises, to becoming more robustly informed and cohesive, serving as the master blueprints and roadmaps.

In terms of metrics to gauge success, the best metrics would be those which demonstrate that alignment on mission, function and coordination have been achieved.

As I have been ramping up on EPA's Facility Registry System over the last couple of months since coming on board with EPA, I have also had the opportunity to work on a number of other projects - one recent one that's rolled out is MyPropertyInfo.

The most truly fun thing about working in EPA's Office of Environmental Information is that they are involved in a lot of collaborative, cross-cutting efforts, so I get exposed to a lot of different things across the agency. As an example of this, in working with EPA's Freedom of Information Act (FOIA) officer Larry Gottesman and FOIA staff, they were pursuing an idea of greater accessibility toward reducing FOIA requests, such as in the case of common requests for data which actually is already being published by EPA, but which may be scattered across separate locations in the agency.

One example of this is MyPropertyInfo - http://epa.gov/myproperty/

Here, we sought to address frequently-asked questions about properties. This type of basic background and screening is highly useful and important to bankers, realtors, prospective buyers, developers and others who deal in real estate and properties - yet, to gather all of the relevant information about a property, one might have to visit multiple sites across EPA, or to submit a FOIA request and wait to have EPA gather the data from those disparate sources. So what we did in the case of MyPropertyInfo is quickly roll out a tool that basically just gathers that existing content in one place, and additionally provide it in printer-friendly form.

Thought it was essentially just screen-scraping (as we do not directly control some of the source reporting systems), it was nonetheless a quick and effective way of getting questions answered.  Moving foward, it again demonstrates also that using approaches that can provide easily integratable content like web services in addition to traditional HTML reports, content can be even more elegantly repurposed and reused in a variety of effective ways to answer business questions - with web services associated with the reporting engines, the widgets and iPhone apps for these types of applications will virtually build themselves.  For example, real estate sites like Zillow.com would also be able to dynamically pull environmental profile information about properties of interest to prospective buyers - hopefully a vision for the future at EPA.

Here is some additional perspective on MyPropertyInfo as posted to EPA's Greenversations blog by the FOIA office's Wendy Schumacher:  http://blog.epa.gov/blog/2010/08/30/my-property-info/

For something along a different theme, given my extremely late (1:30AM) arrival back in Pennsylvania last night, Intelligent Transportation Systems (ITS) and Congestion Management.

As I've posted previously, one of the newest hats I now wear is that I'm now the national program manager for EPA's Facility Registry System (FRS), where I am collecting and managing locational data for 2.9 million unique sites and facilities across states, tribes, and territories - I'm certainly excited about being able to contribute some good ideas toward enhancing its' capabilities, holdings, and collaborating and integrating with others across government.

A large part of this is data aggregated from other sources, such as data collected and maintained by state and tribal partners, EPA program offices and others, and then shared out via such means as EPA's Exchange Network. Historically, FRS has done what it can to improve data quality on the back end, by providing a locational record which aggregates up from the disparate underlying records, with layers of standardization, validation, verification and correction algorithms, as well as working with a national network of data stewards. This has iteratively resulted in vast improvements to the data, correcting common issues such as reversed latitude and longitude values, omitted signs in longitudes, partial or erroneous address fields and so on.

However, it still remains that there remain some issues with the data, with the weakness being in how data is collected, imposing limits on what kinds of backend correction can be performed. In most cases, data is captured via basic text fields. The further upstream that the data can be vetted and validated, the better, in particular, right at the point of capture, for example instances where facility operators themselves enter the data.

So, here is the notion - a toolbox of plug-and-play web services and reusable code to replace the basic free-text field, which allows real-time parsing and verification of data being entered. Part of that may involve using licensed commercial APIs to help with address verification and disambiguation, for example, the Bing Maps capability to deal with an incomplete address or one with a typo, such as "1200 Contitutoin, Wash DC" the web services would try to match these and return "Did you mean 1200 Constitution Avenue NW, Washington, DC?"

Between suggesting an alternative which attempts to correct partial and/or incorrect addresses, and providing an aerial photo as a visual cue for verification, it improves the likeihood that the user is going to doublecheck their entry and either accept the suggested alternative or type in a corrected address, along with having the visual verification in the aerial photo. Notionally, if the aerial photo view shows a big open field where there should be a large plastics plant, they would stop and wonder, and perhaps doublecheck the address they had entered.

That's certainly a good first step, and is something I'm currently looking to promote on the short term. In talking to some of my EPA stakeholders, they are very interested in this, and I will look at developing some easy-to-integrate code for them to use.

But, to think more long-range, let's take that further - from the large universe of facilities that I deal with, not all things populating "address" fields are conventional street addresses. For example, remote mining activities in western states might instead be represented on the PLSS system, such as "Sec 17, Twp 6W Range 11N", or rural areas might simply use "Mile 7.5 on FM 1325 S of Anytown" or "PR 155 13.5km west of Anytown".

Again, perhaps there are ways to improve this, a longer-term discussion, but certainly the ingredients exist. A first step might be to look at developing guidance on consistent ways to have folks enter this type of data, for example "Sec 17, Twp 6W Range 11N" versus S17-T6W-R11N, along with developing parsers that can understand and standardize the possible permutations that might be entered, including entry of section and meridian info, e.g. NW1/4 SW1/4 SE1/4 SEC 22 T2S R3E MDM for an entry that includes drilldown into quarter sections to identify a 10-acre parcel, also referencing the Mount Diablo Meridian.


Currently, there isn't any truly standardized way of entering and managing these, but perhaps there is a role in the surveying community toward standardized nomenclature to assist in database searching and indexing.  Coincident with this is potential collaborative development of ways to approach parsing and interpreting nonstandardized entries, along with leveraging existing PLSS data and  geocoders built toward translating these into locational extents, such as a bounding box, along with provisioning it with appropriate record-level metadata describing elements such as method of derivation and accuracy estimate.

In concert with this, obviously, should be an effort toward providing linkages to actual field survey polygonal data, as appropriate if it's a parcel-oriented effort (for example, for superfund site cleanup and brownfields), and where such data is available.

Similarly, one could collaboratively develop guidance and parsers for dealing with the route-oriented elements, for example "Mile 7.5 on FM 1325 S of Anytown" or "PR 155 13.5km west of Anytown" toward standardizing these types of fields as well - for example, whether or not to disambiguate or expand FM as "Farm to Market Route", what order to place elements consistently.

And then, one would want to leverage routing software to measure the distance along the given route from the given POI, toward providing a roughly-geocoded locational value to get in the ballpark.  And again, one would want a web service that does this to return any appropriate metadata on source, error and so on.

PLSS locations, mileage-along-a-route locations, and things like this are just a sampling of the universe of possibilities.  And as I point out, there are bits and pieces of tools that can do some of these things, but they are currently scattered and uncoordinated, and community-oriented, collaborative efforts can help to pull some of these together.

Atop these, as mentioned above one could also provide additional pieces, such as tools for visual verification, at the most basic level, or, if collection mandates permit, tools to allow the user to drop a pushpin on an aerial photo feature, drag a bounding box, or digitize a rough boundary - (and most ultimately of course, a means of entering and/or uploading survey data for field-located monumentation points, boundary topology, and record description data).

From a federal perspective, EPA is certainly not the only agency that needs some of these types of tools, and EPA is certainly not the only agency that needs internal policy and/or best practices guidance on how to deal with how these types of values are best represented in databases.  It would make sense, from an Enterprise Architecture perspective, for the federal community to collaborate, along with state, tribal and local governments.  Similarly, I would think that there are a lot of non-profits, academia and private sector entities that have a big stake in locational data improvement that could benefit from improved data that would be facilitated by such tools, along with benefitting from such tools for data collection themselves.

For my part, I will try to do what I can toward leading the charge on these, and to leverage any existing efforts already out there.  Additionally, given the capabilities that FRS has, I am looking to continue to integrate across internal stakeholders as well as external agencies toward being able to aggregate, link and reshare, with a process where data is iteratively improved and upgraded collectively.

I'd certainly be interested in getting thoughts, ideas and perspectives from others on this.

"In 2010 and 2011, Federal data managers for geospatial data will move to a portfolio management approach, creating a Geospatial Platform to support Geospatial One-Stop, place-based initiatives, and other potential future programs. This transformation will be facilitated by improving the governance framework to address the requirements of State, local and tribal agencies, Administration policy, and agency mission objectives. Investments will be prioritized based on business needs. The Geospatial Platform will explore opportunities for increased collaboration with Data.gov, with an emphasis on reuse of architectural standards and technology, ultimately increasing access to geospatial data."

- President’s Budget, Fiscal Year 2011

Earlier this week, I had the opportunity to attend one day of the multi-day National Geospatial Advisory Committee (NGAC) meeting in Shepherdstown, WV - Though I had attended a few of their meetings previously, the thing that I was most interested in for this particular meeting is discussion of the emergent Geospatial Platform.  As the NGAC is a FACA committee, non-member involvement and participation is limited, though was able to get to get a sense of things...   The intent has a lot of potentialities, such as being able to provide more robust visualization and geospatial tool capabilities such as geocoding services, to augment ongoing Data.Gov efforts, as well as support ongoing FGDC initiatives.

The sense I got is that thre are many pieces still undefined, many things not yet prioritized, and so on, and discussion of options and alternatives was a big focus of the discussion that I sat in on - and one big challenge yet ahead is refinement of governance structure - as to how its' strategic vision and board of directors would be structured and at what level of government, where its' managing partner and operational/tactical component would reside.  These things are being discussed in iterative fashion, as they develop their roadmap.

Some interesting thoughts and ideas, not new, but again being raised - of the need for a strategic ownership stake in geospatial data at the White House level, e.g. a Federal GIO to reside within OMB, who would have the authority and teeth to centrally direct and manage geospatial policy in executive agencies at the federal level.  Another question, at the operations level, of commoditized geospatial technology platforms which could be shared across all federal agencies - a federal geocoding service, for example, or a geospatial data services hosting platform where individual stewards in agencies which might not have their own robust geospatial infrastructure could upload data and register it, apply symbologies, et cetera to be served as fed-wide robust, shared OGC web services, and so on.

What shape this will take is yet to be determined, and it sounds like the plan is to firm up the roadmap internally within the NGAC and then circulate it more broadly when v3 of the Roadmap is completed.

More about the Geospatial Platform:

• Geospatial Platform:  http://www.geoplatform.gov/
  
• GeoPlatform - More Information:  http://www.geoplatform.gov/more_geoplatform.html
  
• BP Oil Spill Visualization (using NOAA's ERMA platform) on GeoPlatform.Gov:  http://www.geoplatform.gov/gulfresponse/index.html

One of those key philosophical notions that circulates among many stewardship and advocacy groups is to think globally, act locally - The same notion can be applied in best practices in solutions architecture, requirements development, and coding principles, where it applies to so many things - in terms of true enterprise architecture and integration approaches, in terms of data stewardship, and for public sector agencies, in terms of transparency and open government.

Each and every day, folks craft queries for accessing complex data, they write business logic for analysis and so on - and more often than not, they then wrap it up with a nice glossy user interface.  MVC and many other best practices applied, check...  But here is where another key opportunity to really open things up is lost.

Let's take the example of state or federal agencies - many of them are doing great things, in terms of publishing datasets (Open Government Intitiative, Data.gov, Geospatial One-Stop, State Cartographers' Offices and Clearinghouses, and so on).  They are doing great things in terms of reporting tools, web queries and lookups, and mapping and visualization tools.  But...  As wonderful as all of these efforts are, imagine how powerful it would be if these could be linked and integrated, from agency to agency?  Imagine, for example, applications pulling in data from NOAA, NASA, EPA and other agencies?  Imagine state environmental agencies pulling in information from federal environmental agencies - the power of open government and transparency begins to multiply and become more and more powerful by orders of magnitude.

So what are we talking about?  Web services and APIs.  Not even anything complex, it could be as simple as REST and JSON, as in the space of public-facing applications, for a vast majority of data-centric or analytical applications, we are generally talking about read-only, non-transactional, nonsensitive data.  Why web services or APIs?   Isn't something like publishing datasets to Data.gov enough?  Publishing datasets to someplace like Data.gov is fine - but consider this - if someone downloads your data and integrates it into their own standalone application, what control do you then have over it?  Precious little.  When you refresh your database afterward and post a new dataset, is there any assurance that they will come back and get a fresh copy and keep up to date, or do you begin to incur a liability of your data being out of sync as it is represented in someone else's public-facing application?  Absolutely.

If, on the other hand, you post an easy-to-integrate RESTful service or API, you make it far easier to have your data current.

Criticisms?  Yes, there are many, but we can look at those as well - some might push back and say, "is there sufficient bandwidth and infrastructure for hosting those web services?"  The mere fact of web services in and of themselves generally incur no more new bandwidth or infrastructure demand than the public-facing web applications that you are already building.  So if that's really a concern, then maybe you shouldn't be building ANY applications.  The argument is generally a red herring.

Security concerns?  Same deal - you are already exposing the data and business logic via your web applications - if you think the web service poses new security concerns, then perhaps you haven't adequately thought through your EXISTING security.  So another red herring.

"They will come and take all our data!" - Again, why would they, if they know they can grab it dynamically and that you will be assured of their reliance on them by continually posting data refreshes?

What about poorly-behaved queries against your web service that might bring your database to its' knees?  Same thing - those are things that really should be handled in the logic for your existing application.  Better yet, think ahead a bit more and provide options - query filters, such as by a data attribute or domain, bounding boxes for geodata, and so on.

So - in conclusion, this type of thinking can up developers' approaches to how they deal with security, queries and filters, and so on, and generally tighten things up - but in the meantime, also provide a tremendous opportunity for data sharing and integration, whether within an agency, company or office, fostering collaboration across departments and programs, or outside of one's own organization, fostering collaboration across agencies and levels of government, across industry, academia and so on.

An individual organization can try all they like to anticipate all of the public's thoughts, needs, interests, they can try to walk in their stakeholders' footsteps - but ultimately, one can never fully anticipate all possibilities, and there are a lot of bright people out there with many untapped ideas - so why not open it up and facilitate that larger collective brainstorm of ideas by providing services ready to integrate?  Let's take things like the Open Government Initiative and other good things ongoing in government and elsewhere to the next level - dynamic, services and resources oriented architecture...

My big news to report:  After 6 years at Synergist Technology Group, Inc., I am changing directions.  I have accepted a position at the U.S. Environmental Protection Agency's Office of Environmental Information.  I will be starting at USEPA the week of April 26th, 2010.

I greatly enjoyed the work I was doing at Synergist, having been involved in everything from business development to writing code and everything in between, supporting geospatial, mapping and integration efforts to support diverse business areas from environmental protection to emergency response to transportation to military and intelligence applications.  I enjoyed the diversity.

I have worked in private sector, consulting for over 20 years, but all throughout this, have always been solutions-focused, and have always had a keen interest in supporting the core mission of the agencies that I worked with - though, the downside of private sector consulting is always in the vagaries of its' occasionally fragmentary nature, with competetive bidding and teaming arrangements often dynamic and changing.

So, coming into Federal service brings a whole gamut of new things.  In some ways, I will get to dig deep into some of my core passions of environmental protection, geospatial technology and integration - and I look forward to this. However, it will surely bring many other challenges along with it - but I am up for any challenge.

My new role will, among other things, involve support to EPA's Facility Registry System (FRS), which is a repository for facilities data for 2.5 million unique facilities regulated under a variety of environmental laws and statutes. Herein, I see opportunity for further geo-enablement of Agency business processes, along with continued integration potential, to put hooks and eyes into a variety of other processes for ever-improving analytical, reporting and querying capabilities, cross-media, cross-agency, cross-domain, cross-dimension, as well as facilitating further partnership-building, between local, state, and federal government, tribes, academia, industry and the public, and supporting data publishing, OGI and transparency initiatives.

I anticipate I will also be pulled into a variety of other geospatial efforts across EPA as well... In many ways, I will essentially continue to do many of the things I already did - only, from the other side of the fence. In terms of physical logistics, I have already essentially been commuting to Washington DC for 6 years - though, now having a permanent duty station there, I can now consider getting a place to stay, as opposed to living out of hotels and bouncing between various locales as I have been.

So - mixed emotions - I will certainly miss working with Synergist, but likewise, there is a great team at EPA, and I am sure I will have a great time there.

Once again, I greatly enjoyed this year's ESRI Federal User Conference - I was able to make it to several sessions Thursday and Friday... Perhaps will post more on this, as time permits.

This will be as close as I get to live blogging from the ESRI Federal User Conference, Day 1.

I am looking forward to spending this week in Washington DC, despite any further threats of snow (1"-3" expected tonight)... Living in Northeastern Pennsylvania, 1 to 3 inches of snow is no big thing. But the 30+ that hit the Washington area last week are astounding. Hopefully, much of the prior accumulation is now under control.

Last week, I attended a discussion session sponsored by the Pennsylvania Mapping and GIS Consortium (PaMAGIC) and facilitated by John Palatiello, regarding standing up a Geospatial Coordination Council as a formal governmental advisory body for Pennsylvania. This is not a new concept, it is something that PaMAGIC has been pursuing for several years, it has been discussed several times prior at the PA GIS Conference, and has been introduced in the legislature several times, in various incarnations. It was last introduced in 2007-2008 by Representative Russ Fairchild as House Bill 1304.

The discussion session was held at the Pennsylvania State Association of Township Supervisors' office just outside Harrisburg, and roughly 60 people attended in person and by phone - an excellent cross section of state government, county and local government, private sector, utilities and others. I did not, however, see any representation by the Pennsylvania Society of Land Surveyors or Pennsylvania Society of Professional Engineers. Similarly, I do not see a spot designated on the proposed Council for these organizations.

I have posted two documents - one is a summary of the meeting, the second is the newest version of the proposed bill - the GIS community is invited to provide comment, by the end of this week, to PaMAGIC President Glenn McNichol, gmcnichol -at- dvrpc.org.

For the last few days I have been working on efforts to help Haiti earthquake response - part of this is mapping Haiti via OpenStreetMap. Currently, useful maps of Haiti are few and far between, in some case there are detailed maps for parts of the country and cities like Jacmel, but which are print maps (no digital edition exists), in many cases many decades old and outdated, in other instances the only maps which exist are small-scale, with limited detail. Commercial map platforms like Bing Maps, Google Maps and Yahoo vary greatly in their detail as well, and update cycles are slow - however, here, OpenStreetMap has been able to rapidly respond and provide very speedy and robust updates, to include capturing data about collapsed buildings, and so on.

Mikel Maron captures the speed and effectiveness of OpenStreetMap with these two screenshots of Port-Au-Prince, just before the earthquake and just after:

before:


after:


I would encourage any others who have time to contribute to get involved in this effort as well - editing can be done directly in OpenStreetMap via the 'edit' tab, which opens a web-based tool called Potlatch - or, a number of other tools are available as well. (You will need to register an account in order to edit - feel free to connect with me there as well - http://www.openstreetmap.org/user/Dave%20Smith). The OpenStreetMap WikiProject Haiti page provides a lot of good information and frequent updates. A number of data sources have been assembled, together with fresh post-earthquake imagery generously donated by companies like DigitalGlobe.

For folks who are interested in more robust tools, I primarily use Merkaartor which runs best on Windows platforms - others favor JOSM which is Java-based and runs on any platform supporting Java.

With either of these, you should be able to use the download function to navigate to an area of Haiti (select a relatively small area) and then download the OSM data

Some have wrestled with getting the various available imagery and map services to work properly in JOSM and Merkaartor - they are both a bit clunky about accessing WMS servers - I can offer some of my tips gleaned from a little debugging using Fiddler2: For Merkaartor, use Tools -> WMS Servers Editor and create a new entry with the following URL: http://maps.geography.uc.edu/cgi-bin/mapserv?map=/home/cgn/public_html/maps/mapfiles/haiti.map&version=1.1.0&SERVICE=WMS&REQUEST=GetMap? and show capabilities to access the DigitalGlobe CrisisEvent imagery (DG_crisis_event_service), select EPSG:4326 (only option available) and image/png and you should be able to go from there. If there is no image layer showing, go to Layers -> Add new image layer, and then right-click on the newly added image layer and select your newly-added WMS server for DigitalGlobe.

Digitization tasks are fairly intuitive - tools allow you to draw points, lines and polygons, as well as to create relations which allow multiple entities to be grouped together - however the absolute key to success is in proper use of tags to provide attribute values for any entities being created. These are generally intuitive as well, e.g. tag of highway, value of residential to turn a generic line into a residential road. It also helps to look at tagging of existing features, and to familiarize yourself with the features list - the OpenStreetMap wiki is searchable and quite useful. Finally, as terms of using the DigitalGlobe imagery, any data entered using their imagery should also be tagged with source=digitalglobe.

One of the other projects I have been working on is development of a set of tags that would be useful for emergency responders, relief and aid efforts - for this, I have started a wiki page http://wiki.openstreetmap.org/index.php?title=Humanitarian_OSM_Tags- any comments and thoughts can be added to the wiki page.

In Pennsylvania, the position of County Surveyor was abolished decades ago. Elsewhere, some states do still have County Surveyors - yet where still in use, it has in some instances become politicized, or may have duties which are either murky, inconsistent from one place to another, or even a position without any duties. Many consider the position "antiquated".