WKTReader generates "wrong" geometries, compared to JTS about nettopologysuite HOT 7 CLOSED

I suppose it has to deal with the way numbers are parsed. Maybe that can be changed using a different NumberFormatInfo in FloatToken.

Anyhow the DiscreteHausdorffDistance between the geometries is less than 1E-9 which raises the question if it is worth to deal with it.

from nettopologysuite.

FloatToken now uses a formatter like String.Format(GetNumberFormatInfo(), "{0:R}", (Double) obj)) that, as far as I know (not much, actually) is maximum precision available.
So, to me, probably our code is correct.

from nettopologysuite.

That is for output, don't know if there is a way to control parsing

from nettopologysuite.

eheheh, right! I'll check

from nettopologysuite.

I played around a bit more and it seems that the problem is not in the WKTReader, not in the WKBWriter, not in the ToHex function. It is beyond our control:

The number 6232756.00054126 is internally treated as 6232756.0005412595 with the bytes
0x3_5_DE0800ADC65741. Java treats that number as 0x3_6_DE0800ADC65741.

from nettopologysuite.

@FObermaier only to know, how you found this information? :)

from nettopologysuite.

I tried :), it was the only number that was different

from nettopologysuite.