Measuring distances over time

[MarilenaKallweit]

Hello community,

I have a problem analysing the data of my master thesis. Hopefully someone can help me.

I have tracked many dogs and their owners with GPS while hunting and now I want to measure the distances between these two "moving point objects" over time.

By now I load the GPS Data in ArcGIS and make a tracking layer out of it, so I can use the Playback Manager of the Tracking Analyst tool. I set it to 1 minute per second and go manually through it and measure the distance at every step per hand. This costs a lot of time, especially because I have a lot of these tracks.

So my question is: is there a solution to get a table or a graph of the distances between the two objects over time automatically? That would help me so much!

Thanks in advance,

Lena

[MarilenaKallweit]

Thank you for the effort. That sounds very promising! I will try it over the weekend and report.

[NeilAyres]

If you need further guidance about the queries in the mdb or anything else, post here....

Good luck.

[MarilenaKallweit]

I only worked with your tables by now to see if I get it with ArcMap. Everything worked in the attribute table, but I don't see the lines on the map. That is not a big Problem, but maybe you can tell me what I do wrong.

I got an Access account from the University now. It's been a while since I worked with that kind of software. So I would really appriciate a little help with the queries, because I don't even know how to start.

[NeilAyres]

This is the view of the TimeMatching.mdb in ArcCatalog.

The lines are the feature class LinkedLines. You should be able to see that and load it into ArcMap.

Will post more detail on the queries in access shortly

[NeilAyres]

This inside Access.

We are joining Chef (dogs - 2250 records) back to Kallweit (owner - 1306 records).

First we create a query which "joins" the 2 input tables (tblChefGPXDataPoints @ tblKallweitGPXDataPoints).

Because there is no "join" as such, this just creates a very large / long cross product of the 2 tables.

Then query 2, summarises this query across the ChefID and the minimum time.

Then query 3, joins this back to the first (a bit circular) so we can find the IDs on both sides.

Query 4, then uses this as a join in between the original input tables so we can get back to the Lat/Longs on both sides.

Hope this makes some sort of sense.

Do you have any folk there who know a little about Access?

[MarilenaKallweit]

Thank you so much!

It took a while, but know I got it. It's a little bit easier for me, because Access 2013 recognizes the ltime field as date/time field. So I don't have to add an extra TimeStamp.

It is exactly what I need. Now I can finally go on with my work Thanks again!

[NeilAyres]

Marilena,

good to hear that this works for you.

Good luck with the rest of the study.