Features (you are) missing in Arc Editor

Hi,

There have been some recent comments from Matt about the Arc Editor being close to a possible release, along with questions about which features should be included in the first version and requests for feedback from us users about what we’d like to have.
I’m wondering, what’s the best way to share this feedback? Is https://changemap.co/bigpaua/arc-app/ still the preferred place, or should we make these requests here instead?

If posting here is fine, the one must-have feature I’m missing is GPX import (mainly for flight tracking).

Hi @lmpinto!

Either here or the Changemap site are both good.

I sort of think of the Changemap site as being the “political rallying point” for larger features or changes, that require enough people voting for them to raise them up the priorities list. While here on the forum is more of the “chat and brainstorm” and informal voting place. Like, here it’s much easier to discuss ideas, while Changemap is more about “this is my feature idea, and I want everyone else to vote on it, to show it’s a popular idea”.

For things that are in Arc Timeline but are missing from Arc Editor, I think the forum is probably still the best place. Because those aren’t really optional things I might or not not build - Arc Editor is meant to eventually have everything Arc Timeline has. It’s just a matter of which order I add them in! And I’m basing that largely on feedback here on the forum.

Cool! As it happens, I’m just finishing up the rebuild of the workouts importing feature, which has large overlap with the GPX importing feature. This time around I used Arc Timeline’s GPX importer’s UI as the template for the newly rebuilt workout importing, because I like that UI better than the old workout import UI.

Anyway that means that a lot of the foundations for GPX importing have already been laid in Arc Editor now. So once it comes to building GPX importing it should be a much faster process. I’ll make sure it’s in the todos, and hopefully get to it soon!

For flight importing, I’m curious where you’re getting the GPX data for that? From a third party service that provides flight GPX exports? That’s actually something I’ve wanted to build into Arc properly, as a proper feature of its own. I even partially started on it at one point, but ended up deferring it because it became apparent that it was time to rebuild everything from scratch (thus the creation of LocoKit2 and Arc Editor).

It’s a two-step process. I export the data from Flightradar24 as a CSV file containing the fields “Timestamp, UTC, Callsign, Position, Altitude, Speed, Direction.” Then I run a Perl script that converts it into a GPX file using the timestamp and position.

A built-in FR24 importer would be nice to have, but I think the GPX importer offers more use cases. Maybe a generic CSV importer where you can define a template for your data would be a good alternative?

1 Like

I look forward to flight tracking being a thing. As well as all niche movement types :face_savoring_food:

Importing from Flight Tracking API is a good one, another possible stopgap until youre there is simply guessing that you were in a flight, if your GPS cuts out for a period of time and you travel a long distance in that time. This is something that you can do now, or have be a feature of the AI you mentioned earlier.

The next step is letting you import flights from just flight numbers.

I see that as stage one and two. Stage three would be it using that information to actually guess which flight you were on, by querying the two locations and times against the flight tracker API, this way it could verify the flight and even grab flight info.

This is one of the big steps on the way to making Arc a truly complete travel/location tracker. :relieved_face:

1 Like

Ooh, clever! I never actually noticed they had a CSV export. I’d been looking at their API docs instead, for building it into Arc proper.

Yeah that seems like it could be super useful. Though… would want to check if there’s more cases where people can get CSV data but not GPX data. Otherwise it might end up being an importer that’s only ever used for FR24.

If that’s the case, then better to just build in proper FR24 importing into Arc, presumably via their API. I think that has some cost associated with it, but my expectation was that that should be covered by the Arc subscription, assuming they’re not charging API consumers crazy high rates. Similar to how the Arc subscription covers the Apple weather data importing cost.

@DotKern You’re articulating a bunch of ideas there that are very similar to the ones I’ve long wanted to do for train trip auto detection! Like, if you start moving at a location that’s near a train station, and then travel along a route that’s a known train line, Arc should be able to auto identify “this is the green line, southbound”, and then annotate that in the UI and map.

So exactly the same for flights. If Arc has access to flight data then it should be able to autodetect that some travel started at a time that lines up with a flight recording in FlightRadar24, sanity check that it matches up at the other end, then intelligently auto label it. And then it could offer “This looks like you were on flight SL259. Would you like to import that flight recording from FlightRadar24?”

That would be the ideal. And … I honestly think it’s not that far fetched. It all sounds quite technically plausible. If anything it should be easier than the train line one.

Oh this also has some conceptual overlap with one of my oldest ever feature wishlist items: custom activity types. Like, if you go for the same or similar run every morning around the park, you could create a custom activity type “morning run”. Then the activity type classifier would learn that the best match for the samples in that item are “morning run” instead of just “running”. Could give it a custom colour, get custom stats for it, etc.

Yeah! This idea would work for nearly any method. Trains should be a little harder, I agree, and be portrayed different on the map, since they do follow a route on the ground. Planes are kind of… ephemeral as far as GPS is concerned. You magically teleport. I’m fond of the gentle arcing line from takeoff to landing. It does a good job of capturing how planes feel to me. A whole different universe. Stealing the same back-end (with different APIs of course) to use other systems is clever though. The same concept could be applied to boats as well, although a little different as they have less rhyme and reason.

Some photos of what I mean for planes below.

Although, now that I think of it, knowing when you were over certain cities via more accurate tracking would be pretty neat.

1 Like

Yes certainly may be cool, yet at least when it comes to Arc Editor, forgot if anyone has reported such, somewhat often it seems when I’m at some larger retail location it currently does something like this when it should be walking:

location → car → location → car → location

It trends towards car or bike by default I’ve noticed. After correcting it for a week via clean-ups and whatnot it no longer makes the mistake for me though. How long have you had this issue?

In your envisioning of this, would it work for something‎ fifteen minute breaks at work? Where at some point during my shift I leave my desk and go to the same place every day, twice a day. Currently it just thinks it’s a walk; because fifteen minutes isn’t enough for it to pull a brief visit automatically for the full time. It thinks three minutes at most. But a custom activity could work here.

@agastya If it’s picking up car instead of walking it’ll likely be a case of the activity type models for that area not having enough data yet, as @DotKern says. It should self correct fairly quickly, or at least that’s what I usually notice. Even just one or two days of data for a certain area can settle the activity type classifiers into more sensible results.

Hmm. This sounds more like the Places/Visits systems rather than Trips related. Is it an area with low accuracy location data? Like inside a larger building?

One of the currently fixed thresholds is 2 minutes duration for a Visit to be considered a “keeper”. If it’s shorter than that then it’ll get automatically merged in to an adjacent item. It could be that for some reason it’s failing to record a long enough stationary portion / Visit.

I do actually have a loose plan for that in mind. I want to eventually get rid of that 2 minute requirement and replace it with something learned. Like if it learns that there’s a convenience store that you typically only stay 1 minute inside, it should learn that that’s an adequate “keeper” duration for that Place, instead of requiring you to stay a full 2 minutes inside the store.