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!
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.
+21Hi @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 @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?
+21
+21
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?
+21
+17It 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!
+21Hi @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!
+43Hi @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?
+43Oh 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.
+21Hi @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!
+21Hi @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!
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.
+21Hi @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!
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
