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%.

[Mario]

Just tried today again. Unfortunately, every tile request using the newly created API key results in a HTTP error 429 - too many requests. Even the first one!

HERE provided only support for accounts with a paid support plan. Which I neither have nor need.
I've tried my luck on Stack Overflow today, maybe somebody has a tip.

If this does not work, ...

[thrinn]

I tried the HERE Map Image API with an example call from their Migration Guide. I don't know which endpoint oder API the Map Panel (or the OpenLayers library) use, but here are my results.

First test: V1 API call:

Code Select Expand

https://image.maps.ls.hereapi.com/mia/1.6/mapview
?apiKey=###MyAPIKey###
&lat=52.53086
&lon=13.38662
&z=12
&w=256
&h=256
A call with my old API key works.
A call with a new API key fails with "Too many Requests).

Now, a test with a call to the V3 API.

Code Select Expand

https://image.maps.hereapi.com/mia/v3/base/mc/center:52.53086,13.38662;zoom=12/256x256/png
?apiKey=###MyAPIKey###A call with my old API key works and retrieves a tile.
A call with my new API key works and retrieves a tile.

Conclusion: Old API keys work with V1 and V3 of the API. New API keys only work with V3 of the API.
Strangely enough, this is not what they say on their web site:

Previously used HERE developer accounts don't work for the HERE Map Image API v3.

[Mario]

IMatch does not directly interface with HERE, it uses the OpenLayers library (same for Bing, OpenStreetMap, CyclOSM). I don't have the mental or personell capacity to implement each custom JavaScript library / REST interface for the Map Panel in IMatch.

This means HERE must work with OpenLayers, and whatever code they use to fetch map tiles at specific zoom levels on-demand in their code. For many years, this endpoint worked:

https://{1-4}.${ld.base}.maps.api.here.com/${ld.type}/2.1/maptile/newest/

(ld.base and ld.type) are just controlling the type of map the user has configured. This works with the old keys, but produces "too many requests" errors with my new API key. All official OpenLayer examples use this endpoint, so I have no idea what to change to make HERE work again.

The general idea of using versioned endpoints (like the 2.1 in this case), is to keep things working, even if newer API's introduce breaking changes. Not working in this case, unfortunately.

[Jingo]

I just verified my Reverse Geocoding app (which was created to add the option for HERE) is also not working... and that is too calls the IMatch function to do the coding. I am modifying this now to directly call the API so at least it is an easy way to get HERE reverse geocoding to function... though sounds like OL needs to resolve their endpoint issue.

[Mario]

With the help of an awesome person on Stack Overflow I've found out what the reasons are.

1. Enforced switch to new endpoint versions for new keys.

2. Draconian limitation of the number of requests you can make per day if you don't add a credit card to your account and switch to a billed plan

3. All map styles names have changed, too.

Action plan would be:

a) Add a credit card. The daily limit for new keys is so low that zooming in and out a map immediately causes the "too many requests" - which is bad for testing

b) Find a way to figure out of a user has an old or new key

c) Duplicate all HERE-specific settings for old and new, using the new styles instead of the old scheme for users which have a new key.

Or, more likely, breaking compatibility with the old API for HERE users and ask them to get a new key which works with the new APIs. And add a credit card to get a "usable " daily free limit. Unless the old keys remain working?

Not sure if this is worth it?

[jch2103]

Credit card was the missing piece. When HERE maps didn't work (black, blank map), I created a new API key, which didn't work either. After seeing Mario's most recent post above, I went back to my HERE account and added a credit card. Now all the HERE map variations work properly. My only remaining issue is that HERE reverse lookup isn't working, but I may not have enabled it; will follow up once I've checked that. Here are details of pricing: https://www.here.com/get-started/pricing These are generous enough that I shouldn't be charged for my level of use.

Bottom line: Existing help for setting up HERE mapping should work, except needs to be amended to include the need for setting up a credit card in the HERE account. (Caveat: User may need to set up a new API key also.)

[Jingo]

Not sure if this is worth it?

I would say it is probably not worth it... with 2 other reverse geosetting options already available that do a nice job - and a small percentage of HERE users anyway.  

[Jingo]

just an fyi: I just updated my Super Geolocator app to now work correctly with the free level of HERE's API for reverse geocoding (using the new apikey). 

Once I add some additional fields that I can now leverage from the API, I will update the APP post in case any wishes to use it again.  

Enjoy!

[Mario]

I have now migrated all HERE-related features (Map Panel, Find in the Map Panel, Reverse Geocoding) to use the new HERE endpoints and responses.

The new implementation is compatible with old and new keys, no changes needed by the user!