I'm using the NeighborFinder transformer in FME Desktop 2013, and I need it to use a maximum distance in meters. My input data, however, are points and lines in WGS84, so before sending them into the NeighborFinder, I'm using Reprojector to convert the geometry into FME's dynamic coordinate systems AZMED or AZMEA.

The lines reproject okay. The points, however, all reproject to 0,0. So when the points go to NeighborFinder, they create meaningless output.

Here's a part of the setup before NeighborFinder:

enter image description here

enter image description here

Using Inspection, I can see a point before entering the Reprojector:

enter image description here

And after leaving the Reprojector:

enter image description here

Note the loss of geometry.

I've tried leaving the Source Coordinate System as "Read from Feature", but still no gold.

The Transformer Description for Reprojector gives an example of reprojecting a point to AZMED or AZMEA. And I can't find any indication online that points aren't supported.

I can reproject the points by changing the Destination Coordinate System to the relevant UTM zone (EPSG:32617, UTM Zone 17). But I'd prefer a scalable solution because I have global data to feed into the workbench.

Does anyone know why I can't reproject my points into AZMED or AZMEA?

  • You need to use the reprojector before the NeighborFinder to get your distances to meters (WGS84 is decimal degrees) – Mapperz Apr 9 '13 at 21:07
  • @Mapperz, thanks for having a look. Indeed I'm trying to do what I think you're indicating, but my output was bad and I tracked it back to Reprojector (before NeighborFinder) converting all my points to meters coordinate 0,0. I wasn't clear in my intro: the first diagram above shows a part before NeighborFinder. The blue line leads off to a CoordinateSystemExtractor (for GroupBy in NeighborFinder) and then to NeighborFinder. I edited the question to clarify the sequencing. – andytilia Apr 10 '13 at 16:28

That is the expected behavior. Each point is getting its own unique coordinate system, where the point is placed at the origin.

In your example, your point has been placed into the coordinate system _AZMED_WGS84_-71.496825_42.8188720 which is a unique system with origin at -71.496825, 42.8188720. As a result, every point ends up at 0,0 (or rather, every point ends up at 0,[some extremely small number which rounds to 0]).

NeighborFinder is not going to work with the _AZMED_ projection on the Reprojector transformer.

Instead, use the CommonLocalReprojector transformer with an AZMED projection type. This will still be a dynamic projection, but using one single projection for the entire dataset. Do not use the Group By setting when feeding these results into NeighborhoodFinder.

Note: CommonLocalReprojector is a blocking transformer, this will affect your performance for large datasets.

| improve this answer | |
  • 1
    That's it! Thanks for the good explanation. I misunderstood AZMED, and now I see why my initial approach didn't work. It was obvious something was wrong on the points (with all 0,0). But now it's clear that the lines were bad too, even though it wasn't as obvious. Each line had its own coordinate system, with the line centroid at the origin. So, I fed my points and lines into the same CommonLocalReprojector (separate reprojectors give different CS to points vs lines) and then used a GeometryFilter to pull the points and lines apart for Base and Candidate inputs to NeighborFinder. – andytilia Apr 10 '13 at 18:12
  • Awesome. I suspected that your lines were bad too, but was not sure since you said they looked okay :) – blord-castillo Apr 11 '13 at 13:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.