The Owston Blog

Moving On...

2010-04-16T10:48:00.000-07:00

As many of you already know, today is my last day at ERDAS. I will be moving on to other new and exciting opportunities.

I want to thank everybody at ERDAS...what an amazing group of people! How such a small group of people get so much done is really amazing. I also want to thank all the distributors and resellers globally.

I look forward to promoting ERDAS technologies in the market in the future.

Managing Regression Issues in Agile Software Methodology

2010-02-25T12:22:00.000-08:00

A software regression is an issue introduced into the software during the development cycle that breaks a "feature" that was previously working as designed. Lets provide a "concrete" example of a software regression issue.

Say I have the .NET "Hello World!" web service and up and running and working as designed. A new feature has been requested to add a new method to the web service that allows me to add my name as a user input and a message of "Hello World, I'm Shawn Owston!". You develop the net method, build and deploy and start testing. The first time you test it, the new method "Hello World, I'm Shawn Owston!" works...hoooray! But then when you try to use the old method, it throws an exception!

Now the new feature is working, that's a good thing, but the originally released feature is now broke, that's regression.

The first method to manage regression is to NOT introduce it in the first place! This requires architectural design, review and understanding of all of those involved in the development before writing code to ensure that the "best" framework, tools and coding standards are used to build a new feature. Remember that "Agile" doesn't equivocate" to "don't design anything" which is an interpretation that some pundits may object to the methodology. You may plan architectural designs in sprints and properly resource them as required...big and small architectural designs.

The second method to manage regression is for each developer to be thorough and pay attention to what they are doing "at all times", especially in a multi-developer team environment. This covers the entire gammet of the development cycle from proper branch management of source control, proper check-in/check-out procedures and proper automated build systems. It also means that developers must be "conscious" of the other team members dependent on the quality of their work. Do NOT check in work that is not "complete" into the build branch that your QA team is performing daily testing and do NOT take shortcuts or introduce known "hacks" into the software without communicating the issue to QA or Product Management to see if it's appropriate even in the short term.

The third method is to of course implement automated testing on your software. There are many automated testing software suites like QTP and SilkTest that allow you to "record" a user workflow as a script and to automatically run these scripts against your software to ensure that the features PASS/FAIL upon every software build or simply on some scheduled basis. These only test the "functional" aspect of software although...there are non-functional aspects that regression can reak havoc in your customer experience; i.e. PERFORMANCE. Yes, the user workflow may work, but it it now takes the software 10 times longer to perform the workflow, you have issues. Luckily, there is automated load testing software...HP LoadRunner being my preference. In the long run, automated testing saves a great deal of time and money by reducing the amount of human QA that needs to be performed. It also catches issues early rather that allow the regression issues to not pile up to an insurmountable and unmanageable quantity.

The fourth method is to test, test, test and retest the software. There is no supplement for having skilled QA and humans that know the workflow, expected performance and overall "usability" of the software.

Now regression will always occur, these are only ways to avoid them and to discover them. So once they issues exist, how do you "manage" them in an agile software project?

In our projects, we make sure to label all regression issues with a "regression" label in our bug tracking system. From the Product Management side of the house, these are ALWAYS Release Stopper issues. Refuse to let the software be released with features that used to work.

We also make sure all regression issues bubble up to the top of the priority list to resolve in the very next sprint. We plan and resolve the issue immediately. The issue was just recently introduced in the previous sprint if the QA cycle is working as designed, so resolving it immediately is important because the code is "fresh" in the developers head and it also reduces the chance that the regression issue will be "built upon" and cause further issues downstream as the more features are added that may be dependent on the code with the issue.

From all of the above, you can see that managing regression is a harmony of a good plan on not creating the regression issue, discovering the issue in a timely manner and resolving the issue "just in time" to avoid a pile up of regression issues that possibly are required to be released to the market because your out of development time.

Simulate the 501'st user in a live webinar on Imagery through WMS

2010-02-03T15:32:00.001-08:00

The recorded webinar for “Prove it: Can ERDAS Really Deliver Terabytes of Imagery Faster than the Competition?” has been posted to the ERDAS Website at the following URL:

http://www.erdas.com/Resources/Webinars/ArchivedWebinars/tabid/175/currentid/3334/objectid/3334/default.aspx

This download contains the webinar recording. The PowerPoint presentation used during the presentation and the LoadRunner Performance Report generated during the presentation that reports on the Servers usage and throughput during the load test will be posted tomorrow.

This webinar demonstrates LIVE an ERDAS APOLLO with a load test running 500 concurrent users on it then live use of a web client using this server (simulates being the 501’st user). It also demonstrates several publicly available web sites that showcase our technology in publicly available web sites.

I had to cut short the questions at the end of the recording and we fielded another 20 minutes of questions that were not recorded (I wanted the recording to be 60 minutes and it ended up 75 because of questions).

I'm going to reproduce the demonstration with 1000 users next time, try and put a heavier load on the server. 37% resource usage is nothing!

ERDAS APOLLO 2010 Proves Itself as the "Fastest" Raster Imagery Server

2009-12-17T16:10:00.001-08:00

Chris Tweedie of our ERDAS Australia Region has recently reproduced the FOSS4G raster imagery performance benchmark tests using ERDAS APOLLO to compare the results and has published them on his blog:

Here are the Results of ERDAS APOLLO 2010 using the FOSS3G Test Sceneario

We've all been really busy with the Recent APOLLO 2010 Release, but Chris made it a priority to get these numbers completed and published. Nice work Chris!

Chris did a great job of providing graphs for Image Format performance for each Map Server and graphs for Throughput and Response Times for each format with each Map Server to make it comparable by Server or by Format/Server.

Some analysis of the results:

1. ECW imagery format is a "performance purpose" built imagery format. The throughput of ERDAS APOLLO with the ECW format is 2.5 the Open Source Servers at a 150 user load and can support a much higher load than 150 which wasn't represented in the this test scenario. The throughput curve had a steep positive slope even at 150 users where the other servers were peaked out with throughput at the 150 user measurement.

2. ERDAS APOLLO outperformed each Open Source server on every image format with the highest Throughput (transactions/second) and lowest Average Response Times (the time that it takes to get the image on your map). ERDAS APOLLO outperformed open source with every image format in the test.

ERDAS will be providing several webinars and whitepapers regarding the subject of "Raster Imagery Performance" to showcase the ERDAS APOLLO 2010 and it's performance capabilities.

Keep in mind that these numbers do not even showcase our faster imagery protocols that we provide with ERDAS APOLLO....

ECWP and our Optimized Tile Delivery are MUCH faster and support much higher user loads compared to the WMS protocol (THOUSANDS of users on a standard server). In short, we can produce maps MUCH FASTER than these numbers published with the "slowest" protocol provided by the APOLLO 2010.

Good work again Chris...

How Does ERDAS Support Open STANDARDS?

2009-10-15T15:28:00.000-07:00

ERDAS expends a large effort to support Open Standards and in the end, interoperability with other software implementations that as well support open standards. We invest in the development and implementation of Open Standards because as an organization, we believe in our software products working seamlessly with any other geospatial package that exists on the market and providing our customers with a large variety of deployment and design options for geospatial solutions. We support open standards to additionally be a compelling and viable option in ANY geospatial system under design irregardless of an organizations existing systems "vendor". We also measure each component and feature we develop with any pertinent existing IT and Geospatial standard to ensure that we maintain a high degree of interoperability.

So "how" does ERDAS support Open Standards then?

