At a guess, your point should be about 5.5km southeast of Bad Reichenhall right?
If so, the problem you have is you're interpreting your input coordinates incorrectly. The clue is in the source projection's name: LAEA which stands for Lambert Azimuthal Equal-Area, which is a projection that uses linear units (metres in this case) rather than angular units.
So your data of N2736 E4541 should be translated into metres - and here's the rub, they're in 1000's of metres, so your actual coordinate is 4541000, 2736000 (eastings are usually given before northings). If I use GDAL's gdaltransform:
$ gdaltransform -s_srs EPSG:3035 -t_SRS EPSG:4326
and type in the coordinates:
4541000, 2736000
I get:
12.9300691689392 47.6983999922817
Which puts me near the border between Bavaria and Austria.
In terms of PostGIS, you'd use:
SELECT ST_AsText(ST_Transform(ST_GeomFromText('POINT(4541000 2736000)',3035),4326));
Which returns me:
st_astext
------------------------------------------
POINT(12.9300691689392 47.6983999922817)
(1 row)
As per documentation of function it can use both:
http://postgis.net/docs/ST_DWithin.html
boolean ST_DWithin(geometry g1, geometry g2, double precision distance_of_srid);
boolean ST_DWithin(geography gg1, geography gg2, double precision distance_meters);
boolean ST_DWithin(geography gg1, geography gg2, double precision distance_meters, boolean use_spheroid);
Watch out for this:
For geography units are in meters and measurement is defaulted to
use_spheroid=true (measure around WGS 84 spheroid), for faster check,
use_spheroid=false to measure along sphere.
But for 10km buffer radius it shouldn't be a big error.
Best Answer
As described, the answer is "neither", for the following reasons:
ST_DWithin(geom::geography, %anothergeom, %radius)
. Because geography is involved, the system will look for a geography index (which is built on a sphere, not on a plane) and will find none. Since it has no index, it will perform the join using full scans of the table(s). It will be slow.ST_DWithin(ST_Transform(geom, 2163), %anothergeom, %radius)
. Your tests is not against the indexed column (geom), but against a function applied to the column (ST_Transform(geom,2163)
) and so again, your spatial index will not be used. It will be slow.You need for your query and your index to harmonize. If you do not want to change the projection of your data, you will have to use a functional index, for example, if you create a function geography index, you can use a geography-based query:
Or, in the transform case:
The absolute fastest performance will be if you convert the data in your table to a planar projection (like EPSG:2163), create a spatial index, and then use
ST_DWithin()
on the result.