Thanks for your response Andrea,
Regarding FilterFactory I was just really wondering if it made use of
the FilterToSql class when building filters. The follow test errors out
(JDBCFeatureSourceTest):
FilterFactory ff = dataStore.getFilterFactory();
SortBy sort = ff.sort(aname("stringProperty"),
SortOrder.ASCENDING);
DefaultQuery query = new DefaultQuery();
query.setSortBy(new SortBy[] { sort });
SimpleFeatureCollection features =
featureSource.getFeatures(query); <--- HERE
With a NullPointerException. I'm uncertain as to why that is and having
some difficult tracking it down.
The way I build geometries is through a AsBinary(col_name) then in
decodeGeometryValue I do this:
try {
byte bytes[] = rs.getBytes(column);
if(bytes == null) {
return null;
}
Geometry geom = (Geometry) new WKBReader().read(bytes);
return geom;
}
There are no exceptions as far as I can tell so the read is okay.
AsBinary will return WKB as per the specification.
Thank you!
On 06/29/2010 05:39 PM, Andrea Aime wrote:
> Alex Trofast ha scritto:
>> Greetings,
>>
>> While working on the Ingres JDBC driver a couple of things I've been
>> wondering about:
>> The FilterToSql class encodes the WHERE clause of SQL if I'm correct,
>> is this the class that gets used for FilterFactory filters? For
>> example the sort method of FilterFactory, if it's not working
>> properly is there a method I should overwrite in any of my classes?
>
> FilterFactory just builds filters, OGC filters in particular.
> What do you mean "if the FilterFactory method is not working properly"?
> Do you have a test showing a misbehavior? If it's not working we fix it,
> we don't work around it.
>
> What has it to do with the FilterToSql?
>
>> Next, one test fails because the Geometry.getUserData() returns null
>> and not a CoordinateReferenceSystem even though I have implemented
>> createCRS and getGeometrySRID and these two are functioning properly.
>> Is there a reason why a Geometry would "forget" about it's CRS? The
>> only issue I've been able to track down is something like this:
>> FINER: GEOMETRYCOLLECTION (POINT (1 1)) is not of type
>> com.vividsolutions.jts.geom.GeometryCollection, attempting conversion
>
> Conversion might certainly make the geometries loose their userdata,
> not sure that case has ever been covered.
>
> Searching for the non parametric part of that error message I've found
> this code in JDBCFeatureReader at line 629:
>
> // they value may need conversion. We let converters chew the initial
> // value towards the target type, if the result is not the same as the
> // original, then a conversion happened and we may want to report it
> to the
> // user (being the feature type reverse engineered, it's unlikely a true
> // conversion will be needed)
> if(value != null) {
> Class binding = type.getType().getBinding();
> Object converted = Converters.convert(value, binding);
> if(converted != null && converted != value) {
> value = converted;
> if (dataStore.getLogger().isLoggable(Level.FINER)) {
> String msg = value + " is not of type " + binding.getName()
> + ", attempting conversion";
> dataStore.getLogger().finer(msg);
> }
> }
> }
>
> The message is quite odd though... how is it possible that
> GEOMETRYCOLLECTION(POINT(1 1)) is not a jts geometry collection?
>
> The conversion is likely being performed by GometryTypeConverterFactory,
> but the fact remains there is something quite odd going on... how
> are you building the geometries in your dialect code?
>
> Cheers
> Andrea
>
--
Alex
http://bit.ly/geodb
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
