Re: character encoding problems

[Ziegler Stefan]

Some javascript/style in this post has been disabled (why?)

Hi Mauricio

> Hi I was testing cql and filter, they look right. What store
> are you using?
> shape file?

No, wfs datastore. When I print the filter in the command line the special characters are still there. The problem is when I'm requesting the features from GeoServer. Have to check Geoserver's logfile but I think the special character is replaced with some nonsense character and therefore Geoserver doesn't find and return the feature.

regards
Stefan

>
> cheers
>
> --
> Mauricio Pazos
> www.axios.es
>

------------------------------------------------------------------------------

_______________________________________________
Geotools-gt2-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users

[Mauricio Pazos]

On Friday 03 July 2009 03:52:22 pm Ziegler Stefan wrote:
> No, wfs datastore. When I print the filter in the command line the
> special characters are still there. The problem is when I'm requesting
> the features from GeoServer. Have to check Geoserver's logfile but I
> think the special character is replaced with some nonsense character and
> therefore Geoserver doesn't find and return the feature.
I was testing with a shape file and I could reproduce the reported problem:
"nonsense character "

Testing details:
shape file: cities.shp
I replaced in the feature cities.1 the ADMIN_NAME by the value string "üä".
I wrote the following sentence to retrieve the features

        Filter filter = CQL.toFilter("ADMIN_NAME LIKE'%üä%'");
        // I try too : Filter filter = CQL.toFilter("ADMIN_NAME = 'üä'");
        FeatureCollection<SimpleFeatureType, SimpleFeature> collection =
                    featureSource.getFeatures(filter );
It result in empty collection.

Debugging I found that ShapefileDataStore sets the charset ISO-8859-1 (it is
correct to read your characters).
But when the FeatureReaderIterator.hasNext is executed it return false,
because the FilteringFeatureReader gets a feature with ADMIN_NAME equal to
"üä" so the filter evaluation is False.

I guess geoserver is ok and there is a bug in Geotools data store (I suppose
that your Geoserver is publishing shp ).
 
Maybe, the module maintainers could said more about.

cheers
>
> regards
> Stefan

--
Mauricio Pazos
www.axios.es


------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize
details at: http://p.sf.net/sfu/blackberry
_______________________________________________
Geotools-gt2-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users

[aaime]

Mauricio Pazos ha scritto:

> On Friday 03 July 2009 03:52:22 pm Ziegler Stefan wrote:
>> No, wfs datastore. When I print the filter in the command line the
>> special characters are still there. The problem is when I'm requesting
>> the features from GeoServer. Have to check Geoserver's logfile but I
>> think the special character is replaced with some nonsense character and
>> therefore Geoserver doesn't find and return the feature.
> I was testing with a shape file and I could reproduce the reported problem:
> "nonsense character "
>
> Testing details:
> shape file: cities.shp
> I replaced in the feature cities.1 the ADMIN_NAME by the value string "üä".
> I wrote the following sentence to retrieve the features
>
>         Filter filter = CQL.toFilter("ADMIN_NAME LIKE'%üä%'");
>         // I try too : Filter filter = CQL.toFilter("ADMIN_NAME = 'üä'");
>         FeatureCollection<SimpleFeatureType, SimpleFeature> collection =
>                     featureSource.getFeatures(filter );
> It result in empty collection.
>
> Debugging I found that ShapefileDataStore sets the charset ISO-8859-1 (it is
> correct to read your characters).
> But when the FeatureReaderIterator.hasNext is executed it return false,
> because the FilteringFeatureReader gets a feature with ADMIN_NAME equal to
> "üä" so the filter evaluation is False.
>
> I guess geoserver is ok and there is a bug in Geotools data store (I suppose
> that your Geoserver is publishing shp ).
>  
> Maybe, the module maintainers could said more about.

That would be me. DBF is stuck by spec on ISO-8859-1 as far as I know.
However, many implementations coaxed different charsets on top of that
scheme, but there is no marker of what the charset in the DBF will be,
so ISO-8859-1 is the default, and the datastore takes an extra param
in which you can specify in which charset the DBF has really been
encoded.
There are tests in the shapefile datastore suite that do check the
ability to read european, arab and chinese characters.

So I guess you just have to figure out which charset your DBF
is really written into and pass the param to the store on creation.

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
Geotools-gt2-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users