# How much is 1 meter in decimal degrees?

I am using FME's Tester to select objects that are bigger than 1 meter.

My data are in EPSG:4326.

How much is 1 meter in decimal degrees?

• Check the answers to: gis.stackexchange.com/questions/2951/… – underdark May 29 '12 at 6:42
• The thrust of Underdark's comment and @Alex Markov's answer is that the conversion between length and decimal degrees depends (strongly) on location and orientation. If your test does not have to be very accurate--e.g., if 1 m is a crude threshold and 1/2 m or 2 m might do just as well--and if it does not have to apply in polar regions, then you can safely use very rough approximations (and perhaps even ignore the dependence on orientation and location). – whuber May 29 '12 at 14:34

Although I like Alex's answer - it's better to reproject than to simply convert decimal degrees to metres with a fixed multiplier - I never really like having to reproject data back and forth if not necessary. I figure you're bound to lose some degree of accuracy/precision.

What I would try is the ReprojectLengthCalculator transformer. With that you could measure the length in decimal degrees and reproject that attribute value. You wouldn't need to reproject the feature to metres and back again.

The drawback here is that I think it will only really work with 2-point lines and - for some reason - you'll have to calculate the angle of that line as part of the input.

If you do reproject as Alex suggests, then I would encourage you to do that as a separate stream, and merge the resulting distance back onto the original data. That way you retain a good (un-reprojected) copy of the geometry.

I also suggest reprojecting to a dynamic coordinate system; `_AZMED_` for measuring distances, and `_AZMEA_` for measuring areas. Each feature effectively gets converted to its own equal-distance (equal-area) coordinate system, giving the best results.

I think it would look something like this:

You could put the Tester after the FeatureMerger, but I think this configuration is more efficient. The FeatureMerger will need a unique ID on the features to work.

• could using GeometryExtractor before and GeometryReplacer after produce better results than FeatureMerger? It seems to me that GeometryExtractor/GeometryReplacer can process feature by feature, while FeatureMerger would load all features into memory (twice in this case), am I right? – Alex Markov May 29 '12 at 18:10
• Thanks for interesting CS (`_AZMED_` / `_AZMEA_`)! Where is it possible to read more about it? – Alex Markov May 29 '12 at 18:12
• Just realized: also by using GeometryExtractor/GeometryReplacer we actually can get rid of `Reprojector_2` transformer... – Alex Markov May 29 '12 at 18:17
• Reprojecting to `_AZMED_` or `_AZMEA_` results in a coordinate system centered on your input feature being generated. General details about these projections: en.wikipedia.org/wiki/Lambert_azimuthal_equal-area_projection en.wikipedia.org/wiki/Azimuthal_equidistant_projection – Raven May 29 '12 at 23:53
• "could using GeometryExtractor before and GeometryReplacer after produce better results" - Possibly. I haven't done a comparison. But there is a performance hit in serializing data like that, so it's not a sure thing. What is certain is that you really need to use an AttributeRemover to get rid of the geometry attribute, if there is further processing to come. Otherwise you are carrying very large attributes through the rest of the translation for no purpose. – Mark Ireland May 30 '12 at 16:45

I can propose you to do next steps in order to get results with appropriate accuracy:

1. Reproject your data into some projected CS with metric units.
2. Calculate length and use Tester transformer.
3. Reproject your data back into source CS (EPSG:4326).

This part of the model should look like:

EDIT1:

It is also possible to use GeometryExtractor and GeometryReplacer transformers. In this case we will not modify geometry of the feature at all and we can get rid of `Reprojector_2`:

• I did this before than I got some discrepancies in coordinates!! – Z77 May 30 '12 at 6:44
• Take a look at my edits. Hope it helps! Also try model proposed by @Mark-Ireland – Alex Markov May 30 '12 at 7:10