[Geoserver-users] Weird problem

All,

I have a dataset on geoserver where I make queries with filters, like this:

<PropertyIsEqualTo><PropertyName>mlra_id</PropertyName><Literal>81D</Literal

</PropertyIsEqualTo>

My problem is that it doesn't work when the value ends with a 'D', like
above: '81D'
It works for 'A','B','C' but not 'D'....not '81D' or '83D' or '58D' etc

My guess is that it is a character encoding problem, about which I know next
to nothing. Datastore is postGIS; geoserver 1.4.0.

Any ideas?

Thanks again,
Steve

Stephen Crawford
Center for Environmental Informatics
The Pennsylvania State University

Stephen Crawford ha scritto:

All,

I have a dataset on geoserver where I make queries with filters, like this:

<PropertyIsEqualTo><PropertyName>mlra_id</PropertyName><Literal>81D</Literal

</PropertyIsEqualTo>

My problem is that it doesn't work when the value ends with a 'D', like
above: '81D'
It works for 'A','B','C' but not 'D'....not '81D' or '83D' or '58D' etc

My guess is that it is a character encoding problem, about which I know next
to nothing. Datastore is postGIS; geoserver 1.4.0.

Any ideas?

Hmmm... first of all, try to up your logging level to FINE or FINER
in the GeoServer section of the configuration and try to see if you
get the query in the logs, that might help.

Also, you should try upgrading GeoServer, 1.4.0 is really old :slight_smile:

Cheers
Andrea

You know what it may be? The guessing of literals starting with the first guess being numbers. The D probably makes it think it's a number.

C

Andrea Aime wrote:

Stephen Crawford ha scritto:

All,

I have a dataset on geoserver where I make queries with filters, like this:

<PropertyIsEqualTo><PropertyName>mlra_id</PropertyName><Literal>81D</Literal

</PropertyIsEqualTo>

My problem is that it doesn't work when the value ends with a 'D', like
above: '81D'
It works for 'A','B','C' but not 'D'....not '81D' or '83D' or '58D' etc

My guess is that it is a character encoding problem, about which I know next
to nothing. Datastore is postGIS; geoserver 1.4.0.

Any ideas?

Hmmm... first of all, try to up your logging level to FINE or FINER
in the GeoServer section of the configuration and try to see if you
get the query in the logs, that might help.

Also, you should try upgrading GeoServer, 1.4.0 is really old :slight_smile:

Cheers
Andrea

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

!DSPAM:4005,46b8d394284941439371379!

Chris Holmes ha scritto:

You know what it may be? The guessing of literals starting with the first guess being numbers. The D probably makes it think it's a number.

Aahh right, I forgot about this one. Yes, it may well be it.
And we have a solution for this illness too, but only from GeoServer 1.6.0 onwards. So I'd suggest you try out 1.6.0beta2.
The changes needed to avoid this issue are so extensive there is
no way they are going to be ported back to 1.5.x.

Cheers
Andrea

Why do A,B,C, and E work but not D?

Also, is there any time frame on when 1.6 will be officially released? My
1.4 is used in production, and I'm hoping to wait until 1.6 to make the
move.....this 'D' problem just adds to it, but there are some projections in
geotools that I really want (NEED!) to use for a couple projects.

Thanks,
Steve

-----Original Message-----
From: Andrea Aime [mailto:aaime@anonymised.com]
Sent: Wednesday, August 08, 2007 2:28 AM
To: Chris Holmes
Cc: Stephen Crawford; geoserver-users@lists.sourceforge.net
Subject: Re: [Geoserver-users] Weird problem

Chris Holmes ha scritto:

You know what it may be? The guessing of literals starting with the
first guess being numbers. The D probably makes it think it's a number.

Aahh right, I forgot about this one. Yes, it may well be it.
And we have a solution for this illness too, but only from GeoServer 1.6.0
onwards. So I'd suggest you try out 1.6.0beta2.
The changes needed to avoid this issue are so extensive there is no way they
are going to be ported back to 1.5.x.

Cheers
Andrea

Stephen Crawford ha scritto:

Why do A,B,C, and E work but not D?

Frankly I have no idea... the problem would not occur if your
codes started with a letter (to make a number interpretation impossible).
Anyways, have you tried increasing the Geoserver logging
and see what's the query that's being sent to the server?

Also, is there any time frame on when 1.6 will be officially released?

For sure in time for FOSS4G 2007, but I cannot be more specific.

Cheers
Andrea

With the loggin set to fine it shows that does indeed treat it as a number
when it ends in D:

Select .......where mlra_id = '83.0'

Other than D, it's workd fine:

Select..... Where mlra_id = '83C'

Does the 'D' somehow add a decimal? The field is defined as a char is the
db, and as a string in GS, doesn't that matter?