We support the entire array of IT and Spatial Standards. On the IT side of the house, we support a variety of Operating Systems, credentials stores (LDAP, Active Directory, DB, etc), Application Servers, Databases, chip-sets and virtualization environments (both hardware and OS) and of course, industry web service standards of WSDL/SOAP/UDDI.

On the GeoSpatial side of things, we support the web mapping standard WMS, the gridded data delivery service of WCS, vector feature delivery service of WFS, open catalog service of CSW, map context WMC, WRS, URN, OWS common, Filter, on and on an on....

We also participate in the development of standards within the OGC standards body. There is a "cost" to participating in these standards development bodies of which ERDAS is more than willing to participate to ensure the standard meets our customers use cases and to bring to the table the wealth of industry proven "knowledge" to ensure the standards meet in the end, market needs.

Why support Open Standards?

We do this because it's important to our exiting customers and a market driving initiative in the geo-market space. We do it because the standards are becoming "mature" and capable to meet customer use cases (not just a prototype, actually used in a production environment). We also do it to proliferate the standards within the industry and prove the capabilities of the standards within extremely high volume, rapidly changing production environments.

Why point these facts out?

There's been quite a bit of "noise" superimposing Open Standards with "Open Source" that can be confusing to non-IT decision makers and a propensity of some open source pundits to raise an argument that "commercial"="proprietary"="vendor lockin"=an advantage to open source. This is definitely not the case in the market today, whereas ERDAS is not the only vendor ensuring a high degree of open standard support and interoperability.

This "noise" rises from the organization and productization of the disperate open source projects in the geo-space and to create competitive marketing against the existing commercial products. It is now officially a "vendor" option to customers. ERDAS stands firm in out position in the market and our capabilities to provide highly interoperable, entire end-to-end geospatial processing and analysis chains with market proven maturity and market leading segment to PROVE it.

ESRI Bails on FOSS4G Performance Shootout

2009-10-14T10:47:00.001-07:00

ESRI has withdrawn from the FOSS4G Performance Shootout. There hasn't been any official statement on the Performance Mailing List announced as to the reason why yet, just that they will no longer continue with the exercise.

Why would ESRI pull out so late in the game?? The performance numbers were supposed to be completed this week?? Why put in so many WEEKS of effort in getting the system setup and deal with all the "issues" that were encountered during the setup and testing period to "bail" right at the end??

I've been following the mailing list quite closely, and I have a couple of observations:

1. There was a lot of disorganization in terms of the coordination of the hardware topology, testing procedures, the data configuration, what data to use, what tests would be performed and "who" was responsible for what! It was a total free for all with no scheduling, responsibility and probably the "hand holding" necessary to keep ESRI engaged. It was up to ESRI to meander through the minefield of issues presented with the data, changes to the system, test scripts and hardware.

If your ESRI and you feel like you just jumped into a circus, would you continue to parade in line with the rest of the show?

2. I am EXTREMELY glad I didn't waste any resources on attempting to participate in what should be an EXTREMELY interesting and engaging exercise.

I highly recommend that an independent organization provide a non biased, preapproved methodology, preapproved dataset with the opportunity to put the data in a vendor recommended format (which every customer usually does anyways), capable and diverse hardware set to limit the non-functional limitations, proven performance testing software and methodology to measure LOAD not throughput and the right to review, control the rights of the results to be published/non published, there will be very high participation from ALL the available vendors.

This is even after the publication announcing the "shootout" which I felt was aimed at throwing ESRI under the bus anyways.

What a disaster...

ENEA Relies on ERDAS APOLLO to Ensure Sustainability

2009-10-11T11:44:00.001-07:00

http://www.erdas.com/Company/News/NewsReleases/tabid/96/currentid/3084/objectid/3084/default.aspx

Open Source Doesn't like to be talked about :)

2009-10-11T01:08:00.001-07:00

Here's a thread on the OSGeo discussion regarding my comments on "Advantages and Disadvantages of Open Source Software" on linkdin.

If anybody is interested in what "FUD" means, it's an acronym for "Fear, Uncertainty and Doubt".

WorldView II Successfully Launched!!

2009-10-08T21:11:00.000-07:00

So the WorldView II sensor is in orbit! I can't wait to get some of the products into the APOLLO and the Web Processing Service!!

The sensor has a short wave IR band that REALLY is needed for lots algorithms that can only use LANDSAT TM and MODIS imagery...but WorldView II will do it at 46 cm!

I will definitely be showing that data off on the demo site as soon as we gain access to it!

Geospatial Performance Benchmarks "Apples to Apples"

2009-09-18T15:41:00.001-07:00

I get a lot of requests for Performance Benchmarks of APOLLO vs. lots of other systems. We provide extremely analytical and detailed performance results of our server every release. A couple issues always crop up in any performance benchmarks:

1. Features - first of all, ANY competitive product cannot DO what APOLLO can do...so I find myself either A: Dummying down APOLLO and the test to even be able to do an "apples to apples" test or B: not making it "apples to apples".

2. Return on Investment - ROI on software is not just performance, but HOW LONG IT TOOK TO SETUP, ADMINISTER and GET the feature operational in a production scenario!! I find myself spending such a HUGE part of my time getting the competitive software to even "work" to do the test.

I've been following the FOSS4G's Web Mapping Shootout announced for their 2009 conference. I get a really HUGE chuckle because their "shootout" couldn't be perfomed on a more CARTOON set of data and NON-REALISTIC use case. I don't know ONE client that requires one image and a handfull of vector data sets (3 to be precise).

Our smallest benchmark has 459 7 band images...choke on that Open Source.

They should call it a "water gun fight" instead of a "Shootout".

Also what will NOT be collected in the "shootout" is how long it took them to setup the system and service enable the data...how many "WEEKS" are you willing to struggle with that?

PERFORMANCE is about ROI on the investement and of course the ability of the system to handle a user load. Weigh both when your looking at the numbers!!

ERDAS APOLLO 2010 BETA has BEGUN!!

2009-09-18T15:24:00.000-07:00

The ERDAS APOLLO 2010 has been released at the beginning of this week!! For the ERDAS Enterprise Products, we will have a very detailed BETA Web Page providing procedures, documentation, video short tutorials (*new*), announcement and FAQ's. It's not too late, contact your ERDAS Sales Rep to participate!!

The first week has been a GREAT week! The Geoprocessing workflow feedback has been excellent!! What I'm particularly VERY PROUD of this release is not just that we have an interoperable WPS and can perform such AMAZINGLY COMPLEX spatial workflows within a single process, but the WORKFLOW of WPS is so smooth and easy to use. From the publishing experience for Analyst users (THANKS IMAGINE TEAM) to the management of processes on the server, to the execution through a thin client (web browser) of models by end users who don't know imagery or remote sensing AT ALL...the end to end use case is AWESOME!!

If your end users need ADVANCED Spatial Modeling and INTEROPERABLE delivery of data and spatial modeling products...AND your looking at MAN YEARS of customization of your existing proprietary system or NEVER ENDING full blown core development of your extremely limited, disconnected OPEN SOURCE project (because these are the only options that exist today), ERDAS IS YOUR SOLUTION!!

Maintaining a Schedule with an Agile Software Development Methodology

2009-08-15T12:06:00.001-07:00

As a commercial software vendor, it is EXTREMELY important to maintain a SCHEDULE and deliver software on the date that we communicate to the market that the software will be released. This is critical because we have existing customers who pay software maintenance and expect on a regular basis:

