I just saw a note about VBA in regards to ArcGIS 10.  Apparently it is still available, but requires a separate install and (free) license file.  So you've still got one more version to use your vba scripts, but essentially it isn't supported.  I suspect this might be available for at least one more version, because of the vast quantity of scripts available.  Then again, ArcGIS 8 got rid of their AML and ArcView's crap scripting language.

Hopefully I won't make this posting too rambling.  Full Disclosure:  I am not a database expert of any kind.  For the most part, all GISers are probably familiar enough with what a database, or more specifically a Relational Database is.  Pretty much any entry-level GIS textbook discusses it, and you might even use one like the personal geodatabase in ArcGIS or something more sophisticated like Oracle Spatial.  The idea behind the relational database (and I realize I will butcher this) is that you have a series of tables, and those tables are related to one another throu primary keys and foreign keys stored in those tables.  There is a movement, and I'm not sure how long it has been going, for a non-relational data storage system that has been called NoSQL.  Google uses a NoSQL data store called BigTable, and Facebook uses something called Cassandra by Apache.  NoSQL is a bit all-encompassing, because it really covers any of the data stores that are not the classic Relational Databases.  These cover a range of things that I don't really want to get into.  The two that are of most interest to me are the Document Store and Graph Databases.  Document stores are cool because they store, well, documents rather than tables.  Each document can have it's own set of properties and values, and you aren't tied to a database schema.  Typically the documents are stored in a format like XML or JSON (Javascript Object Notation).  It isn't hard to make a leap of storing GIS geometry in a Document-oriented Database, because there already exists a specification called GeoJSON.  Personally, I find it freeing not to be tied to a database schema, and find it difficult to design them.

 But now for the meat of this post - Graph Database.  If you don't know a graph is not a chart.  A graph is a mathematical structure to model relationships.  We GISers are most familiar with its form as a network, or transportation network.  Graphs are made up of nodes, or vertices, and edges that connect nodes.  Importantly, an edge may have direction or no direction.  For example, node1 and node2 are mutual friends and are just connected, or node1 considers node2 a friend but node2 doesn't consider node1 a friend.  As you can probably guess, graphs are used extensively in social network analysis.  A graph database is a database that stores data as a graph, or I suppose multiple graphs.  The emphasis is on the relationship between the nodes of data.  Personally, I think this type of database is the obvious direction that spatial-enabled databases should take.  A lot of our spatial analysis tasks involve searching the relationships between data.  This could really expand those functions, and potentially make them quicker.  There are at least two areas that come to mind when I think of these possibilities.  One is topology.  What is topology to us but the relationship between different geometries?  Here is graph of the topological relationship of some theoretical data:

 

 One thing that might be obvious from this is that we are used to separating out our polygons into different tables or shapefiles that group our data.  At a higher level geometry is grouped by type: polygon, point, and polyline.  But with the graph database that wouldn't be necessary and we would be able to search for data based on their relationship with each other.  This presents new analytical possibilities because data is no longer separate.  See Tim Berners-lee's Ted talk for more info about linked data.

The other possibility that I see with this, is relationships between metadata.  Metadata in a GIS is boring.  Yes it is important, but no one seems to use it, and it is tedious to create.  FGDC is a pain.  Metadata through relationships sounds a lot more interesting to me.  Searching for related information by who it was created, regions/areas, or temporality could be really useful.  

Anyway, those are my thoughts on how NoSQL should be the next step in the GIS world.

 

I suggest you go over to this site to help build a GIS stack exchange similar to Stack Overlow, but dedicated solely to GIS.  Should be a very valuable resource.

Just saw these new videos about the upcoming release of ArcGIS 10.  I have to say, I dig the look of the new layout, way to join 2005 ESRI.  Way better than MapInfo and Manifold's 1996 designed on sandpaper layouts.  But seriously, I do think it looks really nice.  There appears to be some really great additions too. There is an attempt to include temporality in the data.  Continued support for Python (possibly expanded) and .NET.  Here is a good video where you can see the layout design, and interacting with models.  I particularly like those query layers.  I'm not quite sure how this works, but it seems they are integrating with 3D quite a bit.  Essentially letting you switch between the 2D and 3D.  This is the one that got me really drooling though.  Don't those new data editing tools look sweet!  The problem with this promo stuff is they don't really tell you what license level these will be available, and what extensions are required.  My guess is all the extensions, and working with ArcInfo. 

 

So, what did I learn from all this?  GIS Analysts do not belong in front of the camera.

I'm working on a series of maps of differing scales and different labels.  In my head I'm thinking, I'll just do one map, use bookmarks for each individual map, and annotation groups with zoom scales set.  That way I could just use the same background symbology, and just label at different scales where needed.  How come things are never easy as they are in my head?  I exported my first map to see how they were turning out.  Nothing, no labels, just the background layers.  After some mucking about it seemed to be a problem of setting the zoom scales.  I used the scale of 1:110,000 because that's what everything was set at.  Well, you can't do that, you need to have the Out Beyond and In Beyond buffer the scale of your map.  Why is this actually a huge problem?  It indicates that ArcMap doesn't export at the scale you set.  This makes you a liar, or at least your scale bar a liar.  This happens on occasion when you close ArcMap and reopen the same mxd.  Noticed those scale numbers bounced around a bit, and your scale bar changed?  I guess ArcMap does it for exports too.  This is actually a good reason to use a graphics scale bar rather than text based.  Your scale bar should shift slightly with the export...at least in theory.