Drops small polygons about wagyu HOT 5 CLOSED

@Algunenano sorry for the late responses here as I have been on holiday. I am going to dig into this right now

from wagyu.

Alright, I do not think this is a bug -- this has to do with the way that snap rounding occurs and the danger of using wagyu with very small differences between your integers. The snap rounding within Wagyu attempts to snap any possible crossing of a line within a 0.5x0.5 square of any point being processed. After iterating through it snaps down this entire shape into a single line, which is then discarded during processing.

Here is a screenshot of the original shape:

Here is a screenshot of the result after the vatti step (before it is then passed to correct_topology)

from wagyu.

I do not like that the algorithm does this, but it is one of the few ways that it can fix really nasty issues with data. The solution might be to consider how we could scale up and then down the values here based on a parameter before entering and exiting the algorithm. Something like "snap_rounding_precision", where if you set it to a value of 0.5 for example, it would scale all values up and then back down before performing the entire operation.

However, in this case the results would then need to be in a floating point format as a result, because you could have points at 0.5 etc.

from wagyu.

@Algunenano sorry for the late responses here as I have been on holiday. I am going to dig into this right now

No worries; happy new year!

Alright, I do not think this is a bug -- this has to do with the way that snap rounding occurs and the danger of using wagyu with very small differences between your integers. The snap rounding within Wagyu attempts to snap any possible crossing of a line within a 0.5x0.5 square of any point being processed. After iterating through it snaps down this entire shape into a single line, which is then discarded during processing.

Are you sure that that snapping is the issue? If I scale the polygon (I've tried both x2 and x10) I get nothing out of the Vatti execution, and if I translate the polygon (x += 10000, y stays the same) I also don't get anything out of that step.

However, in this case the results would then need to be in a floating point format as a result, because you could have points at 0.5 etc.

I guess that even if this worked I'd need to be able to do the scale down before validation, as rounding to int values might produce invalid polygons again.

from wagyu.

Are you sure that that snapping is the issue? If I scale the polygon (I've tried both x2 and x10) I get nothing out of the Vatti execution, and if I translate the polygon (x += 10000, y stays the same) I also don't get anything out of that step.

There was an error in these tests, this indeed works but it has other effects (see above).

So I've tried 2 things to workaround this small polygons disappearing:

• Reduce the snap margin (or remove it completely).
• Scale the geometry up and then down, which for MVT meant gridding it again to integer values after wagyu was done (to make sure no .5 were left behind).

In both cases I end up seeing more small parts that before were removed (like the ones in the issue I opened) but I also see self-intersections and spikes; for example:
Before:

After:

Obviously it'd be great to have the cake and eat it, but I don't see an easy way to keep the small polygons and the validity. Taking into account that dropping small polygons in MVT isn't that bad (it's just that we are dropping some extra ;D), I'll stick with having the cake and maintain validity.

Closing this for now, maybe I'll revisit it in the future.

from wagyu.