You are correct Martin. I dug into the Buffer code and it indeed uses the source GeometryFactory to create the buffer, so it should inheret the same SRID.
It was my misinterpretation. The Geometries I was buffering were resultant of a transformation using the GeoTools utility class JTS and the transform(Geometry geom, MathTransform transform) method. The Geometries returned by this method had a GeometryFactory with SRID set to 0 and I was setting their SRID manually with the setSRID method. Later in my code I was buffering these Geometries and their SRID was set to 0 as well, and this was the motivation of my first message on the subject. I will look into the GeoTools source and see if I can come up with something to fix this. Sorry for the false alarm. Regards, Alexandre Pretyman On Tue, Nov 4, 2008 at 11:37 PM, Martin Davis <[EMAIL PROTECTED]>wrote: > I've been looking into this issue a bit more. > > This might be a problem with how JTS is being used. The way that it is > designed to work is that the desired SRID is set into the GeometryFactory > used to create the geometries. Every geometry created by this factory will > then carry the specified SRID value. This includes all geometries created > by constructive operations. > > The setSRID operation is really only provided for backwards compatibility - > it should properly be deprecated. > > If the SRID on a geometry is set manually to be different to that in the > GeometryFactory, you will observe the behaviour that constructed geometries > carry different SRIDs to the input (i.e. the input will have the manually > set SRID, whereas the constructed ones will have the SRID of the parent > factory). Is it possible that this is what you're observing? > > Martin > > Alexandre Pretyman wrote: > >> Happy to hear! >> >> Let me piggy back on the subject. I notice that the Buffered Geometry >> result does not carry the source spatial reference id. Would it make sense >> to have this set on the JTS api, or leave it as it is to the client >> programmer to set it by hand? >> >> I acknowledge the fact that JTS doesn't want to deal with the SRID, and >> leave it to another layer of the application to do so, but in my little >> experience I would think it would make sense that the API would just copy >> this value from the source to the resultant buffer. >> I guess this could be easily done in the BufferOp.computeGeometry() >> method. >> >> I would like to know what the other more experient users of the API have >> to say, maybe there are situation where this is not actually desired, but I >> fail to find them. >> >> Thanks, >> Alexandre Pretyman >> >> On Wed, Oct 15, 2008 at 6:34 PM, Martin Davis <[EMAIL PROTECTED]<mailto: >> [EMAIL PROTECTED]>> wrote: >> >> Matthias Bobzien pointed out a bug in the new JTS buffer code, >> which occurred during processing some polygons with CCW >> orientation. Luckily the fix was simple. This has now been >> commited to CVS, and a new alpha release is available at >> >> http://tsusiatsoftware.net/jts/files/jts-1.10-alpha.zip >> >> Keep up the good work, testers! >> >> -- Martin Davis >> Senior Technical Architect >> Refractions Research, Inc. >> (250) 383-3022 >> >> _______________________________________________ >> jts-devel mailing list >> [email protected] >> <mailto:[email protected]> >> http://lists.refractions.net/mailman/listinfo/jts-devel >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> jts-devel mailing list >> [email protected] >> http://lists.refractions.net/mailman/listinfo/jts-devel >> >> > > -- > Martin Davis > Senior Technical Architect > Refractions Research, Inc. > (250) 383-3022 > > _______________________________________________ > jts-devel mailing list > [email protected] > http://lists.refractions.net/mailman/listinfo/jts-devel >
_______________________________________________ jts-devel mailing list [email protected] http://lists.refractions.net/mailman/listinfo/jts-devel
