With the release of 9.x.67 (referred to internally as just 67) we thought that it was about time we started to talk about some of the functionality that will be included. The first one on the list is Multi-tier synchronization support.

9.1.66 and prior architecture

GO! Sync® takes information from ArcSDE® and delivers it to occasionally connected field devices when they are online.

This functionality has been available for many years now and is in operation at numerous clients. The architecture of this application prior to 67 was 2-tier.

This caused problems for some of our clients with Operating regions and slow WAN connections between them as it means data is sent multiple times from one server over the WAN to each client.

9.x.67 and onward architecture

With the 67 release multi-tier architecture is now supported where changes from the Mobile GIS Server are delivered to Staging Servers. Clients then get their data, configuration and application from the ‘closest’ staging server rather than the Mobile GIS Server.

Note: The two-tier architecture is still fully supported and is in-fact the default configuration even in 67.

Conclusion

With the 9.x.67 release GO! Sync is able to support organizations that have multiple locations and bandwidth considerations between them.

One of the questions we were asked at GITA expanded on a common theme. “What do we have to do on the ArcSDE server to make GO! Sync work?” The quick answer is NOTHING!

GO! Sync was designed and has been implemented to be data model agnostic. This allows our users to synchronize, display and manipulate data and centrally manage their implementation regardless of the underlying ArcSDE data model. This design consideration is something that we are very proud of since it allows us to support all departments within an organization (Gas, Electric, Water, Wastewater, Police, Fire, Public Works, etc…) from a single solution.

When you add our single interface support for integration with work management systems, customer information systems, permitting systems, outage management systems, computer-aided dispatch systems and a whole host of other mobile workforce management business systems, you really begin to see the value of GO! Sync within your organization.

Other vendors have taken a different approach where the data-model is specific to a particular application, the workflow is virtually dictated, custom objects are required for the system to work, and upgrades and changes are expensive and risky to attempt. All this might make sense if you are dealing with a single commodity and have an unlimited IT budget, but it really hinders organizations that must support users in a multi-mode, multi-commodity environment on a limited budget with limited resources.

We think we’ve gotten it right, and we’d like you to give us a try.

One of the first tasks that we at Tadpole have to do when installing GO! Sync is make sure that the .NET Framework support is added in ArcGIS before we install GO! Sync.

A very good article on how to check this and what to do about it has been posted here.    

Any client that has started to look deeper into the inner workings of GO! Sync will realize that the $data\MobileUploads\Logs folder on the Mobile GIS Server starts to fill up quckly and the files disappear as fast.

This is due to an extremely useful process that we have in place which logs information (Errors, General Information) about what is happening in all applications that make up the GO! Sync product line and stores then in a set of XML files on the client machine in the $data\Logs folder.  The contents of this folder are configured to be uploaded to the Mobile GIS Server when the client synchronizes so it never clutters the client machine. When the files arrive at the Mobile GIS Server within an organization they are then uploaded to Tadpole server in Carlsbad, CA!

As you can imagine the amount of files that we recieve gets interesting and to be useful they really need to be processed in some way. Tadpole have implemented a Windows service that takes the XML files and loads them into a SQL Server database. From this database we perform daily queries for errors and occasionally use it try and find out why a mobile device is having problems.

I mention this is it is something we have in all our products and have found it so useful that it is here to stay.

Overview

Something that has been utilized but Tadpole in most implementations but not advertised all that often is Performance Tools. Performance Tools exists as in the early days of field deployment using ArcGIS 8.x products (over 5 years ago now!) Personal Geoadatabases (pGDBs) suffered from performance problems (searching, drawing etc etc) when dealing with databases that where 800Mb and higher.

This is a combination of a bunch of data within the pGDB for ArcGIS to look through but also the burden being put on the hard disk as information next to each other in real life – poles running down a street holding up a primary line – would not necasarilly be next to each other on the hard disk. This resulted in the hard-disc being ‘thrashed’ when it had to draw an area on the map.

The problem also manifests when opening a Map Document (MXD) as ArcGIS needs to grab all of the information it can to draw the map resulting again in the hard-disc bein ‘thrashed’.

Performance Tools was designed and implemented to solve this problem and it’s whole goal is to spatial order the data contained within feature classes. In order words, place things that are next to each in real life next to each other on the disc.  

Metrics

The gains from doing this are wide and varied as it depends on the:

• Size of the data
• Have fragmented the dataset is
• The makeup of the data (believe it or not datasets that are square perform better to the the way that spatial indexing works in the Geodatabase!)
• The hardware that the Geodatabase is being used on.

That said, on average Geodatabases that have had Performance Tools run on it seem to run about twice as fast as that of a Geodatabase that has been extracted using GO! Sync (Extractor) or ArcCatalog.

Usage

Performance Tools has it’s main benefit is the first time that it has been run on a Geodatabase but when updated using Incrmental Updater it can get fragmented again and Tadpole recommend that the Geodatabases are spatially defragmented on a regular basis. This not only helps performance but the process also compresses the database which helps with file size.