1. bug fixes
2. minor feature improvement/enhancements to existing features
3. resolutions to any workflow issues they may have reported
4. new features at major releases

It is also critical to deliver new major features to the market to enable the sales force to meet the demand of the feature in the market on time to capture the sale! If you deliver the feature 1 year after another software vendor has already released the equivelent feature, you put your sales force at a disadvantage as they are playing catch-up against the competition.

ERDAS targets two releases per year (a minor release in Q1 and a major release in Q4).

It is far too easy to get trapped in "release date creep" in an Agile Software Development Methodology. There are several reasons for this...

1. The very nature of the methodology is user experience driven, not software architectural by nature like a waterfall methodology
2. It is easy to "not" do architecture or take the "big picture" into account before implementing a use cases. This sometimes leads to the inclusion of "technical debt" into the software by the final implementation not "fitting" into a holistic architecture of the software. This results in the need to refactor the software at a later time to "clean up" the architecture and/or create harmony across similar use cases.
3. The use case may be implemented, but the resulting performance and non functional requirements were not accounted for...only the ability of the use case to be met by the actor in the system was focused upon. For example, the use case works on Oracle, but not PostGreSQL, or the use case works in IE6, but not Firefox.

In short, the analysis of "what it will take to implement a use case" process when planning a sprint can be a difficult process on very large feature sets and feature sets that span multiple tiers of the software (i.e. Database, Server, Middleware, Clients).

In previous blog posts, I mentioned our own software development teams use of the "Spike" in our methodology to "flush out" technical unknowns and document architectural requirements before implementing use cases. This process in the Agile Methodology has been a great tool to our development teams.

Besides technically flushing out architecture and technology before implementing use cases, it's important to take a step back and look at the release cycle as a whole and the stages of the release cycle to ensure that the software meets not only the user experience, but the non functional categories of quality, performance and OS/DB/App Server needs.

Rather than develop the use cases "just in time" on a sprint by sprint basis, our Product Management Teams develop all the use cases for a release cycle BEFORE the release cycle begins. This allows the development team to understand the system under design as a whole and also for the Product Management teams to clearly and concisely present to the development teams what we expect the system actors to be able to accomplish when the software is released. Building a "Release" backlog of use cases really enables the development teams to consider architectural dependent use cases, understand the software as a whole and choose appropriate technology to meet all of the use cases, not just incorporate technology at run time during sprints.

We also provide ample time at the end of the release cycle for software stabilization (bug and improvement issues that provide quality to the software and ensure the software meets performance and the non functional requirements). Completion of the new features and stabilization signifies a "Feature Complete" state of the software, where the teams agree that the software could be released to the market.

We're still not "done" at that point!! The software goes through a final QA which it must pass to be released to the market, Acceptance Testing and BETA and then finally if AT and BETA does not reveal any critical bugs, the software goes into a box and is delivered to the market.

In short, if you are new to the Agile Methodology, MAKE A DATE that you expect the software to be released, MAKE A PLAN that adequately will enable your development team to meet that date and MAKE ROOM to test the quality and performance of the software BEFORE releasing it to the market!

ERDAS APOLLO 2010 OGC Web Processing Service (WPS)

2009-08-14T16:17:00.000-07:00

The ERDAS APOLLO 2010 release coming this October will have an OGC Web Processing Service (WPS). This OGC standard is not as well known as the Web Mapping Service (WMS), Web Feature Service (WFS), Web Coverage Service (WCS) or Catalog Service Web (CSW), so here's some information about this service and what ERDAS has done to build the most powerful WPS available on the market!

What is the Web Processing Service?

"The WPS standard defines an interface that facilitates the publishing of geospatial processes and makes it easier to write software clients that can discover and bind to those processes. Processes include any algorithm, calculation or model that operates on spatially referenced raster or vector data. Publishing means making available machine-readable binding information as well as human-readable metadata that allows service discovery and use.

A WPS can be used to define calculations as simple as subtracting one set of spatially referenced data from another (e.g., determining the difference in influenza cases between two different seasons), or as complicated as a hydrological model. The data required by the WPS can be delivered across a network or it can be made available at the server. This interface specification provides mechanisms to identify the spatially referenced data required by the calculation, initiate the calculation, and manage the output from the calculation so that the client can access it.

The OGC's WPS standard will play an important role in automating workflows that involve geospatial data and geoprocessing services." Quoted from the OGC Web Site

What is the WPS in APOLLO?

The WPS in APOLLO is the interoperable Web Service that is exposed by the server for client applications to self describe, publish and execute Geoprocesses. At a higher level, the WPS is integrated into a web based Geoprocessing workflow where end users can execute extremely powerful WPS processes through a web client "on demand".

Highlighting the consumer users use case, they will be able to navigate to anywhere in the map, discover the WPS Processes they have been provided the security right to execute, select the process, discover the PROPER data to execute the process and "on the fly" execute and receive output "data" that can be immediately mapped and downloaded after the WPS process has been completed.

The WPS in APOLLO is EXTREMELY powerful because we have enabled the IMAGINE Spatial Modeler Engine within the WPS process execution framework! So what does that mean...

In short, Analyst actors in the system will be capable of graphically designing complex spatial models and algorithms in the IMAGINE Spatial Modeler to create chained spatial model workflows and publish these workflows to the APOLLO WPS for execution for consumer end users!!! This means that a single WPS process bundles a full geoprocessing model (i.e. hydrologic models, change detection models, terrain analysis and portrayal, any gridded data processing model in fact), not just a simple mathmatical or pixel process!

We've added many "bells and whistles" to integrate the MASSIVE catalog of data that exists in the APOLLO and make it VERY EASY for end users to know what data "loads" a WPS process. During the Publishing Workflow of a model from IMAGINE, the analyst user stores for each model input a CSW query against the catalog to provide for the end user a "list" of valid data that exists within the catalog that satisfies the model input requirements (i.e. is a Multispectral image with NIR and Red band or is Terrain of > 10 meter resolution, etc, etc). The web client executes these CSW queries (along with a spatial domain query based on where the user is in the map) to display a list of valid inputs for wherever the end user is looking at the map!!

Compiling the extreme power and ease of CREATING complex geoprocesses in the Spatial Modeler, with the interoperable web service for executing these processes, with the EASE of the user experience to execute these processes by a 'non remote sensing' web client user and you have a secure, CONSUMER based geoprocessing platform over the web!

Get ready for my WPS demonstrations coming soon!!! It's going to blow your socks off!

Get a Preview of What ERDAS Is Working On For the Next Release!!

2009-06-03T13:23:00.000-07:00

We have released ERDAS Labs website today that provides a "peek" at what we are working on for this September ERDAS 2010 Software Suite!

I am really excited about the ERDAS IMAGINE 2010 Ribbon Interface, LPS eATE and of course, the Web Processing Service (WPS)!!

ERDAS Labs is created to enable our existing and potential customers to see what we are developing through feature synopsis and demo videos. The site elicits comments and direct developer feedback for each showcased feature!

Check out just a few of the ERDAS 2010 major features...today!

Do you need data to go??

2009-06-02T15:17:00.000-07:00

Gridded Data Provisioning Solution built on ERDAS APOLLO Image Manager...

Check it out!

http://www10.giscafe.com/nbc/articles/view_article.php?articleid=702262

The Spike - Quality Software and Agile Software Development

2009-05-28T16:33:00.001-07:00

