1. Can you introduce yourself, your involvement with OpenStreetMap, and what first got you interested in open mapping?

I’m Volker, contributing to Free Software for more than two decades, mostly in the KDE community. As part of the work on the travel app “Itinerary”, I started using OpenStreetMap data, initially for indoor map rendering and indoor routing, especially in train stations. That’s also how I ended up as part of the team that started Transitous two years ago.

2. What is Transitous, and what motivated you to build it? What problem are you trying to solve with it?

The primary source for public transport routing for Free Software applications prior to Transitous were the proprietary APIs of public transport operators and agencies. Usage of those was tolerated at best, the APIs had to be reverse engineered and could change or even disappear entirely at any time.

That’s not an ideal foundation to build applications on, so we wanted something better. Transitous is a public transport routing service built entirely on Free Software and Open Data. It’s run by the community as shared infrastructure for free applications needing access to realtime public transport data.

3. Why does it matter to build open, shared public transport routing infrastructure instead of relying on proprietary platforms?

What’s even worse than the technical limitation mentioned above is that these proprietary APIs only cover the regions an operator is active in, and only their own services. While understandable from their perspective, as a traveler I don’t want to have to manually find the right operators for the regions I’m traveling in, and to query multiple sources to get the full picture of all available options.

Transitous doesn’t care about regional nor operator boundaries, on the contrary.

Having no conflicting interests also allows us to look into things that are unlikely to be provided in proprietary services. One such example is transfer routing for wheelchair users, taking into account the realtime operation status of elevators. These kinds of features usually only appear in proprietary services in response to regulatory pressure.

Another example is ongoing work for taking empirical delay information into account, something that is also very unlikely to be done by operators trying to advertise their own services.

We’ll only get things like these if we as a community build them ourselves, and Transitous is a platform on which we can do this.

4. Where does OpenStreetMap data work well for routing today, and where does it still fall short, especially for pedestrians and public transport use cases?

The OpenStreetMap data generally works very well for routing, and the fact we just have to work with one single integrated planet-wide dataset alone is a massive help.

For routing transfers inside e.g. train stations there’s some aspects where improving the mapping would help though.

In multi-floor stations we heavily rely on the “level” tag. Its use and maintenance varies a lot across different countries. Also, none of the standard views on the OSM website visualize it in any way yet, which isn’t helping with this either.

When considering accessibility in routing it’s mostly about the level of detail. Technically it’s not a big difference whether you route for a pedestrian or a wheelchair user, but for the latter the result becomes useless if we miss just a single step somewhere. So every such barrier has to be mapped for this to work reliably.

5. What are the main technical and data integration challenges in building a cross-border public transport routing system using OpenStreetMap and open transit data?

For the public transport schedule data we don’t have the luxury of a single integrated dataset. There we are currently integrating more than 3000 data feeds. Those need to be properly aligned so overlaps don’t result in duplicates, and normalized so that you get consistent results everywhere.

Part of that is also realtime data that updates once a minute, and that continuously needs to be matched to the static baseline data. Given the rapid update frequency, this has to work fully automatic, without human review or intervention.

6. What could the OpenStreetMap and open mobility communities do to better support projects like Transitous?

While there’s of course always details in the data that could be improved, the collaboration with the OSM community works great.

Public transport operators actually providing their data (which at least in the EU is legally required), doing so with a decent quality, and being responsive to feedback to issues we find would help a lot though. How well that is done varies greatly unfortunately.

7. OpenStreetMap recently celebrated 20 years. Where do you see the project in another 20 years?

I’m sure OSM will still be around and be more relevant than ever. I find it very hard to predict how things will evolve though.

For example: Just three years ago a community-run public transport routing service with even just national-wide coverage was considered technically impossible with realistically available resources. Two years ago the assumption was that the best we could do is stop-to-stop routing in a handful of European countries. Recently our test server has demonstrated door-to-door routing from Berlin to Tokyo. Something that might seem infeasible today might just get implemented tomorrow.

One area in the vicinity of OSM that I’d like to see progress in and that today is still dominated by a few proprietary vendors is dynamic traffic data, i.e. anything from temporary road closures to traffic flow data. I hope we’ll have all that liberated as well eventually, maybe even a bit earlier than in 20 years.

Transitous demonstrates the power of open data and community collaboration in solving complex mobility challenges, from cross-border routing to accessibility-aware navigation. As Volker notes, the future of open mobility will depend on how communities continue to build and expand these shared systems.

A big thank you to Volker Krause for sharing his insights.

Danielle

Please let us know if your community would like to be part of our interview series here on our blog. If you are or know of someone we should interview, please get in touch, we’re always looking to promote people doing interesting things with open geo data.

