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?

Implemented Moved/Removed Portals

Discussion in 'Feature Requests' started by digitalpoint, Mar 17, 2016.

  1. digitalpoint

    digitalpoint Administrator Staff Member Illuminator Enlightened L15

    This is mostly a reminder to myself to build a system that lets users flag a portal as moved or removed (which will send it to a queue for manual review/action).

    The feature that lets people import their historical damage reports definitely brought the issue to light with portals being moved and deleted over the years.
     
  2. digitalpoint

    digitalpoint Administrator Staff Member Illuminator Enlightened L15

    The ability to flag (or unflag a portal if you did it accidentally) has been added. You can flag a portal as being moved as well as being deleted from any portal profile page.

    That will put the flagged portal into a queue for review by an administrator (me).

    While the front-end stuff (flagging) is done and working, the backend stuff (review queue) is not... but I figured why not let people go ahead and flag portals now.

    This is going to be particularly useful as users are importing historical data going back years and the portal landscape has changed over the years.

    I'm also going to build a system that should be able to automatically queue most portals for review if they moved (for example if two portals have the same portal image and they are in close proximity to each other... probably worth sending to the review queue).
     
    Niemil and PaTChBuZ006+outgress like this.
  3. automatically queue most portals for review if they moved (for example if two portals have the same portal image and they are in close proximity to each other

    Glad to see you were already thinking about this. I noticed a few duplicates introduced by historical data.

    If they were within 50m and had the same image URL, would you even need to queue them? If it had been >100m, I'd have reservations. If the name was changed, I'd have mild reservations. The same image URL is almost certainly the same portal.

    Couldn't you merge the historical damage/attack data as opposed to removing the old location altogether? Would you note in the history that it was at some delta latitude/longitude?
     
  4. digitalpoint

    digitalpoint Administrator Staff Member Illuminator Enlightened L15

    I haven't really had the time to loop back and finish the backend part of this yet. But yeah... the plan is to move the attack history from the old portal location to the new one (and no, probably wouldn't bother flagging individual attacks as something that occurred a few meters away... just adds more internal complexity than it's worth).

    There are certainly going to be some parameters that could be used to do it automatically (no need to review into a queue). For example if a portal was within say 50m of another portal with the same title and same image and all attacks on one portal happened after the last attack on the other). I'd say something like that could be automatic (and probably would cover the majority of moved portals anyway).
     
    PaTChBuZ006+outgress likes this.
  5. Sounds really good! I just figured the MOST you'd want to do is put in a line notation between records that said where the transition happened but there would be some complexity if another new record was imported between the two adjacent existing historical records and you'd refine the boundary.
     
  6. digitalpoint

    digitalpoint Administrator Staff Member Illuminator Enlightened L15

    Yeah, there are a lot of weird scenarios you start getting into... like if a portal moved more than once. So then you would need to track movement on a per attack basis rather than a movement date for the portal itself. And like you mentioned, it gets more complicated as more people import old data in the future.

    Like I said, just too much added complexity for no useful reason... like is someone going to do anything different because the portal was in a slightly different location 3 years ago? Doubtful. Plus there's the data overhead of storing a flag about something moving on a per attack basis (specifically there would be a 4 byte overhead for every attack [regardless if it moved or not]). We just opened the site up and we are already into millions of individual attack records... so it's not out of the question to at some point be at billions... is it worth 4 bytes x millions (maybe billions) for a little bit of data that serves no useful purpose? Probably not. :)
     
  7. The trickiest scenario is that if you don't track some demarcation that it moved but completely merge records, a subsequent imported attack record could end up appearing to have overlapping time interval and thus appear to be a distinct portal. It almost could be better to internally treat it as a chain of separate portals but merge them only on the map as a single portal where you could toggle display of historical locations/names/images. Easier to break links in that chain and relink than try to split


    [EDIT: An even trickier scenario but infinitesimally rare is if the portal moves then a new portal is placed in the exact identical original location. Corner case that you can probably ignore]
     
    Last edited: May 11, 2016
  8. digitalpoint

    digitalpoint Administrator Staff Member Illuminator Enlightened L15

    You would probably have an internal database that notes the new position of old portals so incoming old data (from import) could be moved automatically after the fact.

    As far as a new portal popping up in the place of an old portal... If that has ever happened, it would be so rare... Ingress tracks portals to the 6th decimal place for longitude/latitude... Which works out to 4.3 inches. So if the new portal was setup 5 inches away from the old location, it would be a unique location.
     
  9. digitalpoint

    digitalpoint Administrator Staff Member Illuminator Enlightened L15

    Moved/removed portals now automatically removes themselves from the intel map for the user that flagged them (it's too much work to try and validate data globally, so flagged only apply to yourself now).

    There's a new intel map mode that lets you see just "Portals Flagged By You", which will let you find and undo any mistakes you may have done that affects the intel map for yourself.