There is a balance between delivering use cases to the market and maintaining overall software quality in an Agile Software Development Project. It's extremely easy to get "trapped" into the "tunnel vision" of providing user facing features as fast as possible and quickly encounter architectural deficiencies and technical debt that impacts the overall quality and performance of the software.

Agile does not mean NO architectural design! Many teams just learning agile have difficulty understanding how design "fits" into the use case or user story methodology.

Here at ERDAS, we utilize planned 'spikes' and design sessions and plan them in iterations before implementation of the the user/system interaction to ensure that the resulting imlpementation soundly builds upon our architecture.

A SPIKE is a "technology" discovery process. It can be a research project into technologies or algorithms, an evaluation/benchmark or prototype of technologies to find a "best fit" or a discovery process of existing algorithms and archtecture to provide man day estimates or "Level of Effort" to get some use case completed. We effectively use SPIKES to address the "unknown" or "uncertain", dedicate time to make it known and to determine how long it will take to satisfy a use case and always report the results of every spike in the Iteration Review.

We also enforce a "time capped" rule on spikes. This rule essentially allocates a fixed amount of time that it will take to "discover" what we want to know. At run time if a blocking issue is encountered, we can always increase the duration of the spike, but we very seldomly do so. Time capping the spike really enables detailed planning, ensuring we avoid "creep" in a discovery process and stay on schedule.

OpenGeo Team is "faster and better" than anyone else in the world???

2009-05-28T16:12:00.001-07:00

I really get a kick out of the self provocative proclamation that the OpenGeo Team is "...faster and better than anyone else in the world..." at solving geospatial problems on the OpenGeo Team page.

I recommend a "geospatial" Academic Decathalon!

ERDAS has been solving "real world" National Mapping Agency geospatial workflows for decades now. ..so how are you 'faster' and or 'better' than the world class geospatial scientists, remote sensing scientist and developers that exist at ERDAS?

Should we measure this based on software revenue? Possibly an 'apples to apples' comparison of products and satisfied use cases? "Challenge" each team with a use case to satisfy (FULLY!!)? How about number of supported sensors and formats? Or what about a third party review of resumes?

Thats just a rediculous statement guys...

ERDAS APOLLO Reference Sites

2009-05-22T11:24:00.000-07:00

With a new enterprise product suite on the market, it's extremely important to have reference sites and to determine "who" is using the ERDAS APOLLO and "what" they are doing with it.

Here's a small list of some of the ERDAS APOLLO customers that have Press Releases:

British Transport Police Preparing for 2012 Olympics with ERDAS APOLLO

Cyprus University of Technology Implementing ERDAS APOLLO

ERDAS APOLLO 2009 Selected by China’s National Environmental Protection Ministry

ERDAS Solutions Used for Tourism 3D Spatial Analysis

Saxon Forestry in Germany Implementing ERDAS APOLLO

CycloMedia Implements ERDAS Image Manager

Capturing & Delivering Digital Imagery of the Netherlands

The Price of "FREE" Open Source Software has really become Expensive!!

2009-05-21T11:08:00.001-07:00

I was looking at the OpenGeo Version Matrix and the price to "buy in" to the open source geospaital software has really become crazy! It appears the line between capitalist and geospatial philanthropist has really become blurred. It's more expensive to buy into open source than to purchase COTS software today!

$70,000 for 300 hours of service!!!!!!!!!!! OMG!

I run into so many clients that are "hamstrung" on open source solutions that are being funnelled into a bottomless money pit with open source. No doubt, the "hook" to allure people into the evaluation stage is there with the "free" pitch, but the REALITY of what it will take to really meet requirements smacks you in the face immediately.

The business model of "Try it...figure out what you really want...then pay me 70K" open source model is a bit crazy.

Always remember, you buy into it, YOU MAINTAIN it for the rest of your life. OUCH!

The market is begging for a vendor to pick up the ball here...luckily, ERDAS is HERE!

Give the "out of the box" SDI that works, has a WORLD CLASS development, support and product management team supporting the project with real world PRODUCTIZED features and evaluate the difference for yourself!

The ERDAS APOLLO!!!

Can somebody calculate an ROI for me immediately!

Cherokee County, Georgia...the MOST MAPPED SPOT ON EARTH??

2009-05-19T16:27:00.000-07:00

For the ERDAS Enterprise Products Public Demo Site, we've been very fortunate to leverage our data vendor business partners and the Cherokee County GIS Team to collect lots of vector, terrain and imagery data for this area of interest and serve this data through our enterprise products. For one, ERDAS global headquarters is in Norcross, Georgia which makes it a close proximity to Cherokee County and second, it's just a pretty nice place (thats went through massive change over the past 10 years).

Lets take an inventory of the data that we've collected:

1. LANDSAT 1, 4-5 and 7 scenes from 1973 - 2008 (multispectral and panchromatic)
2. Digital Ortho Quarter Quads from 1999
3. Airborne 2006 high resolution ortho imagery
4. IKONOS imagery from 2000-2008 (multispectral and panchromatic)
5. USGS Digital raster graphics at 1:24k, 100k and 250K
6. SRTM DTED
7. SPOT scenes from 1999-2008 (multispectral and panchromatic)
8. National Land Cover Dataset from 1992 and 2001
9. 2008 Vectors of Roads, Parcels, Land Lots, Zoning, Buildings, etc, etc from Cherokee County Georgia

on and on and on and on....

Note that all of the imagery and terrain is being served from a SINGLE Web Service endpoint (of course you are only gaining access to the public layers by clicking on this).

The vectors are being hosted from an Oracle 11g Database with Spatial Cartridge with no proprietary middleware required or proprietary SDK or proprietary data model, JUST Oracle spatial please!

All of this data over all of these timeframes in one location made me ponder, is Cherokee County Georgia now the MOST MAPPED AREA IN THE WORLD!!!

We are using our business relationships to collect even more data over the area so stay tuned to and see how many "sensors" we can collect over a single area!!

There is some really EXCITING FEATURES coming in the ERDAS APOLLO 2010 release this September so GET READY to see Cherokee County Georgia like you've never seen it before!!!

Is the Geospatial World devoid of Performance Benchmarks??

2009-05-15T01:11:00.000-07:00

Why are performance benchmarks so elusive for enterprise geospatial software?? Every Request for Proposals for enterprise geospatial software requires some level of "performance" to be reported. Commonly RPF's request the expected number of concurrent users, throughput and "load" the system can handle and indirectly a hardware set to be recommend based on a purported number of users that will be using the system.

Here at ERDAS, we invested in HP LoadRunner to design an enterprise performance testing system that is the best I've ever seen in my history with enterprise software. Unlike many vendors, we don't report "predictive" numbers, we produce and report ACTUAL performance numbers on real world enterpise systems under design! We of course use the testing setup internally to determine 'things to improve' and the impact of individual features (i.e. portrayal or reprojection) vs. a known baseline. Just to be forwarned, the setup was not cheap and it was also not easy to figure out how to properly implement, but the stability, flexibility, repeatability of test "scenarios" and RESULTS produced are AWSOME!

All I know is that I "FROTH" at the opportunity to stand APOLLO up to any system on the market today! We've "handily" beat out several competitors in "head to head" evaluations and always meet our documented performance results. I attribute this to our investment in performance testing setups and required performance test scenarios to pass before every release. The testing setup has proven INVALUABLE in succinctly diagnosing performance issues, ensuring our performance at release time is to our standards and report to customers the performance they should expect...and MEET that expectation!

ESRI vs. OGC Community

2009-05-13T13:53:00.000-07:00