one small thing to announce before we head off into the long weekend.

Specifically we’ve made a minor security-conscious update to how the OpenCage Geocoding API handles the optional add_request parameter.

When add_request is set to 1, the API includes the original request parameters in the response, a useful feature for debugging. One of those parameters is the required API key.

We now return only the first 6 characters of your key in the response, with the remainder replaced by asterisks (e.g. ab1234**************************).

For a full example of the JSON response:

{
   "documentation" : "https://opencagedata.com/api",
   "licenses" : [
      {
         "name" : "see attribution guide",
         "url" : "https://opencagedata.com/credits"
      }
   ],
   "request" : {
      "abbrv" : 0,
      "add_request" : 1,
      "address_only" : 0,
      "format" : "json",
      "key" : "ab1234**************************",
      "language" : "en",
      "limit" : 10,
      "min_confidence" : 0,
      "no_annotations" : 0,
      "no_dedupe" : 0,
      "no_record" : 0,
      "pretty" : 1,
      "proximity" : "",
      "query" : "52.5432379, 13.4142133",
      "roadinfo" : 0,
      "version" : "v1"
   },
   "results" : [
      {
...      

Why the change?

API responses are often written to log files, and it’s easy for sensitive values to end up somewhere they shouldn’t be. By masking most of your key, we reduce the risk of it being inadvertently exposed through application logs or debugging output.

What do you need to do?

For the vast majority of developers, nothing. This change is purely cosmetic, your actual key is unchanged and your requests will continue to work exactly as before.

Unrelated to this change, you can always generate a new key at any time. Subscription customers can have multiple keys, free-trial and one-time plan customers are limited to a single active key.

We also encourage you to review our guidance on how to protect your API key and our broader security policies.

This change is listed in our public Change Log.

As always, we welcome you feedback.

Happy geocoding,

Ed

1. Who are you and what do you do? What got you into OpenStreetMap?

I’m Christian Quest, almost 60, currently working at IGN (French Geographic Institute) on Panoramax.

My first contact with OpenStreetMap was in 2009, when I signed in. Then I became a founding member of OpenStreetMap France, in 2011 and a board member for 11 years. I’m still maintaining a large part of OSM-FR servers, including the OSM-FR Panoramax server and blurring API.

2. What is the proposed Panoramax foundation? What inspired you to create it?

Panoramax is a project that started in 2022. OpenStreetMap France proposed to IGN to work together to build an open source, collaborative, decentralized and federated way of sharing ground level imagery. The idea was not new, I proposed something similar back in 2012!

After almost 4 years, it is time to setup a dedicated structure to take care of the project which cannot stay inside the French borders. We already have Panoramax servers in Taiwan, Wales, Spain, Croatia and several others should arise soon.

The OSM foundation is a source of inspiration, mainly on its light approach. OSMF takes care of the very core things (the main database, some basic services on top of it, and tools for the contributors), letting an ecosystem and local chapters build on that core to provide many additional services around OSM data.

I think the Panoramax foundation should also take care of the core of the project, like the meta-catalog that is federating the autonomous local Panoramax instances and some shared tools for contributors or to help set up new Panoramax instances.

Another thing the Panoramax foundation should take care is the coordination of the actual software stack development. This does not mean the foundation will do all developments, but it should make sure they fit a shared goal for the emerging Panoramax ecosystem.

3. What unique challenges or obstacles do you foresee in creating the Panoramax foundation?

The diversity of actors can be a source of challenge because we already have public services, local authorities, companies, not-for-profit structures and individuals involved in the project and their culture may be quite different.

Another source of challenge is the international aspect. We’ve been moving quite fast in France, but Panoramax is still not massively deployed outside of France.

4. The creation of the foundation is expected at the end of August during the annual OpenStreetMap conference. How can the OSM community get involved, and what types of contributions would be most helpful?

The SotM 2026 in Paris is an opportunity that we could not miss to extend Panoramax. We’ve been talking many times during the past years about creating a Panoramax foundation, setting the SotM 2026 as the birth of this foundation is pushing all the possible founding members to move forward before that date.

Some hardware, hosting and human resources will be needed. These can be donated to the foundation (hardware, hosting or human work time), and some may need to be funded. Funding can come from foundation membership fees, grants, donations, and other sources allowed by the law for non profit associations.

5. OpenStreetMap recently celebrated its 20th anniversary. As someone who has been active in OSM for years, where do you see the project in 20 years?

That’s a very difficult question to answer!

I see many challenges that we need to address… “data gardening” is my main concern. OSM needs more and more contributors to maintain the ever increasing amount of data.

Maybe more automation will be used to help gardening, but I’m also afraid of the AI trend if it is not viewed with enough objectivity.

We should continue to see OSM first as a community, then as a huge amount of data maintained by this community.

Thank you, Christian, for taking the time to speak with us again and share your perspective. It’s been great catching up after all these years, and we look forward to seeing how your work with Panoramax and OpenStreetMap continues to develop.

Danielle and the OpenCage team

Please let us know if your community would like to be part of our interview series here on our blog. If you are or know of someone we should interview, please get in touch, we’re always looking to promote people doing interesting things with open geo data.

Welcome to the April 2026 edition of #fridaygeotrivia, our social media geotrivia contest.

As per tradition we play on the final Friday of the month, which this month is Friday, 24th of April, 2026, at 17:00 Berlin time, 4pm London time, 11AM New York time.

See how to play below.

The April 2026 geotrivia question:

Name country pairs that share at least one significant land border segment deliberately drawn along a line of latitude or longitude - a “ruler border.”

An example is the 🇺🇸 US and 🇨🇦 Canada along the the 49th parallel.

As always:

• Only one answer per toot

• You must include the hashtag #fridaygeotrivia and the emoji flag of the countries

Prizes

#fridaygeotrivia is a game with two prizes:

1. the sheer joy of geographic knowledge and pedantry.

2. the bragging rights of getting the answer first.

The #fridaygeotrivia Mastodon thread:

Post by @opencage@en.osm.town

View on Mastodon

The winner

The winner by a mile was @ccferrie. Second place was shared between @milvus and @tlohde.

This month’s geotrivia answer:

Show / hide answer

How to play

Anyone can join in, you just need a Mastodon account.

• Follow us on Mastodon, our account is @opencage@en.osm.town

• When the game starts we will post the question here on the blog and on Mastodon, and will embed the Mastodon question here. We highly recommend using a mastodon client you feel comfortable with. We’ve made the switch to the Elk client and are loving it, but use whatever works for you.

• Reply to the question thread on Mastodon (it will be embedded above) using the hashtag #fridaygeotrivia in your answer.

• Only one answer per response (don’t stuff multiple answers into a single reply).

• Our definition of “country” is usually (it depends on the question) any place with an ISO 3166-1 alpha-2 code. Read more background about ISO and country codes in our guide.

• To get full points for an answer it is good form not just to name the relevant country but (if possible) to include the emoji flags of the country.

• While you can use a map, please do NOT use the internet to just search for an answer. That is cheating and will lead to seriously bad geokarma.

Some people have complained that the format is a bit chaotic and hard to follow. Yes. The mad chaos is part of the fun. Embrace it. The goal is just to have fun and learn. We win by playing

Thanks for playing,

Ed

next week our friends at GeoAwesome will be hosting “The Next Geo”, a five day, global online event to celebrate 15 years (amazing!) of GeoAwesome, while also looking forward at the technologies and trends that are shaping the geospatial industry.

I am delighted to share that I have been invited to take part, I will be speaking on Monday, 20th April in the “The AI Transformation: From APIs to Conversations” session, which will take place from 8:30pm to 9:30pm central European time.

Like every industry, AI is bringing major changes to the geospatial technical stack. And yet geospatial fundamentally remains a way to describe the complxxities of the physical world to humans, and humans are not changing. It is this contrast (some might say “conflict”?) that we will explore.

Registration is now open, I hope you can join us!

I close by offering huge congrats to the GeoAwesome team for their efforts over the last fifteen years, it is quite the milestone.

Ed

like almost everyone in software development, we’ve been playing with using AI to help with our work. Most notably we’ve been spending a lot of time in Claude Code.

We’re excited to announce the release of OpenCage Agent Skills to make it simple for Claude and other agentic AI systems to quickly learn about our geocoding API and geosearch service.

The geocoding Skill includes general background about the API and references for installing and using SDKs for various popular programming languages (Python, Node.js, Ruby, Java, etc) as well as our command line geocoding utility. The geosearch Skill trains the AI on how to configure and install our location autosuggest widget.

In both cases the goal is to make it simpler for agents (and software developers) to understand our services and quickly implement them. The new skills are hosted on GitHub and we welcome any pull requests you may have.

The future of AI and geocoding?

We are now frequently getitng asked about whether AI will replace geocoding APIs. So much so that we recently added a “What about AI?” section to our Geocoding Buyer’s Guide. In short, geocoding is a deterministic process where there is a clear correct answer. This is very different than the probabilistic nature of Large Language Models (LLMs). So the correct model is almost certainly for an AI agent to call a geocoding API to get the correct answer. This is also significantly cheaper and faster. And with out new Agent Skills that sort of combined architecture is now easier than ever.

Try It Now

If agentic coding is your thing please take our new Agent Skills for a spin (see the install.md file to get started (or just ask Claude to install it), and let us know how it works out. We welcome your feedback.

Happy agentic geocoding,

Ed

Note - this post was written by a human, not an agent!

Welcome to the March 2026 edition of #fridaygeotrivia, our social media geotrivia contest.

As per tradition we play on the final Friday of the month, which this month is Friday, 27th of March, 2026, at 17:00 Berlin time, 4pm London time, 11AM New York time.

See how to play below.

The March 2026 geotrivia question:

Name countries whose official/primary language uses a writing script unique to that country

As always:

• Only one answer per toot

• You must include the hashtag #fridaygeotrivia and the emoji flag of the countries

Prizes

#fridaygeotrivia is a game with two prizes:

1. the sheer joy of geographic knowledge and pedantry.

2. the bragging rights of getting the answer first.

The #fridaygeotrivia Mastodon thread:

Post by @opencage@en.osm.town

View on Mastodon

The winner

We had an intense game, that in the end resulted in a eight way tie! Two points each by @amapanda, @SuperDani, @antonia, @milvus, @AtanasE, @ccferrie, @tlohde, and @lis

This month’s geotrivia answer:

Show / hide answer

How to play

Anyone can join in, you just need a Mastodon account.

• Follow us on Mastodon, our account is @opencage@en.osm.town

• When the game starts we will post the question here on the blog and on Mastodon, and will embed the Mastodon question here. We highly recommend using a mastodon client you feel comfortable with. We’ve made the switch to the Elk client and are loving it, but use whatever works for you.

• Reply to the question thread on Mastodon (it will be embedded above) using the hashtag #fridaygeotrivia in your answer.

• Only one answer per response (don’t stuff multiple answers into a single reply).

• Our definition of “country” is usually (it depends on the question) any place with an ISO 3166-1 alpha-2 code. Read more background about ISO and country codes in our guide.

• To get full points for an answer it is good form not just to name the relevant country but (if possible) to include the emoji flags of the country.

• While you can use a map, please do NOT use the internet to just search for an answer. That is cheating and will lead to seriously bad geokarma.

Some people have complained that the format is a bit chaotic and hard to follow. Yes. The mad chaos is part of the fun. Embrace it. The goal is just to have fun and learn. We win by playing

Thanks for playing,

Ed

it has been a while since we’ve posted here about Geomob, the geospatial event series we sponsor and help organize.

Geomob is thriving, and so far this year it was my pleasure to take part in very well attended events in Berlin (25 Feb) and London (28 Jan).

Best of all, I am very pleased to announce two new Geomob locations joining the community.

On April 16th the first ever Geomob Cologne will take place thanks to local organizer Christoph Friedrich, and I will be speaking on the topic of The Joy of Geocoding!

The on May 26th there will also be the first ever Geomob Fredericton in New Brunswick, Canada. Unfortunately that’s a bit too far for me to travel (this time!), but the line-up looks excellent and I have no doubt it will be a great event. The first of many I hope. Thank you to Bernie Connors for heading up the local organizing.

We of course continue to have events in London, Barcelona, Berlin, Edinburgh, and other European cities. A huge thanks to all the speakers, organizers, venue partners, sponsors, and of course attendees that make Geomob possible. It is fantastic to see how the community has grown over the past few years.

If you can’t make it to an event - or even if you can - there is also the weekly Geomob podcast, where we discuss topics from across the whole spectrum of geospatial. We recently added industry veteran Jeremy Morely as our fifth host, helping to expand the range of topics we cover.

I hope to see you at a Geomob event soon, be it in Cologne or elsewhere!

Ed

1. Who are you and what do you do? What got you into OpenStreetMap?

Martin: We are Freemap Slovakia, the Slovak local chapter of the OpenStreetMap Foundation, established in 2009. Our main goals are to promote OpenStreetMap in Slovakia, to build and operate our own map portal freemap.sk, and to improve OSM data coverage — including negotiating access permissions and performing imports from open government sources. The organisation is run entirely by volunteers.

2. What would you say is the current state of OSM and the OSM community in Slovakia?

Martin: Slovakia has a small but technically skilled and dedicated community. On a typical day, around 10–20 mappers are active, and the top contributors are very prolific. Many active Slovak mappers are not yet members of Freemap Slovakia — if you map in Slovakia, we’d love you to join us! We’d also like to attract more mappers overall, especially from rural areas and smaller towns that are still less well covered.

Data coverage is strong for a country our size. Address coverage stands at around 96%, road networks and hiking trails are well-maintained, and we have excellent open government geodata to work with: the Ortofotomozaika SR provides high-resolution aerial imagery updated in regular cycles, and high-quality LiDAR data is publicly available — we actively use both for improving landcover, waterways, and terrain shading.

We also have a close relationship with the Czech OSM community — cross-posting in each other’s forums is common, and we jointly organise the annual State of the Map CZ+SK conference.

3. What are the unique challenges and pleasures of OpenStreetMap in Slovakia? What things should the rest of the world be aware of?

Martin: The landscape is a genuine pleasure to map — Carpathian mountain ranges, dense forests, thousands of kilometres of marked hiking and cycling trails, castles and historical sites. There is always something interesting to add or refine.

We are proud of www.freemap.sk — our non-commercial map portal built on OSM data, offering a detailed outdoor map for hiking, cycling, skiing, and horse riding across Central Europe. It includes marked trail overlays, route planning for many transport modes, a GPX track viewer, live tracking (OsmAnd, Locus, Traccar), offline map export, GPS device map downloads, and a community photo layer — available in seven languages. We also maintain LiDAR-based tooling for landcover tracing and waterway accuracy improvement.

On the challenge side, the open government data situation has been deteriorating. Our government has been gradually closing datasets that were previously freely available, and the cadastral office suffered a serious cyberattack with poor backups, slowing access to up-to-date cadastral data. This is a real concern for OSM in Slovakia going forward.

4. What is the best way to get involved? Is there a regular meet-up? A mailing list? Where does the community meet (in person and online)?

Martin: The best starting point is our Google Group:— technical discussions, import proposals, and mapping questions all happen there.

For news and updates we also have a Facebook page and a Mastodon account .

In person, we hold an annual general assembly once a year as a weekend gathering — talks, planning, and always some local mapping. A good chance for remote contributors to finally meet.

5. What steps could the global OpenStreetMap community take to help support OSM in Slovakia?

Martin: Anything that helps OSM globally helps Slovakia too — better tooling, broader public awareness, stronger core infrastructure.

One area worth highlighting specifically: the OSM tagging schema. Documentation for many tags is unclear or unfinished, and the same feature often has multiple competing tagging conventions. The community should be less afraid to clean up legacy tags and consolidate — AI tools could actually be a real asset here for auditing and rationalising tagging at scale.

6. OpenStreetMap recently celebrated its 20th birthday — a natural time to reflect on how far the project has come, but also to look forward. Where do you think the project will be in 10 years, both globally and in Slovakia specifically?

Martin: Globally? Hoping for OSM API 0.7 😄. More seriously, I expect OSM to become the default base layer for geospatial applications worldwide, with AI-assisted mapping accelerating coverage in under-mapped regions — though quality assurance and community governance will need to keep pace.

For Slovakia, I hope to see address coverage climb from ~96% toward complete, and a general improvement in precision across all feature types — landcover from LiDAR, more accurate waterways, better building footprints. The data is largely there; the next decade is about refining and deepening it.

Many thanks to Martin and the Freemap Slovakia team for taking the time to share their perspective and for the work they do supporting OpenStreetMap in Slovakia.

Forward!

Danielle and the OpenCage team

Please let us know if your community would like to be part of our interview series here on our blog. If you are or know of someone we should interview, please get in touch, we’re always looking to promote people doing interesting things with open geo data.

We’re excited to announce the launch of unlocode-lookup.com — a fast, simple tool for looking up UN/LOCODEs anywhere in the world.

What is a UN/LOCODE?

UN/LOCODEs are standardized five-letter codes used to identify ports, airports, rail terminals, and other logistics locations across the globe. They’re essential in international trade, shipping, and customs documentation. Long time blog readers will recall we added support for geocoding to and from UN/LOCODEs a few years back.

What We Built

Our new stand-alone UN/LOCODE Lookup site does exactly what it says: enter a code (like DEBRV for Bremerhaven, Germany) and instantly get the location details you need. No clunky spreadsheets, no digging through UNECE downloads — just a clean, focused search experience.

Behind the scenes the tool is powered by our geocoding API.

Who It’s For

Whether you’re a logistics professional, a developer building trade software, or just someone trying to decode a mysterious five-letter code on a shipping document, UN/LOCODE Lookup is built for you.

Try It Now

Head to unlocode-lookup.com and give it a try. And if you need programmatic access at scale, check out our geocoding API.

We welcome your feedback.

Happy geocoding - whether with normal addresses or UN/LOCODEs,

Ed