peaq Brings Korea's Public Data to Robots and Machines

Korea's public data portal, data.go.kr, is now on robotic.sh. With peaqOS, a robot or machine can query government feeds directly, EV charger availability, the next hour of weather, the air quality where it stands. Autonomously, on demand, without human intervention.
Korea's public data portal, data.go.kr, is now available to robots and machines running peaqOS. A machine can ask whether a charging bay is free, whether it will rain in the next hour, and how bad the fine dust is where it is heading, and get the country's own answer back. Autonomously, on demand, without human intervention. Available now on robotic.sh.
An electric car is working its way through its day in Korea with 19 percent left on the battery. Its sensors read the road perfectly: the lane, the traffic, the curb ahead. What they cannot read is whether the charging bay it is driving toward is occupied.
It has two options. Commit to the nearest charger and find out on arrival, with too little charge left to try the next one. Or stop early and charge where it stands, giving up range it still had and the stops it still owed.
With Korea's public data on peaqOS, there's a third option: it asks before it moves. Sensors see what is around it. Data sees what is ahead.
What Korea's Public Data Portal Unlocks on robotic.sh
data.go.kr is Korea's official open data portal, and it is enormous: 11,867 Open API datasets published by ministries, agencies and public utilities. Charger locations from KEPCO. Next-hour precipitation from the Korea Meteorological Administration. PM2.5 from AirKorea's monitoring network. The country writes down what is happening on its own streets, and gives the data away.
It gives it away to developers, though. Every dataset needs a portal account and its own separate approval, and the key that comes out of that has to be held, scoped and kept alive by somebody. A developer can work through that once. A robot deciding something mid-shift cannot.
Starting now, selected services from that portal are available through robotic.sh. A robot or machine running peaqOS can ask which chargers around it are reported idle, pull the KEPCO station directory for locations and access hours, request the next hour of precipitation for its own 5 kilometer grid cell, and read PM2.5 from the monitor nearest to it. Each call goes out with the machine's own coordinates, under its own peaqOS identity, and the operator's key travels with the request instead of sitting on the robot.
It's the first integration of its kind: a national open data portal, made machine-consumable. And it's live on robotic.sh today.
Why This Matters: Cities Already Publish What Machines Need to Know
Public data was built for dashboards and app developers. But read the list again and it is an operations feed: is the bay free, is rain coming, is the air clean enough to run. Not civic statistics, but the inputs a machine needs before it commits a battery, a route, or an hour of its shift.
Getting them to a machine used to mean an integration project per dataset, per fleet: register the account, get each API approved, wire the endpoints, keep the key alive. That works for one robot. Not for a fleet querying a country dozens of times a day.
With the portal on peaqOS, the machine reads public infrastructure the way it reads its own sensors. It also stacks: NAVER Maps is already live on robotic.sh, so a machine in Korea can take its route from NAVER and its conditions from the government. Every new service added compounds peaqOS Scale's overall value.
peaq Handles the Coordination
peaq is the layer that lets machines reach Korea's public data and use it. For each query, peaq handles:
- Machine identity, via peaq DIDs
- Discovery of the service on the Machine Market
- Request-scoped credentials, so the operator's key never sits on the machine
- Coordination of the query, from request to result
- A verifiable, auditable record of what ran
So a machine can read a country's public data, without an account of its own and without a credential to carry.
Showcase: An Electric Car Asks Three Questions Before It Moves
We're showcasing the integration with a demo where an electric car in Korea checks three public services before committing to a charging stop. It's a real government-data flow, simulated with peaqOS, with peaqOS handling identity, discovery and the record, and data.go.kr returning the answers. This creates the foundation for autonomous delivery vehicles.
Here's the scenario: 19 percent left on the battery, a charging bay somewhere ahead, and both the weather and the air able to change the plan. Here's how the process unravels:
→ The car checks in under its own peaqOS identity and asks the Machine Market for Korean public data; peaqOS resolves the service and sends the operator's portal key scoped to that one call
→ Charger: the nearest bay is reported idle. That report is only as fresh as the provider's last update, so the car commits on the data and confirms with its own sensors when it arrives
→ Weather: no rain coming in the next hour in its 5 kilometer grid cell. Nothing to slow for
→ Fine dust: the AirKorea monitor nearest the bay grades the air good. Nothing to adjust
→ Every query leaves a verifiable, auditable record, and nothing is left behind: no credential stored in peaqOS, none on the robot
Three answers, no drama. Most of a machine's day is exactly this: ruling things out before they cost anything. Three public services, one machine, and not one account in its name.
More Real-World Scenarios
Scenario 1 — A Delivery Fleet Plans the Night Around Korea's Charger Map
The last van docks at eleven. By morning every vehicle needs to be full and back on a route, and the depot's own chargers cover half of them.
The old way is a list of public stations someone exported once, and a dispatcher phoning around to find out which are free.
Instead, each vehicle reads the KEPCO station directory through robotic.sh for locations and access hours, so it only considers the sites that are actually open at two in the morning. Then it asks which of those are reported idle, and takes the one that still works at its arrival time.
Locations from the directory, availability at the moment of the decision. No dispatcher, no exports.
Scenario 2 — An Outdoor Robot Waits Out the Next Hour
An inspection drone is due to fly a rooftop survey. Its camera is fine in clear air and useless in rain, and fine dust turns a clean image into a noisy one.
The old way is a forecast written for a city of ten million, checked by a human, and a machine that flies anyway because nobody told it not to.
Instead, the drone asks for precipitation in its own 5 kilometer grid cell and the PM2.5 grade at the monitor closest to the roof. Rain in the next hour means it waits twenty minutes. Dust above grade means it flies later, and files a usable image instead of a wasted one.
A forecast is only useful to a machine when the machine can read it itself.
And chargers, weather and air are where this starts. Parking, traffic disruptions, road works: Korea publishes all of it, 11,867 open APIs deep, and each one is a query a machine could be making.
Available Now on robotic.sh
Korea's public data is now live on robotic.sh for robots and machines running peaqOS.
Machines can query government feeds directly, under their own identity, with no account in their name and no credential stored on board. Every query leaves a verifiable, auditable record.
Because autonomous machines shouldn't have to choose between driving blind and waiting for a human to go and fetch the data.
They should be able to read the country they work in.
→ Visit robotic.sh to get started.