ESRI is really pushing hard on proliferating their own PROPRIETARY services with their 9.3.x Server offering and recommending this over standards based interoperable web services to the GIS community "at large".

I am also PUBLICLY stating that thier support for the OGC services (especially CONSUMING them in their clients) is VERY WEAK functionally as a feature set and the performance is very, very poor. The ERDAS APOLLO Image Manager Web Client is such a better user experience and faster at consuming OGC services than ArcMap!!

Lets put ourselves in their shoe's and dwell on why this would be??

ESRI currently holds the largest marketshare in the GIS domain. They have every intention to keep that marketshare. To the market leader, making the OGC services actually work equivelently to thier proprietary services does have the possibility of marginalizing and commodotizing feature sets in the GIS market leaving "opportunity" to those who are supporting the interoperable services. Forcing the customer to "have" to use proprietary services and SDK's to meet thier use case is also in ESRI's interest as it requires vendor lock-in on the server and client side. It's quite easy to say that the OGC services aren't "rich" enough to provide the use cases that clients need when thier only experience with it is extremely limited and the performance is very slow (as experienced in thier software today). They also have no interest in a "governing" body controlling technology decisions and/or application profiles on the technical side.

OGC Services on the other hand need to provide the user experience and the PERFORMANCE that proprietary services do. In my opinion, this can only be provided by the geospatial vendors. The open-source project don't have the wealth of domain experience, existing codebase and market experience to do this. They of course will provide a user experience, but at a very poor performance.

Entre...VENDORS SUPPORTING THE STANDARDS AND DOING IT RIGHT! ERDAS has really supported the OGC standards in an extremely MEANINGUL and HIGH PERFORMANCE manner. We are CITE certified OGC services and provide "under the hood" the depth and richness of format support, sensor model support, workflow and an out of the box end user experience in a single product that is expected of a commercial vendor.

If you really want to see the OGC services FLY on TERRABYTES worth of heterogenous data with real world use cases...the APOLLO Enterprise Suite is what your looking for.

The ESRI Geodatabase Proprietary cluster

2009-05-12T13:29:00.000-07:00

I usually don't complain in general, but this time I've had it up to my eyeballs with the inability to work with the ESRI geodatabase without using their proprietary SDK's. I've developed with ArcObjects for over a decade now so it's not a matter of "complexity", it's simply an issue of total lack of interoperability!

The "marketecture" on thier website speaks of interoperability and IT standards yet they don't allow anybody to access the data that they store in their PROPRIETARY storage format...say one thing, do another.

Don't get me wrong, I'm a huge fan of the FEATURES of the geodatabase, but I've had it with having to use ArcObjects to work with what should simply be free flowing GI.

So there is supposed to be a published specification for the "file" geodatabase in the 9.4 release. Great...but what about the DB persisted "enterprise" geodatabase? It must only be "simple" feature specification as all the behavior of objects is in the application tier?? I'm looking forward to implementing the real "simple feature specification" on top of whatever specification they provide....ughhh.

The "marketecture" should read, "We are totally interoperable...with ourselves only"!!!! (note the very small typeset caveat disclaimer said that under my breath reality check).

ERDAS APOLLO Image Manager: Saxon Forestry in Germany Case Study

2009-04-22T01:29:00.000-07:00

Need interoperable delivery of huge volumes of gridded data? See the Saxon Forestry in Germany Case Study.

ERDAS APOLLO Image Manager: Cyclomedia Case Study

2009-04-21T16:52:00.000-07:00

Need management of 75 TB of rapidly increasing imagery??? Check out this Case Study for Cyclomedia and the ERDAS APOLLO Image Manager 2009.

Call for Content

2009-04-13T12:24:00.000-07:00

The blog contains a variety of readers interested in different disciplines; enterprise, product management and methodology and ERDAS product related content. This is an open post to request from you the reader what subjects you would like to hear about or read about.

Just add your comment to this post and I will make sure to reply to your request.

SOAP vs. REST in Geospatial Applications

2009-04-13T10:54:00.000-07:00

It's interesting to see the decision making process at organizations evaluating geospatial technologies. One area that I see a lot of "effort" from an IT and developer stakeholders in Geospatial Software Purchases is in the form, function and ROI of the technologies REST or SOAP. This is being driven on the enterprise side of the house where these technologies are essentially thier choice of which to invest in.

The ESRI Developer Summit Keynote provides a good technology overview by Dave Chappel on "SOAP vs. REST". Probably for people at a decision maker level trying to understand the technology and "keywords" or end users trying to get a better understanding of the technology, this is a good starting point.

Two areas that is always analyzed and heavily weighed in any evaluations is INTEROPERABILIY and SECURITY, and this is where SOAP clearly becomes the "leader of the pack" in technologies today. This is with any technology that these two categories are scrutinized. The requirement for proprietary REST client interfaces is such a drawback of the technology. Why would I want to have to integrate a proprietary interface in everything that I want geospatial data and have a proprietary client interface integration effort to 'work' with my GI and services? The pushback in that process is definately "loud and clear" from the market. In terms of security, you CAN secure REST endpoints, this is not a problem, but a lack of any standard to do so and/or the client interfaces proper ability to handle security rhealms must be accounted for, you shouldn't have to 'poke' at it to find out if it works. Again, same theme, proprietary is a big blocking issue there.

Mr. Chappell raises a good point in that SOAP is not "easy" to manage from the client side of the house as managing XML isn't the easiest or most eloquent. Fortunately in the GI space, everybody already supports the standardized services (WMS, WCS, WFS, etc, etc), so the "effort" and ability to handle it with standard interoperable client interfaces is widely prolifererated and highly available, so i think that point is rather 'mute'.

Don't get me wrong, REST is a GREAT technology, it simply needs some standards bodies to define how and where they will be used to get the same ROI and proliferation as the well defined SOAP services today. This process is firing up with the OGC right now. Hope the conjur up something useful with that... :)

EAIM 2009 R2 Released

2009-04-10T19:01:00.000-07:00

The ERDAS APOLLO Image Manager 2009 R2 has officially been RELEASED!! The performance improvements are incredible! HUGE Volumes of imagery in their original formats delivered even faster! Please request the EAIM Performance Benchmarks Whitepaper to see the numbers...I'm very, very happy with the results.

The new high performance catalog with CSW interface has made such a huge difference in all aspects of the software. Not only from a user experience in WMS and CSW Catalog Search response times but the ability of a single server to handle a large load of web clients, concurrent GI Crawlers and CPU intensive jobs (i.e. Clip, Zip and Ship).

GET READY for the market previews of the ERDAS APOLLO Web Processing Service (WPS)!!!! I've never been so excited about a software feature before!! A preview will be coming in the NEW ERDAS Labs website soon, so stay tuned!!

EAIM 2009 Release

2008-09-26T15:49:00.000-07:00

It's official! The ERDAS APOLLO Image Manager 2009 has been released!!!

What a great major release of the EAIM 2009! The software bundle has also been repositioned so that every EAIM 2009 purchase recieves an ERDAS APOLLO Server 2009 as well to provide Enterprise Vector Service Enabling (WMS, WFS-T).

In addition, two major wins for the EAIM 2009 coinciding with this release, both with direct head-to-head evaluations with the competitor!

1. The British Transport Police
2. 3001

If you have large volumes of raster data that you need to server to multiple GIS/Remote Sensing/Web/Open Source clients, you need to check this out!

