Hi,I'm using FME13 to clip some MapInfo files.In the screenshot below, the red dot polygon is my clipper, the black line polygon is the clipee. I'm trying to get rid of the part of black line polygon that's outside of the red one. For the output I pick "inside" and the green is what I get. I'm not sure why the green is not snapped and aligned to the red. I've tried all the parameters within the transformer. Does anyone have similar experience or solutions?Thanks!

Clipper not clipping properly

It might be a slight rounding error in your data. You can check by using a Snapper or an AnchoredSnapper (type: segment snapping) with a tiny tolerance on the Clipper and the Clippee, before sending them off to the Clipper.

Hi @judychang, looks like the screenshot is not from FME Data Inspector. Depending on viewer software, geometries might not be displayed with high accuracy. Even if you inspect them with Data Inspector, does the gap still exist?

The screenshot is from MapInfo. FME Inspector doesn't let me zoom in that much so I can't check with that.

All the coordinate values of a selected feature are displayed on the Feature Information window of Data Inspector, so you can check whether the vertices common to the red and green shape are match.

From the inspector it actually looks fine - does that mean MapInfo rounded my data and causes the misalignment?

I guess it's a possible reason.

It might be a slight rounding error in your data. You can check by using a Snapper or an AnchoredSnapper (type: segment snapping) with a tiny tolerance on the Clipper and the Clippee, before sending them off to the Clipper.

My Snapper/AnchoredSnapper doesn't have segment snapping - maybe it's time to ask work for an FME upgrade.

Sounds like your version of FME is getting old. You might also want to try the CoordinateRounder.

Hi @judychang, looks like the screenshot is not from FME Data Inspector. Depending on viewer software, geometries might not be displayed with high accuracy. Even if you inspect them with Data Inspector, does the gap still exist?

Hi @takashi, I still haven't been able to solve the issue. I have got some other examples where I can see the little gaps from the Inspector. Do you know any other way to cut the polygon using other transformers than Clipper? Thanks!

Can you share the examples with us?

It is the case that MapInfo rounds off coordinates in its format -- there is not full double precision. Suggest you save the results in FFS in your workspace and look at those in the data inspector, and then overlay the same data as was saved in MapInfo.

Though I strongly suspect the issue here relates to coordinate precision in MapInfo, I might also add that FME's numeric precision has improved since FME 2013, so I'd also suggest trying FME 2016.1. That said, if the output format is still MapInfo, I'd not be surprised if there remain issues. Definitely interested in getting to the bottom of this if you could share the data. (Aside -- there are ways to fiddle with the MapInfo "bounds" so that you preserve more precision if your data is fairly localized, we could explore that too).

Hi @takashi and @daleatsafe,

The samples are here:

https://www.dropbox.com/sh/0dvkb20wo8nnttf/AABYwWCrehXjPeDOsZ829dGLa?dl=0

It's mostly fine but when zoomed very in at 150.1647797 -33.48549369 there is a small gap. And when the polygons get complicated it becomes messy.

Thanks!

Hi @takashi and @daleatsafe,

The samples are here:

https://www.dropbox.com/sh/0dvkb20wo8nnttf/AABYwWCrehXjPeDOsZ829dGLa?dl=0

It's mostly fine but when zoomed very in at 150.1647797 -33.48549369 there is a small gap. And when the polygons get complicated it becomes messy.

Thanks!

I see that there is a gap between the boundaries of A and B, but only from the resulting data, it's hard to know what the problem is. How did you create A and B, and what was the required result?

Hi @judychang, looks like the screenshot is not from FME Data Inspector. Depending on viewer software, geometries might not be displayed with high accuracy. Even if you inspect them with Data Inspector, does the gap still exist?

Yes, the question is whether you are looking at the data before or after it is written to MapInfo. I'll take a look at the samples below and see what I can figure out.

Oh gosh, this is really difficult to investigate (and explain) because I can't see inside a MapInfo file to find what coordinates are being used. All I can do is read them back into FME, which is not exactly the same thing (there is an integer to floating point conversion going on).

Anyway, to confirm the issue I wrote the Clipped:Inside part to MapInfo TAB. Then I read it back and compared it to what was output from the clipped port (the FFS equivalent). In theory they should be the same, in practice they are not.

For example, whereas the Clipper outputs a coordinate as:

150.16802876675786, -33.482923469220246

Writing to MapInfo and then reading it back into FME I get:

150.16802876675851, -33.482923469221177

You can see that FME is using 15 decimal places. But I believe MapInfo is only 6 decimal places. So FME truncates when it writes to MapInfo, but converts back to double precision when it reads it and the result is very slightly different.

That's not unexpected and Dale's suggestion of overlaying FFS and MapInfo in the Data Inspector would show you the same thing.

So FME won't think the data matches - but it's not really helping get what you want. It seems to me that your original data is MapInfo, and the output is MapInfo, so that if the two don't line up it's because they each have a different precision set. Again it's hard for me to tell because I can't see inside the MapInfo files.

So, my suggestions:

