How to activate HERE-Maps

[Gasthof]

How can I use HERE maps in Imatch?

I have a HERE API key and an APP code. Unfortunately, I am too stupid to enter the code and/or the key correctly in the HERE-Id field in 'settings/Geo and Maps' to activate the HERE maps.

Do I only have to enter the API key or also the APP code? With or without spaces?

Or do I have to enter the description APP-Code in the input field before the key and/or code? API-ID: or API-Code:? Is a single entry sufficient, i.e. just the API ID or the app code? Or both together? With or without a hyphen in between?

I have tried out several variants. None led to success. The HERE maps are not displayed, even after restarting Imatch.

Thank you for your help!

[thrinn]

My understanding is that you either enter a combination of App-ID and App-Code (an older method for authentication) or the API key only (newer authentication method). I have an API key which I provide in Preferences, and it simply works.
I assume you did read the corresponding HERE API key documentation in the IMatch help?

I don't use HERE very often. I assume it should be possible to find the API keys I requested somewhere on their developer platform - but I failed to do so. Just got lost on the platform

[Jingo]

I think something is either going on at HERE or they changed a URL to their API requests.  I cannot get my own HERE Reverse geocoder app to work and the IMatch Map app is getting a "429 - Too Many Requests" back from HERE... will try again later to see if something changes.  

BTW: a credit card is now required at HERE (just like Google) to fully utilize their free tier... seems all companies are headed in this direction now.

[Mario]

Just tried. HERE works both in the Map Panel (map and search) and also for reverse geocoding.

[Gasthof]

Thank you for your answers.
My problem seems to be that I am not entering the key in the correct format:

Let's assume the key has the following content:12345691234567891234569

The APP_Key would be: 9999888777


In "Preferences/Geo and Maps/Services" I enter the Api key in the "HERE App.Id ..." field.

But in what format? Just the character/letter sequence? Or with the prefix Api-Key:12345691234567891234569

Both variants do not result in the HERE maps being displayed.

Or do I have to enter and concatenate the App-iD in addition to the Api-Key? In which format? How are both details to be separated?(, or; or: or not at all?)

Also: 9999888777:12345691234567891234569
or
9999888777,12345691234567891234569
or
APP-iD:9999888777,APi-Key:12345691234567891234569

I am swamped!

[Mario]

For the past couple of years, the format was

Since 2020 the format is just the API key.

That's what I use for years and it works (just checked).
This is also the format to use according to the IMatch help: HERE API Key

Take note of the You need a REST API KEY. Not JavaScript instruction.

[Jingo]

Its working again for me now... I guess the 429 was on the HERE side and they shut down map requests for traffic issues?

[Mario]

Its working again for me now... I guess the 429 was on the HERE side and they shut down map requests for traffic issues?

Very possible. Occasionally, all vendors have out-times due to upgrades.

[jmsantos]

I have never been able to get the Reverse Geocoding system to work with HERE. Sometimes I can see the maps, other times I can't. I have created the API Key as instructed, but it never worked and I have given up. I try again sometimes, like now, to no avail.

[Mario]

When reverse geocoding fails, IMatch logs the error message returned by the service to the log file log file.
This will tell you what's wrong. If the HERE map does not load, there is also usually an error message either in the Map Panel itself or in the Output Panel > Apps. I would recommend to double-check your API key in their Dashboard to see if it has not expired (e.g. credit card expired and not updated). They usually send emails in that case, like Google or Microsoft.

[jmsantos]

I attached last warning lines in the Log file, every time I try Reverse Geocoding with HERE.

And this window.

[Mario]

I see an error 403 (access forbidden) in the log.
Check your HERE license key and ensure it is valid and entered correctly. See HERE Maps API Key for details about the key and which type of key you need.

[jmsantos]

Yes, I have followed the process explained in the help several times. I have created a new account, a new API Key, but it doesn't work for me for some reason.

[Mario]

Make sure you get yourself a REST API key, not a JavaScript API key.

[jmsantos]

Yes, I have made sure to create REST API KEY.

[Mario]

Then I have no further idea, sorry.

I have setup my HERE account years ago, updated it once when they changed the style of their API keys, and that's it. Still works fine, just checked. Maps and geocoding working.

[jch2103]