Thanks again,
Steve

-----Original Message-----
From: Andrea Aime [mailto:aaime@anonymised.com]
Sent: Wednesday, August 08, 2007 9:44 AM
To: Stephen Crawford
Cc: 'Chris Holmes'; geoserver-users@lists.sourceforge.net
Subject: Re: [Geoserver-users] Weird problem

Stephen Crawford ha scritto:

Why do A,B,C, and E work but not D?

Frankly I have no idea... the problem would not occur if your codes started
with a letter (to make a number interpretation impossible).
Anyways, have you tried increasing the Geoserver logging and see what's the
query that's being sent to the server?

Also, is there any time frame on when 1.6 will be officially released?

For sure in time for FOSS4G 2007, but I cannot be more specific.

Cheers
Andrea

Hi,

don't know if this helps, but

double d = 1D;

is valid syntax in Java.

(But I haven't looked up the geoserver code.)

Cheers,

Ugo

Stephen Crawford wrote:

With the loggin set to fine it shows that does indeed treat it as a number
when it ends in D:

Select .......where mlra_id = '83.0'

Other than D, it's workd fine:

Select..... Where mlra_id = '83C'

Does the 'D' somehow add a decimal? The field is defined as a char is the
db, and as a string in GS, doesn't that matter?

Thanks again,
Steve

-----Original Message-----
From: Andrea Aime [mailto:aaime@anonymised.com] Sent: Wednesday, August 08, 2007 9:44 AM
To: Stephen Crawford
Cc: 'Chris Holmes'; geoserver-users@lists.sourceforge.net
Subject: Re: [Geoserver-users] Weird problem

Stephen Crawford ha scritto:

Why do A,B,C, and E work but not D?

Frankly I have no idea... the problem would not occur if your codes started
with a letter (to make a number interpretation impossible).
Anyways, have you tried increasing the Geoserver logging and see what's the
query that's being sent to the server?

Also, is there any time frame on when 1.6 will be officially released?

For sure in time for FOSS4G 2007, but I cannot be more specific.

Cheers
Andrea

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

--
Ugo Taddei

Fraunhofer Institut Intelligente Analyse- und Informationssysteme (FhG IAIS)
http://www.iais.fraunhofer.de
Department Knowledge Discovery - IAIS.KD -
Working Group Spatial Decision Support
http://www.iais.fraunhofer.de/kd.html
phone (+49)2241-14-2184 fax (+49)2241-14-2072
Schloss Birlinghoven, D-53754 Sankt Augustin, Germany
------------------------------------------------------
Visit our thematic mapping tool CommonGIS: http://www.commongis.de

Stephen Crawford ha scritto:

With the loggin set to fine it shows that does indeed treat it as a number
when it ends in D:

Select .......where mlra_id = '83.0'

Other than D, it's workd fine:

Select..... Where mlra_id = '83C'

Does the 'D' somehow add a decimal? The field is defined as a char is the
db, and as a string in GS, doesn't that matter?

Only in Geoserver 1.6.0 onwards.
Before filters were parsed without any knowledge of the attribute type,
and a progressive parsing algorithm was used, that is, try to parse it
as a number, then as a date, and so on, if everything else fails, then
treat it as a string. In your case unfortunately the number parsing succeeded.

In 1.6.0 onwards, the literal is kept as a string, and when it's time
to encode the actual sql, the encoder asks the literal class to
return the value as a String, or as an Integer, or as a Double,
according to the type of the attribute being compared.

Cheers
Andrea

Which is to say, Stephen, if you upgrade to 1.6.0-beta2 there's a decent chance this may work. If it doesn't with WFS 1.0 try with WFS 1.1, as it has a completely new parsing system.

Chris

Andrea Aime wrote:

Stephen Crawford ha scritto:

With the loggin set to fine it shows that does indeed treat it as a number
when it ends in D:

Select .......where mlra_id = '83.0'

Other than D, it's workd fine:

Select..... Where mlra_id = '83C'

Does the 'D' somehow add a decimal? The field is defined as a char is the
db, and as a string in GS, doesn't that matter?

Only in Geoserver 1.6.0 onwards.
Before filters were parsed without any knowledge of the attribute type,
and a progressive parsing algorithm was used, that is, try to parse it
as a number, then as a date, and so on, if everything else fails, then
treat it as a string. In your case unfortunately the number parsing succeeded.

In 1.6.0 onwards, the literal is kept as a string, and when it's time
to encode the actual sql, the encoder asks the literal class to
return the value as a String, or as an Integer, or as a Double,
according to the type of the attribute being compared.

Cheers
Andrea

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

!DSPAM:4005,46b9d67b103291096210785!