Showing posts with label fail. Show all posts
Showing posts with label fail. Show all posts

Friday, February 19, 2010

Gaps in Polyline Coverages / Vector Linear Direction

I'm editing a large statewide line coverage of streams across the state of Florida based on 24k NHD Flowlines. I have been continually coming across what appear to be small gaps in the coverage, however zooming in (even to 1:1 or further) does not reveal disconnected features.  Setting snapping parameters and repositioning the endpoints in an editing session doesn't help either.

Here's a screenshot with an enlargement of the gap to the left.  The instances of the gap are subtle, and even more so in screenshot below (click to enlarge):

A gap between two segments in a polyline coverage with
an enlargement of the issue to the left

It turns out that the line segments do in fact intersect and their ends are connected.  The problem is that the vector feature directions may not be aligned properly.  Although it is possible for two stream segments to flow away from each other (via confluence at usually obtuse angles), when the directions of two line segments are converging (see below) a small gap appears between the two features which is usually only one pixel wide.

There's a bit more to the distance and direction parameters that polyline features preserve in a vector dataset. A tertiary "from-to" designation is included in the bearing, although it's not always apparent at first glance (nor is it always needed, though it's a good idea to consider to avoid future problems).

Vector Linear Direction:

As an illustration, two simple line segments are created.  Line 1 is digitized from west to east / left to right, and Line 2 is digitized from east to west, however it isn't immediately apparent:


By viewing a line's vertices (double click on a line segment using the edit tool in an edit session to expose its sketch) one can view the from-to direction orientation of a line feature.  Initial / first, and intermediate vertices are green, and the final / last vertex is red; which indicate from-to direction:


The from-to direction of a line can be flipped easily: select a line, expose its sketch (double click using the edit tool), then right click the sketch and choose Flip from the context menu.

It's easier to visualize flow direction of a linear network by putting arrow heads on the end of each line:


Arrowhead Symbology:
  • Open the "Symbol Selector" dialog for a line coverage (change the symbol properties):
 
  • Click Properties to open the Symbol Property Editor
  • Change the Type to "Catrographic Line Symbol"
  • Navigate to the Line Properties tab
  • Select the middle, right facing arrow from Line Decorations area and click OK until you're back at your map:

The default symbology is a bit bulky so play around with different settings and characters to represent arrowheads or other symbols at either or both ends of your line features.

Linear Network Interactions:

So the single pixel-wide gap seems to appear only with converging line segments, and not with diverging, or in-line interactions:




Friday, October 23, 2009

Office 2007, you're pushing my buttons! / Micosoft Inefficiency .NET

This is unacceptable! A mail client should not use the same amount of resources as GIS software. I am convinced that Outlook 2007 is making my other programs crash. I've said it before, and I'll say it again. Office 2007 missed the mark.

Here is a screenshot of my ArcMap editing session:


I am running Windows Media Player in the background with with 200+ songs on the playlist (topping out around 20,000 k of memory usage). I am assuming WMP references the songs via a list rather than caching all the 855 MB of files, however my media player is using fewer resources than my mail client is using.

Outlook is hogging just short of the almost 200,000 k that ArcMap uses - and it's just sitting there:

Rather than trying to make Office and Windows look like a Mac, why doesn't Microsoft take what they already have a make it more efficient? After that, go ahead and add the neat little trinkets (about which I honestly couldn't care less). There is absolutely no reason for my mail client to use such vast amounts of memory and processing power to sit there and ding a few dozen times a day.

Personal computer technology continues to increase at a terrific rate, and the price of powerful and small computers is steadily decreasing. The average user (non-tech/home computer user) seems to be utilizing web-based resources more and more. Other than gaming, I can only think of a few other examples of power users who need very elite computers: photo/graphics editors and video editors.

Taking advantage of this by writing software that runs efficiently would allow one to use a computer for more than a few years without it being bogged down (I'm looking at you, Windows XP). It takes my laptop a few minutes to open Mozilla. MINUTES! That is just stupid.

Instead, Microsoft continues to write clunky software that needlessly hogs computing resources so when the computer seems to become "out of date" in a year or two, unknowing consumers will go out and buy another laptop with a new and even more inefficient version of Windows products. This seems like planned obsolesence. Lame.

Well, I'm glad to see that Dell (and others I'm sure) is giving the option for new computers to be loaded with the free Ubuntu (Linux) OS. I've been meaning to give Linux a try. Even worse, another option is to "downgrade to Windows XP" on new systems. Fail.

Intro to Customizing ArcGIS Desktop, Toolbars, and Normal.mxt

While attempting to build a (forthcoming) custom tool for my ArcGIS environment, I encountered a problem: I cannot save my new custom toolbar to Normal.mxt. Every time I close and re-open ArcMap, the toolbar does not return.

