You cannot do that.
Geometry and Geography are two completely different types of data. You probably did read up on it..., but here is an explanation...
Geometry are points on a flat surface. If you would like to calculate the area of your bedroom, i.e. 3.5m by 6.8m, it would result in 23.8m2 - if you would have drawn it in a CAD program, you would start from 0,0 and draw a rectangle to 3.5 in width, and 6.8 length, which gives you the area of the flat surface, on a Z elevation of 0
When you get to Geography, we are talking about the way the earth or sphere are measured. Yes, the earth is round, but not completely round as a ball. It actually looks like a potato mixed with a watermelon. So, when you draw lines on the earth's surface, they are not flat. For the first couple of meters, its "ok" to measure a flat line, but after that you have to consider using calculations and Coordinate systems (i.e. WGS84, a.k.a. 4326 SRID)
Explanation: http://en.wikipedia.org/wiki/Earth_radius | http://en.wikipedia.org/wiki/Horizon
When you store something in Geometry, they are normally X,Y,Z, and when you store something in Geography they are normally Latitude, Longitude, Elevation. Also to note is, when you store in Geometry it is usually in units of measure, i.e. Meter. When storing in Geography is is usually in which datum the data reside, for example a province or state in America would not the be the same area if measured in Australia. The earth's curve is not the same, and you would sit with errors in your calculations. So, the idea was to use WGS84 as the major measuring unit across the world, but that has led to many errors locally on the ground for some surveyors. Measuring with a theodolite instrument, you would calculate the correct area of a surveyed place to the accuracy of less than 0.002m - which is acceptable. Imagine measuring an area of a place by only having 3 decimal digits after a lat/lon.
shape2SQL has a selection where you can choose between the two. BUT, you cannot compare the two against each other...
Looking closely at your data it looks like in the distance calculations you have used different coordinates from those in the *activity_objects* table.
In example on the first query you wrote:
[...] ST_GeographyFromText('SRID=4326;POINT(-70.01 15.01)'));
where it should have been:
[...] ST_GeographyFromText('SRID=4326;POINT(-73.01 15.01)'));
Notice -70.01 being used in place of -73.01.
hence the discrepancies in all your subsequent calculations.
Best Answer
The definition of SRID 4326 is in fact IN DEGREES. ALso as it says in the ST_DWithin page:
Since you're are using the 4326 SRID, you can cast from geometry to geography and vice versa like this :
Most of the functions in postgis are overloaded, meaning, they return values and run a different procedure based on the input data type.
eg:
they have the same name, but the first function returns T/F based on units of the srid, and the second returns T/F based on meters.
If you plug into the function geog types, for its calculation, will take into account the curve of the earth so the algorithm 'costs' a bit more.
If you want to check how much more it costs, you can run for each query an EXPLAIN-ANALYSE