Soft-launched this yesterday and nothing blew up. Basically /v2/wvw/objectives is an actually working replacement for /v1/wvw/objective_names.json — it provides a bulk-expandable endpoint for WvW objective data. It also provides some additional fields that the v1 endpoint doesn’t, notably the label coordinates, sector_id and such.
It’s really important to note that due to backend changes objectives ids will going forward no longer be integers — they’ll be strings. This will be reflected in /v2/wvw/matches (and likely /v1/wvw/match_details.json) which I’m trying to get out before HoT ships. Check (and comment on!) the /v2/wvw/matches Github PR if you’ve got some time before we ship it!
Thank you Lawton for you job!!
Now I’m not using this API, but I have a question for the future.
I have read “/v2/wvw/objectives” and there are big value for coordinates. If I’d like to use them with a scale of 1:1, the coordinates retrieved by API are to compare with a maximum zoom in of the map?
I have read “/v2/wvw/objectives” and there are big value for coordinates. If I’d like to use them with a scale of 1:1, the coordinates retrieved by API are to compare with a maximum zoom in of the map?
I don’t get your question 100% because syntax error. But from what i get, you’re basically asking how to project them 1:1 on the map.
The project() function in the php example or fromPointToLatLng() in the gmaps one is probably what you’re looking for. (map.project/unproject in leaflet)
Soft-launched this yesterday and nothing blew up. Basically /v2/wvw/objectives is an actually working replacement for /v1/wvw/objective_names.json — it provides a bulk-expandable endpoint for WvW objective data. It also provides some additional fields that the v1 endpoint doesn’t, notably the label coordinates, sector_id and such.
It’s really important to note that due to backend changes objectives ids will going forward no longer be integers — they’ll be strings. This will be reflected in /v2/wvw/matches (and likely /v1/wvw/match_details.json) which I’m trying to get out before HoT ships. Check (and comment on!) the /v2/wvw/matches Github PR if you’ve got some time before we ship it!
Will the int->str change be going into any of the other API endpoints (pvp, item, etc)?
No, it’s only for WvW objectives (and even then, only for the v2 for now — the v1 stuff won’t change without a good deal of notice).
In the old system, the borderlands maps were literal copy-pastes of the red borderlands. For the new borderlands maps, we added support for a programmatic copy-paste that uses almost all of the same data (so same map details, objectives, etc) but with map-specific overrides. So all of the same keep on each of the borderlands would have different metadata (e.g., different name) but same objective id because the name was just overridden. To work around this, I made the objective ids be the concatenation of the map id and objective id just to make them unique.
This change is pretty WvW-specific, so no other endpoints need to change.
Notice how the markers all seem to be offset towards the center of the map. My initial thought was that I had to play around with the zoom a little, but since it is happening on all maps and the offset is relative to each individual map (instead of the world as a whole), I’m starting to doubt that.
I’ll probably work on creating a Javascript fiddle tomorrow to see if it is just the library I’m using, but I’ve seen it on two libraries so far. I’m also not particularly fluent in mapping terminology, so if anyone knows what I should be looking for, I would appreciate pointers.
This looks like a rounding error to me, but then again, the positions of the keeps are odd.
What library are you using? Leaflet? Google Maps?
I tried with Google Maps back with v1 and the sectors, and I believe I had the same result. I am currently using Mapbox’s Android SDK .
Here’s a JS fiddle using leaflet with the same problem. I know that the PR for this mentioned that the coordinates are just the centroid of the objective’s sector- perhaps that doesn’t actually line up with where the markers should be?
If that’s the case, is there a better way to get the “correct” location of markers without just figuring them out myself and hard coding them?
Ok, that’s clearly API side (tbh, i haven’t checked the new coordinates yet). I wonder if it’s possible to get the positions of the markers. The thing about the sector centroids was in context of the sector name positions, so the current coordinates may be used that way instead.
I’m hoping I can find something in the API that will be reliable when objectives are changed or added, as I’m trying to update to support the new desert borderlands prior to the HoT release.
Has anyone had any luck using the coordinates in /v2/wvw/objectives? I can’t quite get markers to line up on a map created with the tile service.
I’m actually not sure how the game client places markers — my impression is that the sector centroid is used for the label placement, not marker placement. I need to dig up how the markers are placed; I’m not certain that they’re data-driven.
Great endpoint but I have one question.
Is it possible to give us 3D coordinate instead of 2D? Currently I’m tracking the coordinates of the objectives in wvw on my own using the mumble api. Well I have the coordinates even for HoT but I would prefer to skip this step.
The data we’re using for objectives doesn’t have coordinates at all but they’re associated with sectors. Sectors don’t have 3D coordinates — they’re entirely 2D. IIRC the 3D bit comes from which floors the sector belongs to, though I think there’s only 1 floor for the WvW maps.
I’m actually not sure how the game client places markers — my impression is that the sector centroid is used for the label placement, not marker placement. I need to dig up how the markers are placed; I’m not certain that they’re data-driven.
If you find out that they are not data-driven, it would be awesome if we could get access to the desert borderlands in the tile service so we could map out those objectives prior to the release of HoT.
Maybe I asked wrong because I know how the layered maps are working.
Let me reword my question. Here is an older example of my overlay. It projects the self-tracked 3D coordinates of the objectives, in the same way the gw2 graphic engine would do, into the field of view of the users. As coordinates I use the center of the flipping areas of each objectiv.
Would it be possible to give us such 3D coordinates too?
Maybe I asked wrong because I know how the layered maps are working.
Let me reword my question. Here is an older example of my overlay. It projects the self-tracked 3D coordinates of the objectives, in the same way the gw2 graphic engine would do, into the field of view of the users. As coordinates I use the center of the flipping areas of each objectiv.
Would it be possible to give us such 3D coordinates too?
You’re looking at the capture gadget location (which is a 3D point). The capture gadget is only casually related to the objective, so pulling them out is going to be a doozie. It’s something I can look into doing, but I can’t make any guarentees.
The marker and label coordinates are only 2D points because they’re currently only used to render the map. I found out where the marker coordinates are stored so I’ll work on having those piped through (maybe before HoT ships, I dunno).
Has anyone had any luck using the coordinates in /v2/wvw/objectives? I can’t quite get markers to line up on a map created with the tile service.
I’m actually not sure how the game client places markers — my impression is that the sector centroid is used for the label placement, not marker placement. I need to dig up how the markers are placed; I’m not certain that they’re data-driven.
Found and fixed the issue. Github PR. It should go out with HoT release.
Found and fixed the issue. Github PR. It should go out with HoT release.
Woohoo! Thanks!
Out of curiosity, are there going to be any more API updates prior to HoT, or is this issue one that required some changes outside the API and that release isn’t happening until HoT?
