How rugged is a Nomad?

Ever wondered how rugged your Nomad really is? Take a look at this...



Not that we recommend you try this though!

Using ArcPad Training Courses

RIA Mobile GIS provide and run a number of Training Courses, which are designed to assist organisations and users achieve the most from their Mobile System.

Currently we have three 'Using ArcPad' courses scheduled around Australia:

• Adelaide - Wed 19th August, 2009 (the day after OZRI SA)
  
• Darwin - Tue 1st September, 2009 (the day after OZRI NT)
• Hobart - Tue 22nd September, 2009
  

If you are interested in attending a course in a different region, then please let us know.

More information on the course can be found on the Support and Training page of our website. To register you interest, download the appropriate resgistration form and send it back to us:

• Adelaide
• Darwin
• Hobart
  

Get in fast! Numbers are limited, and early bird discounts apply.

Field Naming Tips #2

Another tip when naming fields in a feature class, for use with ArcPad: Avoid using SQLCE reserved words.
You will find that if you do use any of these words, you will not be able to check any features in. When you select the AXF from the ArcPad Data Manager Toolbar, it will correctly list the number of features that you have created in the field (in the summary section), but then when you try to check it in, it says there are no edits in the selected layer. Unfortunately there are no error messages displayed telling you why the check in failed. I have lodged another request with ESRI, so we will see how we go in the future.
The complete list of SQLCE reserved words can be found here.

Subtype Field Names: Make them different to the feature class name

I recently had a call from a client using ArcPad 7.1, saying that their drop down lists (subtypes and coded value domains) were not appearing in ArcPad. I got a copy of their database, and performed my own check out to see what was happening.
First of all, I checked the feature class in ArcCatalog and ArcMap. All of the lists appeared as expected there.
Next I checked the .axf.xml check out log, which gets created in the same directory as the AXF file. Usually this reveals a lot about why check out was not successful, for things such as data and schema errors. Again, this was empty.
I then opened up the AXF file in ArcPad Studio, and it turned out that the Data Tables branch of the AXF structure was empty. This is where all of these tables are stored within the AXF.
After digging around for a while, I realised that the feature class was called Heritage, which was the same as the Subtype field. Turns out that this was the cause of the problem; if I renamed that field, it all worked as expected.
There are two reason for writing this blog:

1. To make you aware of the bug - I have logged this with ESRI so hopefully it will get fixed soon.
2. To outline the troubleshooting process that I went through.

Hopefully someone will find this of use. If nothing else, it should serve as a reminder for me!

GUIDs and Global ID Fields for Related Tables in ArcPad

When working with related tables, you will often need some form of unique value to make up the Primary Key / Foreign Key relationship. This is particularly important in ArcPad, where more than likely, you will have multiple field officers collecting data at the same time.

Perhaps the most convenient way of achieving this is through the use of Global IDs and GUIDs. Both of these data types store registry style strings consisting of 36 characters enclosed in curly brackets: for example, {90A942E1-BC7C-4F1E-94D5-AACAAD24F08C}. What this means is that there are a total of 2¹²⁸ possible values – which makes the likelihood of repeating a value within your database about as likely as South Africa winning the next World Cup.

What is the difference between the two? ArcGIS actively maintains the Global ID fields (i.e. when a new feature is created, a GUID value will be assigned), whereas the GUID fields are left blank. It is up to the user to maintain these fields.

So to use these in your relationship class, you need to use the Global ID in the Origin Table as the Primary Key, and have a GUID field in the Destination Table as the Foreign Key. This way, ArcGIS and ArcPad will automatically copy the Primary Key Global ID into the Foreign Key GUID field.

To explain this a bit better, let's work through an example. Let's assume that we have a relationship between a feature class 'Weeds' and a related table 'Inspections'. Here, you would:

• Set up the feature class with the required fields
  
• Set up the related table with the required fields
  
• Add the Global ID field to the Weeds feature class
  
  • Right click on the Weeds feature class in ArcCatalog
    
  • Select 'Add Global IDs...'
    
• Add a GUID field to the Inspections table
  
  • Right click on the Inspections table in ArcCatalog
    
  • Select Properties
    
  • In the Fields page, add a field called 'Weed_ID' and make it type GUID
    
• Create a relationship class between the feature class and the table
  
  • Right click in ArcCatalog
    
  • Select New à Relationship Class...
    
  • Follow the prompts. Make the:
    
    • Origin Table = Weeds feature class
      
    • Destination Table = Inspections Table
      
    • Primary Key = GlobalID (Weeds feature class)
      
    • Foreign Key = Weed_ID (Inspection table)
      

