Hi, I think that the real trouble is that with certain database and client settings the numerical data that is stored into Oracle is not interpreted correctly and correct place to fix the issue is somewhere very close to Oracle. Not in making GML parser to accept commas or to make WFS string comparisons to work correctly with numerical data in Oracle.
GDAL had similar troubles for sure with Finnish, Italian and French locales and probably with all the other locales using comma as decimal separator as well. In practice it meant for me that GDAL truncated decimal numbers "1234,56" at comma "1234". For many years I used some workarounds but after this GDAL fix it has not been necessary any more: http://trac.osgeo.org/gdal/ticket/5709 I suggest to study the patch "'OCI: force NLS_NUMERIC_CHARACTERS to ". " (patch by giorgiomugnaini, #5709)'" and consider if it could be applied to the native Oracle driver in Mapserver. I guess and hope that Mapserver would recognize the datatype correctly if the Oracle layer is configured to read Oracle through CONNECTIONTYPE OGR and GDAL 2.0 is in use. Perhaps setting environment "ALTER SESSION SET NLS_NUMERIC_CHARACTERS = '. '" locally before starting Mapserver would be enough but I do not know how and where to set it. -Jukka Rahkonen- Steve.Toutant wrote: Is there a documentation that says that it is not? Folks from gdal list also think that it is not supported...I guess you are right. But as I said on the gdal list, many countries are using a comma as a decimal separator....what other people on the planet do? Anyway the comma is another problem that I try to manage later...... For now, We have an application that generate and launch spatial queries on WFS, matchCase=false by default. Before modifying the code I want to understand what is going on.... It seems,when using numeric value, that matchCase as no impact in PostGIS, but it is important in oracle to be set to true gml_type = auto, returns double in postgis and oracle, so that is fine A WFS getFeature with the operator PropertyIsEqualTo AND matchCase=false using this value -64.225 PostGis: it works Oracle (from mike's test): it fails...matchCase must be set to true A WFS getFeature with the operator PropertyIsEqualTo AND matchCase=false using this value -64,225 PotsGis: not tested Oracle: it fails...matchCase must be set to true Is there a reason why, with oracle, matchCase should be set to true when using numeric value, or that could be fixed? Regards Steve
_______________________________________________ mapserver-users mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/mapserver-users
