Re: [Jts-topo-suite-user] Any interest in fixing bugs?

[Smiley, D. W. <ds...@mi...>]

As an aside, Ideally this back & forth would occur on the issue tracker.  This way people see the discussion in context.  Without the context, the bug appears to be ignored / unobserved. Martin, did you notice my bug report before today?

As this code is written in Java, the Java semantics of equals() and hashCode() most hold regardless of whatever definition of equals() the OGC has.  If two objects are equal, then they MUST have the same hashCode (but there is no converse rule).  If this is not possible or has pitiful performance, then throw an UnsupportedOperationException .

I took a little more careful look and I see that Geometry.equals(Object) is actually NOT implemented.  You implemented Geometry.equals(Geometry) which is overloaded but doesn't truly override the method by the same name in the superclass Object.  So it appears you are not actually violating anything -- yay!  But since you don't override equals(Object) and hashCode(), you're not providing a useful service.  Assuming you can implement equals(Object) without violating OGC spec, is there a way you can do it such that any two object that are equal are guaranteed to have the same Envelope?  If so, then that the hashCode could be taken from that of the Envelope.  And as for an efficient equals(Object), I recommend an efficient implementation that is only guaranteed to work when both objects have been normalized.

A further question: what exactly are you trying to do by using hashcode on a Geometry object?  In my experience it's rare to use Geometrys as keys in Maps or Sets.  It's much more common to use Coordinates or LineSegments (for instance) - and they provide the appropriate methods.

To put this another way, there doesn't seem to be much point in implementing hashcode just for the sake of doing so, especially given the issue with equals -  unless there is a clear use case for doing so.

I am implementing geospatial search in which a user query is a Geometry.  These get cached so that subsequent queries need not be repeated.  They key to the cache is the geometry.

~ David Smiley

On Jan 27, 2011, at 2:16 PM, Martin Davis wrote:

Actually it's worse than that.  For historical reasons "equals" implements the OGC topological semantics, which is probably NOT what is wanted when using equals in Java containers.  (It's very slow, for one thing).   Another result of this decision is that the semantics of equals and hashcode are quite different.  So I'm not sure that simply  implementing hashcode really solves the problem.

Another question - if hashcode is implemented for Polygon, is performance a concern?  Ie should it only take a few points of the Polygon into consideration?

Sigh....  I really wish that "equals" had proper Java semantics - but it seems too late to change now.

Comments & ideas are welcome.

Martin

On Thu, Jan 27, 2011 at 10:39 AM, Smiley, David W. <ds...@mi...<mailto:ds...@mi...>> wrote:
I reported a bug that I find rather serious involving broken equals/hashcode on Polygon:
http://sourceforge.net/tracker/?func=detail&aid=3134622&group_id=128875&atid=713120

Is there any interest in it getting fixed?  Would it help if I provide a patch?  Was this bug report "noticed" prior to me sending this message to the mailing list now?

~ David Smiley
------------------------------------------------------------------------------
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires
February 28th, so secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsight-sfd2d
_______________________________________________
Jts-topo-suite-user mailing list
Jts...@li...<mailto:Jts...@li...>
https://lists.sourceforge.net/lists/listinfo/jts-topo-suite-user

<ATT00001..txt><ATT00002..txt>