1) Try a CoordinateRounder after the Clipper. Set the precision to, say, 6 decimal places and see if that reduces the gap (incidentally, how much of a gap is there between red and green lines? Without a scale it's hard to tell how bad the issue is). I don't know if this is the best solution, but it's something that would be very quick to try.

2) Try setting the bounds values in the MapInfo writer. I tried this and got different values than when I didn't, so it's having some effect. Basically setting the bounds as small as possible to enclose your data is probably what you should use. The BoundingBoxAccumulator is a transformer that would help to find out the bounding box coordinates if you need it.

3) If neither of those help then let us know. It's probably best to file a support case (safe.com/support) and that way we can get our development team involved. I'm hoping they will have better tools for exploring the insides of a TAB file than I do.

I see that there is a gap between the boundaries of A and B, but only from the resulting data, it's hard to know what the problem is. How did you create A and B, and what was the required result?

hi @takashi, sorry A and B are the input and I just put 1 and 2 on dropbox too which are the clipped inside and outside. At the coordination I mentioned there is a small gap. But the sliver on the right seems to be fine.

Hi @takashi and @daleatsafe,

The samples are here:

https://www.dropbox.com/sh/0dvkb20wo8nnttf/AABYwWCrehXjPeDOsZ829dGLa?dl=0

It's mostly fine but when zoomed very in at 150.1647797 -33.48549369 there is a small gap. And when the polygons get complicated it becomes messy.

Thanks!

Hi @judychang, you can see some vertices have been inserted to the resulting polygon boundary (green - Clipped Inside). Those vertices are intersections between the A boundary (red - Clipper) and the B boundary (blue - Clippee). Here, you have to be aware that the inserted vertices might NOT be located precisely upon either the A boundary or the B boundary, in mathematical strictness. Because the number of significant figures of a floating point number is 15 or so at best and therefore there always is unavoidable computational error in geometric operations. And I therefore don't think that such a slight gap between the original boundary and the resulting boundary split by the inserted vertex can be avoided. That's my view.

Hi @takashi and @daleatsafe,

The samples are here:

https://www.dropbox.com/sh/0dvkb20wo8nnttf/AABYwWCrehXjPeDOsZ829dGLa?dl=0

It's mostly fine but when zoomed very in at 150.1647797 -33.48549369 there is a small gap. And when the polygons get complicated it becomes messy.

Thanks!

A simplified example.

Mathematically precise coordinates of the intersection should be (20/3, 0). However, the coordinates will be treated as (6.666666666666667, 0.0) in fact, since computers cannot handle any infinite decimal such as 20/3. Therefore, if the green line was split by the intersection, a slight gap between the split lines and the original line occurs inevitably. I guess this is the cause for the gap you have observed.

Oh gosh, this is really difficult to investigate (and explain) because I can't see inside a MapInfo file to find what coordinates are being used. All I can do is read them back into FME, which is not exactly the same thing (there is an integer to floating point conversion going on).

Anyway, to confirm the issue I wrote the Clipped:Inside part to MapInfo TAB. Then I read it back and compared it to what was output from the clipped port (the FFS equivalent). In theory they should be the same, in practice they are not.

For example, whereas the Clipper outputs a coordinate as:

150.16802876675786, -33.482923469220246

Writing to MapInfo and then reading it back into FME I get:

150.16802876675851, -33.482923469221177

You can see that FME is using 15 decimal places. But I believe MapInfo is only 6 decimal places. So FME truncates when it writes to MapInfo, but converts back to double precision when it reads it and the result is very slightly different.

That's not unexpected and Dale's suggestion of overlaying FFS and MapInfo in the Data Inspector would show you the same thing.

So FME won't think the data matches - but it's not really helping get what you want. It seems to me that your original data is MapInfo, and the output is MapInfo, so that if the two don't line up it's because they each have a different precision set. Again it's hard for me to tell because I can't see inside the MapInfo files.

So, my suggestions:

1) Try a CoordinateRounder after the Clipper. Set the precision to, say, 6 decimal places and see if that reduces the gap (incidentally, how much of a gap is there between red and green lines? Without a scale it's hard to tell how bad the issue is). I don't know if this is the best solution, but it's something that would be very quick to try.

2) Try setting the bounds values in the MapInfo writer. I tried this and got different values than when I didn't, so it's having some effect. Basically setting the bounds as small as possible to enclose your data is probably what you should use. The BoundingBoxAccumulator is a transformer that would help to find out the bounding box coordinates if you need it.

3) If neither of those help then let us know. It's probably best to file a support case (safe.com/support) and that way we can get our development team involved. I'm hoping they will have better tools for exploring the insides of a TAB file than I do.

Thanks for your suggestions! I tried the first 2 and didn't seem to work. I think @takashi has some very good points below and that it might be unavoidable. What do you think @Mark2AtSafe?

Hi @takashi and @daleatsafe,

The samples are here:

https://www.dropbox.com/sh/0dvkb20wo8nnttf/AABYwWCrehXjPeDOsZ829dGLa?dl=0

It's mostly fine but when zoomed very in at 150.1647797 -33.48549369 there is a small gap. And when the polygons get complicated it becomes messy.

Thanks!

I don't know details of the MapInfo format specifications, but theoretically, I think that the gap would be larger if the precision of coordinates in MapInfo data is lower than the full double precision.

Reply

Community Stats

Reply

Community Stats

Sign up

An FME Account is required to contribute

Login to the community

An FME Account is required to contribute

Scanning file for viruses.

This file cannot be downloaded