This topic covers functions built into the Manifold query engine, called SQL functions or query functions, that begin with Coord. Functions that begin with Coord provide numerous utility functions for manipulating coordinates and coordinate systems, for example, converting geometry from one coordinate system into another, or for georeferencing. For both raster and vector data.
The Manifold query engine also supports declaring and calling functions, including script functions, functions in external files and compiled functions as .NET assemblies.
Manifold has so many SQL functions they have been grouped into several topics:
The list of functions below uses the same nomenclature as the function templates in the Query Builder. SQL functions take arguments as specified in angle < > brackets. The data type or value type the function returns is given after the : colon. For example, Chr(<value>) : <string> takes a numeric <value> and returns a text <string>, as noted in the description a string that is a single character. CoordSystems() : <table> takes no arguments and returns a table.
Examples in the list below which use an ? expression evaluation command are intended to be run in a Command Window. Do not add a semicolon ; character when using the ? command in a Command window. When using the ? command we use CALL when the function returns more than just a value, for example, when it returns a table.
Indexes are always zero based: for example, in an object consisting of three branches the first branch is branch 0, the second is branch 1 and the third is branch 2.
This is a long list, so to find a function it is best when viewing this topic in a browser to do a Ctrl-F to open a Find box and to enter the function name of interest to be able to jump to that function. The list in this topic is comprehensive but new items are often added with updates to Manifold and may appear in the product before they appear in this documentation. See the list in the query builder tab of the Command Window for an authoritative list of operators, commands and functions.
See the Identifiers, Constants and Literals topic for some useful constants. For information on functions that use a <filter> argument or which produce a filter definition matrix, see the How Matrix Filters Work topic.
CoordConvert(<converter>, <geom>) : <geom> |
Converts a geom from one coordinate system to another. The function takes a coordinate converter object and a geom value, and returns a new geom value. |
CoordConverterIsIdentity(<converter>) : <value> |
takes a coordinate converter object and returns true if it represents an identity operation (performs no conversion). |
CoordConverterIsScaleShift(<converter>) : <value> |
CoordConverterIsScaleShift returns true if the conversion is limited to scale and shift. |
CoordConverterIsScaleShiftSwap(<converter>) : <value> |
CoordConverterIsScaleShiftSwap returns true if the conversion is limited to scale, shift and coordinate swap (XY to YX or vice versa). |
CoordConverterIsXYZ(<converter>) : <value> |
CoordConverterIsXYZ returns true if either target or source coordinate system is cartesian XYZ. |
CoordConverterMake(<target>, <source>) : <converter> |
Takes the definitions of target and source coordinate systems (in that order) and creates a coordinate converter object. Coordinate converter objects are treated syntactically like a table, so we have to write
CALL CoordConverterMake(...)
Returns NULL if an coordinate converter object cannot be created. That can happen due to an impossible combination of parameters in either of the coordinate systems. |
CoordConverterMakePath(<target>, <source>, <hint>, <strict>): <converter> |
Takes a pair of coordinate system and a conversion path hint, and returns a coordinate converter object that can be used to convert coordinates between the systems. Coordinate converter objects are treated syntactically like a table, so we have to write
CALL CoordConverterMakePath(...)
The conversion path hint can be either 'EPSG:xxx' with the EPSG code of the transform to use in the path, or 'GRID:xxx' with the name of the grid file of the transform to use in the path. For a list of transforms that can be used to convert coordinates between the specified systems, use CoordTransformChoices.
Returns NULL if an coordinate converter object cannot be created. That can happen due to an impossible combination of parameters in either of the coordinate systems, or due to an invalid coordinate conversion path, or due to a path that references a missing or invalid grid file. |
CoordConverterMakeWarpNumeric(<geom-from-to>, <type>): <converter> |
Takes a line geom containing warp coordinates and a numeric type code for the warp, returns a coordinate converter object that performs the warp. Coordinate converter objects are treated syntactically like a table, so we have to write
CALL CoordConverterMakeWarpNumeric(...)
Each branch of the line geom is interpreted to contain the source location as the first coordinate and the target location as the second coordinate. The easiest way to understand how the line geom is structured is to set up georeferencing using two or three control points and to then press Edit Query in the Register pane to see how the resulting SQL is arranged.
The numeric type code is one of the following values, corresponding to the desired warp method:
0 = auto (currently picks order 1, affine), 1 = order 1, affine 2 = order 1, projective 3 = order 1, shift + uniform scale 4 = order 1, shift + uniform scale + rotate 5 = order 1.5, affine + cross-product 6 = order 2 7 = order 3
Returns NULL if an coordinate converter object cannot be created.
See the Register pane topic for a discussion of methods. |
CoordConverterMakeWarpThinPlateSpline (<geom-from-to>): <converter> |
Takes a line geom containing warp coordinates and returns a coordinate converter object that performs the warp using a thin-plate spline method. Coordinate converter objects are treated syntactically like a table, so we have to write
CALL CoordConverterMakeWarpTriangulation(...)
Each branch of the line geom is interpreted to contain the source location as the first coordinate and the target location as the second coordinate. The easiest way to understand how the line geom is structured is to set up georeferencing using two or three control points and to then press Edit Query in the Register pane to see how the resulting SQL is arranged.
Returns NULL if an coordinate converter object cannot be created. |
CoordConverterMakeWarpTriangulation (<geom-from-to>): <converter> |
Takes a line geom containing warp coordinates and returns a coordinate converter object that performs the warp using a triangulation method. Coordinate converter objects are treated syntactically like a table, so we have to write
CALL CoordConverterMakeWarpTriangulation(...)
Each branch of the line geom is interpreted to contain the source location as the first coordinate and the target location as the second coordinate. The easiest way to understand how the line geom is structured is to set up georeferencing using two or three control points and to then press Edit Query in the Register pane to see how the resulting SQL is arranged.
Returns NULL if an coordinate converter object cannot be created. |
CoordConverterSteps(<converter>) : <table> |
Takes a coordinate converter object and reports conversion steps as a table. |
CoordConvertPoint(<converter>, <valuex2>) : <valuex2> |
Takes a coordinate converter object and an XY coordinate and returns the converted coordinate. |
CoordConvertPoint3(<converter>, <valuex3>) : <valuex3> |
Takes a coordinate converter object and an XYZ coordinate and returns the converted coordinate. |
CoordConvertRect(<converter>, <valuex4>, <intermediate>) : <valuex4> |
Takes a coordinate converter object, a rect value, and the optional number of intermediate divisions, and converts the rect to the desired coordinate system. If the number of intermediate divisions is positive, the function creates a grid of intermediate coordinates covering the rect, projects all these coordinates and uses the results to compute the shape of the resulting rect more accurately (useful when the projection is curvilinear). |
CoordConvertTile(<converter>, <image>, <valuex4>, <interpolation>) : <tile> |
Converts coordinate systems of tiles for images similar to how CoordConvert converts coordinate systems for geoms. The first argument is a converter from the coordinate system of the original image to the coordinate system of the new image. The second argument is the original image (passing the table with the image data will not work - we must pass the image). The third argument is the rectangle of the tile to produce in the coordinate system of the new image. If the rectangle is denormalized (xmin > xmax or ymin > ymax) or empty (xmin = xmax or ymin = ymax), the function returns NULL. If the rectangle coordinates are fractional, they are rounded to full pixels: xmin and ymin are rounded down (Floor) and ymin and ymax are rounded up (Ceil). The <interpolation> argument specifies interpolation type: 0 = nearest neighbor, 1 = bilinear, or 2 = bicubic. |
CoordConvertTileSet(<converter>, <image>, <valuex4>, <divisions>, <interpolation>): <table> |
Takes a coordinate converter object, an image in the source coordinate system, a rectangle in the target coordinate system, and an interpolation argument specifies interpolation type: 0 = nearest neighbor, 1 = bilinear, or 2 = bicubic. Returns a table with image tiles projected to the target coordinate system using the standard projection method. The result table returned by the function supports a BTREE index on XY fields, which allows efficiently using the function in a join directly without having to copy the returned data into a different table. |
CoordConvertTileSetDirect(<converter>, <image>, <valuex4>, <divisions>): <table> |
Takes a coordinate converter object, an image in the source coordinate system, a rectangle in the target coordinate system and a number of pixel subdivisions, and returns a table with image tiles projected to the target coordinate system, using the sub-pixel projection method.
When 0 is specified for the number of pixel subdivisions, the function uses nearest neighbor instead of weighted averages to create result pixels. Use this for reprojecting images with values, such as classification codes, that must not be averaged. The maximum number of pixel subdivisions is 8, to prevent against erroneously passing an unreasonably high value and spending a lot of time performing unnecessary computations.
The result table returned by the function supports a BTREE index on XY fields, which allows efficiently using the function in a join directly without having to copy the returned data into a different table. |
CoordConvertTileSetDirectPar(<converter>, <image>, <valuex4>, <divisions>, <threads>): <table |
A parallel form of the CoordConvertTileSetDirect function that takes a parameter for the suggested number of threads as encoded in the JSON <config> string as "threads". If the number of threads is less than or equal to 1 the CoordConvertTileSetDirect function will be executed. Use ThreadConfig to generate a JSON string with the desired number of threads.
The result table returned by the function supports a BTREE index on XY fields, which allows efficiently using the function in a join directly without having to copy the returned data into a different table. |
CoordConvertTileSetPar(<converter>, <image>, <valuex4>, <divisions>, <threads>, <interpolation>): <table |
A parallel form of the CoordConvertTileSet function that takes a parameter for the suggested number of threads as encoded in the JSON <config> string as "threads". If the number of threads is less than or equal to 1 the CoordConvertTileSet function will be executed. Use ThreadConfig to generate a JSON string with the desired number of threads. The result table returned by the function supports a BTREE index on XY fields, which allows efficiently using the function in a join directly without having to copy the returned data into a different table. |
CoordConvertTrace(<converter>, <valuex3>) : <table> |
Takes a coordinate converter object and an XYZ coordinate and reports conversion steps as well as the intermediate conversion result after each step as a table. |
CoordDatum(<manifold>) : <value> |
Returns the definition of the datum with the specified Manifold ID. |
CoordDatumDefault() : <value> |
returns the definition of the default datum. |
CoordDatumEpsg(<epsg>) : <value> |
Returns the definition of the datum with the specified EPSG code. |
CoordDatumParameters() : <table> |
Returns a list of datum parameters.
? CALL CoordDatumParameters()
|
CoordDatums() : <table> |
Returns a list of datums in the internal coordinate system database.
? CALL CoordDatums()
|
CoordMeasureArea(<measure>, <geom>): <value> |
Takes a measure object and a geom for an area object and returns the area of the area object. The geom must be an area in the coordinate system of the measure object. The returned value is in the squared units of the measure object. |
CoordMeasureBearing(<measure>, <geom>): <value> |
Takes a measure object and a geom for a line object and returns the bearing of the line. The geom must be a line with a single branch in the coordinate system of the measure object, the bearing is computed from the first to last coordinate of the line. The returned value is in degrees. |
CoordMeasureBearingPoint(<measure>, <valuex2>, <valuex2>): <value> |
Takes a measure object and a pair of point (x2) values and returns the bearing from the first point to the second point. The point values must be in the coordinate system of the measure object. The returned value is in degrees. |
CoordMeasureDistancePoint(<measure>, <valuex2>, <valuex2>): <value> |
Takes a measure object and a pair of point (x2) values and returns the distance between the points. The point values must be in the coordinate system of the measure object. The returned value is in the units of the measure object. |
CoordMeasureLength(<measure>, <geom>): <value> |
Takes a measure object and a geom and returns length. The geom must be an area or a line in the coordinate system of the measure object. The returned value is in units of the measure object. |
CoordMeasureMake(<system>, <unit>, <geodetic>): <value> |
Takes a coordinate system definition, a unit name and a geodetic boolean flag and returns a measure object (similar to a coordinate converter object) that can be used to perform measurements.
As with the CoordConverterMake function, the measure object returned by CoordMeasureMake is treated as a table and thus the function must be invoked with a CALL.
For example, suppose our Mexico table has area geoms in the default Latitude / Longitude coordinate system. We can get the first argument for CoordMeasureMake , the definition of that default Latitude / Longitude coordinate system, by using CoordSystemDefaultLatLon().
To get the geodetic area measurement we could write:
SELECT CoordMeasureArea( CALL CoordMeasureMake(CoordSystemDefaultLatLon(), 'Meter', TRUE), [Geom] ) FROM [Mexico];
More efficiently, there is no need to recompute CoordMeasureMake for each record when it could be done once as part of the expression context:
VALUE @measure TABLE = CALL CoordMeasureMake( CoordSystemDefaultLatLon(), 'Meter', TRUE);
SELECT CoordMeasureArea(@measure, [Geom]) FROM [Mexico];
|
CoordMeasureRadius(<measure>, <geom>): <value> |
Takes a measure object and a geom and returns the radius of the minimum enclosing circle for the geom. The geom must be an area or a line in the coordinate system of the measure object. The returned value is in units of the measure object. |
CoordSystem(<manifold>) : <value> |
Returns the definition of the coordinate system with the specified Manifold ID. We can see a list of all coordinate systems with their EPSG IDs and Manifold IDs using CoordSystems().
? CoordSystem(612)
|
CoordSystemBase(<string>): <value> |
Takes a coordinate system string and returns the base Latitude / Longitude coordinate system. |
CoordSystemDefault() : <value> |
Returns the definition of the default coordinate system.
? CoordSystemDefault()
|
CoordSystemDefaultLatLon() : <value> |
Returns the definition of the default lat/lon coordinate system.
? CoordSystemDefaultLatLon()
|
CoordSystemEpsg(<epsg>) : <value> |
Returns the definition of the coordinate system with the specified EPSG code.
? CoordSystemEpsg(4326)
|
CoordSystemForceXY(<string>): <value> |
Takes a coordinate system string and returns the same coordinate system with axes forced to XY order. If the original coordinate system definition is an EPSG or SRID code, the new coordinate system is the same code with overrides. |
CoordSystemMatchEpsg(<string>): <epsg> |
Takes a coordinate system definition and returns the corresponding EPSG code. The EPSG code is taken from the name. The definition of the referenced EPSG system is then checked against coordinate system parameters without local scales and offsets. |
CoordSystemMatchEpsgBase(<string>): <epsg> |
Takes a coordinate system definition and returns the EPSG code corresponding to its base lat/lon coordinate system. The EPSG code is taken from the name of the base. The definition of the referenced EPSG system is then checked against datum parameters. |
CoordSystemOverride(<string>, <json>) : <value> |
Takes a coordinate system string and a JSON string with the parameter overrides, and composes a new coordinate system string merging the two together.
ALTER Table [WaterwaysTable] ( ADD PROPERTY 'FieldCoordSystem.Geom' CoordSystemOverride('EPSG:4269', '{ "Axes":"XY" }') );
|
CoordSystemParse(<string>) : <value> |
Takes a string (JSON / XML / any of the subformats with prefixes like "EPSG:xxx") and parses it into a coordinate system. Parsing coordinate system data supports OSGEO:xxx codes (used in TMS), as well as ESRI and OPENLAYERS codes for web Mercator. |
CoordSystemParseEpsg(<string>) : <epsg> |
Takes a coordinate system string, checks if it specifies an EPSG code, and if so, returns the code. |
CoordSystemParseOverrides(<string>) : <json> |
Takes a coordinate system string and returns parameter overrides if they exist. |
CoordSystemParseSrid(<string>) : <srid> |
Takes a coordinate system string, checks if it specifies an SRID code (a coordinate system local to a database), and if so, returns the code. |
CoordSystemParseSridSubtype(<string>) : <subtype> |
Takes a coordinate system string, checks if it specifies an SRID code, and if so, returns the SRID subtype. For example, 'SRID:SDE:2230' returns 'SDE'. The table with the definition of the coordinate system is named 'MFD_SRID_SDE'. |
CoordSystemPlain(<string>): <value> |
Takes a coordinate system string and returns the same coordinate system with local offsets set to 0 and local scales set to 1. |
CoordSystems() : <table> |
Returns a list of coordinate systems in the internal database.
? CALL CoordSystems()
|
CoordSystemScaleXY(<string>): <valuex2> |
Takes a coordinate system definition and returns a FLOAT64X2 value for local scales for X and Y. |
CoordSystemScaleXYToUnit(<system>, <unit>): <valuex2> |
Takes a coordinate system and a unit name and returns a FLOAT64X2 value for X and Y scales that are required to scale the geom in the coordinate system to the specified unit. If the specified coordinate system and unit are incompatible (for example, if the coordinate system is Pseudo Mercator and thus metric, but the unit name is degree), the function returns a NULL value.
The idea behind CoordSystemScaleXYToUnit is to use it together with GeomScale and GeomScaleRev instead of more complex coordinate converter functions, to perform measurements in the desired units when the math required is minimal.
For example, if we want to find a location on a line two miles from the start of the line, we could call CoordSystemScaleXYToUnit and pass mi as the name of the unit to get the scale required to convert the line coordinates into miles. We can then call GeomScale with that scale on a line, call GeomCoordLine and pass 2 as a distance, then convert the returned x2 value to a geom using GeomMakePoint, and finally call GeomScaleRev with the exact same scale as before to convert the created geom to the coordinate system of the line. |
CoordSystemScaleXYZ(<system>, <forceMeters>): <scalex3> |
Given a coordinate system, composes and returns XYZ scales as an x3 value. If the coordinate system is metric, the values are in meters. If the coordinate system is lat/lon and the forceMeters parameter is FALSE, the XY values are in degrees and the Z value is in meters. If the coordinate system is lat/lon and the forceMeters parameter is TRUE, the XY values are converted to meters based on the scale at the equator. |
CoordSystemScaleXYZBounds(<system>, <forceMeters>, <boundsx4>): <scalex3> |
Same as CoordSystemScaleXYZ, except that lat/lon scale is converted to meters based on the scale at the center of the given bounds. Bounds are a rectangular extent specified by a four part (x4) number given the diagonally opposite corners of the rectangle as x1,y1, x2 y2 values. |
CoordSystemTypeParameters(<system>, <withScalesShifts>) : <table> |
Returns a list of parameters for the specified coordinate system type.
Example:
? CALL CoordSystemTypeParameters('Lambert Conformal Conic', TRUE)
|
CoordSystemTypes() : <table> |
Returns a list of supported coordinate system types.
? CALL CoordSystemTypes()
|
CoordSystemWkt(<string>, <strict>): <wkt> |
Takes a coordinate system definition and a <strict> boolean flag and returns the WKT (PRJ) representation. If the coordinate system cannot be represented as WKT, the function returns a NULL value. If the <strict> flag is false, the function maps coordinate systems that cannot be represented as WKT to close variants. For example, the Lambert conformal conic variant for Michigan is mapped to Lambert conformal conic.
? CoordSystemWKT('EPSG:4326', TRUE)
Returns the WKT string:
GEOGCS["GCS_WGS_84", DATUM["D_WGS_84", SPHEROID["WGS_1984", 6378137, 298.25722356300156]], PRIMEM["Greenwich", 0.0], UNIT["Degree", 0.017453292519943295], AXIS["Lat", NORTH], AXIS["Lon", EAST]] |
CoordSystemWkt2(<string>, <strict>): <wkt2> |
Takes a coordinate system definition and a <strict> boolean flag and returns the WKT2 (updated version of WKT) representation. If the coordinate system cannot be represented as WKT2, the function returns a NULL value. If the <strict> flag is false, the function maps coordinate systems that cannot be represented as WKT2 to close variants. For example, the Lambert conformal conic variant for Michigan is mapped to Lambert conformal conic.
? CoordSystemWKT2('EPSG:4326', TRUE)
Returns the WKT2 string:
GEODCRS["WGS 84", DATUM["WGS 84", ELLIPSOID["WGS 1984", 6378137, 298.257223563, LENGTHUNIT["metre", 1.0]]], CS[ellipsoidal, 2], AXIS["latitude", north, ORDER[1]], AXIS["longitude", east, ORDER[2]], ANGLEUNIT["Degree", 0.017453292519943295], ID["EPSG", 4326]]
See the ESRI presentation PDF on WKT2. |
CoordSystemXml(<system>) : <xml> |
Takes a coordinate system definition and converts it to Manifold 8 XML. Not all systems can be converted (example: EPSG:5515 can not be converted, because the system type is modified Krovak and Manifold 8 does not support that), but the vast majority can.
? CoordSystemXml('EPSG:4200')
? CoordSystemXml('{ "System": "Azimuthal Equidistant" }')
|
CoordTransform(<manifold>) : <value> |
Returns the definition of the coordinate transform identified by the specified Manifold ID. Use CoordTransforms() to see a list of IDs for transforms.
? CoordTransform(399)
Manifold ID 399 is the same transform as EPSG:1064.
|
CoordTransformChoices(<target>, <source>): <table> |
Takes a pair of coordinate systems and returns a table of transforms that can be used to convert coordinates between them. |
CoordTransformEpsg(<epsg>) : <value> |
Returns the definition of the coordinate transform identified by the specified EPSG code. Use CoordTransforms() to see a list of EPSG codes for transforms.
? CoordTransformEpsg(1064)
EPSG:1064 is the same transform as Manifold ID 399.
|
CoordTransforms() : <table> |
Returns a list of coordinate system transforms in the internal database.
? CALL CoordTransforms()
See the SQL Example: List Transformation Grids topic. |
CoordTransformTypeParameters(<transform>) : <table> |
Returns a list of parameters for the specified coordinate system transform type. The returned table contains a field for the parameter name and a field for the default value.
? CALL CoordTransformTypeParameters('Complex Polynomial (3)')
|
CoordTransformTypes() : <table> |
Returns a list of supported coordinate transform types.
? CALL CoordTransformTypes()
|
CoordUnit(<manifold>) : <value> |
Returns the definition of the coordinate system unit for the coordinate system unit identified by the specified Manifold ID. Use CoordUnits() to see a list of Manifold IDs for units.
? CoordUnit(17)
The coordinate system unit specified by Manifold ID 17 is the same, Clarke's Foot, as specified by EPSG:9005.
|
CoordUnitByName(<name>) : <value> |
Takes a coordinate system unit name and returns the unit definition. Remember to escape any single quote ' characters used in the name of a unit.
? CoordUnitByName('Clarke\'s Foot')
|
CoordUnitDefault() : <value> |
Returns the definition of the default / default coordinate system unit.
? CoordUnitDefault()
|
CoordUnitDefaultLatLon() : <value> |
Returns the definition of the lat/lon coordinate system unit.
? CoordUnitDefaultLatLon()
|
CoordUnitEpsg(<epsg>) : <value> |
Returns the definition of the coordinate system unit for the coordinate system unit identified by the specified EPSG code. Use CoordUnits() to see a list of EPSG codes for units.
? CoordUnitEpsg(9005)
The coordinate system unit specified by EPSG:9005 is the same, Clarke's Foot, as specified by Manifold ID 17.
|
CoordUnits() : <table> |
Returns a list of coordinate system units. Returned tables contain a field for the Manifold ID, a field for the corresponding EPSG code, which can be NULL, a JSON definition of the described object, and sometimes additional data.
? CALL CoordUnits()
|
CoordUnitScale(<unit>): <scale> |
Takes a coordinate system unit definition, parses it and returns the unit scale as a number. |
New functions - The list in this topic is intended to be comprehensive but might be not up to date. New items are often added with updates to Manifold and may appear in the product before they appear in this documentation. See the list in the query builder tab of the Command Window for an authoritative list of operators, commands and functions.
GPGPU - Manifold automatically uses GPU parallelism (see the GPGPU topic) in functions where it makes sense to do so and when workflow is such that it is worth it to dispatch to GPU instead of simply using CPU parallelism. In many cases both CPU parallelism and GPU parallelism will be used. For example, all Kriging implementations (standard, median polish, and regression Kriging) use GPU, if available, to compute model parameters together with CPU parallelism in other parts of the function's operation. GPU cards are so cheap that it doesn't make sense to try to guess when it pays to use GPGPU: simply install a GPU card, at least a cheapo GPU card. Always. Do not overthink it. Just install an NVIDIA GPU card.
Performance of query functions when projecting images - For the standard projection method there are two ways to perform the projection with multiple threads: either use CoordConvertTile in a SELECT with THREADS, or use CoordConvertTileSetPar.
Curvilinear objects - Functions for GML, WKB and WKT support curvilinear objects for all types supported by each format: circular arcs, ellipsoidal arcs, splines for GML and circular arcs for WKB and WKT.
Division by zero - returns NULL.
All types of values - Operators and functions generally support all types of values so that, for example, we can use comparison or boolean operators on tiles and not just on scalar values.
Everything Math - For a handy reference to anything in mathematics, see the Wolfram MathWorld site. Thank you, Wolfram!
Command Window - Query Builder
Identifiers, Constants and Literals
Example: Create and Run a Query - See how the different parts of a command window operate when creating and running SQL queries. Includes use of the Log tab as well as the ?expression and !fullfetch commands.
Example: Transfer DEM Terrain Heights to Areas in a Drawing - Given a map with an image layer that shows terrain heights taken from a DEM, and a drawing layer that contains areas, using a small SQL query we transfer the average terrain height within each area to that area as a Height attribute for the area. Easy!
SQL Example: Process Images with 3x3 Filters - Shows a step-by-step example of developing an SQL query that takes a query written by the Edit Query button and then modifies that query into a general purpose query that can apply any 3x3 filter. This makes it easy to use matrix filters we find on the web for custom image processing. We extend the query by using parameters and adding a function, and then show how it can be adapted to use a 5x5 filter.
SQL Example: Process Images using Dual 3x3 Filters - A continuation of the above topic, extending the example query to utilize two filters for processing, as commonly done with Sobel and Prewitt two filter processing.
SQL Example: Process RGB Images using Matrix Filters - A continuation of the above two topics, extending the example query to process three channel, RGB images.
SQL Example: Miscellaneous SQL Functions - A variety of small examples using SQL functions.
SQL Example: GeomOverlayAdjacent Function - Using the GeomOverlayAdjacent function, an example that shows how this function and similar functions such as GeomOverlayContained, GeomOverlayContaining, GeomOverlayIntersecting and GeomOverlayTouching operate.
SQL Example: GeomOverlayTopologyUnion Function - A continuation of the SQL Example: GeomOverlayAdjacent Function example, using the GeomOverlayTopologyUnion function, an example that shows how this function and similar functions such as GeomOverlayTopologyIdentity, GeomOverlayTopologyIntersect and GeomOverlayTopologyUpdate operate.
Example: Merge : areas (dissolve) - In this example we combine multiple area objects into a single area object by using the Merge template in the Transform pane, using the areas (dissolve) option. A drawing of French regions shows some regions as more than one area. We would like each region to be one area so the table of regions has one record per region.
SQL Example: Learn SQL from Edit Query - Merging Areas - We learn how to write an SQL query that does a Merge : area (dissolve) operation by cutting and pasting from what the Edit Query button automatically generates.
Example: Use a Transform Expression to Create Buffers in a Drawing - Use the Expression tab of the Transform pane to create three different sizes of buffers for different lines in a drawing and then automatically create a query which does the same thing. Includes examples of using the Add Component button and also the Edit Query button.
Example: Clip Areas with a Transform Expression - Use the Expression tab of the Transform pane to clip areas in a drawing to fit within horizontal bounds. Includes examples of using the Add Component button and also the Edit Query button.
Example: Transform Templates, Expressions and Queries - We learn to use a function by clicking on a template in the Transform pane, seeing what it does in a preview, looking at the query Manifold creates and then trying out the function in the Expression tab.
SQL Example: List Transformation Grids - In this example we use a few snippets of easy SQL to list NTv2 and NADCON transformation grids that are available within the grids.dat compressed collection of transformation grid files. Grid transformation files can be used when creating custom base coordinate systems, for NADCON / HARN / HPGN and NTv2 high accuracy transformations that use grid files.