Spatial Metadata: Why is it so hard?

Why can't my GIS data be as easy to organize/provide metadata for as my music collection?

I want a clean, detailed interface to explore my files. I want an indexed library for fast searches and simple playlist dataset/layer package/group/namespace creation. I want to change the owner, license, one-line description of files the same way I might change them in a Music folder in Windows Explorer, not by diving into some ugly wizard.

ESRI shouldn't throw out ArcCatalog, they should make it the iTunes of geospatial information. Move it from the smaller segmented market of GIS professionals to the mass market. Clean up the UI, throw up a "store" that connects with ArcGIS Online and the Resource Centers. Refashion the toolbox into components available for purchase from an in-application repository and open that repository to 3rd party developers (with a trusted [reviewed] and untrusted section).

Have it read every damn spatial format possible. Embed Webkit so you can jump to Bing, Google MyMaps, OpenStreetMap, WeoGeo, and everything else out there of geospatial interest. Metadata is largely a solved problem with my music in Foobar (music player). Why? Because of freedb, a license-free database of song metadata. There isn't any reason why we couldn't do something similar for spatial data.

Ideas are cheap and this is a lot of hard work, but it is something I'd like to see. There is a lot of moving parts to spatial data - a lot of sources, metadata, and datastores. It would be nice if we could abstract away all the stuff you currently have no interest in. The fact your spatial data is in PostGIS, or AGS, or in the cloud somewhere is unimportant when all you want to do is supply the key information of when it was collected and why.

Fun with SQL Spatial

This is old hat by now, but I love how much cruft can be killed by outright avoiding older APIs.

A unique location number needed to be generated for an engineering design tool. A vendor contact sent an example to work off that was about 400 lines of C# code. This little stored procedure replaced basically all of it.

CREATE PROCEDURE [sde].[IntersectGrid]
@x FLOAT, @y FLOAT
AS SET NOCOUNT ON
BEGIN

DECLARE @g geometry;
DECLARE @grid int;
SET @g = geometry::STPointFromText('POINT ('+str(@x)+' '+ STR(@y)+')', 2);
SET @grid = (
  SELECT TOP 1 [areaName]
  FROM GridTable
  Where @g.STWithin(Shape) <> 0
 )
return @grid
END

How do you make this 400 lines? Easy, use the ArcObject API to do the intersect. Instantiating dozens of objects, checking out/in licenses, and using reflection to read a config file (not sure why they didn't just use AppSettings) adds up fast.

I could probably even do it with even less effort using Shapely, but no one else is really familiar with Python in this situation (vendors or coworkers).

SortaLogic

The new job is different from my former one in the kind of work so far, the organization, and the environment. The responsibility for other systems - customer service, outage management, geographic information - is not on "some other team" in some other department in the company, but your responsibility.

There is only one technical team, and while other departments have personnel that are technically competent, ultimately your team is charged with making everything run on a day to day basis.

A good example here is on a rush job today - pulling data out of what we'll call a relational spatial database (CertaLogic) and putting it into an industry standard XML format (Multispeak). I am not familiar enough with CertaLogic to do an extensive complaint, but it is sufficient to say that whatever flavor we have is not easily mapped to said industry standard.

In my previous job, I would have seen this requirement coming. The confusion over whether or not it was a task I was responsible for comes from the fact that at a smaller firm, more work appears to be contracted out to 3rd parties, and one of them was charged with doing the "migration". Much of my department was surprised that this didn't include some specific parts of our GIS.

As with all unexpected requirements, there was some pressure to get it done fast.

Short answer for those that in the same situation, you have three options. Roll your own solution using a standard xml library (lxml for Python, System.Xml for .NET, etc.), XmlSpy/MapForce, or use SQL's built in XML functionality.

(Edit: hat tip Scott Hanselman for XmlSpy)