Skip to main content
Solved

Problem with Coordinate rounder and following Change detector


lazarlubomir
Contributor
Forum|alt.badge.img+7

Hello,

unfortunately, I have problem with result from coordinate rounder and following process in changedetector.

Example of my situation is below:

There are 2 sources of data. One is actual to 2016 (technical map) and second to 2012 (plan of renewal). Plan of renewal was made from technical map in 2012. Now I want to compare these two sources in actual form with coordinates accuracy 0,01 m. I chose this way of processing - first I used coordinate rounder with X,Y precision 2 for both sources. I sent features with rounded coordinates to change detector. Values of coordinates are following:

First source

Coordinate 0: -536260.78633329261, -1226140.6460811181 Coordinate 1: -536258.07004669344, -1226118.8444450819

Second source:

Coordinate 0: -536260.7862999998, -1226140.6460000016 Coordinate 1: -536258.0700000003, -1226118.8443999998

Result is disappointing... In spite of fact that I rounded coordinates to precision 2, change detector said, that coordinates are different, but they arent in real...

Can anybody help me please?

Thank You very much!!

Lubo

Best answer by takashi

Hi @lazarlubomir, in use of the CoordinateRounger, indeed there could be slight error caused by the unavoidable computational error on calculating floating point number. Snapping would be a common approach in this case, as David suggested.

As another option, I think this approach might also bring your desired result.

View original
Did this help you find an answer to your question?

23 replies

david_r
Evangelist
  • June 9, 2016

Hi

I just tested with FME 2016.1 using the exact coordinates you posted and it worked as expected: The feature exits as Unchanged.

A few questions:

  • Do you have measures on your lines?
  • Did you define any additional attributes to match in the ChangeDetector?
  • Are the coordinates in the same order on both features? (Tip: lenient geometry matching)
  • Do both features have the exact same coordinate system? (Tip: check with inspector)

David


lazarlubomir
Contributor
Forum|alt.badge.img+7
  • Author
  • Contributor
  • June 9, 2016
david_r wrote:

Hi

I just tested with FME 2016.1 using the exact coordinates you posted and it worked as expected: The feature exits as Unchanged.

A few questions:

  • Do you have measures on your lines?
  • Did you define any additional attributes to match in the ChangeDetector?
  • Are the coordinates in the same order on both features? (Tip: lenient geometry matching)
  • Do both features have the exact same coordinate system? (Tip: check with inspector)

David

My answers are below:

- No, I dont. Is it neccessary to have measures on lines? How can I reach it?

- No, I didnt define any additional attributes, I just wanted to compare geometry.

- I used lenient geometry before.

- The coordinate system is the same on features from both sources - EPSG 5514.

I should note that older source (plan of renewal) is in ESRI SHP format, whilst newer source (technical map) use Bentley DGN format.


david_r
Evangelist
  • June 9, 2016

If you don't have any measures, then you don't need them :-)

Even though both datasets are EPSG:5514, I'd still send both features to the Inspector (just before they enter the ChangeDetector) and carefully compare which coordinate system FME has them tagged with:

You could also consider inserting a CoordinateSystemSetter set to EPSG:5514 on both datasets before they enter the ChangeDetector, to see if it makes a difference.


takashi
Contributor
Forum|alt.badge.img+19
  • Contributor
  • June 9, 2016

Hi @lazarlubomir, perhaps is there any difference in geometry type? e.g. one is IFMEMultiCurve (or IFMEAggregate), another is IFMELine.


lazarlubomir
Contributor
Forum|alt.badge.img+7
  • Author
  • Contributor
  • June 9, 2016

Unfortunately, the problem is still there even after your supposed operation. But I tried to find, where could be the problem... Please check following images:

Image below is attribute table of line feature from SHP:

Image below is attribute table of line feature from DGN. The values of coordinates in igds_xhigh, igds_xlow, igds_yhigh and igds_ylow are different to coordinates in IFMELINE.

It could be reason of my problem... How can I solve it please?

Thanks a lot

Lubos


gio
Contributor
Forum|alt.badge.img+15
  • Contributor
  • June 9, 2016

one is arc other is line...?


david_r
Evangelist
  • June 9, 2016