Just to bullet one particular feature in this release, I'm VERY happy with the Defense Formats for EAIM 2009! NITF and TFRD with RPC's or Defense Sensor Models, NO PROBLEM! The EAIM will catalog this imagery, utilize the related terrain source to perform "ortho-on-the-fly" and deliver GIS ready imagery for real time access through WMS and WCS and also available for download as orthorectified imagery through the Clip, Zip and Ship web based workflow. DTED, CADRG, ADRG, CIB all supported. AWSOME!

The EAIM 2009 is the most comprehensive gridded data server in the world! The EAIM will deliver data in any protocol you require:

1. WMS
2. WCS
3. ECWP
4. JPIP
5. Out-of-Band

You have to see the WebEx presentations scheduled for October!

ERDAS Apollo Image Manager 2009

2008-08-13T18:39:00.000-07:00

There is so much NEW in this August 2008 version...EVEN THE NAME! The Leica Image Manager has now been renamed to the ERDAS Apollo Image Manager 2009! We have also "synched" our version numbers with our flagship application ERDAS IMAGINE to v.9.3.

This version marks a MAJOR milestone in the ERDAS Apollo Enterprise Software Suite. the EAIM 2009 is a true vertical market solution developed on the Apollo Enterprise SDK (release Feb 09) and now comes with the Apollo Platform, a full vector management and OGC Web Services Platform!!!! Not only manage imagery, but manage vectors from disperate data sources, create, style and publish WMS, WFS, WCS services and catalog them in the NEW Apollo Catalog.

The BETA Release has been announced today! Get your BETA ON!

Whats New?

1. An end-to-end WEB BASED Clip, Zip and Ship Workflow
2. JPIP SERVER!!!! Integrated with the EAIM 2009 Data model and WEB SDK through the ERDAS Web Plugins. Who's ready for web based JPIP!!!
2. NITF 2.1 support (with commercial and defense RPC sensor model support and Defense Sensor Models with the Defense Productivity Module)!!!!
3. Defense format support - DOD Metadata support, CIB, ADRG, CADRG, USRP Direct Read and custom GI Crawler behaviors
4. MORE Data Model enhancements (see EAIM 2009, Modeling Gridded Data Whitepaper)
5. New Styplized Web Client
6. Apollo Platform Product included out of the box!
7. Performance Enhancements
8. Single FlexNET Licensing for all ERDAS Software

I'm really excited about this version and getting it released to the market. Grab onto your seats folks and get ready for the ERDAS Enterprise Software Suite!!!

The Open Source Business Model

2008-05-23T13:22:00.000-07:00

In the GI "interoperability" domain, the "chatter" regarding open source softwares really interests me. I've had the opportunity to develop upon and deliver solutions with both open source projects and commercial products.

The geospatial open source community has had success. I attribute a couple of phenomena for this:

1. Early adoption of interoperability standards and availability of functional software in the Open Source community (they were there first)
2. Slow adoption of interoperability standards by "known" software vendors (wait and see approach)
3. Mandated interoperability requirements for "government" entities (US and Europe require it now, but how?)
4. Early "success" for limited use cases in prototypes with open source softwares
5. Good "marketing" jargon

The open source communities have really done a good job at targeting and developing the "basic" GI requirements. The open source community provides a good "cartoon web map" experience, several 2.5 D globe viewers and there are some good SDK's as well, GeoTools, GDAL and PostGIS.

"Behind the scenes", there is undoubtedly a business model behind open source software...don't believe the philanthropy when you here that there isn't. The main contributors of open source software make money, unfortuantely, it' s the only means of existence in the industrial world.

So what is the Open Source Business Model? It's both services and the traditional software product model.

Service Model - with the very limited use cases available in open source, any adopter of open source must "develop" their requirements through customizations, extensions and integration with other systems. To what extent this is required is dependent on the complexity of the use case. Support for the product falls into this category as well. Taking an average developer rate of $70 x 8 hrs x 5 days = $2800/week. There's always some level of Project Management that is required as well in contracting that is traditionally "billable".

Software Product Model - again, with the limited use cases available in open source, the contributors to the project can be directly contracted to develop features. The contributor will collect the requirement and develop the capability "direct" into the open source project and delivery it. Many of the "heavy" requirements are done in this mode.

The commitment from commercial vendors to the interoperability standards has arrived, so point #2 is becoming rather a mute point.

There's a saying that really suites the current scenario..."you get what you pay for". There's a stability, reliability, quality, performance, documentation, feature velocity and progression that are inherently required of all commercial products. If you spent money on it, you expect it to work well, fast and progress with future releases. Most customers also require a long term commitment and vision with the product that assures them that it is going in the direction that meets future needs as well.

There's also an economy of scale issue here. You can produce cartoon maps in a 'free' database today and it's only going to cost 15k for the services....great, but what about tomorrow and where will that implementation be in 2 years? Are you sure that open source project will be around in 5 years? Most open source projects are extremely "fragile" because they are "driven" by a small critical core of contributors that essentially 'manage' the project.

There's undoubtedly pushback to many open source projects in Enterprise deployments from IT. They are traditionally difficult to get "approved" by IT groups. IT likes to see proven, well established products that have references, case studies and a track record before they approve it themselves. They also require "accountability" and a formal channel for support and bug fixes. IT is a primary stakeholder and a huge contributor to the decision making process for enterprise software. This again leads us into the discussion of Brand Equity.

In the end, the decision is more than pure economics, it's about meeting the users needs (today and thinking about tomorrow), having confidence that the "product" will work and be there for you in the future.

ERDAS Videos

2008-05-23T12:50:00.000-07:00

Here is some great ERDAS videos (Thanks Erin!!)

Introducing the New ERDAS

ERDAS Product Demonstration: Part 1

ERDAS Product Demonstration: Part 2

Webinar

2008-05-23T10:26:00.000-07:00

Thanks to all who attended the ERDAS Image Manger Webinar "Fast: Catalog and Deliver Terrabytes of Imagery". I've had several requests for the Powerpoint Presentation. I've made it publicly available here:

FAST! Catalog and Deliver Terrabytes of Imagery Powerpoint

Here is the schedule of webinars that will be provided in the coming weeks:

Schedule of ERDAS Webinars

ERDAS Image Manager WCS

2008-05-18T16:18:00.000-07:00

I'd like to present the utility and feature "highlights" of the ERDAS Image Manager Web Coverage Service (WCS). For proper delivery to image exploitation clients, the Image Manager has the requirement to deliver the original pixel values and bit depth of gridded data to client applications for analysis. A WMS provides a "portrayed" map of the gridded data, so it effectively stylizes and delivers an "encoded" image focuses at a visualization experience for the user, so the pixel values are "changed", as well as the bit depth.

An example Image Analysts goal would be to "calculate NDVI for a user specified area".

The Lieca Image Manager functionally works just like a WMS, it has a "GETCAPABILITIES" request and it lists the aggregates of data based on the username/password that has requested the capabilities document. The difference is that for the GET requests, the WCS will deliver the raw pixels of the gridded data in the client specified encoding format.

For example, I can have modeled 50 LANDSAT image scenes with coverage over the southeast US into a single "South East US" aggregate and exposed as a single WCS layer. The aggregates extent will be the union of all the 50 LANDSAT scene extents. With the WCS, I can request any extent, spatial reference system, resolution, number of bands and encoding format for the aggregate. A sample use case would be to request the extent for Atlanta, GA in WGS84, bands 4,3 (for NDVI calculation), at 1:1 (full resolution) and in GeoTIFF format.

