This task is based on the following information received via IRC:
<chriadam> pa: someone mentioned that the old ovi.com and nokia.com API urls aren't going to be supported by HERE for much longer
<chriadam> pa: e.g. https://code.qt.io/cgit/qt/qtlocation.git/tree/src/plugins/geoservices/nokia/uri_constants.cpp?h=dev#n41
<chriadam> are there any plans to rewrite that plugin against the latest HERE APIs?
<chriadam> cc amccarthy ablasche kenz ^
<amccarthy> chriadam: I believe there was a jira long ago about switching to the here.com urls.
<amccarthy> You could look into whether the same API is available from the here.com domain. If not some porting effort would be required.
<amccarthy> You can also probably drop the CN urls. As far as I am aware HERE doesn't have CN end points. At least I don't remember seeing any in any of the documentation I had.
<chriadam> https://developer.here.com/rest-apis/documentation/geocoder/topics/key-concepts-schema-evolution.html says:
<chriadam> "Major updates that significantly change the API behavior are released on a different URL."
<chriadam> and... well... they're switching URLs
<amccarthy> For the geocoder and reverse geocoder you're jumping from version 2.0 on the nokia/ovi urls to version 6.2 on the here url.
<chriadam> right, but I suspect that since it's a new url, no backwards compatibility will be offered (via the gen thing)
<chriadam> so it will require at least rewriting the geocoding part. I suspect also the map tiles one, but didn't look into that one
<amccarthy> I think the gen thing is on top of the url changes which happen when there is a significant schema change
<chriadam> my understanding is that minor changes could be made to the API, and the client can tell the server which behaviour they want (for those minor changes) via the gen parameter
<chriadam> but yeah, the url change requires client rewrite / porting effort
<chriadam> I may be wrong