A geography datatype represents two dimensional spacial objects in an elliptic coord system.
The difference from geometry and geography type:
PostGIS 1.5 introduced a new spatial type called geography, which uses geodetic measurement instead of Cartesian measurement. Coordinate points in the geography type are always represented in WGS 84 lon lat degrees (SRID 4326), but measurement functions and relationships STDistance, STDWithin, STLength, and STArea always return answers in meters or assume inputs in meters.
What is best to use? It depends:
When choosing between the geometry and geography type for data storage, you should consider what you’ll be using it for. If all you do are simple measurements and relationship checks on your data, and your data covers a fairly large area, then most likely you’ll be better off storing your data using the new geography type. Although the new geography data type can cover the globe, the geometry type is far from obsolete. The geometry type has a much richer set of functions than geography, relationship checks are generally faster, and it has wider support currently across desktop and web-mapping tools
Fallback policy: If this type is not supported, an error will be raised.
Defining a Geography type attribute
Where this DataType is being used.
Override this method to emit an error or a warning if the Data Type, as it is configured, is not compatible with the current dialect.
The dialect using this data type.
Returns a copy of this DataType, without usage context. Designed to re-use a DataType on another Model.
Escapes a value for the purposes of inlining it in a SQL query. The resulting value will be inlined as-is with no further escaping.
The value to escape.
This method is called when AbstractQueryGenerator needs to add a bind parameter to a query it is building. This method allows for customizing both the SQL to add to the query, and convert the bind parameter value to a DB-compatible value.
If you only need to prepare the bind param value, implement toBindableValue instead.
This method must return the SQL to add to the query. You can obtain a bind parameter ID by calling BindParamOptions#bindParam with the value associated to that bind parameter.
An example of a data type that requires customizing the SQL is the GEOMETRY data type.
Called when a value is retrieved from the Database, and its DataType is specified. Used to normalize values from the database.
Note: It is also possible to do an initial parsing of a Database value using AbstractDialect#registerDataTypeParser. That normalization uses the type ID from the database instead of a Sequelize Data Type to determine which parser to use, and is called before this method.
The value to parse.
Used to normalize a value when Model#set is called. That is, when a user sets a value on a Model instance.
Returns a SQL declaration of this data type. e.g. 'VARCHAR(255)', 'TEXT', etc…
Checks whether the JS value is compatible with (or can be converted to) the SQL data type. Throws if that is not the case.
Generated using TypeDoc