Hi,
the shapefile renderer experiment went fine... until today...
Today I discovered one significant issue.
You know the shapefile renderer get the extra speed by
bypassing the datastore machinery and going straight to
the disk. Well, this bypass means things do not work if
the original CRS of the data is not equal to the declared
one, because we do force the declared one in a wrapper
that's being bypassed. I noticed this today testing a few
user provided layers with Tim sandbox google map integration...
in 1.5.x the layers worked fine, on trunk I did not see anything
much to my surprise.
Debugging I noticed that the shapefile renderer uses the native
CRS of the shapefile, and the two layers that were failing
had no .prj file, thus no projection from 4326 to 900913 (google
projection) was done -> no features on the screen.
Now, that renderer has a hint to force the data crs, but this
is then applied to all layers... it's something that works in
udig, where there is one renderer per layer, but fails in GeoServer
as soon as there is a mix of CRS in the input layers.
Now, the attached patch fixes the issue I'm having... basically
I removed the explict usage of the shapefile datastore for
grabbing the CRS and used the one provided by the feature source
(which is a GeoServer feature source wrapper that adjusts the
default geometry CRS before returning it).
It's a hack, but seems to be working. Crossing fingers and
hoping that we won't find many other issues like these
(and also that Jesse finds the patch acceptable)
Cheers
Andrea
(attachments)
ShapefileRenderer.patch (1.35 KB)