[Feature Request] Get Jump Bridge Locations

[colcrunch]

Feature Request

Allow for retrieving a list of all Jump Bridges, basically just the data that is publicly available through the in-game map.

Use case

Useful for building more complete maps out of game.

Authentication

Public Route, no auth required.

Example return

[
  {
    "structure_id": 1234567890123,
    "system_id":  30004684,
    "destination": {
        "structure_id": 1234567890123,
        "system_id": 30002187
     }
  },
  ...1000 other bridges
]

Checklist

Check all boxes that apply to this issue:

• Feature request description is provided
• Use case exists
• Feature requires a new route
• Feature adds data to existing route
• Feature requires new auth scope
• Feature can reuse existing scope
• Feature does not require auth
• Meta feature, applies to all routes

[ErikKalkoken]

I support this feature request. We currently use a manual list of our coalition jump gates for our own route finder tool. That is a great help for our members, but its very labor intensive to keep up-to-date. Would be so much better if that information could be retrieved from the API.

Public access to all existing jump gates as suggested by IP would in my opinion be too much, since it would allow you get full intel about the jump gate network of your enemies without having to manually scout them.

Instead I would suggest an authed endpoint that gives you the list of current jump gates that your authed character has access to. The "has access to" part is important, because non-friendly jump gates are useless for routing.

[Blacksmoke16]

I'm pretty sure you can already do this by pulling corp structures then parsing the name to pull out to/from location.

Or something along those lines

[Slazanger]

You cant easily (without breaking the search rules) get a list of structures that are dockable etc.. so any alliance or coalition level structure scraping is troublesome

[disc]

You cant easily (without breaking the search rules) get a list of structures that are dockable etc.. so any alliance or coalition level structure scraping is troublesome

How to do this?

[Blacksmoke16]

@disc Don't. Scraping the search endpoint for discovery is not allowed.

[ddouglas]

The "breaking the search rules" portion is the hint there. Those of us that have been around awhile know what to do to do this, but we have a responsibility to not reveal that technic to others as it breaks the rules that have been put in place, especially in an open forum.

[colcrunch]

Public access to all existing jump gates as suggested by IP would in my opinion be too much, since it would allow you get full intel about the jump gate network of your enemies without having to manually scout them.

This can already be done via the in game map, as stated in the original post.

[ErikKalkoken]

Public access to all existing jump gates as suggested by IP would in my opinion be too much, since it would allow you get full intel about the jump gate network of your enemies without having to manually scout them.

This can already be done via the in game map, as stated in the original post.

you are quite right. but my main point is that the endpoint needs to show the gates that a char has access to (like the green ones on the map). That would only work if the endpoint is authed.

[colcrunch]

you are quite right. but my main point is that the endpoint needs to show the gates that a char has access to (like the green ones on the map). That would only work if the endpoint is authed.

I think that would be a different feature request. This one is specifically requesting, ALL jump bridge locations.

[ErikKalkoken]

I'm pretty sure you can already do this by pulling corp structures then parsing the name to pull out to/from location.

Or something along those lines

Technically possible, but if you think it through you would realize that it would be quite a challenge to implement. You would need API access to structures of all corporations in a coalition, which is not easy to organize and maintain. Not easy to setup and maintain and probably only achievable for a large and well organized coalition like the Imperium.

But if we had an endpoint as described a route finder tool could be easily implemented without requiring any coalition wide coordination. In fact it would be possible to create a public route finder tool that would automatically use the jump gates of the char that is currently logged in.

[ErikKalkoken]

you are quite right. but my main point is that the endpoint needs to show the gates that a char has access to (like the green ones on the map). That would only work if the endpoint is authed.

I think that would be a different feature request. This one is specifically requesting, ALL jump bridge locations.

would use is that information if you do not know if you have access to the jump bridge?

[guiguilechat]

well you could do another path to get the ones you have access to ?

first path would return the list of jump bridges
/structures/jb/public

second path would return the jump bridges a user has access to, with id->cost
/structures/jb/access/{userid} and would require auth

third path would return the list of jbs managed by a corporation, as id-> costs
/structures/jb/corporation/{corporationid} and require structure access in the corporation.

[ErikKalkoken]

well you could do another path to get the ones you have access to ?

first path would return the list of jump bridges
/structures/jb/public

second path would return the jump bridges a user has access to, with id->cost
/structures/jb/access/{userid} and would require auth

third path would return the list of jbs managed by a corporation, as id-> costs
/structures/jb/corporation/{corporationid} and require structure access in the corporation.

First & Second: Sounds like a good compromise. Although I personally see the most value in the second.

Third: not necessary as the jump bridges should already be included in the existing endpoint for getting the list of all corp structures: /corporations/{corporation_id}/structures/

[guiguilechat]

I was trying to take into account the performance cost for ESI.

There is no sense in having only the second. If you can't identify the bridge you have access to, it's useless. Plus if you add all the data from the first in the second path, you end up with many computations to perform for the servers (eg for cache). On the opposite, the data is already public in the game, so there would be a huge performance increase in having that data public for everyone (one shared cache for everybody). Think of primary keys in a database.

Third one was more on how to know the costs set to the jb, but if you say this information is present then it would become useless.

[ErikKalkoken]

Apparently I misunderstood your 2nd endpoint. I expected it to return a rich list of all structures rather than just one. So to make the whole concept work I think your 2nd endpoint should be defined like this:
/structures/jb/access/{structureid}

[guiguilechat]

No because you need to have the list of structures id you have access to.

My 2nd endpoint would return something like :
/structures/jb/access/7777
[
"21": 5000000
"22": 0
]

in this example I (user id 7777) have access to the jump bridge with id 21 for 5M isk, and 22 for 0 isk.

So now I need to get the structure 22 in the data from the first path to know which couple of systems I can link (typically that should be a system1->system2 while jb 21 should be system2->system1)

The return type of the second path should be a dictionnary of floating values.

The return type of the first path should be a dictionnary of JB structures (mainly : origin_id, destination_id, owner_id, position_x, position_y, position_z)
(I explained here why using dict is way better than a list of items as we have now in most paths)

Of course, the returned dictionary MUST be sorted by the key so that successive call to the public path can only return different data IFF at least one jb has been modified. ( ie, no modification implies exactly same returned data)

[DuffleOne]

Any further thoughts or plans on this?

[tehraven]

Two years later. Hello! We still want this feature. Not a huge fan of some of the suggestions, but I think the TLDR stands:

• Search endpoint that doesn't show structures that died 9 months ago
• Be able to filter to structure type
• Honor ACL