Transform - Text: Compose

The Compose template appears in the template list when a variable length text field, of type nvarchar or varchar, has been picked in the Transform pane. It allows composition of standard forms of GeoJSON, GML, WKT, or URL text strings from various sources.

Compose

Compose a text value conforming to the syntax of the specified text standard:

geojson - Compose a GeoJSON text geometry specification from a geometry field and a coordinate system name.
gml - Compose a GML text geometry specification from a geometry field and a coordinate system name.
url - Compose a URL string from Scheme (http, https, ftp, etc.), Host, Port, User, Password, Path and Extra values.
url from base and relative - Compose a URL string by appending a Relative path URL string to an absolute URL Base string.
wkt - Compose a WKT text geometry specification from a geometry field.
wkt2 - Compose a WKT2 text geometry specification from a geometry field.

Launch the template by choosing a text field and then double-clicking the Compose template. When the template launches we can specify options.

Compose : geojson

Compose a GeoJSON text geometry specification from a geometry field and a coordinate system name. The operation provides a way to extract geometry from a Manifold geometry type, such as a geom, into GeoJSON text representation of the geometry.

We use our sample drawing.

The drawing's table has a Geom field giving the geometry for each object in native Manifold geometry data type. We have created an nvarchar text field called GeoJSON, which we will populate with geometry in text GeoJSON form. Alternatively, we could have created the GeoJSON field using varchar text type. Many Manifold users get in the habit of using nvarchar all the time for text fields.

With the focus on the table, in the Transform pane we choose the GeoJSON field, and then we double-click the Compose template to launch it.

In the Compose template we choose geojson as the Compose option. We choose the Geom field as the Value from which we will extract geometry in GeoJSON text form.

The System box specifies the coordinate system to use. We enter a System value of EPSG:9840. Note that no quotes are used around the EPSG:9840 string for the System.

For the Result destination, we leave the default choice of Same Field. Press Transform.

The GeoJSON text field is immediately populated with the geometry for each object in text, GeoJSON form.

The full value of the GeoJSON string generated for the first record is:

In this example, we have used an EPSG code to show that an EPSG code can be used in a GeoJSON text representation of geometry, which is a great convenience for drawings that use EPSG codes to specify their projections.

A much longer GeoJSON string must be used in cases where the coordinate system used for geometry is not an EPSG code but instead is a custom definition, or a coordinate system specification constructed from the name of a coordinate system plus parameters.

For example, suppose the value of the FieldCoordSystem.Geom property of the Objects table above was:

{ "Axes": "XY", "Base": "WGS 84 (EPSG:4326)", "CenterLat": 0, "CenterLon": 0, "Eccentricity": 0.08181919084262149, "MajorAxis": 6378137, "Name": "WGS 84 \/ Pseudo-Mercator (EPSG:3857)", "System": "Pseudo Mercator", "Unit": "Meter", "UnitScale": 1, "UnitShort": "m" }

We could have copied that and entered it into the System box In that case the JSON string generated for the first record would have been the considerably longer:

{ "type": "Polygon", "coordinates": [ [ [ -526.500001064457, 268.50000015848167 ], [ -429.5000005859413, 222.5000000896422 ], [ -459.5000010256266, 333.500000304547 ], [ -526.500001064457, 268.50000015848167 ] ] ], "crs": { "type": "name", "properties": { "name": "{ \"Axes\": \"XY\", \"Base\": \"WGS 84 (EPSG:4326)\", \"CenterLat\": 0, \"CenterLon\": 0, \"Eccentricity\": 0.08181919084262149, \"MajorAxis\": 6378137, \"Name\": \"WGS 84 \\\/ Pseudo-Mercator (EPSG:3857)\", \"System\": \"Pseudo Mercator\", \"Unit\": \"Meter\", \"UnitScale\": 1, \"UnitShort\": \"m\" }" } }, "bbox": [ -526.500001064457, 222.5000000896422, -429.5000005859413, 333.500000304547 ] }

GeoJSON text format cannot store curvilinear segments. Saving curved segments from Manifold or WKB binary geometry directly into GeoJSON format will simply replace curvilinear segments with single, straight line segments between the start and end coordinates of the former curvilinear segment, to produce shapes that usually are highly unlike the original shapes using curvilinear segments.

