here in Europe Spring is in the air, it is a time for new beginnings, and thus yesterday we rolled out a clean up to the look and feel of our main site and this blog.
It’s not a radical change by any means, just a slight refreshing which hopefully makes it easier and quicker for customers to find the content they need.
As time has passed we’ve pubished more and more guides and tutorials, which is great, but also means we need to continually work on keep it as simple as possible to find your way around the site.
Here are a few example screenshots, but of course you should check out the OpenCage site to explore in detail.
Please let us know what you think.
Happy geocoding,
]]>two weeks ago it was my pleasure to speak at IoTStars Barcelona which took place during Mobile World Congress (see the pics over on LinkedIn)
Lots of interesting discussions, and my presentation - especially the interactive component - seemed to be well received. It is thus with pleasure that I announce that I will also be speaking at the 2024 edition of IoTStars in Nuremberg on the evening of the 9th of April (during Embedded World).
We’re very fortunate to work with many customers from the IoT / asset tracking industry, small and large, around the world. IoTStars is the perfect forum to share the story of how we work with these partners and make new connections.
Many thanks to the IoTStars community, organizer Marc Pous, and the event sponsors for making these events happen.
We have a limited number of tickets to share, please ping me if you would like one.
Wir sehen uns in Nürnberg!
Final note - yes, the whole Nürnberg / Nuremberg is a great example of the joy of geocoding.
]]>This morning we had a delightful toot from our friend - and Geomob Berlin regular - Jilles van Gurp announcing a new Kotlin SDK for our geocoding API.
Thank you, Jilles!
While there was already a Kotlin SDK it was a few years past its prime and purely for Android. The new SDK from Jilles is multi-platform and uses all the shiny new libraries. You can of course find it on GitHub, and I am sure pull requests will be gladly received.
This new SDK joins the list of SDKs for geocoding in 30+ other languages and frameworks, so no matter how you like to do your geocoding we should have a solution for you.
Happy geocoding - whether in Kotlin or any other language
]]>Hi everyone,
welcome to the February 2024 edition of #fridaygeotrivia, our a social media geotrivia contest. We play on the final Friday of every month.
The game was played on Friday, 23rd of February, at 17:00 Berlin time, 4pm London time, 11am New York time.
See how to play below.
On the 21st of Feb, the world celebrated International Mother Language Day, a day to celebrate linguistic diversity. Thus this month’s #fridaygeotrivia question is - name countries with a single official language that is unique to that country (ie not official anywhere else - nationally nor regionally). As an example we have Iceland 🇮🇸 - the only country in the world where Icelandic has official status.
As always:
Only one answer per toot
You must include the hashtag #fridaygeotrivia and the emoji flag of the countries
#fridaygeotrivia is a game with two prizes:
the sheer joy of geographic knowledge and pedantry.
the bragging rights of getting the answer first.
Well done to Jocelyn for taking home the prize.
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,
]]>we’ve made a change to the
roadinfo annotation returned by our geocoding API. We now additionally try to set the fields
maxheight
, maxweight
, and maxwidth
.
As an example here’s map showing a bridge at the coordinates 53.63086, -1.80068
An API request to those coordinates with the optional parameter roadinfo=1
set will now return
"roadinfo": {
"drive_on": "left",
"maxweight": 3.0,
"road": "Hanson Lane",
"road_type": "residential",
"speed_in": "mph"
}
thus we see that that bridge has a maximum weight of 3 metric tons.
As you would expect the various fields and their possible values are explained in the API docs.
As always the key caveat with our road information is that this information comes from crowdsourced data sources like OpenStreetMap. It is not in any way “official” or “governmental” data. It may be wrong, incomplete, or out of date. Always drive safely.
Happy geocoding,
]]>I’m very pleased to share that I will be speaking at the 2024 edition of IoTStars on the evening of the 26th of February in Barcelona (during the week of Mobile World Congress).
We’re very fortunate to work with many customers from the IoT / asset tracking industry, small and large, around the world. IoTStars is the perfect forum to share the story of how we work withthese partners and make new connections.
Many thanks to organizer Marc Pous and the event sponsors. I have attended several times in past years, it is always a fun and informative evening, and I am excited to finally make it on the stage.
We have a limited number of tickets to share, please ping me if you would like one.
Also, even if you can’t make it to IoTStars, please let me know if you will be attending Mobile World Congress and would like to meet up.
See you in Barcelona!
]]>welcome to day five of Launch Week 2024!
Many of the users of our geocoding API are relatively new to the world of APIs, they come to us because they just want to geocode some data. They might be unaware of all the innovation happening in the API space over the last few years. Just as with all other corners of tech, there is a lot happening.
One of the key developments has been the continual refinement of the OpenAPI standard and the growth of an ecosystem of tools around that standard. If you are not yet familiar with OpenAPI, I can highly recommend Phil Sturgeon’s excellent Brief Introduction to OpenAPI.
OpenAPI has been around for a while, and we have had a basic OpenAPI specification for our geocoding API for many years. But it feels like the project is reaching a more mature stage. As such, I am pleased to announce we have revisited our OpenAPI specification, cleaned it up and upgraded it to the newest standard (v3.1.2).
Beyond just a general desire to stay abrest of technical change, one key motive behind this update is the rise of AI. We believe the future will hold more and more machines “talking” with each other. That conversation will happen via APIs, and necessitates tools that make it easy for computers to discover and understand APIs.
Frankly, it is a challenge. While some APIs have a finite list (usually very short) of possible responses, we are geocosing the entire world in all its diversity. And we do this with open data, much of it crowdsourced. This has many benefits, but it also means we work with a very diverse, continually-changing dataset. It is not always possible to anticipate what the API will return.
For those wondering, yes! the new OpenAPI spec of course includes reference to the distance_from_q field announced on Day 1 of Launch Week, and the _normalized_city field in components announced on Day 3.
We hope you find the new OpenAPI specification useful and welcome all feedback for improving it.
BTW if you want to stay on top of the innovation in the API space, I can recommend the APIs You Won’t Hate podcast. It was my pleasure to be a guest on the show last year.
And with that we wrap up Launch Week. We hope you’ve enjoyed the new features and improvements. People love “big bang” launches, but incremental improvements like these - improving the product 1% every day - are a very powerful lever that really compounds over time. Please let us know what you think.
Happy geocoding,
]]>welcome to day four of Launch Week 2024!
Today we go live with a new field in the components
portion of Geocoding API results: _normalized_city
.
A reality we are confronted with daily is that humans have an almost endless number of ways to organize their administration. Different countries (and even regions within countries) subdivide into cities, towns, municipalities, townships, villages, districts, suburbs, neighbourhoods, boroughs, etc, etc, etc. In some parts of the world these administrative divisions have clear definitions, in others they have evolved organically over centuries of history. There is not always a clear logic as to why one place is a village and another a town or whatever.
As you would expect we do our best to return the reality of the local situation for each geocoding result. But this often leaves geocoding API users - particularly those trying to build international products - confused about whether a location is in a city or a town or a village or what.
To solve this issue we now attempt to set the key _normalized_city
within the components
section of the API result. We do this simply by looking through the various fields in descending order (checking for the existence of city
, then town
, then township
, and so forth).
Developers who want the name of the settlement can now simply look for this new field and not need to worry if they are dealing with a town
or a village
or whatever.
Here’s an example of the components
portion of the response for the coordinates 51.37817, 10.13119
"components": {
"ISO_3166-1_alpha-2": "DE",
"ISO_3166-1_alpha-3": "DEU",
"ISO_3166-2": [
"DE-TH"
],
"_category": "travel/tourism",
"_normalized_city": "Heilbad Heiligenstadt",
"_type": "castle",
"castle": "Mainzer Schloss",
"continent": "Europe",
"country": "Deutschland",
"country_code": "de",
"county": "Landkreis Eichsfeld",
"house_number": "8",
"political_union": "European Union",
"postcode": "37308",
"road": "Friedensplatz",
"state": "Thüringen",
"state_code": "TH",
"town": "Heilbad Heiligenstadt"
},
You can see the new field "_normalized_city": "Heilbad Heiligenstadt",
Like the other component fields that we set (_type
and category
), rather than those we simply take from the underlying geodata we have available, this new field begin with an underscore. All of these fields are documented in the
section of the geocoding API documentation devoted to components
.
We should note that while we do our best to set _normalized_city
, it is not always possible. For example when the result is in a location where there is no concept of human settlement like coordinates in the middle of the ocean or similar. As ever we do the best we can with the data we have available to us.
Happy geocoding,
]]>welcome to day three of Launch Week 2024!
A few months ago we shared our new geospatial tools section to our site, where we expose various internal tools we’ve developed in the course of our day to day work, with the goal that others could also benefit.
Today we release a new “tool” - address and coordinate lists we use in testing. Often we have situations where we need to test algorithm changes or new features and we arrive at the situation where we say “We need coordinates in France to test with” or “I need a list of random postcodes”. Nothing is more annoying than working on fixing a bug or a new feature and not having good data to test - now you have two projects: fixing thoriginal bug and coming up with data for testing.
Overtime we’ve built up such lists, and we thought it could be useful to expose them publicly to help others. As a start we have lists of coordinates (by country), lists of addresses (by country), lists of European postcodes, random cities, lists of POIs (shops). Over time we will add more datasets, as we need them internally.
This new resource is of course listed with all the others on our tools page. Have a look, hopefully you find something that makes your life as a geospatial developer a bit easier.
Happy geocoding,
]]>welcome to day two of Launch Week 2024!
Just over a year ago we launched our NUTS annotation, whereby we return NUTS codes (levels 0-3) for locations in EU member states. Today I am pleased to report that we have now expanded coverage to the EFTA countries: Iceland (IS), Liechtenstein (LI), Norway (NO), Switzerland (CH)
As an example, here is the NUTS annotation in a geocoding result in Gelterkinden, Switzerland.
"NUTS": {
"NUTS0": {
"code": "CH"
},
"NUTS1": {
"code": "CH0"
},
"NUTS2": {
"code": "CH03"
},
"NUTS3": {
"code": "CH032"
}
Here you can see a map, (a screenshot taken from the Eurostat website) shows NUTS2 regions across Europe.
Learn more about the NUTS annotation (and all the others) in our geocoding API documentation.
For now We still don’t return NUTS codes for EU candidate countries, potential candidates, or former-EU countries. If you need those please get in touch, our progress is of course guided by customer requests.
Happy geocoding,
]]>