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.
Thursday, October 15, 2009
Wednesday, October 14, 2009
ESRI Bails on FOSS4G Performance Shootout
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...
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...
Sunday, October 11, 2009
Open Source Doesn't like to be talked about :)
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".
If anybody is interested in what "FUD" means, it's an acronym for "Fear, Uncertainty and Doubt".
Thursday, October 8, 2009
WorldView II Successfully Launched!!
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!
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!
Friday, September 18, 2009
Geospatial Performance Benchmarks "Apples to Apples"
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!!
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!!
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!!
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!!
Saturday, August 15, 2009
Maintaining a Schedule with an Agile Software Development Methodology
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!
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!
Friday, August 14, 2009
ERDAS APOLLO 2010 OGC Web Processing Service (WPS)
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 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!
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
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!
Wednesday, June 3, 2009
Get a Preview of What ERDAS Is Working On For the Next Release!!
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!
Subscribe to:
Posts (Atom)
