[postgis-devel] Distance operator in presence of M

Havard Tveite havard.tveite at nmbu.no
Fri Jun 5 00:17:12 PDT 2015


On 4/6/2015 15:15:PM, Greg Troxel wrote:
>
> Sandro Santilli <strk at keybit.net> writes:
>
>> As you may have noticed, I'm working on adding some functions to work
>> with "trajectories". These are linestrings in which each point corresponds
>> to the location of an object at a given time. Location uses XYZ, time uses M.
>
> I hadn't noticed, but I have long been pondering how to represent
> tracklogs from GPS, because eventually I'd like to put all my logs into
> postgis to be able to then have them show up in viking and/or do
> analysis somehow, including geotagging photos.  I haven't said anything
> on the list because I hadn't done my homework, but had been converging
> on a table with an id for the segment, a point, and a time.  Using a
> line seemed unhelpful.  So if there's a new trajectory data type, that
> seems to fit, as I was basically trying to get that from primitives.
>
>> The "closest points" between two trajectories are those in which the two
>> moving objects are spatially closest at the same point in time.
>>
>> The ST_ClosestPointOfApproach function, which I committed in r13569,
>> returns such point in time.
>
> It seems that someone would want to know the two points as well.
>
> I would expect ST_ClosestPointOfApproach to interpolate, so that it
> really finds the closest approach of the object, assuming that it moves
> linearly between observed points.  (This seems difficult to compute if
> the times aren't uniform or matching.)
>
>> Now, when it comes to the <<->> operator, for geometry or geography, we
>> have to pick a distance semantic in case of M presence. Right now this
>> semantic is just discarding M, compute in 2d or 3d space (whatever is
>> available in both operands) and then "add" the M difference to the euclidean
>> distance.
>>
>>   https://trac.osgeo.org/postgis/ticket/3133
>>
>> But I'm wondering, is current approach any useful ?
>
> I don't see how it makes sense to add distance and time, unless you
> scale by c and compute pseudoranges as in GPS :-) But seriously, adding
> distance and time assumes a speed, and I don't see where you are going
> to get a speed; if you take it from the trajectory that feels bizarre
> and likely to lead to triangle inequality violations, and otherwise you
> have to assume it somehow.   1 m/s is a sane speed for a wide range of
> actual experiences, though, semi-interestingly, althought it's quite off
> for tectonic plate motion.

For operations involving distance calculations, you need to have
a way to compare space+time "distances".  Which is closest of two
points where the spatial distances are 200m and 250m while the
temporal distances are 80 seconds and 60 seconds?
As Greg says, for that you need to have a velocity.
If velocity is supplied as a parameter, it could be possible to
support such operations.

HÃ¥vard Tveite



More information about the postgis-devel mailing list