For what its worth I have at least one place (possibly more) in the code
base I am responsible for where I introduce duplicate points on purpose.
Even though they are moved later on, a unit test meant to exercise the
correctness of this code in isolation could then no longer rely on using
normalize for comparisons to expected output. I realize this may represent
an edge case though.
Also it would seem to me that if repeated points in geometries are
considered valid and normalize is meant to make exact comparisons easier
that you could well make the argument that two geometries that are
identical in all respects aside from the existence of repeated points are
still not really "equal". Perhaps an overloaded version of normalize is in
order?
Best regards,
Geoff Bantle
On Sep 16, 2014 11:29 AM, "Martin Davis" <[email protected]> wrote:
> Good argument, Rob. I'll work on adding de-duplication to normalize.
>
> Martin
>
> On Tue, Sep 16, 2014 at 9:14 AM, Rob Emanuele <[email protected]>
> wrote:
>
>> Since normalize is normally used as a preparation step to make
>> comparisons between geometries, I think the question is best answered by
>> determining, if we have two geometries such that the only difference
>> between them is one has duplicate vertices and other other does not, should
>> they be considered exactly equal after normalizing?
>>
>> What I would expect from a usage standpoint is that yes, normalization
>> would make these geometries exactly equal, so I agree that it should
>> de-duplicate.
>>
>> On Tue, Sep 16, 2014 at 4:30 AM, Sandro Santilli <[email protected]> wrote:
>>
>>> On Mon, Sep 15, 2014 at 10:28:39AM -0700, Martin Davis wrote:
>>>
>>> > But the real question is: should normalize removed duplicate
>>> vertices? My
>>> > first reaction is yes - but the fact that this hasn't caused any
>>> apparent
>>> > problems so far makes me pause a bit. In JTS normalize was really
>>> intended
>>> > to make exact comparisons between geometries easier, and in particular
>>> in
>>> > unit tests where one geometry is read from WKT and one is the result
>>> of a
>>> > computation. In this case, there are rarely or never duplicate points
>>> in
>>> > the computed output, so it's not an issue if they aren't removed.
>>> >
>>> > Perhaps I'll try making the change and see if anything breaks. Other
>>> > comments welcome.
>>>
>>> I think it does make sense for "normalizer" to remove duplicated
>>> vertices.
>>>
>>> --strk;
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Want excitement?
>>> Manually upgrade your production database.
>>> When you want reliability, choose Perforce.
>>> Perforce version control. Predictably reliable.
>>>
>>> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Jts-topo-suite-user mailing list
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/jts-topo-suite-user
>>>
>>
>>
>
>
> ------------------------------------------------------------------------------
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce.
> Perforce version control. Predictably reliable.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
> _______________________________________________
> Jts-topo-suite-user mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/jts-topo-suite-user
>
>
------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
Jts-topo-suite-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jts-topo-suite-user
