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.

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.

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

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

one is arc other is line...?

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.

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.

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

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?

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

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

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

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

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

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...

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).

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! :-)