Performance Tools can be implemented alongside incremental updater or as a process run after ‘The Extractor’ has extracted the Geodatabase.

Conclusion

Performance Tools is a valuable mechanism for performing perdiodic maintenence on the Geodatabases received by the field clients. It helps with performance and keeping the Geodatabases smaller and maintainable.

If this is something that you wish to discuss with Tadpole then please contact support@us.tadpole.com, your account manager or the business partner that implemented GO! Sync. 

Folks have been asking about the “business fit” for tracing tools. For background information on electric and gas networks, I’d recommend going to HowStuffWorks (www.howstuffworks.com) and searching on electric distribution and gas distribution.

As for the business “fit” for the traces…try this:

Electric

System isolation – absolutely useless in my experience…it’s simply too slow

Trace source/end – these are useful for identifying the substation circuit breaker that is feeding a particular circuit, or alternately for accumulating load points (transformers and meters) on circuit for outage reporting purposes.

Trace upstream/downstream – these are useful for finding the next device (source and/or load) on the line. Can be used to browse up or down on the circuit to find transformers, fuses, switches, open points, reclosers and sectionalizers and then get to them using the routing tool.

Trace upstream/downstream protective device – an upstream/downstream trace for protective devices (fuses, reclosers, sectionalizers and switches) only.

Phase trace – electric networks operate in three phases (alternating currents, sine waves, that are offset 60* from each other). The phases are alternately referred to as A, B, and C; 1, 2, and 3; or red, white, blue by different utilities. Hooking up an A phase device to a B phase line is potentially DEADLY, not to mention costly. Think about when you hookup a light switch the wrong way when you’re wiring your basement and you cause a short and burn out the switch. You walk away with a throbbing thumb due to the fact that you were only “stung” with 120 volts. The guys in the field would be dead after 4800 (4.8kv) – 13200 (13.2kv) volts coursed through them. A phase trace is designed to follow a particular phase or phase configuration. For instance, A, B, C, AB, BC, AC, or ABC. Transformers can be hooked up in configurations wye or delta configurations that combine phases to boost power. Iindustrial/agricultural machines and commercial lighting systems typically need three phase power. Homes are almost exclusively single phase.

Hydraulic (water/sewer/gas)

Valve isolation – useful for identifying the valves that need to be closed to isolate a section of pipe for replacement or repair.

Interactive isolation – the “new” tool that allows valves to be added/subtracted from the trace results to extend or constrain the trace. The main benefit of this is for in-field decision support surrounding accumulated load and the effects of planned and unplanned outages during damage restoration/repair efforts.

Pressure zone isolation – hydraulic networks operate on different pressure planes (water) and different operating pressures (gas). It’s useful to isolate the pressure zone during troubleshooting. Water pressure planes do not typically connect. As for gas, you don’t want to hook-up a high pressure line to an intermediate or low pressure line with out a pressure reducing valve. Regulator stations typically isolate pressure zones in a gas network.

Trace upstream/downstream – mainly for sewer since s*** flows downhill, you want to know which direction downhill is…sewer can also be pressurized (typically called “force” as opposed to “gravity”)

Trace next feature upstream/downstream – mainly for sewer and useful for locating manholes, vaults and clean-outs.

Traces that we’re missing…

Hydraulic – CP (cathodic protection) system trace – water and gas pipes are protected by anodes that are designed to rust out by drawing the oxidizing current off the bare (or coated) steel pipes. Pipe operators want to know where their cathodic networks are because they have to regularly inspect them for regulatory compliance. Rectifiers, anodes and test points are points on the CP network where readings are taken on current loss to determine if the anode is still active and doing its job. The recent news about the BP oil pipeline that rusted out and spilled crude oil on the North Slope of Alaska is evidence to why operators need to know about CP systems.

Electric – Circuit trace – similar to a phase trace, but following a particular circuit designation as opposed to phase designation. This is a safety consideration as well as an operations concern. The guys in the field might think that opening a switch on a section where they are doing a “hot line” job will kill power to that section of line, but in fact it’s still hot because of a switching operation that was done the previous week and it’s now fed off of a different circuit. Tracing the circuit would alert them to this. From an operations perspective, the guys in the field can also identify overloaded circuits and find tie switches that allow them to manually shift load.

I have spent the last week visiting a few clients in the Florida area and among all the other discussion one seems to stand out…User Feedback.

When implementing Mobile GIS systems it has always been a rule that you should involve the users of the system as often and early as possible. This allows them to get what they want from the system.

What is missing in that goal though is allowing simple and easy feedback of enhancements from the user community to the administrators of the system and optionally to Tadpole (we would be delighted to hear these requests). Thinking about this more in a spare moment this morning it seems like a toolbar button (ICommand in ArcObjects speak!) that allows the user to type in a comment would make sense. This information would then be logged into a database on the server and can be processed by Administration staff…..just a thought.