I have a function that takes a point and compares it with lines that are stored in PostGIS and then gets the line closest to the point. Initially I did not transform the data because I did not think that it would matter when I want to get the minimum distance. I thought that small distances (up to 100m) would not need transformation but I was wrong! Sometimes it gets a line that is not the closest one even if the compared distances are 1.2m and 2.5m. I discovered that and I re-designed the SQL command to transform the point and line to the local UTM zone and now its working fine.

I would appreciate it if someone could explain to me how is this possible at such a small scale. Why did PostGIS think that a line 2.5m away from my point is closer than a line 1.2m away? Perhaps an emphasis on UNITS vs metric unit usage?

Thank you for your time and effort! Regards, A


2 Answers 2


You'll have to put your mental visualization cap on, but remember, lines of longitude converge at the poles. So, a 5x5 square at the equator squeezes down to a narrow rectangle at the poles. Effectively, a "unit" of unprojected horizontal distance covers less and less real distance the further north you go. This is probably the source of the discrepancy you are seeing.


If you're using PostGIS 2.x, you might like to know that ST_Distance will return the ellipsoidal distance for geography types. But if you have an unprojected geometry type (such as SRID 4326), then you are subject to the distortion that entails.

You can visualise the distortion quite easily by viewing the Earth as plate carrée - towards the poles, you'll see that east-west distances appear stretched. Away from the equator, it's quite likely that an east-west line of 1.2 metres appears longer than a north-south line of 2.5 metres.

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.