I'm having the same problem. I hadn't used the HERE maps option for a while, but tried to use it after seeing this thread. I've had HERE maps keys since 2019 that worked successfully. When I now select one of the HERE options in Map Type, I now just get a black window in Maps. Like @jmsantos, I tried creating a new HERE REST map key, but no better results.  

I also tried reverse geocoding with the HERE REST API and got this error message:

Code Select Expand

Connection Problem
IMatch could not establish a connection with the geocoding service at HERE. The server may be unavailable or too busy. Please try again later. 
I've attached the log in case it's of any help. 

[Mario]

Same 403 (forbidden / access denied) error.
Maybe your IP address has been put on a ban list?

Looking at the number of spam bot registrations I have to kill every day here in the community, more and more IP address ranges are taken over by bot nets. Which may result in entire IP ranges being blocked by the big services to protect their servers...!?

[jch2103]

HERE provides for trusted domains in their API: 
https://www.here.com/docs/bundle/identity-and-access-management-developer-guide/page/topics/plat-using-apikeys.html#using-api-keys-in-a-request

This is supposed to be optional, but if HERE is blocking 'untrusted' domains by default, it may be mandatory. 
If I add a trusted domain, what should I be using for HERE to trust? My desktop IP address? I assume not an IMatch-specific domain.

[Mario]

It's very likely, unless you lease a permanent IP address, that you get a new IP address assigned from your ISP's pool every 24 hours or so.

The access management of HERE is based on the assumption that all requests come from a fixed IP - e.g. IMatch routing all your requests over one of my servers with a fixed IP addresses registered with HERE.

IMatch does not work that way, for privacy reasons.

When you use the Map Panel or reverse geocoding, IMatch directly communicates with the service. It does not route your requests over a server under my control. Which means that whatever IP address you're currently using is the IP address HERE/Google/Bing sees. And if your ISP has assigned you are "bad" IP from a pool, the service may refuse your connection.

When you use other software, all your Map requests and reverse geocoding requests may be routed via a server controlled by the software vendor. And it's IP registered and certified with HERE (Google / Microsoft / ...).

They know who you are (from your subscription) and I'm quite sure they harvest, personalize and sell the data you produce by using their "Map Panel" and "reverse geocoding". A vendor can get very good rebates and kick-backs e.g. for Google Maps and Google reverse geocoding usage when they in return sell the "who" and "when" and "what" to Google.

IMatch does not do that.

Which means that when the IP address you're currently has using been flagged as a "spam source" or abuse vector, services  may refuse to serve you. Or, maybe, the credit card you have registered has expired and you did not update it. Or something similar. I don't know.

I've personally never had any problems with HERE, Google Maps, Bing Maps, OpenSourceMaps or GeoNames.org, so my experience in that matter is really limited.

Maybe contact HERE support and ask them why their server returns 403?
Include the service used, your IP at the time and the date and time so they can lookup the issue in their logs. IMatch provides all the info (excluding your IP address, for privacy reasons) in the log file.

[thrinn]

Mario,
which call does IMatch use internally to reverse-geocode with HERE?
Is it this one (replace XXXMYAPIKEYXXX with the actual API key)?

Code Select Expand

https://revgeocode.search.hereapi.com/v1/revgeocode?at=52.5308,13.3856&apiKey=XXXMYAPIKEYXXX
Or do you use a different API call?

Because there is something I don't quite understand:

• I have an API key I created some years ago. This API key works flawlessly within IMatch as well when used with the direct https call above.
• For testing purposes, I created a second "App" in the HERE developer center. Then I created an API key for this second App. This second API key works when used in the direct call above. But in IMatch, it produces just an 403 error.

So, what is the difference between the API call IMatch issues and the call I use by entering the call manually in the browser?

[Mario]

In IMatch 2023, I use

https://reverse.geocoder.api.here.com/6.2/

for API keys containing a : (old style)

and

https://reverse.geocoder.ls.hereapi.com/6.2/

for other API keys. The APIs are versioned and stable. And my old A:B and my current key works fine.

In IMatch 2025 I have migrated to v7 of their API (latest version). My API key works for both the v6 and v7 API endpoints.
In v7 HERE has changed the response format completely, which required me to add a branch in order to still work with old : API keys and v6 and with v7 with the other API keys.

