The ArcPad Team Blog

Unofficial stuff from the team behind the World's leading mobile GIS platform

Friday, September 22, 2006

Maptel honored at ASIBA Victoria Spatial Excellence Awards

Maptel recently had a night out at the Annual ASIBA Victorian Spatial Excellence Awards. As well as enjoying a great meal and the company of our local industry colleagues we were honored to receive the 2006 Industry and Entrepreneurship Award. The award acknowledged the successful inclusion of ArcPad in the 2010 US Census Field Data Collection Automation (FDCA) program.

As can be seen in the ‘happysnap’ of the Maptel team below ( sans Kaitlyn) the ceremony took place at the local aquarium.
It was a great night and we all managed to stay dry!

Tuesday, September 19, 2006

Large toolbar buttons

A little known feature of ArcPad is the ability to have large buttons - both on existing toolbars and on custom toolbars. I say "little known" as I don't recall seeing a custom ArcPad application that uses large toolbar buttons!

Large toolbar buttons are especially useful when working in the field under conditions when it is difficult to tap a small button, for example when it is cold and windy - and your hands are shivering and shaking! Although one has to be careful with using up too much of the available screen when using large toolbar buttons on quarter VGA screens, this is not an issue when working with larger screens such as on Tablet PCs.
Here is an example of a single toolbar for an application that only needs to add and view data:



So how do you specify large toolbar buttons? The TOOLBAR element, in ArcPad XML, has a buttonsize attribute. The following ArcPad default configuration file (ArcPad.apx) hides the standard toolbar, and creates the toolbar in the above screenshot:

<arcpad>
<config>
<toolbars>
<toolbar name="main" visible="false">
<toolbar name="browse" visible="false">
<toolbar name="draw" visible="false">
<toolbar name="TOOLBAR4" caption="" visible="true" image="" buttonsize="2">
<toolbutton command="openmap">
<toolbutton command="modezoomin">
<toolbutton command="modepan">
<toolbutton command="zoomfullextent">
<toolbutton command="layers">
<toolbutton command="exit">
</toolbar>
</toolbars>
</config>
</arcpad>


Note that the default buttonsize is 1. Custom toolbars can be defined in either the default configuration file, or in ArcPad applet files.

The easiest method to create ArcPad XML code for custom toolbars is using ArcPad Studio. However, you can also use your favorite text or XML editor to create new toolbar definitions or to edit existing toolbar definitions.

So, do yourself or your field users a favor and provide them with toolbars with large buttons! Large buttons are much easier to use.



Friday, September 15, 2006

Selecting a mobile device

A common question that I encounter is “What device do you recommend that I use for my ArcPad or mobile GIS application?” Unfortunately, the most straight forward answer is “It all depends!” Choosing a suitable device for your mobile GIS application and field tasks is not unlike choosing which pair of shoes to wear – it is all a matter of trade-offs. Hiking boots are great when comfort and ruggedness are the most important requirements, but are not really suitable for attending a wedding! There is simply no pair of shoes that is suitable for all the varied activities that we participate in. So it is with choosing a suitable mobile device.

There are many factors which need to be considered when choosing a mobile device. Some of these factors are: price, size, screen, weight, ruggedness, battery life, integrated GPS/camera/rangefinder/compass, and operating system. Many of these factors are mutually exclusive, for example with current technology (that is readily available and affordable!) it is not possible to have a device that is small enough to fit in a shirt pocket and at the same time has a large, laptop-size screen. It is all a matter of trade-offs – choosing which factors are most important and deciding which factors are “nice to have”.

For some mobile applications GPS accuracy is the most important factor. For example, your application might require sub-meter accuracy. This automatically eliminates all but a few GPS receivers available today, and narrows the choice to professional-grade GPS receivers. Your next requirement might be for a cable-free, integrated mobile device and GPS receiver. This reduces the choice to less than a handful of devices, specifically integrated handheld and GPS devices from Magellan (formerly Thales), Topcon, and Trimble.


GPS is just one of the factors that could be the determining factor for selecting a mobile device. There are many other determining factors. Two useful factors to consider are the application needs and the means of transport.


Application Needs

Different mobile GIS applications, and their related tasks, have different requirements for an appropriate mobile device.



Application Needs

Mobile Device Characteristics
Weight
Size
Battery
Life

Operating
System

Smaller Screen
Lighter
Smaller
Longer
Windows Mobile
Windows CE
Larger Screen
Heavier
Larger
Shorter
Windows XP

Consider for example a fire hydrant inspection application for a city. When the person is inspecting the fire hydrant in the field the only geographic information that is of interest is the fire hydrant, and possibly a small geographic area immediately surrounding the particular fire hydrant. For this application, a small screen is suitable and useful. Once it has been decided that a small screen is suitable for our fire hydrant inspection application it automatically follows that a lighter and smaller mobile device is appropriate. These smaller, lighter devices typically run Windows Mobile (or Windows CE) and have much longer battery life.

In contrast, consider a field supervisor for the roads department of a large city. For this field application the person needs to view a large amount of detail for a large area. A small screen for this application is not suitable, since it is not possible to display a lot of detail for a large geographic area on a small screen. The application requirement for a large screen automatically leads to the requirement for a larger, heavier device – such as a laptop or Tablet PC. These larger devices typically have shorter batter life, and run Windows XP (or Windows 2000).


Means of Transport

Another approach to follow when determining a suitable mobile device is to consider the means of transport.



Means of Transport

Mobile Device Characteristics
Screen
Size

Weight
Size
Battery
Life

Operating
System

