CarbonArc revisited

Jeff Harrison’s mass email caught my eye today with the free trial of CarbonArc. I had the pleasure of taking an early release of CarbonArc for a spin last year and while it was a good start there were a few key things missing from my point of view. Having pushed and prodded Mapinfo 9.5 support for use with our SDI, why not run the new CarbonArc 1.6 through its paces …

From the press release,

CarbonArc PRO 1.6 eliminates barriers to SDI usability through advanced SOA-based discovery, analysis, exploitation, transaction management and security tools for OGC SDI – directly from the ESRI ArcGIS desktop.

Instead of just regurgitating the release, the key question that always gets asked is … doesn’t ESRI ArcGIS already do all this?

Its a tricky question to answer because while on paper i could say, “Yes it does!”, in reality there are just so many annoying quirks and missing features, it quickly becomes a nightmare integrating SDI features into your normal ArcGIS workflow (which is what this is all about, right?).  So with fingers crossed, lets dive right in and see what i can find in 5 minutes flat …

The Good

  1. Well laid out and robust tool set which delivers fully functional WMS/WFS/WFST/WCS capabilities … with no mucking about required!. The thing just works.
  2. Very easy export to Shapefile tool
  3. Full featured filter encoding support … no black magic, user has full control
  4. Full access to the query string for all service types
  5. Caching of features / images when saving to project files

The Bad

  1. GML Integration will always be difficult given its a completely new ArcGIS feature source, but its still not up to the average users expectations I dont think. There is no attribute table, the features are independant of pretty much all other ArcGIS functionality so you are really left with GAIA functionality squished into an ArcGIS window.
  2. Web services request headers are devoid of any accept-encoding headers. I’m still pondering the choice of Expect: 100 requests … but i’m sure there’s a good reason in the depths of HTTP …
  3. The exclusive tool for CubeWerx “Identity Management Service” seems a bit strange as i’m not aware of any services that use this technology? Shoot me a link if i missed something!
  4. Lack of support for any WMS LegendGraphics. Users can choose from multiple Styles, but theres no way to actually view legend information which is a bit disappointing
  5. In the full minute spent trying, i wasnt able to get the WFST support working … i could get as far as the schema but as soon as i’d try to insert a feature the thing would just bail out.

I’m beginning to think the best suggestion would be to somehow merge CarbonArc WFS functionality with an automated export to shape on each filter response. This would allow excellent SDI WFS support, while still giving full ESRI ArcGIS functionality to users without having to reinvent the wheel (for things like the edit system). With the WMS/WCS support pretty solid, i think getting the balance of WFS right could mean the difference between a very promising product and one I would recommend to everyone using our platform.


4 thoughts on “CarbonArc revisited”

  1. Chris,

    We have successfully used CarbonArc’s WFS-T (transaction) capability in a project here in Canada to insert, update and delete features from a framework data WFS server.

    Can you describe the nature of the problems you ran into? I am curious myself to see what specific issues you had.


  2. Chris,

    CarbonArc PRO provides a sophisticated set of WFS-T editing tools. But before using transactions CarbonArc needs to to know a little something about the WFS-T server, the transactional feature layers and all properties associated with the transacted features.

    The Manage Transaction Sources tool allows the management and editing of the required information. In addition, this tool can auto-generate property types and rules for WFS Transactions using the appropriate GML schema.

    For example, in order to add a new feature CarbonArc must know what layers in the map have actual Insert capability, what are the properties the feature can have, what rules apply to these properties and what types of geometries are allowed for the feature. Without this knowledge at hand, discovering and applying this information for each operation will make feature editing slow and cumbersome, unfit for a productive, user-friendly environment. CarbonArc resolves this by asking the user to set (just once) the information about the used transaction layers. The information is saved in a transactions cache file. Once a layer is registered to the transactions cache file any changes to its settings and rule will be updated in the managed file and will be available to all future CarbonArc sessions.

    Question – it sounds like you may have set up “Manage Transaction Sources” for your WFS-T but we wanted to confirm.

    The Carbon Project

Comments are closed.