To avoid that effect, before converting Manifold or WKB binary geometry into GeoJSON, first run Clean : convert curves to lines with a reasonable number of segments in the Curve limit parameter, to approximate curvilinear segments with many straight line segments. When converting the result to GeoJSON, the many straight line segments will approximate the shape of the original curvilinear segments.

Compose : gml

Compose a GML text geometry specification from a geometry field and a coordinate system name. The operation provides a way to extract geometry from a Manifold geometry type, such as a geom, into GML text representation of the geometry.

We use our sample drawing.

The drawing's table has a Geom field giving the geometry for each object in native Manifold geometry data type. We have created an nvarchar text field called GML, which we will populate with geometry in text GML form. Alternatively, we could have created the GML field using varchar text type. Many Manifold users get in the habit of using nvarchar all the time for text fields.

With the focus on the table, in the Transform pane we choose the GML field, and then we double-click the Compose template to launch it.

In the Compose template we choose gml as the Compose option. We choose the Geom field as the Value from which we will extract geometry in GML text form.

The System box specifies the coordinate system to use. We enter a System value of EPSG:3857. Note that no quotes are used around the EPSG:3857 string for the System.

For the Result destination, we leave the default choice of Same Field. Press Transform.

The GML text values created are multiline text, with ellipses ... in the GML fields indicating the contents of the field continue on additional lines. We can see the full value by right-clicking into a cell and choosing Edit.

full value of the GML string generated for the first record is:

<?xml version="1.0" encoding="UTF-8"?>

<gml:patches>

<gml:PolygonPatch interpolation="planar">

<gml:exterior>

<gml:LinearRing>

<gml:posList>-526.500001064457 268.50000015848167 -429.5000005859413 222.5000000896422 -459.5000010256266 333.500000304547 -526.500001064457 268.50000015848167</gml:posList>

</gml:LinearRing>

</gml:exterior>

</gml:PolygonPatch>

</gml:patches>

</gml:Surface>

In this example, we have used an EPSG code to show that an EPSG code can be used in a GML text representation of geometry, which is a great convenience for drawings that use EPSG codes to specify their projections.

A much longer GML string must be used in cases where the coordinate system used for geometry is not an EPSG code but instead is a custom definition, or a coordinate system specification constructed from the name of a coordinate system plus parameters.

For example, suppose the value of the FieldCoordSystem.Geom property of the Objects table above was:

We could have copied that and entered it into the System box of the Transform dialog. In that case the GML string generated for the first record would have been the considerably longer:

<?xml version="1.0" encoding="UTF-8"?>

<gml:Surface xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:gml="http://www.opengis.net/gml/3.2" xsi:schemaLocation="http://www.opengis.net/gml/3.2 http://schemas.opengis.net/gml/3.2.1/gml.xsd" srsName="{ "Axes": "XY", "Base": "WGS 84 (EPSG:4326)", "CenterLat": 0, "CenterLon": 0, "Eccentricity": 0.08181919084262149, "MajorAxis": 6378137, "Name": "WGS 84 \/ Pseudo-Mercator (EPSG:3857)", "System": "Pseudo Mercator", "Unit": "Meter", "UnitScale": 1, "UnitShort": "m" }">

<gml:patches>

<gml:PolygonPatch interpolation="planar">

<gml:exterior>

<gml:LinearRing>

<gml:posList>-526.500001064457 268.50000015848167 -429.5000005859413 222.5000000896422 -459.5000010256266 333.500000304547 -526.500001064457 268.50000015848167</gml:posList>

</gml:LinearRing>

</gml:exterior>

</gml:PolygonPatch>

</gml:patches>

</gml:Surface>

Compose : url

Compose a URL string from Scheme (http, https, ftp, etc.), Host, Port, User, Password, Path and Extra values.

We begin with an example table with an nvarchar text field called URLs, and a single blank record.

With the focus on the table, in the Transform pane we choose the URLs field, and then we double-click the Compose template to launch it.

In the Compose template we choose url as the Compose option. By default the parameter boxes allow us to enter text values for the base and relative URLs. We can choose existing fields from the pull down menus for those boxes. We can also choose an existing field from the pull down menu for the Result box.

