Martin Davis a écrit :
I guess no-one else has any opinions on this...
Hi,
I misunderstood the question at my first read, but of course,
Alexandre's proposition to copy the SRID into the buffer geometry makes
sense to me.
In order to sustain the debate, I can add two remarks :
- if it makes sense for buffer, it probably makes also sense (even more
sense) for most of other geometry operations (centroid, interiorPoint,
boundary...)
- the buffer computed by JTS is not a "true buffer" in the sense that it
does not represent the set of points located at a distance < d "in real
life", but instead, it is computed in the projected plan. Giving the
user the SRID of the SRS in which the buffer has been computed seems a
reasonnable option. On the other hand arguing that the JTS buffer may
represent the true buffer (measured on earth surface) in an unknown SRS
doesn't seem reasonable to me (so why do I do such a crazy supposition ?
I don't know ;-)...
That said, computing a buffer around a geometry based on a geographic
coordinate system and transferring the SRID to the result may raise some
tricky problems as JTS does not really manage ellipsoidal coordinates.
my two cents
Michaël
I think I'd agree with you, however - the SRID of a result geometry
should be the same as the input (or one of the inputs, in the case of
binary operations).
I'll try and make this happen in an upcoming release.
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
_______________________________________________
jts-devel mailing list
[email protected]
http://lists.refractions.net/mailman/listinfo/jts-devel
