Okay, I added the "NONE" projection (or just dont mention a SRS in your
WMS request). No reprojection will be done, so it should work the same
as it did before.
dave
----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/
Okay, I added the "NONE" projection (or just dont mention a SRS in your
WMS request). No reprojection will be done, so it should work the same
as it did before.
dave
Many thanks, Dave, that is exactly what I need 
Now images are
rendered almost the same way as before. I say "almost" because I
noticed a very strange thing related, most probably, to styling.
I have two idenatical data sets (and two map layers/feature types)
there, one in shape file, and another one in PostGIS (the later was
created by converting the above shape file using shp2pgsql utility).
The weird stuff is that these two layers are rendered somewhat
different now (in GeoServer 1.2.4 they were pretty identical). The
difference is in the way polygons are filled (of course, I apply
the same style to both layers).
There is a pucture attached to illustrate the above text
(style_diff.gif).
Well, after setting logging level to FINEST and examining the logs
I found that features obatained from PostGIS datastore have strange
values in the 'code' attribute. And as I am choosing fill color for
polygons depending on the value of this attribute, no wonder that my
rules doesn't apply properly. The range of 'code' attribute values is
from 1 to 6. I looked at the corresponding PostgreSQL table manually
in PgAdmin III and all data seems to be correct (see pg_admin.gif).
I also assembled and attached a text file with a few corresponding log
fragments. They describe the process of rendering 2nd and 3rd features
taken from shape file and PostGIS. Closer examination of these
fragments (and optionally pg_admin.gif image) shows that there is some
"shift" in the attribute values in case of PostGIS, i.e. value for
'code' attribute is somehow taken from 'city_id' table column, value
for 'city_id' is taken from 'city_' etc. 'area' attribute seem to have
fixed value '2.0' for all features. Doesn't really know why this happens
I am not sure whether to put this on the task tracker, and on which
one exactly - geotools or geoserver?
P.S. Forgot to mention, I use GeoServer trunk revision 3455,
PostgreSQL 8.0.0 with PostGIS 0.9.1 on jsdk 1.5.0_01.
--
WBR,
Artie
log_fragment.txt (10.5 KB)
Artie Konin wrote:
different now (in GeoServer 1.2.4 they were pretty identical). The
difference is in the way polygons are filled (of course, I apply
the same style to both layers).There is a pucture attached to illustrate the above text
(style_diff.gif).
I may guess at the answer, the Filter parsing code tends to 'try' to parse anything it can as a number. I suspect that your 'code' is
trying to be compare a number with a string for equality.
This is a known, if annoying problem, that I made an effort of at fixing
for the xml parser. Geotools has several SLD parsers a JDOM based one and a one based on the geotools xml framework used for GML.
We do need to make the Filter evaulation code a bit less type aware (as the specification did not seem to distingish between "2.0", "2", 2.0 (double), or 2 (integer).
That said I am *not* sure how we can make the SQL generated by PostGIS not care about the above differences? Fortuantly we have Dave on hand to tell us how it is done.
Jody
I may guess at the answer, the Filter parsing code tends to 'try' to parse anything it can as a number. I suspect that your 'code' is
trying to be compare a number with a string for equality.
This is a known, if annoying problem, that I made an effort of at fixing
for the xml parser.
I guess you mean org.geotools.filter.ExpressionSAXParser::message(String)?
If so, yeah, this is an old bug I came around by just avoiding trying to guess the literal type and passing the plain string. This is done for a project I'm working on and is in a gt2.0 version I retrofited to work on JDK 1.3
for instance, in the above mentioned method:
if (curExprssn instanceof AttributeExpression) {
...
} else if (curExprssn instanceof LiteralExpression) {
((LiteralExpression) curExprssn).setLiteral(message);
}
/* It was:
try {
Object temp = new Integer(message);
((LiteralExpression) curExprssn).setLiteral(temp);
currentState = "complete";
} catch (NumberFormatException nfe1) {
try {
Object temp = new Double(message);
((LiteralExpression) curExprssn).setLiteral(temp);
currentState = "complete";
} catch (NumberFormatException nfe2) {
Object temp = message;
((LiteralExpression) curExprssn).setLiteral(temp);
currentState = "complete";
}
}*/
I guess this is the right way since once the expression is evaluated it would be the responsability of AttributeType.parse to get the
actual literal instance.
May be you can just try this modification and got it solved.
Best regards,
Gabriel.
Greetings, Gabriel,
Ok, I'll try to make this change as soon as I get my hands on latest
geotools sources. But I really can't get how this simple
type-detection algorithm can lead to attribute values "shifting".
Here are two lines of interest from previously posted text-file (it
is somewhat large so I choose to send it as attachment):
101656 [FINEST] org.geotools.renderer.lite.LiteRenderer2 - ... done:
Feature[ id=t_plan_shp.2 , CODE=2 , the_geom=MULTIPOLYGON (((-41355708
-135367696, -41473280 -135213408, -41758912 -135070864, -41814588
-134997808, -41473028 -134738576, -40920272 -135035888, -41355708
-135367696))) , AREA=2.718921E11 , PERIMETER=2208942.0 , CITY_=3 , CITY_ID=374 ]
and
186547 [FINEST] org.geotools.renderer.lite.LiteRenderer2 - ... done:
Feature[ id=t_plan.1 , area=2.0 , perimeter=2.718921E11 , city_=2208942 ,
city_id=3 , code=374 , the_geom=MULTIPOLYGON (((-41355708 -135367696,
-41473280 -135213408, -41758912 -135070864, -41814588 -134997808, -41473028
-134738576, -40920272 -135035888, -41355708 -135367696))) ]
First "line" is part of rendering feature #2 from shape-file, second -
the same feature from PostGIS.
Stripped and compiled into table that will look like this:
area perimeter city_ city_id code
shp | 2.718921E11 | 2208942.0 | 3 | 374 | 2 |
postgis | 2.0 | 2.718921E11 | 2208942 | 3 | 374 |
So in the second case there is no single correct attribute value,
(they are shifted one position to the right) though when I look at the
PostgreSQL table itself all values are in place.
I also should note that layers, which have textual attributes does
not render at all, leaving following log trace for each feature:
6069484 [SEVERE] org.geotools.renderer.lite.LiteRenderer2$DefaultRenderListener
- expected java.lang.Double , but got java.lang.String
Most probably this is caused by the same displacement of attribute
columns. All this looks somewhat strange
But I still try to make the changes you advised and then tell the
results.
WBR,
Artie
I may guess at the answer, the Filter parsing code tends to 'try' to
parse anything it can as a number. I suspect that your 'code' is
trying to be compare a number with a string for equality.
This is a known, if annoying problem, that I made an effort of at fixing
for the xml parser.
I guess you mean
org.geotools.filter.ExpressionSAXParser::message(String)?
If so, yeah, this is an old bug I came around by just avoiding trying to
guess the literal type and passing the plain string. This is done for a
project I'm working on and is in a gt2.0 version I retrofited to work on
JDK 1.3
for instance, in the above mentioned method:
if (curExprssn instanceof AttributeExpression) {
...
} else if (curExprssn instanceof LiteralExpression) {
((LiteralExpression) curExprssn).setLiteral(message);
}
/* It was:
try {
Object temp = new Integer(message);
((LiteralExpression) curExprssn).setLiteral(temp);
currentState = "complete";
} catch (NumberFormatException nfe1) {
try {
Object temp = new Double(message);
((LiteralExpression) curExprssn).setLiteral(temp);
currentState = "complete";
} catch (NumberFormatException nfe2) {
Object temp = message;
((LiteralExpression) curExprssn).setLiteral(temp);
currentState = "complete";
}
}*/
I guess this is the right way since once the expression is evaluated it
would be the responsability of AttributeType.parse to get the
actual literal instance.
May be you can just try this modification and got it solved.
Best regards,
Gabriel.
Hi Artie,
could you send the SLD document you're working against?
Are you styling by one of this attributes?
So, if those are supposed to be the same feature, one from shp and the other fom pg, the first thing to should be seeing why the attribute values got messed up(?)
regarding the patch I comented, my problem was different but may be related, I was filtering by a char field with building number. Some of them are like ' 002 ' and others have letters too, like ' 002A'. In this later case the expression parser was interpreting it as an hexadecimal and messing up the filter. This get solved by passing the plain literal and letting the feature type get the correct instance type at a later instance.
Bu I don't fairly understand what your problem is. Please send the SLD and confirm this two features should have the same attribute values.
cheers,
Gabriel.
Artie Konin wrote:
Greetings, Gabriel,
Ok, I'll try to make this change as soon as I get my hands on latest
geotools sources. But I really can't get how this simple
type-detection algorithm can lead to attribute values "shifting".
Here are two lines of interest from previously posted text-file (it
is somewhat large so I choose to send it as attachment):101656 [FINEST] org.geotools.renderer.lite.LiteRenderer2 - ... done:
Feature[ id=t_plan_shp.2 , CODE=2 , the_geom=MULTIPOLYGON (((-41355708
-135367696, -41473280 -135213408, -41758912 -135070864, -41814588
-134997808, -41473028 -134738576, -40920272 -135035888, -41355708
-135367696))) , AREA=2.718921E11 , PERIMETER=2208942.0 , CITY_=3 , CITY_ID=374 ]and
186547 [FINEST] org.geotools.renderer.lite.LiteRenderer2 - ... done:
Feature[ id=t_plan.1 , area=2.0 , perimeter=2.718921E11 , city_=2208942 ,
city_id=3 , code=374 , the_geom=MULTIPOLYGON (((-41355708 -135367696,
-41473280 -135213408, -41758912 -135070864, -41814588 -134997808, -41473028
-134738576, -40920272 -135035888, -41355708 -135367696))) ]First "line" is part of rendering feature #2 from shape-file, second -
the same feature from PostGIS.Stripped and compiled into table that will look like this:
area perimeter city_ city_id code
shp | 2.718921E11 | 2208942.0 | 3 | 374 | 2 |
postgis | 2.0 | 2.718921E11 | 2208942 | 3 | 374 |So in the second case there is no single correct attribute value,
(they are shifted one position to the right) though when I look at the
PostgreSQL table itself all values are in place.I also should note that layers, which have textual attributes does
not render at all, leaving following log trace for each feature:6069484 [SEVERE] org.geotools.renderer.lite.LiteRenderer2$DefaultRenderListener
- expected java.lang.Double , but got java.lang.StringMost probably this is caused by the same displacement of attribute
columns. All this looks somewhat strangeBut I still try to make the changes you advised and then tell the
results.WBR,
ArtieI may guess at the answer, the Filter parsing code tends to 'try' to
parse anything it can as a number. I suspect that your 'code' is
trying to be compare a number with a string for equality.
This is a known, if annoying problem, that I made an effort of at fixing
for the xml parser.
I guess you mean
org.geotools.filter.ExpressionSAXParser::message(String)?
If so, yeah, this is an old bug I came around by just avoiding trying to
guess the literal type and passing the plain string. This is done for a
project I'm working on and is in a gt2.0 version I retrofited to work on
JDK 1.3
for instance, in the above mentioned method:
if (curExprssn instanceof AttributeExpression) {
...
} else if (curExprssn instanceof LiteralExpression) {
((LiteralExpression) curExprssn).setLiteral(message);
}
/* It was:
try {
Object temp = new Integer(message);
((LiteralExpression) curExprssn).setLiteral(temp);
currentState = "complete";
} catch (NumberFormatException nfe1) {
try {
Object temp = new Double(message);
((LiteralExpression) curExprssn).setLiteral(temp);
currentState = "complete";
} catch (NumberFormatException nfe2) {
Object temp = message;
((LiteralExpression) curExprssn).setLiteral(temp);
currentState = "complete";
}
}*/
I guess this is the right way since once the expression is evaluated it
would be the responsability of AttributeType.parse to get the
actual literal instance.
May be you can just try this modification and got it solved.
Best regards,
Gabriel.
Artie Konin wrote:
Greetings, Gabriel,
tripped and compiled into table that will look like this:
area perimeter city_ city_id code
shp | 2.718921E11 | 2208942.0 | 3 | 374 | 2 |
postgis | 2.0 | 2.718921E11 | 2208942 | 3 | 374 |So in the second case there is no single correct attribute value,
(they are shifted one position to the right) though when I look at the
PostgreSQL table itself all values are in place.
Opps I take it back, that has nothing to do with Filter 
GeoServer does maintain a separate wrapper which is used to ensure correct attribute order with the schena irrespective of column order on the back end database.
I wonder if something has gone wrong with respect to that? that would
be my next suspect if this problem is limited to GeoServer.
Perhaps you need to autogenerate youe xml schema again? (I am thinking a schema leftover from shapefile is trying to be used with postgis?)
Good luck,
Jody
Greetings, Gabriel,
Monday, April 25, 2005, you wrote:
regarding the patch I comented, my problem was different but may be
related, I was filtering by a char field with building number. Some of
them are like ' 002 ' and others have letters too, like ' 002A'. In this
later case the expression parser was interpreting it as an hexadecimal
and messing up the filter. This get solved by passing the plain literal
and letting the feature type get the correct instance type at a later
instance.
In fact, now I remember that I had similar problem several times
before. Sometimes dbf files that our GIS department feeds me contain
numeric values in character type columns Usually I simply changed
the type of the troublesome attributes to be numeric (fortunately,
they didn't contain any character data). From now on I'll be aware
that there is another solution.
And question of the ignorant: are features abstracted from their
physical data source so far that it is impossible to obtain type
information for each attribute? This could eliminate the need of
guessing its type from its value or expression applied to it.
Bu I don't fairly understand what your problem is. Please send the SLD
and confirm this two features should have the same attribute values.
I guess there is no need in this now, as all is working pretty fine
after Dave's fixes for JDBCDataStore and lite-renderer. But both
layers, shp and PostGis are identical and I apply identical styles to
them (well, with the exception of letter case in attribute names). I
resort to set of shapefile-based layers in emergency cases, like this
one
--
WBR,
Artie
Greetings, Jody,
Monday, April 25, 2005, you wrote:
GeoServer does maintain a separate wrapper which is used to ensure
correct attribute order with the schena irrespective of column order on
the back end database.
I wonder if something has gone wrong with respect to that? that would
be my next suspect if this problem is limited to GeoServer.
Perhaps you need to autogenerate youe xml schema again? (I am thinking a
schema leftover from shapefile is trying to be used with postgis?)
You touched a really interesting subject there, Jody. I already heard
about that schema several times and made the conclusion that this
should be a very useful thing. But as all worked fine without it, and
I didn't spotted any examples during my work with GeoServer, I still
have no clear understanding of what it is :)) And, consequently, I do
not use schemas for my feature types. But I sense, that it is worthy
enough to familiarize myself with it. Are there any docs and/or examples
of the schemas around?
--
WBR,
Artie