In the above illustration, we have entered typical values for constructing an FTP URL. For the scheme we use ftp, but we could just as easily build a URL for http or https. The port number for FTP is normally 21, but we use 123 for a contrived example. Most URLs do not include a user name and password, but we can construct a URL with a user name and password if we like, as shown above.

For the Result destination, we leave the default choice of Same Field. Press Transform.

The template instantly builds a URL in the URLs field.

This example above used literal text values we manually entered to assemble a single URL. The transform is more useful when automatically assembling URLs from fields.

Suppose our table has three records, each of which has values for Scheme, Host and Path fields, with the URLs field empty.

We can launch the transform choosing the corresponding fields for the various parameters. Empty parameters are ignored, as is the 0 for the Port. Press Transform.

The transform automatically builds URLs for us.

This transform uses the StringUrlMake SQL function.

Compose : url from base and relative

Compose a URL string by appending a Relative path URL string to an absolute URL Base string.

We begin with an example table that has three nvarchar fields. The Base URL field has a URL, the Rel Path field has a relative path, and the URLs field is empty.

With the focus on the table, in the Transform pane we choose the Base URL field, and then we double-click the Compose template to launch it.

In the Compose template we choose url from base and relative as the Compose option. By default the parameter boxes allow us to enter text values for the base and relative URLs. We can choose existing fields from the pull down menus for those boxes. We can also choose an existing field from the pull down menu for the Result box.

We choose the Base URL field for the Base parameter and the Rel Path field for the Relative parameter. For the Result we choose the URLs field. Press Transform.

The transform constructs URLs by appending the relative paths to the base URLs using understanding of how URLs should be constructed. For example, it knows to insert a forward / slash character between the base URL and the appended relative path for the last record.

Suppose the starting table had additional forward slashes in two of the Rel Path entries:

Repeating the transform, we get:

The transform knows that when a relative path starts with a forward / slash that indicates it is an absolute reference after the host. In the example above, for the first two records the relative path starts with a forward / slash character and thus overrides everything in the base URL after the host.

This transform uses the StringUrlAppend SQL function.

Compose : wkt

Compose : wkt2

Compose a WKT or WKT2 text geometry specification from a geometry field. The operation provides a way to extract geometry from a Manifold geometry type, such as a geom, into WKT (Well Known Text) or WKT2 text representation of the geometry.

We use our sample drawing.

The drawing's table has a Geom field giving the geometry for each object in native Manifold geometry data type. We have created an nvarchar text field called WKT, which we will populate with geometry in text WKT form. Alternatively, we could have created the WKT field using varchar text type. Many Manifold users get in the habit of using nvarchar all the time for text fields.

With the focus on the table, in the Transform pane we choose the WKT field, and then we double-click the Compose template to launch it.

In the Compose template we choose wkt as the Compose option. We choose the Geom field as the Value from which we will extract geometry in GML text form.

For the Result destination, we leave the default choice of Same Field. Press Transform.

The WKT text field is immediately populated with the geometry for each object in text, WKT form.

The full value of the WKT string generated for the first record is:

POLYGON((-526.500001064457 268.50000015848167, -429.5000005859413 222.5000000896422, -459.5000010256266 333.500000304547, -526.500001064457 268.50000015848167))

WKT reports whatever are the native coordinate numbers. The numbers above are the coordinate numbers for the Objects drawing that is in Pseudo-Mercator. If the drawing was in Latitude / Longitude, the numbers would be given as latitude and longitude values.

For example, a geom field that contains a point at longitude 10.687 and latitude 59.8876 using Latitude / Longitude projection would result in the WKT text:

POINT(10.687 59.8876)

This is the inverse operation of the Copy : wkt geometry text transform, which takes Manifold binary geometry and writes a WKT text representation.

Writing a coordinate system to WKT or WKT2 text fields writes authority codes for EPSG systems. Parsing a coordinate system from WKT or WKT2 text fields (such as when using the Copy text transform with wkt geometry in the Use parameter) reads authority codes for EPSG systems and, if the definition of the parsed system matches that of the referenced EPSG system, adds the EPSG code to the parsed system. That allows using transforms for that system specified in the EPSG database, such as transforms based on grid files.

Transform - Text: Compose

See Also