Vehicle-based
Larger
Less
Important
Less
Important
Less
Important
Windows XP
Foot-based
Smaller
Lighter
Smaller
All day
Windows Mobile
Windows CE

If the field application involves spending a small amount of time outside of a vehicle then the size, weight, and battery life of the mobile device is less important since you do not need to carry the device for very long, and the vehicle can provide “unlimited” amount of power to the device. For this situation a laptop or Tablet PC running Windows XP is a good choice.

However, if the field application involves spending many hours walking, away from a vehicle, then the size, weight, and battery life of the mobile device is very important. For this situation a smaller and lighter handheld device running Windows Mobile (or Windows CE) is a good choice. These devices also typically have sufficient battery capacity to use the device for a full day’s work without needing to charge or change the battery.

Summary

Each mobile application is different, with unique requirements. As a result, it is unlikely that there will ever be a perfect device which is suitable for all mobile applications. Choosing a suitable mobile device involves identifying the factors which are essential for the mobile application, and focusing on these selected factors. Placing less emphasis on the “nice to have” factors makes choosing a mobile device much easier!

Wednesday, September 13, 2006

The QuickForm

The key thing that drew me to ArcPad in the first place was the fact that it did everything that I needed (at the time) out-of-the-box. It used my existing files, and it behaved pretty much exactly as my desktop GIS did!

But one of the new features in ArcPad 7, leaves your average desktop GIS for dead! The QuickForm feature allows you to generate a data entry form based on a layers attributes, with basic rules and conditions to regulate data entry. This means that WITHOUT any programming, you can go from using the default attribute table for editing attributes:

to a form with drop downs, check boxes and date pickers:

If you haven’t tried it yet – have ago! Here are the steps:

  1. Go to New > QuickForm.
  2. Your then prompted to select which shapefile you wish to build the QuickForm for. Choose your file and click OK.
  3. The first tab on the QuickForm dialog box allows you to select the layout of the form. There are settings for the name, style and size of the form, and number / type of tabs
  4. The second tab allows you to choose which fields will be available in your form. Not all fields have to be presented, you can check/uncheck as many as you like.
  5. The third tab allows you to set rules and constraints. You can nominate which fields are required, supply a minimum and/or maximum value for numeric fields, and add list values to be presented in a combo box for text fields.
  6. Click OK and you’re done. Next time you edit that layer the new QuickForm will be displayed.

Note that the QuickForm function overwrites any previous apl’s. If you need to make a change (and you don’t have ArcPad Studio) – you will actually need to create a new form (or for small tweaks – you could open the apl in a text editor and make the changes directly). Else, you CAN open and edit your QuickForm’s in Studio.

Friday, September 01, 2006

Event Driven Scripting #1

The Tree Height Applet

If you are comfortable with using ArcPad Application Builder to build simple forms like the ArcPad generated Quickform, but are not quite sure how to progress to the next level , this article is for you…

For those of you that have ArcPad Application Builder 7.0 installed there is a sample in the Samples\Applets\Rangefinder folder that measures tree heights from incoming rangefinder events. This article will describe how this applet works.


<ArcPad>
<APPLET name="TreeHeight">
<SYSTEMOBJECTS>
<RANGEFINDER onmeasurement="MeasurementReceived();"/>
</SYSTEMOBJECTS>
</APPLET>
<SCRIPT language="jscript" src="treeheight.js"/>
</ArcPad>


The applet file (.APA) is very basic! There are two main nodes, the APPLET node, and the SCRIPT node. The APPLET node contains the rangefinder system object node. The rangefinder node is used to define the onmeasurement system event. What this means is when the applet is loaded at startup, the code specified in the onmeasurement event is called by the ArcPad system core when an incoming rangefinder range measurement event is fired.

The SCRIPT node contains the scripting information like the script language and the script file name. The script file name (src attribute) is the file which ArcPad opens and the internal range finder event uses to call the function which you have defined in the RANGEFINDER element, onmeasurement event.

So, we have the Applet file and we have the script file that is referenced in the applet. This still doesn’t handle to data capture. We will now look at the sample data supplied with the applet which is a point layer containing the tree positions and their attributes.

Of interest to us is the second page of the form. This is where the information from incoming rangefinder events gets placed from the Applet event. Pretty cool! The applet updates controls in the form that is open.




How does this happen you ask? Well if you open the applet treeheight.js file you will see the function which is called in the onmeasurement event.

What happens in the function?
1. We have to get the maps layers and place it in a variable.
2. We search for a specific layer in the set of layers
3. If the layer is not found, then we display a debug message to console. (See Elvin’s article below on using the ArcPad Console window).
4. Get the form which is associated with our selected layer
5. Based on the value of a forms control, populate others controls.

This brief script shows how the forms controls values can change based on other control values.

The full sequence of events that occur from start to finish are as follows:

1. The rangefinder is configured in ArcPad
2. The tree layer is loaded into ArcPad
3. You start editing the tree layer
4. Create a new tree feature, or update an existing one
5. Now that the form is display go to second page on form
6. Make a selection in the laser measurement combo
7. Make a laser measurement to base of tree (send to ArcPad if it isn't automatically done). Applet onmeasurement event is called by ArcPad
8. Note the fields get populated on the form
9. Make a selection in the laser measurement combo
10. Make a laser measurement to top of tree (send to ArcPad if it isn't automatically done) Applet onmeasurement event is called by ArcPad
11. Note the fields get populated on the form
12. If your rangefinder doesn't support angle, measure angle from base to top of tree with clinometer
13. If you now click the calculate button on form, the height will be set in the height text control. The onclick button event of the forms page is called by ArcPad
14. Approve your edits on command bar. Edits are saved