GeometryExtractor

Features whose geometry was successfully encoded into the Destination Geometry Attribute are output through this port.

Features whose geometry could not be extracted into the chosen encoding are output through this port.

Rejected features will have an fme_rejection_code attribute with one of the following values: INVALID_FEATURE_LOCATION, INVALID_GEOMETRY_VERTICES.

This parameter can be set to Encoded Polyline, Esri JSON, FME Binary, FME XML, Geo (microformat), Geohash, GeoJSON, GeoRSS Simple Encoding, Geotagging GeoSMS (RFC 5870), GML, hexadecimal-encoded FME Binary, hexadecimal-encoded OGC Well Known Binary (wkbhex), KML, OGC Open GeoSMS, OGC Well Known Binary (wkb) or OGC Well Known Text (wkt).

The most efficient and truest representation of the geometry is FME Binary, and this should be used in most cases. All the FME representations can accommodate all aspects of the FME Geometry Model, including measures and paths consisting of multiple linear segments; however, both the FME XML and Hex Encoded FME Binary representations impose some overhead in translating between the internal binary representation and the ASCII-encoded representation.

The OGC variants are useful if interaction with other OGC supporting systems is required. However, some characteristics of geometries may be lost in these modes; for instance, any path will be flattened into a single linestring.

The GeoJSON, Esri JSON, and GeoRSS Simple encodings may not preserve all geometry characteristics. For example, arcs will be stroked to lines, and ellipses stroked to polygons. These encodings also do not support measures.

The Geohash encoding will not preserve any geometry characteristics. Instead, they will be converted to a point represented by a geohash.

The OGC Open GeoSMS, Geotagging GeoSMS, and Geo encodings will not preserve any geometry characteristics. For example: arcs, polygons, ellipses, etc., will be converted into a point at the center of their bounding box and will then be encoded to their respective formats. If the geometry has a coordinate system other than LL-WGS84, a temporary copy will be created and reprojected; however, the source geometry will not be modified.

The Encoded Polyline encodings are useful if working with the Google Maps API and can be used to represent points, lines and polygons.

The MGRS encoding calculates a Military Grid Reference System (MGRS) code based on the geometry of a feature. The MGRS code for a position consists of a group of letters and numbers which include the following elements:

• grid zone designation
• the 100,000-meter square letter identification
• the grid coordinates (also referred to as rectangular coordinates); the numerical portion of the reference expressed to a desired refinement

For MGRS, if a non-point feature (that is, a feature with more than one point) is passed in, then the first point of the geometry will be used for the conversion.

The Microsoft SQL Server Binary encoding is used to serialize geometries to the native storage format used in Microsoft SQL Server.

The name of the attribute that will hold the encoded geometry.

Removes geometry after extraction. The default value is No. If the value is set to Yes, the geometry will be removed from the feature after it has been extracted into an attribute. This option can be useful for saving memory space if the true geometry will no longer be needed.

The name of the attribute that will hold the encoded levels of a polyline.

You can chose the length in characters of the resulting geohash; this also shows the approximate precision. Please note that the precision of a geohash is limited by the precision of the source geometry.

For XML output formats (except FME XML), this parameter controls whether or not the output contains XML namespace declarations. All well-formed XML output must contain namespace declarations. However, if you are manually inserting the transformer output into a larger XML document, you may want to omit the namespace declarations.

Determines if FME writes the Geometries as a gml:Polygon or a gml:PolygonPatch. The default value is 'no', which prints out gml:Surface geometries. If 'yes', FME creates the geometry as a gml:Polygon in the output.

You can choose between versions 1.1 and 1.2.

Version 1.2 contains two key improvements: support for measures and z-values. Note that the only measure considered when producing an OGC representation is the "default" (unnamed) measure.

This parameter allows you to choose the precision of the strings used to represent the coordinates of the geometry. The options are:

• Shortened 64-bit: Enough precision to store most double precision IEEE floating point numbers.
• Full 64-bit: Enough precision to store all double precision IEEE floating point numbers exactly.
• Full 32-bit: Enough precision to store all single precision IEEE floating point numbers exactly.

This parameter allows you to choose the URL of the mapping service to be used by the OGC Open GeoSMS. The default value is Google Maps.

The ellipsoid used for the conversion. This can be any ellipsoid name supported by FME.

The type of lettering used can be WGS84 or Bessel.

The granularity of the resulting code is determined by the specified Precision which is an integer from 0 to 5 (inclusive). A precision of 5 locates a point within 1-meter square and a precision of 0 locates a point within 100-km square.

If Geometry Encoding is Microsoft SQL Server Binary, choose whether it is a serialized Geometry or Geography.