What Are the Limitations of the Geometry Data Type?
The geometry data type offers exciting possibilities for map-based visualizations and advanced spatial analysis. While there are some limitations to the geometry data type, understanding them helps you make the most of its capabilities.
Limitations with the geometry data type columns:
- Geometry columns can't be:
- Used as joins between database tables
- Used as objects to drill on
- Dragged into any Filter grammar field
- Used to pass context in a custom data action
- Clicked to filter a selection of shapes
- Rendered in maps on mobile devices
- Used in advanced analytics functions like Forecasting, Clustering, Outlier/Non-Outlier, Reference Line, and Trend Line
- Geometry columns:
- Can only be placed in the Category grammar field for a map visualization. The content of a geometry column is only valid when used in a map or as an argument for a spatial calculation
- Are only valid when used in a map, or as an argument for a spatial calculation
- Geometry data have limitations for use in data flows.
- Spatial joins or joins between geometry data types from different database tables or datasets aren’t supported.
- Geometry data type records must each be under 128 kilobytes. If a record
in a data source has a geometry expression where the size is above 128 kilobytes,
the projection for this record doesn’t show on a map.
- For example, suppose a table contains data about US states. The table has 50 rows, each containing a geometry data type column with the polygon representing the state shape. Assume one of the states has a very high resolution for its border definition, and the size of the geometry object string for this state amounts to more than 128 kilobytes. Now suppose Oracle Analytics creates the dataset, and queries made to the dataset honor every single column from the dataset. If geometries are projected on a map, then only 49 states are shown on the map. The state that's larger than 128 kilobytes isn't shown on the map, and a warning displays in the dialog for the Information icon on the map.
If the size of a geometry shape is over 128 kilobytes, then you can try these alternative workarounds:
- Simplify the definition of the polygon (reduce the number of points to delimit the polygon), and therefore reduce its technical storage.
- Split the polygon into two or more distinct polygons to break down the size of each piece.
- For example, suppose a table contains data about US states. The table has 50 rows, each containing a geometry data type column with the polygon representing the state shape. Assume one of the states has a very high resolution for its border definition, and the size of the geometry object string for this state amounts to more than 128 kilobytes. Now suppose Oracle Analytics creates the dataset, and queries made to the dataset honor every single column from the dataset. If geometries are projected on a map, then only 49 states are shown on the map. The state that's larger than 128 kilobytes isn't shown on the map, and a warning displays in the dialog for the Information icon on the map.
- Oracle Analytics supports 2-D map coordinate systems only. Any known coordinate system defined in the data source is projected to WGS 84 (EPSG 4326).
- File-based data sources containing geometry data must be Text/CSV files with the Geometry field expressed as Well-Known Text (WKT) formats. WKT is a text markup language for representing vector geometry objects. It can represent distinct geometry objects such as Points, MultiPoints, LineString, Polygons, and MultiPolygons. WKT format syntaxes such as GeometryCollection or FeatureCollection aren’t supported.
- Files with the GeoJSON format with geometry data aren’t supported for importing as datasets with geometries in Oracle Analytics. In order to create a dataset with a geometry column, you must first convert GeoJSON files into CSV with WKT geometry formats, or load them into an Oracle database with the SDO.Geometry format.