1

I am reading this about "Clustering on Indices" and in 25.2 says that

The geohash algorithm only works on data in geographic (longitude/latitude) coordinates, so we need to transform the geometries (to EPSG:4326, which is longitude/latitude) at the same time as we hash them. CREATE INDEX nyc_census_blocks_geohash ON nyc_census_blocks (ST_GeoHash(ST_Transform(geom,4326)));

I was under the impression that EPSG:4326 is available to both geometry and geography data. Also I thought that you can have geographic data by setting the column type as "geography" when creating a table or by geometry casting using the ::geography

Does the transformation to EPSG:4326 automatically turns the geometry to geography data?

3

I think you're confusing coordinate systems and data types. Geometry and geography are data types in PostGIS, which can have one of a number of coordinate systems, of which EPSG:4326 is one. EPSG:4326 is a coordinate system classified as a geographic coordinate system.

  • Ok. So, please help me understand the example. 4326 is a geographic coordinate system, but is used on a geometric data type and that is fine and normal? – slevin Dec 14 '17 at 21:24
  • 1
    Not quite. It's not a 'geometric data type', it's a geometry because that's what that data type is called in PostGIS. But otherwise correct. – Brynne Dec 14 '17 at 21:31
  • Ah, yes, so "4326 is a geographic coordinate system, but is used on a geometry data type". So the example has "geometries", so geometry data type and uses EPSG4326 to convert them to another coordinate system, a geographic coordinate system. The coordinate system changes, the data type remains geometry. Yes, I see it. Now I have to revisit the chapter about projections and coordinates system, which I hate. Anyway, thank you so much – slevin Dec 14 '17 at 21:42
0

No, transforming to EPSG:4326 does not make the data a geography type. According to this link, other systems (e.g. Oracle) may treat EPSG:4326 as geography automatically (but not PostGIS):

Different spatial databases have different approaches for “handling geographics”

Oracle attempts to paper over the differences by transparently doing geographic calculations when the SRID is geographic.

SQL Server uses two spatial types, “STGeometry” for Cartesian data and “STGeography” for geographics.

Informix Spatial is a pure Cartesian extension to Informix, while Informix Geodetic is a pure geographic extension.

Similar to SQL Server, PostGIS uses two types, “geometry” and “geography”.

Note also that the word "geographic" here can be ambiguous. For CRS, a geographic CRS simply means one that uses lat, long (and often the associated spheric/spheroid geometry instead of planar geometry). For data types, as pointed out in @notkilroy's answer and the link above, geography is a different data type from the geometry type.

Technically, nothing prevents one to use lat, long in geometry types. It's just an unprojected CRS.

You can use SELECT * FROM geography_columns; to verify if a transformed column becomes a geography type.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.