[JPP-Devel] Plug-In Reporting of Bad Features
Back on November 5, 2009 Nacho let us know about a problem with the UnionByAttribute plug-in. It was throwing an exception with Nacho's data. I couldn't help Nacho track down the problem because the exception didn't tell us what feature was causing the exception. I told him I would see about giving the plug-in the ability to report the bad feature to assist with troubleshooting. That was the first item on my todo list for work in preparation of the next OpenJUMP release. I'm starting to work on those tasks this week. It seems like it would be helpful to have a standard way for plug-ins that operate on features or feature geometry to report the bad features that cause problems, especially those that result in exceptions that kill plug-in execution. I need to add this functionality to the UnionByAttribute plug-in, so I wanted to (1) see if we have an existing way to do this, and (2) propose a standard way for plug-in developers to do this that we could discuss a group if no solution exists. Let me know if you have already implemented a standard way of reporting bad feature data in your own plug-ins that I can imitate. I attached an interface for a BadFeatureDataReporter. It has one important method that allows the plug-in to submit a list of bad features. We could implement this interface with a reporter that wrote out the bad feature to a default shapefile (or at least the feature geometry to a well known text file) and then uses the workbench to warn the user that there was a problem. We could then make the default reporter available through the plug-in context or maybe the Registry. I'm thinking if I find a bad feature when processing data in the UnionByAttribute plug-in that I should skip it and continue processing after reporting. That seems a little more robust than ignoring the rest of the selection after the bad feature is encountered. Thanks for any feedback. The Sunburned Surveyor BadFeatureDataReporter.java Description: Binary data -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] Plug-In Reporting of Bad Features
Hi ss Are we certain that the problem was caused by bad features? If so QC would find them. Larry On Jul 12, 2010 12:54 PM, Sunburned Surveyor sunburned.surve...@gmail.com wrote: Back on November 5, 2009 Nacho let us know about a problem with the UnionByAttribute plug-in. It was throwing an exception with Nacho's data. I couldn't help Nacho track down the problem because the exception didn't tell us what feature was causing the exception. I told him I would see about giving the plug-in the ability to report the bad feature to assist with troubleshooting. That was the first item on my todo list for work in preparation of the next OpenJUMP release. I'm starting to work on those tasks this week. It seems like it would be helpful to have a standard way for plug-ins that operate on features or feature geometry to report the bad features that cause problems, especially those that result in exceptions that kill plug-in execution. I need to add this functionality to the UnionByAttribute plug-in, so I wanted to (1) see if we have an existing way to do this, and (2) propose a standard way for plug-in developers to do this that we could discuss a group if no solution exists. Let me know if you have already implemented a standard way of reporting bad feature data in your own plug-ins that I can imitate. I attached an interface for a BadFeatureDataReporter. It has one important method that allows the plug-in to submit a list of bad features. We could implement this interface with a reporter that wrote out the bad feature to a default shapefile (or at least the feature geometry to a well known text file) and then uses the workbench to warn the user that there was a problem. We could then make the default reporter available through the plug-in context or maybe the Registry. I'm thinking if I find a bad feature when processing data in the UnionByAttribute plug-in that I should skip it and continue processing after reporting. That seems a little more robust than ignoring the rest of the selection after the bad feature is encountered. Thanks for any feedback. The Sunburned Surveyor -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] Plug-In Reporting of Bad Features
Not absolutely sure. I can dredge up the exception trace that Nacho posted from my e-mail archives. If I remember correctly, Nacho and I couldn't identify the exact cause of the exception because we couldn't identify which feature in the layer he was operating on was throwing the exception. I don't know if I can fix the underlying problem with Nacho's data, but I was hoping I could help him and other users at least figure out which data was causing the plug-in to choke. After I thought about my idea a little more today, I realized it might be better to create a new working layer with the features causing the problem instead of writing them out to a file. I also think incompatible features may be a better term than bad feature data. A feature may work perfectly fine in one plug-in, but not another. My basic proposal is for a standard way to improve the feedback to users when a plug-in fails to operate because of bad data. Even if we don't implement something like that, I should sitll see if I can get the UnionByAttribute plug-in to skip incompatible features and continue processing. Let me know if you have furhter thoughts after I post the exception trace, Larry. The Sunburned Surveyor On Mon, Jul 12, 2010 at 3:41 PM, Larry Becker becker.la...@gmail.com wrote: Hi ss Are we certain that the problem was caused by bad features? If so QC would find them. Larry On Jul 12, 2010 12:54 PM, Sunburned Surveyor sunburned.surve...@gmail.com wrote: Back on November 5, 2009 Nacho let us know about a problem with the UnionByAttribute plug-in. It was throwing an exception with Nacho's data. I couldn't help Nacho track down the problem because the exception didn't tell us what feature was causing the exception. I told him I would see about giving the plug-in the ability to report the bad feature to assist with troubleshooting. That was the first item on my todo list for work in preparation of the next OpenJUMP release. I'm starting to work on those tasks this week. It seems like it would be helpful to have a standard way for plug-ins that operate on features or feature geometry to report the bad features that cause problems, especially those that result in exceptions that kill plug-in execution. I need to add this functionality to the UnionByAttribute plug-in, so I wanted to (1) see if we have an existing way to do this, and (2) propose a standard way for plug-in developers to do this that we could discuss a group if no solution exists. Let me know if you have already implemented a standard way of reporting bad feature data in your own plug-ins that I can imitate. I attached an interface for a BadFeatureDataReporter. It has one important method that allows the plug-in to submit a list of bad features. We could implement this interface with a reporter that wrote out the bad feature to a default shapefile (or at least the feature geometry to a well known text file) and then uses the workbench to warn the user that there was a problem. We could then make the default reporter available through the plug-in context or maybe the Registry. I'm thinking if I find a bad feature when processing data in the UnionByAttribute plug-in that I should skip it and continue processing after reporting. That seems a little more robust than ignoring the rest of the selection after the bad feature is encountered. Thanks for any feedback. The Sunburned Surveyor -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
