API access?

[kybrarian]

Hi,

On the AIScatcher.org website side menu, I see there is a grayed out option for an AIS API. Is that feature still in development/ is there a plan to enable API access to AISCatcher.org data?

Thanks!

[jvde-github]

In a way we already share data back via the local webviewers for "sharing" feeders but I indeed want to extent that a little so people can build their own apps on top of it (since they take the effort to share their data as well). It is still work in progress.

[kybrarian]

Thanks for your reply and work on the project. I do appreciate the option to add the community feed to the webviewer but also want data accessible in some way that makes it possible to use in my own scripts.

[asinghani]

I see the local webviewer capability was removed in a recent update, was it replaced with anything or is it currently not possible to get access to the data programatically at all?

[jvde-github]

Do you mean access to the community feed in your local web viewer? Because your own data can still be retrieved.

The approach for the community feed was changed indeed where the map on www.aiscatcher.org is now used with local data as overlay to show how reception compares to what others are picking up.

[asinghani]

Yeah I was interested in programmatic access to the community data for doing some analysis on ships that are not fully in my receiver range, but there doesn't seem to be a way to do that anymore even as a contributor

[fencer]

+1 For this :)

[mmDevel]

Hi, how does it look with the API access?

[jvde-github]

not the highest priority with all things going on, but if we organically reach 1000 feeders I will dump everything else :-)

In all seriousness, working now with some people that hopefully can help in this space.

[itemir]

Hi, an API would really be helpful. Is this still planned?

[jvde-github]

hi, yes still have that ambition for active feeders but cannot give a timeline or how we are going to implement.

[Phil353556]

I'm interested by, too. :-)

[bkeepers]

I run an open AIS aggregator, powered by an open source project I just released called aiscast. It already has the API this thread is asking for, and I'd like to offer it as a way to get AIS-catcher feeders their data back without adding to @jvde-github's plate.

What exists today:

• wss://ais.openwaters.io/v1/stream: subscribe by bounding box, get one JSON event per decoded message with source, station, receive time, raw sentence and decoded fields. No token.
• GET /v1/vessels?bbox=...: GeoJSON of everything currently in view. No token.
• GET /v1/stations: every source being heard, with counts and age.
• Raw receptions archived per source so any feed can be purged or attributed cleanly. Every event carries its source, and volunteer station locations are never published precisely.

Code is MIT, terms are per source, and the plan for volunteer data is an open license (ODbL is the proposal) under a written feeder agreement that is opt-in and can't be transferred to an acquirer. It's a beta: coverage is uneven and there's no SLA.

AIS-catcher users can feed it now with either -u ais.openwaters.io 10110 or -H https://ais.openwaters.io/v1/receive USERPWD x:<token> GZIP on INTERVAL 15, alongside -X, and their station page shows up at the map with ?station=<id>.

Two things I propose:

1. Make the -X destination configurable (AISCATCHER_URL / AISCATCHER_PORT are compile-time today). Feeders could then share with aiscatcher.org, aiscast, or both with the same flag, and nobody has to run two outputs.
2. If it would help, aiscast can be the API for the community hub: forward the hub stream (or a subset, with station IDs) and I'll archive it, serve it on the endpoints above and return the combined stream to feeders. Happy to do that under whatever attribution and opt-in terms you want, and to keep the aiscatcher.org map as the place people go to look at it.

I'm aware this is a sibling project turning up in your repo, so no hard feelings if neither fits. I just thought I would offer, and let people know there's an open API available if they need it.

[jvde-github]

Thank you Brandon. Looks like a good aggregator, and the ODbL and privacy angle is the right way to do it. Encourage people to feed you with -u if they like.

The API is still on the roadmap as mentioned above. I first want to tidy up the community site, so it won't be immediate (so is likely one or two more months but to be honest will not be an unlimited feed).

On making the sharing destination configurable, I'd rather keep that one clean. There are plenty of options to feed aggregators via the standard output methods (-u or -P), and community sharing stays reserved for serving and improving this project.

You are not the first to suggest btw. But in my view let's build projects and tools that add something new and are attractive enough for people to want to share data with — which is the direction you seem to be working in.

[bkeepers]

Thanks for the reply.

On making the sharing destination configurable, I'd rather keep that one clean…

What is slightly concerning to me is the change in 97fe081 that turns sharing on by default, while the feed back to contributors that used to exist is gone and the API will be "not an unlimited feed." So the default is that data flows in from everyone, and out to no one. Is that the intent? You've earned a lot of trust with this community and this change quietly erodes it. I know I would feel better about it as a feeder if opting everyone in came paired with contributors being able to get the aggregate back, even rate-limited, even feeders-only.

But in my view let's build projects and tools that add something new and are attractive enough for people to want to share data with — which is the direction you seem to be working in.

That's what everyone in this thread is trying to do. The hard part isn't building something new, it's that every project first has to spend most of its effort assembling enough data to be useful at all. The data layer is where we'd all win by cooperating, and then the tools can compete on what they do with it. That's the direction I'm working in with Open Waters.

My plan is actually to build a reciprocal exchange: I'll share a raw feed of my unique data with any aggregator that is willing to do the same. A rising tide lifts all boats.

Anyway, the offer to provide an API for you still stands. A peer exchange would also be far cheaper to ship than a public API and it would go a long way toward addressing the concern above about 97fe081.

[jvde-github]

Nice to hear that we have trust, and I think rightfully so — I believe this is one of those projects where there has never been any commercial agenda or idea of offering paid plans. Just a nice hobby over the last 5 years, which unfortunately cost me a bit more time and money than I was planning for :-) But it is so much fun.

Maybe good to respond to the point about that commit specifically. The idea was that the webviewer could be enriched with data from nearby stations — so the sharing was itself part of a feedback loop: you share, and your own webviewer shows more than your antenna alone can hear (what are you missing?). The opt-out applied only when running the webviewer, otherwise this would not work, and it came with a clear message on the command line and an easy opt-out. The first approach, where ships were shown in the webviewer (this community feed overlay), failed because the server was collapsing under bots abusing the entry points at over a million fetches per minute. I had to park it for this reason and introduced the Community Pane, which gives users back the same insight and visuals that the community feed provided. That was the quid pro quo.

But even if there is one person who thinks it is not transparent, or that there is an attempt to benefit from people, we should switch it off — it's reverted back to opt-in just now. Not worth any discussion.

I like the idea of a reciprocal exchange and I support people feeding your project. Note that in the past I have referred people looking for an API to AISHub. I might give your API a go as well.

[aragong]

+1, I am also interested in an API.

It would also be great to have an endpoint to access raw NMEA messages, as we (station owners) are sharing with the community. For me, this is the unique problem with AIShub. I do not know if that is due to any technical constraints, but having raw data accessible will be great.

Really great project, thank you Jasper!