For the Map Panel search function, the app uses

https://geocoder.ls.hereapi.com/6.2/geocode.json

for "modern" API keys and

https://geocoder.api.here.com/6.2/geocode.json

for the old keys.

[thrinn]

Apparently, my several years old API key works with both API versions (6.2 and 7). But the ones I created today and some months ago, just for testing purposes, don't work.

Both of them are the "new style" API keys, without APPID. 

I used this example from the HERE web site, which works with the old API key but not the new one:

Code Select Expand

https://geocoder.ls.hereapi.com/6.2/geocode.json?searchtext=425+W+Randolph+Chicago&apiKey=XXXMYAPIKEYXXX
I guess that the new keys do not have access rights to the older 6.2 version of the API. And I can't "link" the 6.2 service to its "project" because it is not available in the corresponding drop-down on the HERE web site. As the 6.2 API is officially in "Maintenance mode" (aka "retired", more or less) I guess they don't allow to create new keys with access to the older API version.

I wil just continue to use my old API key until IMatch 2025 is out (which is in the very near future I hope ) and then try again.

[Mario]

I found this in their FAQ:

A: Any app created on developer.here.com can use the legacy API key, while those using the API key generated on platform.here.com need to migrate to the new successor APIs.

So, maybe that's it?
I can use a freshly created API key for one of my existing (!) apps with the v7 API version (2025), but not with the v6 I've used in IMatch 2023. My older API keys work with v6 and v7.

Which means that users who have recently created a new HERE API key have to wait (and upgrade   ) for IMatch 2025.

Thanks for @thrinn to help figure this out. His involvement in this thread doubled the human resources available

A problem just discovered is that the "new" API keys break the Map Panel for HERE. It no longer works.
There is not much info around, and the examples I've found don't work.
If this means that I also have to upgrade OpenLayers and rewrite tons of code to support HERE, I will just remove it.
HERE is used by a handful of people (telemetry) and this is just not worth it.

[mopperle]

HERE is used by a handful of people (telemetry) and this is just not worth it.

I agree. HEREs main purpose is to provide car manufacturers with a database for their car navigation systems. Their userbase are mainly professionals (logistics, fleet routing, asset tracking etc.). And thats why they have an API at all.
It is not comparable with Google maps, Bing maps or Apple charts.

[Jingo]

HERE is used by a handful of people (telemetry) and this is just not worth it.

I agree. HEREs main purpose is to provide car manufacturers with a database for their car navigation systems. Their userbase are mainly professionals (logistics, fleet routing, asset tracking etc.). And thats why they have an API at all.
It is not comparable with Google maps, Bing maps or Apple charts.

Sorry I'm late to the thread here... 

I've found HERE's reverse Geocoding addresses provided more results than Google so that is why I wrote my GeoLocator app many years ago to provide the ability to use HERE. Over the years, the other services have also gotten very robust but I still use HERE some harder to pinpoint addresses. 

I also can no longer reverse geo using the new api key - too bad when sites modify their API so dramatically! Back to Google for now!

[Mario]

I also can no longer reverse geo using the new api key -

I have reverse-geoding migrated to the latest HERE v7 API, which works with  both old and "new" keys.
Same for the search function in the Map panel, which uses the same endpoints.

But the Map Panel itself, things looks different.
The documented way to use HERE maps with OpenLayers (which is the toolkit I use for everything except Google) fails now, and I could not find anything on the net or with the help of two coding AI's about how to make this compatible again.

I'm still researching.
With my new key, OpenLayers gets a "too many requests" on each endpoint fetching a map tile.
It works again with my old key.

Maybe the 1,000 requests per day for my new key are already used up and the old key has more generous free quota?
They say to get more free quota you must register a credit card. Maybe they are pushing towards that by reducing using a tiny quota for new keys.

I will try again with the new key tomorrow and see if I still get "too many requests". 

If that fails and I cannot find information to how to make this work (OpenLayers forum, HERE support (only available if you have provided a credit card) I will leave thins as is and document it.

Reverse geocoding works, find also works - with old and new keys.
Only HERE maps will not be available for users which get a new key.
I doubt there will be many, if at all, complaints. The number of HERE maps loaded by the map panel per months is < 1%.