The WCS will perform "mosaic on the fly" for the extent requested, reproject the data if required and "encode" and deliver the data through the WCS! As a user, there is no need to have knowledge about the imagery that composes the aggregate and how the aggregate is composed, you simply only need to know where you want to create information products!

IMAGINE will manage the WCS just like any other image format supported, so the use of the WCS is "seamless" in the client. As a user, I simply have to go to the area and produce the NDVI product wherever and whenever I want. I don't have to know anything about the data, just where I want to product products.

So how is this benificial?

1. Increase productivity by centralizing and aggregating gridded data access through web services
2. Only provide imagery to people who have been given the rights to access the data (security!)
3. Streamline the workflow for generating data products that cover possibly many gridded datasets
4. Area based product production, rather than file based
5. Deliver pixels in any parameter combination (extent, SRS, resolution, format and band combination)
6. INTEROPERABLE!!!! Deliver pixels to any WCS client!

ERDAS Image Manager 1.0.1 Service Pack RELEASED!!!

2008-05-09T08:39:00.000-07:00

It's official! The ERDAS Image Manager 1.0.1 has been released! This Service Pack addresses several bugs as well as adds some minor feature enhancements to support ongoing project work. The EIM Demo Server has also been upgraded to this version to support our web service evaluations and support of our international sales teams.

Get your evaluation username/passwords today folks!!

ERDAS Image Manager Online DEMO Server

2008-05-04T15:17:00.001-07:00

We have officially brought online our public access demo server. The server will be hosted out of our US Corporate Headquarters in Norcross, GA.

Here's the link:

EIM Demo Server

The server has been globally tested by our channels and everything is working GREAT! We've successfully performed real world scenario demo's in England, Germany, Holland, Australia and India from the site.

Please request a username and password from me to gain evaluation access to the web services and mapping web client. We also will provide temporary data hosting for potential customer up to 1/2 Terrabyte for evaluation purposes, so lets coordinate and disseminate interoperably!

Look forward to your use!

ERDAS!!

2008-05-04T15:11:00.000-07:00

The Leica Image Manager will officially be renamed to the "ERDAS Image Manager"! Please visit our new website at www.erdas.com.

We will not "officially" rebrand the product face until version 2.0 in August, so the application home web page and Web Mapping Client provided out of the box will still contain the "Leica Image Manager" title.

I have "officially" renamed the blog today as well as the content to reflect the name change.

Here comes ERDAS my friends!!!!

Agile Software Devlopment Methodology - The Sprint

2008-03-28T19:38:00.000-07:00

I wanted to take the opportunity to talk about the benefit of sprints (or iterations) in the Agile Software Development Methodology...not from a developer perspective, but from a Product Management perspective. Our team sprints are 2 weeks. This means that we analyze the priority of features, estimate user stories based on their feature priority and task the team with two weeks worth of "work" to achieve a user experience by the end of the sprint.

The best feature that I like about sprint is the ability to "change gears" every two weeks! Any enterprise product needs the ability to support project work and meet high priority features for clients to "capture the sell". As the Product Manager, I'm the person with "boots on the ground". I get to talk directly with clients, sales teams and distributors to hear their requirements of the software. Although it's impossible to make every feature request a priority, it is within the methodology to change the priorities (every two weeks) to allow the software to demonstrate a feature that is a time critical request for a client.

There is a fine line that must be walked here...you don't want to impact the top priority features for a release, but there is plenty of room to achieve "quick wins" with existing large clients and prospective future clients.

The sprint allows me to reprioritize a "quick win" feature request to fit within the sprint and provide a thin line user experience to allow demonstration of the feature in 2 weeks.

Clients (and sales staff) really like to see their feature requests being demonstrated in two weeks! It demonstrates that we really develop the software for the client to meet their business needs and allows us to be "responsive" to cash flow potential. The interesting phenomena is that most of the time, the client is usually fine with the feature being "productized" and completed by the scheduled release date! By simply demonstrating that we are responsive to their needs shows a commitment to solving their business problems.

The sprint is also a great thermometer for measuring progress. At the end of every two weeks, I get to calculate the velocity of the team that accounts for the number of bugs resolved and the number of user stories estimated and completed in the sprint. It gives us a continuous monitor on our ability to estimate features, our ability to rapidly address bugs and the ability to complete user facing features. Analysis of velocity allows us to continuously evaluate the planned feature set for the release to effectively manage resources, money and time!

Brand Equity

2008-03-23T00:59:00.000-07:00

There are many open source and "small" software companies that provide OGC web services. I get asked a lot of questions about how our product "measures up" against many of them. 100% of the time, none of the open source or small software company offerings meet the requirements of the prospective client or provide a level of confidence that they will ever provide the capability.

Open source offerings are mainly pitched by services companies. These projects provide a lot of "opportunity" for services companies because they require so much customization to meet client needs. This customization provides the opportunity to become "locked in" long term to continue to provide "features" for clients. It's interesting how many service companies are also "technical advisors" for many government agencies, even very large ones.

Small software companies have "niche" market technologies. For instance, they provide web service layers on top of spatial feature database storage. I see success with feature editing through WFS-T for some small organizations. They usually have a very "narrow" feature set, but a market differentiating capability. Most are looking to be "gobbled" up (bought).

The problem for most open source or small company offerings is the inability to provide confidence or the ability to commit to the capablility of supporting the scale of implementations of large customers. They also fail to provide the support required of large production companies, the ability to commit to them.

All of the offerings fail to handle the quantity of data and the load required for large organizations in a production environment. They are currently filling "small" organization requirements, or are in large organizations at a small scale. Step up to 500TB and 1500 concurrent users!

For the Leica Image Manager, it's relatively easy to differentiate ourselves in that Leica is the market leader in imagery. There is no question that we dominate the imagery market, provide end to end imagery production and dissemination systems in large scale production environments. We write and manage gridded data accessors (we don't rely on open source for our imagery support or another company). We handle any type of gridded data that you may have (over 160 image formats supported by Leica software), any sensor model and any workflow. We have great BRAND EQUITY. This means a lot to an enterprise when they are going to invest into software. They trust that you have the capabilities to handle thier data, the quantity of data that they need to handle and the support that they will need. They also are confident that next year, the product will still be around, being improved with new features and be on the forefront of handling new sensors, formats and technologies that are occuring in the market. Never underestimate the power of the brand.

Technical Training

2008-03-13T22:35:00.001-07:00

Please excuse my tardy post...I have been extremely busy catching up on my Product Management duties since my trip to Atlanta for the Technical Training Week.

Leica Geosystems provides world class training for staff, distributors and business partners. There were two major tracts; Remote Sensing and Photogrammetry and Enterprise Products. The Leica Image Manager was a day and a half course with 60 attendees.

Course Agenda:

1. Intro to the Leica Image Manager
2. Pre-requisite setup, Installation and Configuration
3. Post Installation Tuning
4. Use Cases - Data Manager, Web Client, IMAGINE and "other" clients

The highlight is of course allowing all 60 users use the server simultaneously with any client! It's great to see the server perform so well, we could have handled many, many more usmosaicers!

We used IMAGINE (WMS, WCS Image Formats), ArcMap, UDIG, Open Layers, Gaia, UDig, ArcExplorer and more!

Here's some common misconceptions from the class that are important to point out:

Misconception 1: The Leica Image Manager is a tile server.

This is absolutely and unequivocally false! The Leica Image Manager does not "burn" tiles at any time for any purpose. We utilize the source imagery to produce portrayed maps on the fly! We'll read, mosaic, reproject and portray the data..."on the fly"!