I am attempting to construct a toolbar to use in my default environment, so naturally I begin working in a blank (Untitled) .mxd document. This is probably a problem: it seems that Normal.mxt is updated when the .mxd is saved or closed, so I'll start by creating a local project so the "save" command can be called.

The following is my version of a walkthrough that discusses how to properly add a toolbar to the Normal.mxt template.
  • Start ArcMap with a new/blank document
  • Save this document anywhere - location is not important. It can be deleted later. Again, I'm assuming that a saved document allows the .mxt file to be saved, thus edits can be applied, though this is just a hypothesis.
  • Open the Customize dialog (from Tools :: Customize, or double click in a gray area beside a docked toolbar)
  • Choose New to create a new, blank toolbar
  • Give the new toolbar a name, and be sure to change the "Save in" option to Normal.mxt.
    ( Normal.mxt is the default, base template that ArcMap uses to define the which toolbars are included in its operating interface. When a new/blank document is launched, Normal.mxt is called to define which buttons and toolbars go where. Over time it is nice to change this around to suit individual needs)
  • The new, blank toolbar is added to the project
  • Add some buttons/tools/commands to the toolbar by navigating to the Commands tab from the Customize dialog. There are many provided by ESRI, sorted into Categories (the pane on the left) and the actual commands (buttons) are located in the Commands list to the right. Select the one you want and drag it carefully to the new toolbar, or to any other toolbar. Again, be sure to "Save in" Normal.mxt
  • To add customized buttons from which you can run your own Visual Basic code, scroll all the way to the bottom of the Categories list and select [UIControls].
  • Press the New UIControl... button
  • Choose from one of the control types - UIButtonControl will make a button that will run some code that will be programmed later - and press Create
  • Rename the control to something that will be recognized easily, and drag the control to the new toolbar
  • Change the button's icon/picture by right clicking on the button (with the Customize dialog still launched) and choose an icon from the "Change Button Image" sub-menu.A custom .bmp file can be used as the image by choosing Browse from this menu
  • To begin editing code, right click on a button (command) and choose View Source to launch the Visual Basic Editor (shortcut key Alt+F11)
  • Now close the Customize dialog box and save the otherwise blank ArcMap document. From here the new toolbar and its tools should be saved in Normal.mxt.
  • Just for the sake of argument, drag the toolbar to the top of the ArcMap window to dock it. (This really shouldn't be necessary though.)

  • Save the document again
  • Open the Customize dialog again and change the "Save in" option from Normal.mxt to the alternative choice which will be the name of the .mxd. If the toolbar is still present, the Normal.mxt template has been successfully altered with the addition of the new toolbar. Change the "Save in" option back to Normal.mxt and continue alterations if necessary.
See also:
ESRI Article: Save Custom Toolbar Configuration
My Normal.mxt

Thursday, June 4, 2009

Microsoft Office 2007: Fail

Not impressed. Whatsoever.

Microsoft Office 2007 is clunky, awkward, and uninformed. Also it seems like it's trying to dress like a Mac. Look, there's nothing cool, hip, or sleek about spreadsheets or databases. Don't kid yourself on this one. Keep it simple.

Most importantly to me though is that Excel 2007 no longer supports dBase IV, the .dbf file type, because they decided that "nobody uses it anymore." It turns out that DBF is one of a hand full full of required files that make up a shapefile in the world of another proprietary, monopolistic software giant: ESRI's ArcGIS. Don't get me wrong, I bought into the ArcMap scene as well, but it baffles me that A) Microsoft did not do their research before giving the axe to DBF, and B) ESRI did not talk to Microsoft about what is to be expected in their next huge software rollout. FAIL. The both of you.

Anyway, Office 2007 was recently loaded onto my machine at work, and I quickly opted to have Office 2003 installed underneath. I can live with 2007 on my computer, but I am not interested in using it (at least Excel) on a regular basis. I decided to go ahead and return Excel 2003 to the default program used to open .xls files:
  • From the Start Menu choose Run
  • Enter the following (the path may be different on another machine) and hit Enter/OK
"C:\Program Files\Microsoft Office\OFFICE11\EXCEL.EXE" /regserver

That's it. The OFFICE11 directory is where Office 2003 lives, and will now be used to open .xls files with Office 2007 installed as well.

Other Options:
  • Save an Excel 2007 file as .csv, import the CSV in Access 2007 and export as a DBF. What a lame, unnecessary waste of time.
  • Download the free OpenOffice software package. The DBF support from OpenOffice is supposedly much for friendly than Excel ever offered, though I have not gotten around to trying it out.
  • Change industries. Open a surf shop.