# About PostGIS

### About PostGIS

[PostGIS](https://postgis.net/\)) is an open-source extension for PostgreSQL to support geographic and spatial data types that enable advanced geo-spatial analysis and queries. The good thing about PostGIS is, that you can work with spatial data in the same database alongside your non-spatial data, integration simplifies data management and querying.

In spatial databases like PostGIS, spatial coordinates are in longitude and then latitude but in web mapping APIs like Google Maps, spatial coordinates are often in the order of latitude then longitude. <https://postgis.net/documentation/tips/lon-lat-or-lat-lon/>

#### PostGIS Terminology <a href="#m_-3632329581542114881gmail-geodistancefilteringinpostgisvs.elasticsearch-postgisterminology" id="m_-3632329581542114881gmail-geodistancefilteringinpostgisvs.elasticsearch-postgisterminology"></a>

The primary **geospatial** data types are:

1\. **Geometry**: This data type represents data in a **two-dimensional Cartesian plane**. It can store **points**, **multi-points**, lines, polygons, circles, and rectangles.

2\. **Geography**: The data type is similar to `geometry`, but it represents data in a **round-earth coordinate system**. It's better suited for storing data that covers large areas or tracks movement across the surface of the earth.

[Why (Not) Use Geography](http://postgis.net/workshops/postgis-intro/geography.html#why-not-use-geography)

If your data is geographically compact (contained within a state, county, or city), use the geometry type with a Cartesian projection. Both types are interchangeable but `geometry` types support more functions.

**SRID** stands for `"Spatial Reference ID"`. It is a numerical code used to uniquely identify a spatial reference system in the context of geospatial data.\
For example: **SRID** `4326` corresponds to the WGS 84 geographic coordinate system, which is commonly used for representing **latitude** and **longitude** coordinates on the earth's surface.

In our case, we are choosing `geography` data type although we aren't searching/querying the large areas, and for geographically compact areas. The calculations on a sphere (Geography) are computationally far more expensive than Cartesian calculations (Geometry). Here’s the reason why we choose `geography`

* Our use case is very limited, and we are going to use only a few functions `st_dwithin` or `st_distance` and we have a radius given in meters not in radians/degrees.
* With `geometry` type, we have to cast into `geography` which can be a little expensive when we have millions of records.
* Spatial Index also needs to be created as per the query needs which means when we are using `geography` type or functions in our queries, we may have to create spatial indexes by explicit casting.
* We knew calculations on a sphere (Geography) are computationally far more expensive than Cartesian calculations (Geometry) although we can skip spherical calculations on Geography type to perform faster evaluation by using `use_spheroid = false` option.