Dismiss Notice
How Does This Work?

You create a free account and set a Gmail filter to forward your Ingress email damage reports.

The damage reports are processed in realtime into the Outgress analytics and alerting engine.

That's the short version.

Is This Allowed?

We believe so, but you decide.

But My Secret Data!

No one on the opposing faction cares who on their team is attacking you. Do you care who on your team is attacking opposing portals?

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

Discussion in 'Support' started by visualrinse, Jul 18, 2016.

  1. visualrinse

    visualrinse New Member

    Hello outgress administrator,
    My business has a Geo location application named Wayfiler that's been around for a couple years now. We're interested in partnering and using your data to create new mobile apps that assist with gro-location and finding points of interest.

    Wayfiler by Float

    Want to collaborate?
  2. digitalpoint

    digitalpoint Administrator Staff Member Illuminator Enlightened L15

    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)
  3. visualrinse

    visualrinse New Member

    Thanks for the quick response.

    My main goal in the case of the Pokelytics data is to bring a fast, mobile first UI to devices that allows game players search and look in an area for points of interest before they pop into a car etc to go to a distant location to play. Our app would leverage the dataset to start, but then allow a user to add Pokemon screenshots, etc.

    Apps tend to work better for larger data sets in our experience, run faster, load quicker etc. The web version of Pokelytics as it is is a great start, but needs to be responsive etc... Our app's UI is already optimized to handle that.
  4. digitalpoint

    digitalpoint Administrator Staff Member Illuminator Enlightened L15

    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)
  5. visualrinse

    visualrinse New Member

    Millions, no... not yet. ;-) We have some good memory management and caching going on in the app though. You can see that as you zoom in/out.

    I wasn't able to see a responsive UI on my iPhone... maybe I'm missing something?
  6. digitalpoint

    digitalpoint Administrator Staff Member Illuminator Enlightened L15

    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?
  7. visualrinse

    visualrinse New Member

    Really everything just kind of looks a bit like a shrunken down desktop site. Not trying to critique or anything, though. You all have done some great work. Just want to help the date find another home. Happy to have an offline conversation about this more. DM me if you are interested?
  8. digitalpoint

    digitalpoint Administrator Staff Member Illuminator Enlightened L15

    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.
  9. visualrinse

    visualrinse New Member

    Thanks for the further conversation and details. I'm mostly interested in the Pokelytics data, certainly. The infrastructure is scalable - elastic cloud instances.
  10. digitalpoint

    digitalpoint Administrator Staff Member Illuminator Enlightened L15

    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.
  11. I just wanted to chime in here as an programmer with web design experience and add, That is actually what a lot of people (read end users) prefer. Most people that I have talked to really hate it when sites have special "mobile" versions that look nothing like the desktop site. (don't even get me started on that stupid wordpress mobile plugin that everyone used but never changed any settings) Most often those mobile sites have navigation buttons/menus that are too big and take up way more space then they need, and they often disable the pinch to zoom features. And that is on top of the already annoying reduced functionality, links being in different places, and mobile ads that won't go away. More often then I should need to, I am forced to tick the "request desktop site" when viewing mobile websites. There is a reason why many people used the desktop Facebook site on their mobile phone rather than the app or mobile site. And many people still do.

    Personally I feel that a "good" mobile site should look and function exactly like the desktop site. A good web designer can do that with one page instead of making another for mobile users. And if your response is, "some things don't work on a mobile that work on a desktop or vice versa" then maybe you might want to consider doing things a different way. There are still a LOT of people on dial-up and satellite that still can't handle 5mb+ of images, or flash, on one page. And when you think about it, sending that much for one page on a cell phone is not much better as it eat's up a users data plan.

    Sorry for the rant but I take great offense to seeing designers and websites owners not liking the idea of having one site for both Desktop and Mobile. Having two versions of a site is only creating more work for the designer/programmer, and it is annoying the end users that use both versions.

    As a side note: have you ever viewed a mobile website on a 10in+ tablet.... if not, you really need to. Most designers forget a large tablet might as well be a desktop when considering screen size.
    Last edited: Jul 26, 2016