I suspect the x/yhigh attributes corresponds to the geometry bounding box. I highly doubt that the ChangeDetector considers them anyway, so I don't think that's the issue here.

Can you post a screenshot of the coordinate systems of these two? That is, the top part of the property windows.


Forum|alt.badge.img+5

To throw in my 2 cents...

1) The issue occurs because Shape stores data as integers and DGN as floating point. The conversion from Integer to Floating Point throws a tiny change into the mix. In short, don't compare features from different formats without adding a CoordinateRounder.

2) You said you added a CoordinateRounder but it didn't help. I think I'd want to see that the coordinates were rounded (add Inspectors AFTER the CoordinateRounder) to confirm that step of the operation.

3) If the coordinates are rounded, but the ChangeDetector says something is different, then let's check for other differences. Coordinate system and direction of the line are the most obvious items, but to be sure we'd really need the workspace and a small data sample.

4) Make sure background maps are turned OFF on the Data Inspector. I've had a few problems of my own recently where something didn't work even though the data looked correct. It's because FME had reprojected the data in the Data Inspector to match the background map, making it look correct when in fact the unreprojected data was incorrect. So always make sure that is turned off for issues of this type.

I hope this helps. In short, the quickest way for us to diagnose the problem is to get the workspace and at least a small sample of data.


Forum|alt.badge.img+5
gio wrote:

one is arc other is line...?

