Interested in porting Outgress/Pokelytics points to a mobile app?

For what purpose exactly? I mean if it's just for sake of making a mobile app, probably not to be honest. If we were going to do it, we would more or less need to build the Outgress application for a mobile app (with full feature set). But if it's just a mobile app that is essentially a bunch of flags where portals are, it seems like it would be a less complete feature set (as far as Outgress goes) vs. just using the normal Intel map over here from a mobile device.

Of course I don't know much anything about Wayflier, so maybe I'm wrong about what it is? Like is there something it does for users that they can't already do? (I tend to build things when whatever I'm building solves a specific problem for users).

There was a little discussion about an app over here: https://outgress.com/threads/is-there-an-app.41/ ...but so far, I don't really see a reason to beyond just for sake of doing it (which isn't a strong selling point for the added work.. heh)

 

Do you have any sample apps where you have a lot of locations loaded into it (like more than a million)? It would be interesting to check it out. Outgress/Pokelytics has already gone through the growing pains of fairly large 3D geospatial data sets (3rd dimension being time in the case of portal attacks for Ingress/Outgress), so it might be interesting to compare side by side with an app.

On a side note, the Pokelytics (and Outgress) are both already responsive and optimized for mobile. Of course that's not to say there's still work to be done to improve them (anyone who thinks any application is "done" is wrong... heh)

 

There isn't a massive difference between desktop/mobile, but it definitely is (or at least should be) responsive. Are you seeing something that isn't working or formatted weird on the iPhone?

 

I guess the biggest thing is just figuring out if loading the data into something else helps or hinders users. Would need to figure out what benefit they are getting (like what it does for them that they aren't already doing). Without a clear benefit for users, I'm not sure any users would go through the trouble of installing an app if it doesn't give them something beyond what they already have.

The portal location data isn't even the most used data by users... they really are after trends for those portals, and trends by agents who visit those portals. They are managing alerts about portal attacks, they are managing groups of portals for those alerts, drawing on the map to carve out areas for alerts, they can show portals on the maps in various ways (ones they have never visited or owned inside Ingress before for example), recreating links recently broken by users to visualize if they are clearing lanes, etc.

Just having a map of static points really doesn't help users with much of anything... because they already have that (plus a whole lot more important stuff).

There's other technical issues as well... for example do you have the infrastructure in place to manage large amounts of geospatial data? It's a lot more difficult than one would imagine when you get beyond a small data set. For example if you want to get a list of all locations within xxx km of the user (which is a dynamic location of course) do you have the ability to do that *without* needing to do backend geometry distance calculations for every possible location? When you start getting into large data sets, it's not realistic or scalable to be doing those geometry calculations for every possible location on every query. If you have to do those calculations on a million or more locations in realtime every time you want to place some stuff on the map, the map is going to be incredibly slow and just get slower as more locations are loaded into the system.

 

How are you handling the geometry calculations though? You could have a million servers on the backend, but if you aren't doing the geometry calculations in a scalable way (which means *not* calculating distance on a per query basis even when the origin point changes), you will end up with something that *can* do the necessary calculations, but not in a useable way (too slow to be useable). It was one of the more difficult things I had to tackle with Outgress data. I couldn't find anything that could handle the volume of data in a way that works on a huge data set (well, stuff would work, it just wouldn't scale... it would get slower the more data you have). I ended up having to build my own system from scratch to handle the geospatial data. Now we can handle trillions of latitude/longitude records (portal attacks) and get the data out of the servers in a useable way very quickly (0.01-0.05 seconds to generate the data for a large region (maybe encompassing around 200,000 portals for an area like Southern California).

If you are dealing with large geographical data sets, you should test what happens in your system if you load larger data sets (like a million or more records). Ingress has 5.4M portal locations, so if you have a function based on distance (like get close portals or portals in a region), you can't be calculating the distance from the user to the 5.4M portals so you can then show just the ones that re close. Simply doesn't scale.