Question

Issue with Snapping for Snipper in Measure (Value) snipping mode

  • 25 April 2019
  • 2 replies
  • 20 views
J

Hi There, I am building a workspace that generates point location based on measure using line features, it uses Snipper tools with Measure (Value) as snipping mode (screenshot below). I have two questions:

  1. I get this error in one of our datasets, where it shows a warning and FME just hangs. It seems like an issue with generating last point where measure is same as the highest value. I am not sure if this a data precision related issue or a Snipper transformer issue.

2019-04-24 09:43:22| 158.4| 1.7|WARN |@Snip (or FMELine::snip) was given Measures of 49447.77 and 49447.77, which are out of range for a line with min/max measures of 0 and 49447.77. Snapping params to closest valid value.

2. How can I make sure that process proceed with remaining data and skips the record that has problems.

Appreciate any input.

Thanks

Jay

 

2 replies

dellerbeck
Rank
Badge +6

Jay,

I work with measures daily and I have seen this a lot. For example if you are using Esri as your data source, particularly in an Enterprise database, you can have an M aware line that looks like 0-100 but the geometry itself is actually 0-99.99999.

This is normally caused because of extremely high precision and working with measures where the user splits the line, or lets the application calculate the measures, and the application does an absolute calculation of the interpolated Ms. The user is presented with a rounded value so they are not even aware of the decimal points.

I believe that it was FME 2014, the snipper transformer would not output a record when this happened. It was then changed by Safe, I upvoted this myself, to let the transformer "snap to the closest location". Without seeing the data I would suggest getting the list range from the M values and testing it against your measures and not passing anything that is <> 0.001 units, or whatever value works best of you.

I have also use the Python caller to round the list values of measures to the nearest whole value, that way I did not have to explode the list and update each value as a row.

J

Jay,

I work with measures daily and I have seen this a lot. For example if you are using Esri as your data source, particularly in an Enterprise database, you can have an M aware line that looks like 0-100 but the geometry itself is actually 0-99.99999.

This is normally caused because of extremely high precision and working with measures where the user splits the line, or lets the application calculate the measures, and the application does an absolute calculation of the interpolated Ms. The user is presented with a rounded value so they are not even aware of the decimal points.

I believe that it was FME 2014, the snipper transformer would not output a record when this happened. It was then changed by Safe, I upvoted this myself, to let the transformer "snap to the closest location". Without seeing the data I would suggest getting the list range from the M values and testing it against your measures and not passing anything that is <> 0.001 units, or whatever value works best of you.

I have also use the Python caller to round the list values of measures to the nearest whole value, that way I did not have to explode the list and update each value as a row.

Thanks for the input, It looks like precision related issue, I am using ESRI Enterprise Geodatabase. I will make our data editors aware of this.

 

On the second issue, I am using FME 2016, will check with FME support if there were any changes from 2014 version. FME is getting stuck when it’s trying to snap to the closest location.

 

Are you able to share your workaround using python caller. Thanks

Reply


Community Stats

28,731
Posts
109,527
Replies
36,565
Members
Terms & ConditionsCookie settings
A product of
Safe Software respectfully acknowledges that we live, learn and work on the traditional and unceded territories of the Kwantlen, Katzie, and Semiahmoo First Nations.