Some considerations if using this approach:

• You must use ArcPad 8 Service Pack 1 – previous versions do not support GUIDs or GlobalIDs
  
• In order to check the layer out to AXF, your feature class must be a versioned SDE feature class
  
• As you are working with Relationship classes and ArcSDE, you will need ArcEditor or ArcInfo licenses to check the data back in (interestingly, you can still check out with just an ArcView license)
  

Remember that you can always set up the relationship using standard field types (numeric, text etc.), which you will need to do if you are not using an SDE database. Some simple coding can provide you with unique values to use in the relationship.

Remote Display

Microsoft's ActiveSync Remote Display is a very handy applciation which allows you to control your PDA from your desktop. This is extremely useful in a number of ways, including giving demonstrations and capturing screenshots.
The application can be downloaded from here. You will also need ActiveSync or Windows Mobile Device Center (Vista).
Unfortunately the application does not natively support Windows Mobile 5 or 6. To get it to work with these PDA's:

1. Connect your PDA to your desktop, and make sure the ActiveSync connection is established
   
2. Navigate to the C:\Program Files\Windows Mobile Developer Power Toys\ActiveSync_Remote_Display\devices\wce400\armv4 folder
   
3. Copy the cerdisp2.exe file
   
4. Paste it to the \Windows directory of your PDA

You can then launch the Remote Display appilcation from the Start menu on your desktop. You will see a message pop up saying "The OS or CPU of this device is unknown to this application", which can be ignored. Once closed, you should then be able to control your PDA.

ArcPad 8 Service Pack 1 Released

Good news, ArcPad 8.0 Service Pack 1 and ArcGIS Server ArcPad Extension 8.0 Service Pack 1 have now been released. They can be downloaded from the following link:
http://support.esri.com/index.cfm?fa=downloads.patchesServicePacks.viewPatch&PID=26&MetaID=1537

Some improvements to note are:
· Improved detection of generic USB Serial Port GPS, Garmin USB GPS, and Bluetooth Serial Port GPS devices on the Windows platform
· Map.Select no longer fails with a script error when used with AXF layers
· Map.Layers(x) returns Nothing if the layer x is not present, as per previous versions of ArcPad
· Improved hardware button support
· Related Table form samples.
· .NET integration samples

More information on the release of Service Pack 1 is available at:
http://downloads2.esri.com/support/downloads/pad_/ArcPad8.0_SP1_ReadMe.pdf

Changing Field types in File Geodatabases

Ever tried changing the data type of a field in a feature class or table in a File Geodatabase? If you haven't, then believe me, it is not as easy as you would think. The only way of doing it is to actually create a new field and copy the values across.

As an example, let's say we want to change Field1 from an integer to a double field

1. Close ArcCatalog (it will almost definitely have a lock on the database that you can't get rid of any other way)
   
2. Rename Field1 to Field2
   
3. Create a new field called Field1 (type=double)
   
4. Copy any values across using the field calculator
   
5. Delete Field2
   

From this point on, you have to put up with Field1 being the last field in the table, which can be pretty annoying if you have spent the time setting up your feature classes in a logical order, with similar attributes situated near one another.

What is the alternative I hear you ask?

1. Export your table/feature class to a Personal Geodatabase
   
2. Open the database in Microsoft Access
   
3. Open the table in Design View
   
4. Alter the field format
   
5. Copy your table/feature class back to the file Geodatabase
   

You can also use this same method for renaming fields.

Warning! Be very cautious when doing this. Things can go wrong if you are not careful. Do not change any of the special fields (ObjectID, Shape etc.) as your table will become corrupt. You should always create a backup copy of your data before playing around with the schema of any databases.

Pairing Bluetooth Devices in Windows Vista

Windows Vista has a few quirks when compared to previous Windows releases. One such quirk is when pairing a Bluetooth device with your system running Windows Vista, a COM PORT is automatically assigned to the Bluetooth device without user input. Previous versions of Windows (e.g. Windows XP) allowed users to select from the available COM PORTS list when setting up a Bluetooth pairing.

Often some software or terminal input programs may only go up to a specified number of COM PORTS (e.g. COM PORT 20 as a maximum), which causes problems if the Bluetooth Device Manager in Vista has automatically paired your Bluetooth device to an available COM PORT above this threshold.

To get around this issue:
- From Windows Control Panel, navigate to Vista's Device Manager
- Go to the Ports category
- Locate the listed pairing/relationship to your Bluetooth Device
- Right-click on this listing and go to Properties
- Within the Advanced Settings window, there is a drop down box where you can specify the COM PORT for that particular Bluetooth connection