FilterExtension do NOT work properly when filter attributes with double type. I think it can be related with rounding decimals. Steps to get that error: 1.- Open Shapefile attached 2.- Lauch Filter extension 3.- Type FTUFA = 1.02159 4.- Press "New selection" 5.- None is selected (Attached a screenshot and zip with a shp) Related tickets: https://forge.osor.eu/tracker/?func=detail&group_id=89&aid=12217&atid=732 https://forge.osor.eu/tracker/?func=detail&group_id=89&aid=11665&atid=732
| OperatingSystem | None |
| Resolution | Fixed |
| Severity | major |
| SubprojectName | None |
| Component | None |
| Version | gvSIG - 1.11.0 |
| SubprojectVersion | None |
| SubprojectResolveVersion | gvSIG - 1.12.0 |
| Has patch | Yes |
Category
Bugs
Login or create an account to comment.
Comments
I think it is possible to reduce the number of cases where this problem happens, but maybe it will not be possible to remove it completely. If the operator is "=" with a DOUBLE or FLOAT field, then a warning message should appear saying that internal rounding problems can affect the result. I am now trying to fix it.
Thanks Juan Lucas! When you fix it, please indicate the commit number on the bug close message. I would like to learn how to solve that problem.
Me lo he asignado en el ámbito del proyecto EIEL-Pontevedra, cuyas aportaciones (corregir bugs y añadir alguna funcionalidad) esperamos que queden consolidadas en gvSIG 1.12 o posterior.
Hello, the problem is that literals are instantiated as "FloatValue" which has a limited precision. If we use "DoubleValue" the precison increases and this error will not happen in most cases, but I don't think it is possible to correct it completely because the user can input endless decimals... Look for the string "case SQLEngineConstants.FLOATING_POINT_LITERAL" in ValueFactory.java and you'll see it. Instead of "new FloatValue", I have used "new DoubleValue" and it works with your example. I will commit the change when we are not in stabilization period.
I've tested with no success on build 1302 on gvSIG-1.11.0. Is that patch included on that version?
Adjunto patch_err_decimal.zip
Applied path, using Double parser. svn: trunk [gvsig 35774]
I close the bug following the rules of this guide [1]. Once the patch is commited the state of the bug should be changed to closed, the resolution to fixed and the subprojectResolveVersion updated. I checked this with a postgis database and it works. [1] http://www.gvsig.org/web/projects/gvsig-desktop/docs/devel/guia-para-com...