Table to table bug (ArcGIS)?

Is there a bug with the "table to table" tool in ArcGIS when using it to export a DBF from an Excel file (XLS, XLSX)? I don't know. BUT, I would avoid using any Excel files in ArcGIS. This would be one of many poorly documented bugs ... support for Excel in ArcGIS is a weak link, and you really don't want to be basing multistep analysis off some poorly imported data (trust me!). So you have an XLSX file that is more than the limit of rows for XLS ... how do you get it to DBF (since Excel 2007 doesn't export DBF). If you have MS Access, I would recommend going that route. I tried this out with a file that I was getting super incorrect output on, and it worked. Seems like a nice, clean, consistent solution.

Cloud basemaps, so elusive

I wanted to use openstreetmaps as the base data layer for the new UD Campus Maps, but am running into the same labeling issues as when I use a google maps base layer ... labels are prerendered to appear on streets, cities, etc. of course not taking into account placement of "UD" layers (e.g. buildings). When the two are displayed together there is a very unsightly overlapping effect.


So the way around this is to use a custom renderer, which is actually quite a bit of work ... the custom renderer requires a large amount of space, not to mention an initial span of CPU time. It also requires that I create custom style specs, which address all sorts of issues, including a plethora of OSM tags, as well as all the details about base layer appearence ... all to be done manually of course.

... not to mention, the existing baselayers seem to be disagree with cloud services ever so slightly

CloudMade offers a very cool service for rendering custom basemaps from OSM data, all through an efficient GUI, and they even host it for you. Trouble is their terms do not seem to permit "non-personal" use, :.(

Sooo, I can:

1. set up a custom render, which *might* require a lot of space/time, and *might* require a lot of work in symbolization, and will consume local resources instead of leveraging the cloud
   
2. *or* use ArcGIS server to tilecache a national basemap ... having much the same disadvantages as above, except that I have a better idea of how much time/resources it will take
   
3. *or* render on top of satellite data (which doesn't really look that good, and not very informative for directions), plus requiring me to create custom label and symbol scaling and symbology for Newark basemap details (tending to be less attractive than those already available in the cloud, and causing disuniformity with surrounding areas)
   
4. *or* I can mask the extent of all "UD layers" and use this as the default extent for the map, putting in some scale sensitivity which causes UD detailed layers to disappear when viewed at a larger "regional" scale and instead showing some extent rectangle ... then showing these layers again when at a closer zoom (having some of the same drawbacks of disuniformity/attractiveness)

... as of today the last option seems the best ... I sure hope it bares fruit, we need to get this project rolling!

unexpected rows in tables

Occasionally, the number of rows in a table* is not really the number of rows in the table. Sometimes this peculiarity only makes itself known when you export a table and only see a subset of the total rows in the original attribute table ... where all the other rows go to?

One reason that this happens (perhaps the most common), is that when you use the "keep only matches" option when doing a join, the non-matched rows are kinda there, and kinda not. To fix this you would need to go back and use the "keep non-matched" option.


*as counted by the "Records (1 out of x)" at the bottom of an attribute table window