My RIPE visualiser for the DNS root system has previously been using this endpoint, that now returns an error: https://atlas.ripe.net/api/v2/cartography/locations Is there another I can use in its place with the same output? thanks, Ray
Hello Ray, We made quite some changes in the UI recently and eventually removed some older (undocumented, "internal") calls. This was one of them. Apologies if this causes you grievance. You have three alternatives - I'm assuming you're really after basic probe data, in particular coordinates: 1. Use the probes API: /api/v2/probes/ for info about multiple probes or a single one 2. I highly recommend using the daily dumps of the same ( https://ftp.ripe.net/ripe/atlas/probes/archive/) if you don't need real-time values for connectedness (which is usually the case). This is the cheapest option. 3. There's an alternative internal call with similar data to that original one, which we heavily use internally from now on. I can give you the URL if you insist :-) but this is subject to unannounced changes Regards, Robert On Tue, Jun 24, 2025 at 1:57 PM Ray Bellis <ray@isc.org> wrote:
My RIPE visualiser for the DNS root system has previously been using this endpoint, that now returns an error:
https://atlas.ripe.net/api/v2/cartography/locations
Is there another I can use in its place with the same output?
thanks,
Ray
----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/ripe-atlas.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
On 2025/06/24 14:17, Robert Kisteleki wrote:
Hello Ray,
We made quite some changes in the UI recently and eventually removed some older (undocumented, "internal") calls. This was one of them. Apologies if this causes you grievance.
You have three alternatives - I'm assuming you're really after basic probe data, in particular coordinates:
Yes, just coordinates and ID.
1. Use the probes API: /api/v2/probes/ for info about multiple probes or a single one
I have an implementation of this now, but only getting 500 at a time is somewhat suboptimal, for both of us! ;)
2. I highly recommend using the daily dumps of the same (https:// ftp.ripe.net/ripe/atlas/probes/archive/ <https://ftp.ripe.net/ripe/ atlas/probes/archive/>) if you don't need real-time values for connectedness (which is usually the case). This is the cheapest option.
Does your web server support on the fly uncompression of the bzip2 data? I note that the meta-latest is missing its .bz2 suffix despite being compressed.
3. There's an alternative internal call with similar data to that original one, which we heavily use internally from now on. I can give you the URL if you insist :-) but this is subject to unannounced changes
Understood - I'll get back to you on that if I can't make option 2 work. I'd prefer for folks that deploy the code not to have to deploy server-side logic to regularly download (and decompress) the latest file, but instead have the JS client retrieve it direct. The bzip2 compression might prevent that, though. thanks! Ray
Hi, On Tue, Jun 24, 2025 at 7:24 PM Ray Bellis <ray@isc.org> wrote:
On 2025/06/24 14:17, Robert Kisteleki wrote:
Hello Ray,
We made quite some changes in the UI recently and eventually removed some older (undocumented, "internal") calls. This was one of them. Apologies if this causes you grievance.
You have three alternatives - I'm assuming you're really after basic probe data, in particular coordinates:
Yes, just coordinates and ID.
1. Use the probes API: /api/v2/probes/ for info about multiple probes or a single one
I have an implementation of this now, but only getting 500 at a time is somewhat suboptimal, for both of us! ;)
Indeed. The API is really useful for searching, and perhaps fetching more than one page of results. But flipping through all pages (though it's possible) is not ideal.
2. I highly recommend using the daily dumps of the same (https:// ftp.ripe.net/ripe/atlas/probes/archive/ <https://ftp.ripe.net/ripe/ atlas/probes/archive/>) if you don't need real-time values for connectedness (which is usually the case). This is the cheapest option.
Does your web server support on the fly uncompression of the bzip2 data? I note that the meta-latest is missing its .bz2 suffix despite being compressed.
I guess we can make a meta-latest.bz2 to see how that works? It's really just a symlink to the most recent file which otherwise has a predictable name (today that's https://ftp.ripe.net/ripe/atlas/probes/archive/2025/06/20250624.json.bz2),
3. There's an alternative internal call with similar data to that original one, which we heavily use internally from now on. I can give you the URL if you insist :-) but this is subject to unannounced changes
Understood - I'll get back to you on that if I can't make option 2 work.
I'd prefer for folks that deploy the code not to have to deploy server-side logic to regularly download (and decompress) the latest file, but instead have the JS client retrieve it direct. The bzip2 compression might prevent that, though.
Understood. We can try the meta-latest.bz2 approach, but we can also have the latest as an uncompressed file (~25MB, not terrible). Also, my understanding is that one can use a library to uncompress on the client side, even in JS. Cheers, Robert
thanks!
Ray
On 2025/06/25 07:50, Robert Kisteleki wrote:
Understood. We can try the meta-latest.bz2 approach, but we can also have the latest as an uncompressed file (~25MB, not terrible). Also, my understanding is that one can use a library to uncompress on the client side, even in JS
Yes, good point, I'll try that, in the interest of saving your bandwidth! thanks, Ray
participants (2)
-
Ray Bellis -
Robert Kisteleki