Misconception 2: The Leica Image Manager takes a lot of Image Pre-processing

Again...false! There is no pre-processing required for your data. We support any number of bands, band combinations and pixel depth (true 16 bit). We utilize the data "early" in the image processing chain and can provide map quality imagery on demand.

Misconception 3: OGC Web Services are slow.

Again...unequivocally false! Our performance testing framework simulates a ramp up 50 users making simultaneous WMS requests (make another WMS request immediately after validating the WMS response) and averages 2 sec/request on a two core CPU server!!!! We really challenged the class to "load" the server in the class with 60 users and the server performed flawlessly. Thats with large map dimension requests and any client!

The class went good, I learned a lot in the other sessions and it was a great week.

Look forward to the Leica Image Manager Public Server to come on line early next week. Get ready to test the server yourself early next week from a public server. Get your username/password assigned request in today!!!!

Enterprise Software

2008-02-28T21:23:00.001-08:00

I hear the term "enterprise software" used extremely "loose" in the geospatial software market. Now to elude to the term not being used "correctly"...I'm forced to define "what is enterprise software".

Here is a stab at "enterprise software" on wikipedia. I love wikipedia, but that reading is "wikidiculous". "Enterprise Software" is not defined by "solving" an enterprise (entire business level) problem, that would allow almost any software be enterprise. All business units need to "compress" files to make them smaller for distributing them in e-mail...does that make WinZip an "enterprise software"?

There are lots of search engine permutations that you can attempt to find information on "enterprise", "enterprise computing", "enterprise requirements", "what is enterprise"...all leading to a dead end of NO DEFINITION. Its strange that we can probably name 5 enterprise class softwares off the top of our head (I would say Oracle, SAP, E-Bay, Google, and of course, the Leica Image Manager). What "separates" these softwares from the non enterprise class?

...lets start with defining "properties" of enterprise software so we can come up with a "Websters-like" Dictionary definition.

1. Collaborative - all enterprise softwares are multi-user by design. The architecture must support many concurrent user connections and the ability to process each individual users requested as a single transactional unit. This multi user ability allows the users as a whole to collaborate on a single system.

2. Security - all enterprise softwares have security, it is inherent in supporting many concurrent users. In general, if you don't log into it, it's probably not an enterprise software. We can argue public web services and their classification as "enterprise", but we'll get to that later.

3. Scalable - all enterprise system are scalable, meaning they have the ability to increase or decrease with the demand on the system. There are IT standards that define "scalability" as well. You probably hear the words real application clusters (RAC) or GRID or High Performance Computing (HPC). IT wants to use clearly defined and market accepted scalability techniques, meaning if you design your own "scalability", your trying to make something enterprise that is not meant to be.

4. Compatible - Enterprise systems must be compatible with many IT standards in today environments. Operating systems, databases, hardware configurations, virtualization, transport protocols (TCP, IPv6, etc), web protocols, etc., etc. They must also pass some criteria of being "modern" in terms of support development languages and customization techniques (nobody buys COBALT or COM solutions anymore). So enterprise system have an architecture that supports deployment on any type of "server".

5. Standards - Enterprise software must be build on standards, not only IT standards, but in the geospatial market, ISO interoperability standards and OGC application profile standards. It is these standards that standardize the data into something "usable" by other systems (not a stovepipe) and enable any business system who want to consume GI with standard interpretable services and data without the requirement to deploy massive SDK's and middleware.

So lets collate our findings:

Enterprise Software is secure and collaborative software, scalable with IT standard technologies, compatible with IT standard technologies.

A good exercise is to look at your software and see if it "fits" into this definintion!

Request Use Case Demonstrations!

2008-02-28T11:38:00.000-08:00

As a means of disseminating use cases and product demos, I will create flash videos of product demos on demand! Please just request the feature that you would like to see demonstrated, and I'll post a flash video of that feature at work!

I will additionally be posting common use cases of the product frequently, so visit often!

Introduction to the Leica Image Manager: the Business Problems...

2008-02-25T11:46:00.002-08:00

The Leica Image Manager is an Enterprise Class software developed to solve the business problems associated with managing massive volumes of Geospatial Information (GI); with and emphasis on imagery and terrain data.

If your a business that manages large amounts of imagery or terrain or have distributed offices and complex workflows for managing this data type, the Leica Image Manager has been built for you!

Before I explain the "features" of the product and how they work, I'd like to present the business problems that are addressed by the Leica Image Manager. A business problem in this presentation is defined as any situation that constrains a user or scenario that prevents a user from accomplishing their goal in a timely manner.

1. The Data (overwhelmed) - Gridded data sources have unique business problems inherit in the digital modeling and persistence this data type. First and foremost, the data is physically massive in size compared to traditional business data. An ADS40 sensor collects 1TB of data an hour (and thats just the raw data). This phenomena of the data creates large storage requirement and application throughput requirements. This "large data" phenomena puts a high load on the system for each constituent user added to the system. Secondly, the sheer number of imagery formats is high; each proprietary in nature. The user may not have access to a geospatial application that supports the format of imagery acquired or the ability to create the data format requested of a customer. Finally, imagery and terrain data is workflow or application specific requiring a "geospatial expert" to provide the domain knowledge to produce the requested end product or "setup" the user with the capability to produce the end product.

2. The Search (where) - The volume of images and terrain datasets is massive, causing the number of datasets to be very high. The number of imagery and terrain "files" that may cover a given area may be in the thousands...tens of thousands depending on the resolution. Additionally, the data may be spread throughout the organization in databases, storage area networks and other proprietary storage mechanisms. This prevents the end user from understanding what data exists and where the data exists, or have the means to determine which data is the "best" for what they want to accomplish. If users can't easily access the data, they simply won't use it.

3. Lack of Interoperability (can't) - The proprietary and application specific nature of GI has limited the ability of organizations to share data internally and externally. This inability to share forces time consuming processes to convert data into "formats" usable by the customer. This barrier has prevented the free flowing of data throughout the business and external to customers and has "isolated" GI to a boutique skill, rather than readily accessible, easy to use and easy to integrate business data.

4. Security - although geospatial data is business critical data for most enterprises, there is an inherit lack of a standard security model in it's access and distribution. This is more apparent as the number of data sources increase and volume of data increases. The ability to secure the data becomes extremely complex just in terms of traditional data access security. This is further complicated with a requirement to extend security with spatial security features (user 1 can only see this area, or can not see this area).

5. Domain Knowledge - The requirement for some level of domain knowledge to exploit GI is required in todays application specific workflows of GI. Most organizations have some in-house GIS or Remote Sensing Department or user group. These geospatial professionals are the proxy to request and receive meaningful GI. Understanding geospatial principles should NOT be a requirement to using a GI as a business critical data product.

All of the problems stated above prohibit the GI from being a traditional business data source, free flowing throughout the enterprise, easily integrated into business logic applications and securely accessed by the business and the customers.

Welcome to the next generation of Enterprise Geospatial products.

Find, Describe, Catalog, Discover, Exploit Geospatial Information (GI)

Welcome!!!

2008-02-25T11:22:00.000-08:00

Welcome to my Leica Image Manager Product blog!

With the release of the Leica Image Manager 1.0 last week came a deluge of information requests about the product. What is it? How does it work? What data? How much?...

Rather than handle this on a case by case basis, I will be posting product information to this blog. It will serve as an official location for "authoritative" information on the product and a way for the community to contact me directly with questions about the product.

So welcome to my blog and introduce yourself to the Leica Image Manager!