Add character's coordinates in current solar system to the location endpoint

[erittainvarma]

It would be great if location endpoint gave system name (and station/citadel if docked), like it does in CREST.

Also, x, y, z coordinates and/or nearest celestial (same as shown in game) would be nice.

[polarina]

You can take the ID you get from the current location endpoint and call the relevant endpoint to get its name, or refer to the SDE. Data typically aren't denormalized in ESI endpoint unless absolutely necessary.

[erittainvarma]

You can take the ID you get from the current location endpoint and call the relevant endpoint to get its name, or refer to the SDE. Data typically aren't denormalized in ESI endpoint unless absolutely necessary.

Yes I can. This is just something that has been provided earlier and will make conversion to ESI much simpler. I also think that most of the apps using location for something are going to use this information and end up just doing more calls.

[polarina]

I disagree. Not all apps need the name of your location. Besides, setting the precedence for denormalizing data will only end up in people asking for more denormalization so that the endpoint better fits their needs (and possibly no one else's).

[NathenSample]

@erittainvarma pulling an example from the top of my head, a travel app doesnt care what the systems called, it just needs to know the distance.

But as @polarina has set, it's been a long set precedent that the API will give you an ID, then you either need to search, use the SDE, or just have a map yourself, in order to change that to a name.

http://eve-marketdata.com/developers/solarsystems.php

is one such map.

[erittainvarma]

But as @polarina has set, it's been a long set precedent that the API will give you an ID, then you either need to search, use the SDE, or just have a map yourself, in order to change that to a name.

Long set precedent how? I actually made this request in the first place because I kinda find it opposite, as XML corp/memberTracking endpoint and CREST character/location/ endpoint gave this.

Only giving locationID may have been set precedent for things players and corporations own, but for character location related information it has been not.

PS. I would also argue that you will want to show the system in travel app for the user or the UI won't be intuitive.

[polarina]

Only giving locationID may have been set precedent for things players and corporations own, but for character location related information it has been not.

Can you show an example of where ESI does not follow that precedent?

[erittainvarma]

Can you show an example of where ESI does not follow that precedent?

I was talking about how it's usually been with CCP APIs.

I don't know if it has been conscious decision to avoid getting more calls with XML corp/memberTracking or CREST character/location/ and /fleet/members/ or devs just going "oh well let's also throw location name in and call it a day".

I probably understood ESI little wrong from the two CCP blogs and as I just thought "Once we replicate all current CREST and XML API functionality in ESI, we will be shutting down both services." meant getting these exactly how they were in CREST and XML APIs.

Well, anyway, if this ID only and make new request is some sort of rule for the ESI, let's forget that and continue with the rest:

x,y,z coordinates and/or nearest celestial would be nice addition to location endpoint.

[ghost]

I was talking about how it's usually been with CCP APIs. That's not a justification to keep doing it the same way through, or we wouldn't have bothered launching ESI :)

We typically don't inline data in ESI without extremely good reason. The API is designed around acquiring primitives (a character ID, a solar system ID etc) and taking them to specific endpoints. There's a balance to be struck between providing convenience without bloating the API.

Can you give us a concrete use case for an application that absolutely cannot function without inlined solar system names?

Giving the xyz coordinates makes sense to me, but I will need to sanity check it with game design. However, for nearest celestial, I'd rather make the solar system endpoint return enough data for you to do that calculation yourself, give you the player's xyz coordinates and offload that to you. It would be an inefficient use of processing power to perform that on an endpoint with a 5 second cache timer when it could totally be done by the consumer of the API :)

[erittainvarma]

We typically don't inline data in ESI without extremely good reason. The API is designed around acquiring primitives (a character ID, a solar system ID etc) and taking them to specific endpoints. There's a balance to be struck between providing convenience without bloating the API.

I think this is information that should be in dev blogs somewhere or you get lazy tards like me asking these kind of feature adds ;)

Can you give us a concrete use case for an application that absolutely cannot function without inlined solar system names?

Not really.

Giving the xyz coordinates makes sense to me, but I will need to sanity check it with game design. However, for nearest celestial, I'd rather make the solar system endpoint return enough data for you to do that calculation yourself, give you the player's xyz coordinates and offload that to you. It would be an inefficient use of processing power to perform that on an endpoint with a 5 second cache timer when it could totally be done by the consumer of the API :)

Great! Yeah, xyz coordinates are enough (and better).

[gitAskur]

Seems this has been resolved to my liking so imma close this.

[ghost]

Reopening because this hasn't actually been done yet.

[gitAskur]

Anything missing from the monolith end or just ESI stuff?

[ghost]

There will have to be fairly hefty modification on the monolith end to support this.

[ccpStuart]

Reviewed