validate rounded numeric values

[claeis]

Round the value as read from the XTF to the accuracy as defined by the ili model and then validate against that rounded value.

[beistehen]

This new behaviour may lead to duplicate coord errors which actually do not exist in the data.

It was my understanding that the precision of coordinates in ILI2 is not restricted. So a coordinate like

<C1>2721816.3638999984</C1>

was considered VALID against a definition of

2460000.000 .. 2870000.000
(precision = 3)

From my point of view, the precision should be enforced with the input data. So the sending application is responsible to avoid duplicate coords and deliver coordinates with the precision defined in the model.

Please reopen to further discuss this topic.
Stefan

[claeis]

It is valid to encode numeric values with additional precision. (Because of extended models). Nevertheless the data must still be valid against the base definition/model. Therefore the encoded value is rounded and then then this rounded value is validated.

[beistehen]

Ok, I understand the mechanism with base definitions and your explanation makes sense.

So I suggest that when ilivalidator reports duplicate coord errors, the coordinates of the error location should be reported with the original precision of the input data and not with the rounded precision (as it is done now with ilivalidator v1.9.0). Getting the error location with the orginial precision helps localise the error in the data visually (using a GIS) and textually (in the xtf file). The rounded coordinates do not show up in the original data and are therefore less usefull.

[claeis]

Would be nice, but big effort (because the rounding and some of the validations (e.g. uniqueness checks) are in very different code locations)

[edigonzales]

While upgrading our web service to v1.9.2 I run into some problems with this new behaviour. When dealing with "Einlenker" of streets that are segmentized and you just copy/paste them from cadastral surveying shapefile (or similar) to e.g. land use planning, you just end up with these "duplicate duplicate coord at" errors.

This will lead to misshapen "Einlenker" when you have to delete some of the vertices. And I fear this will be very hard to communicate as a whole...