Agree with everything you say. However, since JTS knows nothing about
the meaning of the SRID value, it seems the best it can do is to simply
copy the imput. It's up to the client to ensure that JTS is being used
appropriately.
Michael Michaud wrote:
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
--
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
