Quantcast

FIXED - bug in new buffer code

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

FIXED - bug in new buffer code

Martin Davis
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
[hidden email]
http://lists.refractions.net/mailman/listinfo/jts-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FIXED - bug in new buffer code

Alexandre Walter Pretyman
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 <[hidden email]> 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
[hidden email]
http://lists.refractions.net/mailman/listinfo/jts-devel


_______________________________________________
jts-devel mailing list
[hidden email]
http://lists.refractions.net/mailman/listinfo/jts-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FIXED - bug in new buffer code

Martin Davis
I guess no-one else has any opinions on this...

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 <[hidden email]
> <mailto:[hidden email]>> 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
>     [hidden email]
>     <mailto:[hidden email]>
>     http://lists.refractions.net/mailman/listinfo/jts-devel
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> jts-devel mailing list
> [hidden email]
> http://lists.refractions.net/mailman/listinfo/jts-devel
>  

--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022

_______________________________________________
jts-devel mailing list
[hidden email]
http://lists.refractions.net/mailman/listinfo/jts-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FIXED - bug in new buffer code

michaelm-2
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
>> <[hidden email] <mailto:[hidden email]>> 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
>>     [hidden email]
>>     <mailto:[hidden email]>
>>     http://lists.refractions.net/mailman/listinfo/jts-devel
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> jts-devel mailing list
>> [hidden email]
>> http://lists.refractions.net/mailman/listinfo/jts-devel
>>  
>

_______________________________________________
jts-devel mailing list
[hidden email]
http://lists.refractions.net/mailman/listinfo/jts-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FIXED - bug in new buffer code

Martin Davis
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
>>> <[hidden email] <mailto:[hidden email]>> 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
>>>     [hidden email]
>>>     <mailto:[hidden email]>
>>>     http://lists.refractions.net/mailman/listinfo/jts-devel
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>>
>>> _______________________________________________
>>> jts-devel mailing list
>>> [hidden email]
>>> http://lists.refractions.net/mailman/listinfo/jts-devel
>>>  
>>
>
> _______________________________________________
> jts-devel mailing list
> [hidden email]
> http://lists.refractions.net/mailman/listinfo/jts-devel
>

--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022

_______________________________________________
jts-devel mailing list
[hidden email]
http://lists.refractions.net/mailman/listinfo/jts-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FIXED - bug in new buffer code

Martin Davis
In reply to this post by Alexandre Walter Pretyman
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 <[hidden email]
> <mailto:[hidden email]>> 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
>     [hidden email]
>     <mailto:[hidden email]>
>     http://lists.refractions.net/mailman/listinfo/jts-devel
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> jts-devel mailing list
> [hidden email]
> http://lists.refractions.net/mailman/listinfo/jts-devel
>  

--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022

_______________________________________________
jts-devel mailing list
[hidden email]
http://lists.refractions.net/mailman/listinfo/jts-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FIXED - bug in new buffer code

Alexandre Walter Pretyman
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 <[hidden email]> 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 <[hidden email] <mailto:[hidden email]>> 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
   [hidden email]
   <mailto:[hidden email]> ------------------------------------------------------------------------


_______________________________________________
jts-devel mailing list
[hidden email]
http://lists.refractions.net/mailman/listinfo/jts-devel
 

--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022

_______________________________________________
jts-devel mailing list
[hidden email]
http://lists.refractions.net/mailman/listinfo/jts-devel


_______________________________________________
jts-devel mailing list
[hidden email]
http://lists.refractions.net/mailman/listinfo/jts-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FIXED - bug in new buffer code

Martin Davis
Sounds good, Alexandre.

I have to admit, the use of GeometryFactory to carry metadata about
Geometries (eg SRID and PrecisionModel) is convenient in one way, but
maybe a bit of a hassle when it comes to changing the metadata.  JTS
tries to encourage clients to treat geometries as immutable, so in
theory if the SRID is changed what should really happen is that a new
Geometry is created with the new SRID (and presumably modified
coordinates too).  This does mean that you need a new GeometryFactory,
however, and you have to "decompose" the Geometry into it's constituent
CoordinateSequences, make new ones, and then build the new Geometry back up.

JTS provides the GeometryEditor class to help with this awkward process,
so this is at least fairly well structured.  It's just not as simple as
change the coordinates in place, and set a new SRID (which I suspect is
what GeoTools is doing).  It's safer, but not as efficient.

So far I haven't been able to think of a way of having safety and
performance...

Alexandre Pretyman wrote:

> 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 <[hidden email]
> <mailto:[hidden email]>> 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
>         <[hidden email] <mailto:[hidden email]>
>         <mailto:[hidden email]
>         <mailto:[hidden email]>>> 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
>            [hidden email]
>         <mailto:[hidden email]>
>            <mailto:[hidden email]
>         <mailto:[hidden email]>>
>
>            http://lists.refractions.net/mailman/listinfo/jts-devel
>
>
>         ------------------------------------------------------------------------
>
>
>
>         _______________________________________________
>         jts-devel mailing list
>         [hidden email]
>         <mailto:[hidden email]>
>         http://lists.refractions.net/mailman/listinfo/jts-devel
>          
>
>
>     --
>     Martin Davis
>     Senior Technical Architect
>     Refractions Research, Inc.
>     (250) 383-3022
>
>     _______________________________________________
>     jts-devel mailing list
>     [hidden email]
>     <mailto:[hidden email]>
>     http://lists.refractions.net/mailman/listinfo/jts-devel
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> jts-devel mailing list
> [hidden email]
> http://lists.refractions.net/mailman/listinfo/jts-devel
>  

--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022

_______________________________________________
jts-devel mailing list
[hidden email]
http://lists.refractions.net/mailman/listinfo/jts-devel
Loading...