I think it is a "shape_arc" - basically 'arc' means 'line' in Shape (which doesn't support arcs natively anyway)


Forum|alt.badge.img+5
lazarlubomir wrote:

Unfortunately, the problem is still there even after your supposed operation. But I tried to find, where could be the problem... Please check following images:

Image below is attribute table of line feature from SHP:

Image below is attribute table of line feature from DGN. The values of coordinates in igds_xhigh, igds_xlow, igds_yhigh and igds_ylow are different to coordinates in IFMELINE.

It could be reason of my problem... How can I solve it please?

Thanks a lot

Lubos

I do wonder why your Shape dataset returns an igds_level attribute. Is that stored in the Shape dataset or are you creating/copying it in FME?


lazarlubomir
Contributor
Forum|alt.badge.img+7
  • Author
  • Contributor
  • June 9, 2016

Hello, thanks to everybody for help! Right now I dont have access for data and workspace, but tomorrow I can share .fmw and small sample of problematic data. Where I can share them and in which way (here via insert file)?

Thank you!


Forum|alt.badge.img+2
  • June 9, 2016
lazarlubomir wrote:

Hello, thanks to everybody for help! Right now I dont have access for data and workspace, but tomorrow I can share .fmw and small sample of problematic data. Where I can share them and in which way (here via insert file)?

Thank you!

Attach them here


lazarlubomir
Contributor
Forum|alt.badge.img+7
  • Author
  • Contributor
  • June 10, 2016

Hello,

I attach sample data (dgn, shp) and workspace. Please check DELETED data after ChangeDetector with attribute OBJECTID_1 210724 and 210552. There is the problem according to me...

Thank You!sample.zip


lazarlubomir
Contributor
Forum|alt.badge.img+7
  • Author
  • Contributor
  • June 10, 2016
david_r wrote:

I suspect the x/yhigh attributes corresponds to the geometry bounding box. I highly doubt that the ChangeDetector considers them anyway, so I don't think that's the issue here.

Can you post a screenshot of the coordinate systems of these two? That is, the top part of the property windows.

I attached sample of data and workspace below on this page.


takashi
Contributor
Forum|alt.badge.img+19
  • Contributor
  • June 10, 2016

In my quick test, the CoordinateRounder and ChangeDetector seem to work as expected. The Added features and Deleted features are definitely different in the specified coordinate precision, and the Deleted features don't contain both the 210724 and 210552 features. Am I missing something?


takashi
Contributor
Forum|alt.badge.img+19
  • Contributor
  • June 10, 2016
takashi wrote:

In my quick test, the CoordinateRounder and ChangeDetector seem to work as expected. The Added features and Deleted features are definitely different in the specified coordinate precision, and the Deleted features don't contain both the 210724 and 210552 features. Am I missing something?

I guess this is the cause of your problem.

  • 1.2345 -> [round by 3] -> 1.235 -> [round by 2] -> 1.24
  • 1.2345 -> [round by 2] -> 1.23

david_r
Evangelist
  • June 10, 2016
takashi wrote:

I guess this is the cause of your problem.

  • 1.2345 -> [round by 3] -> 1.235 -> [round by 2] -> 1.24
  • 1.2345 -> [round by 2] -> 1.23

I agree, the Coordinate_Rounder custom transformer is problematic. Try removing it.


lazarlubomir
Contributor
Forum|alt.badge.img+7
  • Author
  • Contributor
  • June 10, 2016

Yes, these lines are now OK. But if I apply this method on whole data, there is problem with another lines :-( Is there any transformer to define tolerance between coordinates?

Example:

I have line with these coordinates -

DGN

Coordinate 0: -536260.78633329261, -1226140.6460811181 Coordinate 1: -536258.07004669344, -1226118.8444450819

SHP

Coordinate 0: -536260.7862999998, -1226140.6460000016 Coordinate 1: -536258.0700000003, -1226118.8443999998

I send this coordinates to change detector, but in Deleted category should be lines, where is the difference between coordinates of lines more than 1 cm. When I use coordinate rounder with precision 2, it throw line to deleted category, because after rounding is difference 1 cm. But the difference in real is only 0,4 cm...


david_r
Evangelist
  • June 10, 2016

This is a pretty common problem with a few different possible solutions, depending on your case.

First, have a look at the Snapper or the AnchoredSnapper. For complex geometries (in particular polygons) consider also going through a GeometryValidator after the snapping.

There is also the ArcSDEGridSnapper if you intend to write the geometries to ArcSDE, but be careful about the settings (read the doc carefully).


takashi
Contributor
Forum|alt.badge.img+19
  • Contributor
  • Best Answer
  • June 11, 2016

Hi @lazarlubomir, in use of the CoordinateRounger, indeed there could be slight error caused by the unavoidable computational error on calculating floating point number. Snapping would be a common approach in this case, as David suggested.

As another option, I think this approach might also bring your desired result.


lazarlubomir
Contributor
Forum|alt.badge.img+7
  • Author
  • Contributor
  • June 13, 2016
takashi wrote:

Hi @lazarlubomir, in use of the CoordinateRounger, indeed there could be slight error caused by the unavoidable computational error on calculating floating point number. Snapping would be a common approach in this case, as David suggested.

As another option, I think this approach might also bring your desired result.

Thanks You for both tips, it works now in @takashi way... But anchored snapper is also good idea.. Well done guys! :-)


Forum|alt.badge.img
  • July 18, 2018
lazarlubomir wrote:

My answers are below:

- No, I dont. Is it neccessary to have measures on lines? How can I reach it?

- No, I didnt define any additional attributes, I just wanted to compare geometry.

- I used lenient geometry before.

- The coordinate system is the same on features from both sources - EPSG 5514.

I should note that older source (plan of renewal) is in ESRI SHP format, whilst newer source (technical map) use Bentley DGN format.

I have the problem and it seems link to Arc as far as I am concerned.

 

Coordinates are rounded by a coordinate rounder but not the center as stated in the documentation: https://docs.safe.com/fme/2018.0/html/FME_Desktop_Documentation/FME_Transformers/Transformers/coordinaterounder.htm

 

 

Any workaround for arc ? Any way to rounder the center point coordinates ?

 

 

Thanks

 


david_r
Evangelist
  • July 19, 2018
biboba wrote:
I have the problem and it seems link to Arc as far as I am concerned.

 

Coordinates are rounded by a coordinate rounder but not the center as stated in the documentation: https://docs.safe.com/fme/2018.0/html/FME_Desktop_Documentation/FME_Transformers/Transformers/coordinaterounder.htm

 

 

Any workaround for arc ? Any way to rounder the center point coordinates ?

 

 

Thanks

 

You can always deconstruct the arcs into attributes, round the attributes and then rebuild the arc.

 

Transformers of particular interest would include the PathSplitter/PathBuilder and the ArcPropertyExtractor/ArcPropertySetter with an AttributeRounder thrown into the mix.

Reply


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings