APP: Super GeoLocator

[Jingo]

Hi All - as part of some research I was doing for some client work, I ran across an alternative Map API (HERE API - https://developer.here.com) with a very reasonable free transaction package and figured it might be a good alternative to Google and OpenStreets.  As a proof of concept before approaching Mario with the thought, I figured I would spend a few hours to see what can be done between IM and the API to gather geo data.  So, I created an app with the work in progress title: Super GeoLocator!  Although not fully ready for sharing quite yet, the app is working quite well and hopefully the functionality with either be useful as an APP or Mario might be able to include the API in the actual MAP panel as another option...

Here are some screenshots of what it currently looks like (subject to change as I continue to play):

You can see the App Icon on the bottom row:



This is the Main App:


As you can see, the Main App will let you select an image (eventually multiple selected items) that has GPS Lat/Long data and perform a reverse Geolocate from the HERE API service (free API/APP keys are needed).  Once the data is pulled back from the API (I am currently pulling 3 results per image), the data is displayed in a button array.  If you click one of the result buttons, the data is displayed in the text boxes and the file is updated with City, State, Country and Location (currently the full address).

I have lots of thoughts on where I could take this... such as:
 

• using the data from the focused image to paste into a group of selected images (in the same location)
• Displaying a map panel within the app to show the location of the image and allow you further refine the location
• Allowing you to grab GPS info from a location search and then reverse geo all in one shot

There is lots of data available through the numerous API and functions... this debug session from the browser shows some of that data which I am using to file into the database:



Skies the Limit!!!  Although I did this just for fun today - I hope this is useful... thoughts and critique always welcome! - Andy.

[Mario]

Thank you for sharing! Very good.

I'm aware of HERE, but so far i did not see reason to implement a 3rd layer for reverse geo-coding or mapping.
Adding another provider would not be too hard, just a couple of changes in the UI for the new company and keys, updates to the classes IMatch uses to do reverse geo-coding, documentation updates etc.
What would be the advantage of using Noka/NAVTEQ data (HERE) in addition to GeoNames.org and Google?

(As a side note: when I tried to look at the HERE web site, it triggered all UBlock Origin Anti-Tracking measures big time (Malvertising filter list). Seems that HERE has some reputation of tracking...

I think (not sure) that OpenLayers (the 3rd party library I use for interfacing with OpenStreetMap, Bing Maps and Stamen) has at least minimal support for HERE maps...
I don't know if I just can add HERE as another map provider or if there are functional limitations compared to OSM or Bing.
I'm not in the details of OpenLayers anymore at this time, but I suggest you make a feature request for supporting HERE as another map provider for the Map Panel.

If we're lucky, OpenLayers handles all the details and I only need to add some new code for selecting HERE in addition to Google, Bing, OSM and Stamen.
If this would require some substantial changes in the Map Panel code, I would need good reasons for supporting it. I already, and regretfully, have to deal with two separate implementations (Google and OpenLayers) and adding a 3rd level of code would cause additional maintenance workload.

[Jingo]

Hi Mario - to be honest - I'm not sure there really IS a good reason to support it but I ran across the implementation and figured let's see what I can do!  One good thing at least, their website is VERY easy to navigate and figure out (unlike GOOGLE) - getting the API key was as straightforward as it can be.... trying to do the same at Google is a frustrating endeavor with oodles of choices that make things much more complicated than necessary.

The data retrieval and map display are very fast as well with lots of options for place, landmark and other API calls... geofencing and even location area calculations are possible.... I can see many uses for the API built into IMatch - but I can also implement many of these features as an App as well...

I'll put in the feature request and we'll see what others think... certainly if it is more work than initially thought - it may not be worth the effort.

I'll continue to play with the app and then share it with others anyway... glad you like it and once again - just shows the power of IM! - Andy.

[lbo]

"Here" has an eventful history and today probably a different business model than Google and Microsoft (look at the owners), so it seems to be very interesting.

[Jingo]

Yes - what impressed me the most was their clear and easy to follow sign-up process, clear inclusion plans and fully documented and easy to follow API's.  Not much more one can ask for as a software developer.  Google on the other hand buries all this... I tried to find my Map API key when I rebuilt my computer and it took me forever to locate.... hidden on some "developer page" and very non-user friendly.

Things are looking good with the app and I should be able to release a version for play by tomorrow...!

[Jingo]

Ok.. so, I have completed work on the initial implementation of the App and believe it is ready for release into the wild.  As with all apps, please be careful using with your database/images until you know what the app does and ensured it is working properly.  My limited testing seems to show all is well.... but - use at your own risk!  To install, just unzip the attached file into your C:\ProgramData\photools.com\imatch6\webroot\user folder... it will appear automatically in the app manager.  The app works equally well inside IM as it does in the browser.

As noted above, the app uses the HERE API to take the lat/lon coordinates of the focused file, retrieve and present 3 reverse geolocations from the API and allow you to write this data back to all selected images.  The data will currently write to the city, state, country and location fields.

So, the first step is getting an API key from HERE (https://developer.here.com/develop/rest-apis).  Once you have both keys, you can add them to the app and click the File API button to save the data to the database.  If you have already added the info to the database, then you must click the Retrieve API button to set the proper variables up (Clunky - I know... I'll fix down the road).

Once the keys are setup and loaded, clicking the Retrieve Data button will look for the GPS lon/lat on the focused file (results[0]) and, if found, perform the lookup to generate the result buttons.

The buttons will display and clicking one of them will file the data to all selected files in the database (as well as update the fields in the app).

Please let me know if you  have any questions, suggestions or thoughts.... even if you don't use the app, but are interested in writing your own, hopefully the code will help you learn how to interact with JQuery, Javascript, API's and IM's database via the IMWS functions.   NOTE: this is not the best javascript code or written app for IM... but I did write it in a few hours :-)   I should clean things up down the road when I have time just to ensure I'm putting out the best product I can. 



Enjoy! - Andy.

[Mario]

Great. Thanks for sharing!

[Jingo]

Great. Thanks for sharing!

Sure... it was lots of fun!!  I also learned a few new things in the process (like I always do when working on IM apps) such as how to use the IMWS.dataGet/dataSet function (Nifty!) and dynamic jquery element creation (the result buttons).  Super Fun for a geek programmer like me!

[Mario]

Excellent.

I write all new IMatch apps using Vue.js
Takes a lot less effort than working with jQuery alone. And is not nearly as bloated or complex as Angular or React.

Tip: Vue.js is already shipped as part of iMatch, you can directly include. Usage examples are the Tag Info app and the MD Analyst app.

[Jingo]

Excellent.

I write all new IMatch apps using Vue.js
Takes a lot less effort than working with jQuery alone. And is not nearly as bloated or complex as Angular or React.

Tip: Vue.js is already shipped as part of iMatch, you can directly include. Usage examples are the Tag Info app and the MD Analyst app.

Thx Mario - i will check out those apps to see what Vue can do!  :-)

[Mario]

https://vuejs.org/v2/guide/index.html

[jch2103]

Thank you for developing this!

I had a HERE api but never used it. When I tied using the Super GeoLocator app, it didn't work at first. Turns out that my year-old api keys no longer worked; I had to sign up for a new Freemium project. Now it functions properly.

Some picky questions:
- Is it possible to obtain the full State name (e.g., Arizona instead of AZ, or Colorado instead of CO)?
- The app returns three sets of location data, all apparently identical. When I select another image and retrieve HERE data, I get another set of three location returns, but only the last set actually returns data (see screenshot).

It's neat to have options like this available. Thank you Jingo and of course Mario for enabling development of apps like this.

[Jingo]

Hi John - my pleasure... was fun to develop!

The 3 results from the API can be the same if that is the results they have on file.  I'll add some checking to the results file so if they are indeed identical, then the additional buttons will not get selected.  I also did forget to clear the data from the last result when a new file is selected so I will work on that as well. 

For the state name - yes.. that data is available and I have made that change... stay tuned for an updated version! 

[jch2103]

Very good. Thanks!

[Mario]

I've made a quick test for the Map Panel, testing if OpenLayers can use HERE tile maps. And it can:



I now need to read all the HERE legalese, limits and restrictions or maybe ask them if using via OL is legal (there are some paragraphs in their terms and conditions which indicate otherwise).
If this is legal, I could probably integrate also the Reverse Geo-coding of HERE, as an alternative to GeiNames.org and Google.
Not sure if users really wait for this... 

[Mario]

I have added support for 8 HERE map types to the next release of IMatch.

See https://www.photools.com/release-notes/ for more information.

[Jingo]

I have added support for 8 HERE map types to the next release of IMatch.

See https://www.photools.com/release-notes/ for more information.

Thanks Mario!  Yes... I think this is another useful source of Map info... as mentioned, I find their clear setup and API quite refreshing after dealing with Google's complexity (I still have trouble locating my google map API info!)

If you can add in the reverse geo - that would be great as well... was just putting some add'l touches on my App but this is only an exercise for my own learning (and fun!).  Having it as part of the main functionality would be preferred!

[Mario]

Not sure about the reverse geo-coding using HERE yet. GeoNames.org is free and works reasonably well and fast.
Google is excellent and super-fast and free for use within normal limits.

refreshing after dealing with Google's complexity (

That's easy to understand.
Google offers hundreds of API's and services, HERE only one. With a few sub-services.

Once you have a Google account you can add new services with a few clicks.
All this is administrated  from their central dashboard:

https://console.developers.google.com/apis/dashboard

Right at the top are your projects (usually you have only one)  and when you click on "Credentials" in the bar on the left you see your API keys.


If you want to access the Maps API, AI services, your virtual servers or databases, it's all done via the single dashboard. This makes it naturally more complex.
Besides, this is all designed for corporate users and developers. Not individuals.
Usually a company would do all that and then make Google Maps available for free to their users.
Like Adobe does, but only in their subscription-based software and only as long as your subscription is active.

Since I don't have the money Adobe has, I cannot afford to pay for Google Maps for all IMatch users. Hence you need to get your own key from Google, Microsoft, GeoNames.org or, in the future, HERE.

[Jingo]

Not sure about the reverse geo-coding using HERE yet. GeoNames.org is free and works reasonably well and fast.
Google is excellent and super-fast and free for use within normal limits.

Well - then I'll keep my app around and try to finish up a few items that need some housekeeping  ... :-)  A fun project for me!!

[Mario]

I had also some fun today and integrated HERE also for reverse geocoding and geocoding (search in the Map Panel).
The HERE API is easy and the docs are good. So it was not too hard and I like to have an alternative to GeoNames (which is often slow and not that precise) and Google (privacy!).

For the reverse geocoding I've also used the AdditionalInfo array in the result, because it often has unabbreviated county names and can be used to fill an empty street name from the district info.

I'm still looking at how here handles language. They seem to need 3-letter codes for the map tiles, but (first tests!) seem to be happy to handle 2-letter codes for the geocoding and reverse geocoding...not sure yet, will look into this over the weekend.

[Jingo]

I had also some fun today and integrated HERE also for reverse geocoding and geocoding (search in the Map Panel).
The HERE API is easy and the docs are good. So it was not too hard and I like to have an alternative to GeoNames (which is often slow and not that precise) and Google (privacy!).

For the reverse geocoding I've also used the AdditionalInfo array in the result, because it often has unabbreviated county names and can be used to fill an empty street name from the district info.

I'm still looking at how here handles language. They seem to need 3-letter codes for the map tiles, but (first tests!) seem to be happy to handle 2-letter codes for the geocoding and reverse geocoding...not sure yet, will look into this over the weekend.

Thanks Mario... agree about the documentation... perfectly presented and easy to understand!  So, I'll retire my app at this point (though will keep it around for educational purposes).  Yes - I used the additionalInfo array as well to grab the unabbreviated State and Country names.  One thing I noticed about the HERE API was they don't have a very good "location" result (such as a sublocation) so I just used the full address in my results which isn't ideal.  Comparing google results to HERE results - I couldn't find a good item.  Curious how you handled this.....

[Mario]

Different services return different sets of data for the same point.
IMatch usually uses the street name determined by the internal classes for filling metadata 'sub-location'. The street name can be filled, depending on the service, from different things.
For HERE, IMatch uses the district if the street name is not delivered. This seems to produce good results for large places, areas without streets, plants etc.
I need to run all my GPS sample files through HERE to see how the results compare or how to improve them. This is always the time-consuming part when implementing things like this. Answering questions like "When no street name is delivered, what other information is available suitable to fill location?"

HERE is aimed at traffic and controlling and advertising. It's used basically by all major car vendors for in-car routing, for example-
I assume that their results for coordinates "in the wild" may be worse than Google's or GeoNames.org's.

Not sure without testing. I see it as an alternative service offering. Users decide in the end.
IMatch separates the search/geocoding and mapping services.
A user can use Google for searching, HERE maps and GeoNames.org for reverse geo-coding. Whatever works for her/him.
This is what I call the freedom of choice. I don't look you into one vendor (Although I could probably make some money that way...)

[lbo]

IMatch usually uses the street name determined by the internal classes for filling metadata 'sub-location'. The street name can be filled, depending on the service, from different things.
For HERE, IMatch uses the district if the street name is not delivered. This seems to produce good results for large places, areas without streets, plants etc.

agencies sometimes request the district name for sublocation, e.g. for aerial imaging where the image often covers many streets.

Oliver

[Mario]

Reverse geo-coding is based on individual GPS coordinates. Depending on the service used, different data may be returned.
For such specific use cases, the user should modify the returned data as needed manually.

[Jingo]

Reverse geo-coding is based on individual GPS coordinates. Depending on the service used, different data may be returned.
For such specific use cases, the user should modify the returned data as needed manually.

I suppose another app I could make would be to take the reverse geo from ALL 3 providers and let you choose which to apply to images for a specific case...

[Mario]

Reverse geo-coding is based on individual GPS coordinates. Depending on the service used, different data may be returned.
For such specific use cases, the user should modify the returned data as needed manually.

I suppose another app I could make would be to take the reverse geo from ALL 3 providers and let you choose which to apply to images for a specific case...

Sure. The user would need to open an account for each service, though.
From experience, there isn't that much of a difference for all normal city targets. Google is usually very good for off-road targets as well (I think this is not the domain for HERE).
GeoNames.org has sometimes better data for bikers or hikers (when provided by the users, similar to OSM).

In general: If you have a Google account, you don't need much else. Google spends a lot of money on their maps and related services and is usually right.

[lbo]

In general: If you have a Google account, you don't need much else. Google spends a lot of money on their maps and related services and is usually right.

Google is what I start with. If I'm not happy with the result, I try other services. I guess that's 20% of the images, but not only reverse geolocation but also to identify and describe the object.

[jch2103]

An FYI for anyone using the HERE APIs:

I had set up a HERE account last year, but never used it. When I saw that Jingo and Mario had made provisions in IMatch for using HERE data, I set up a new account (old one didn't work anymore). Having the HERE data available in IMatch is useful.

Interestingly, I got a phone call this morning from HERE Marketing, asking how I was using the API. I explained that I was using it through my DAM, IMatch, for my photos. The caller thanked me and asked me to let them know if I ever needed additional HERE capabilities in the API. It seems HERE is interested in expanding their footprint in the developer space.

[Jingo]

That's great... I've been quite impressed with HERE, their API and overall ease of use.  I've been using the HERE maps and Reverse Geo and really like it... though the maps are NOT as detailed as Google and the HERE "location" field is lacking quite a bit.  The MAP displays VERY fast on my machine whereas Openstreetmap is VERY slow... panning and moving often results in a blank app screen until it loads... I don't have that issue with HERE or Google.

I do hope HERE continues to develop their product and increase the map detail and reverse location info... if so, I will use them exclusively.

[Mario]

The MAP displays VERY fast on my machine whereas Openstreetmap is VERY slow... panning and moving often results in a blank app screen until it loads... I don't have that issue with HERE or Google.

That's to be expected. OpenStreetMap is an open source project, developed and maintained by volunteers and paid for by donations and sponsored by universities and hosting companies. They don't have the money Google or Nokia (HERE) have to pay for all the server power needed to achieve the same responsiveness. But OSM is free to use and often has better data for bikers and hikers. If you use OSM, donate a few dollars to support them and maybe update and enhance some of their maps if you're happen to be in the place.

Besides, BING Maps are also very good. And fast.

[jcldl]

Hello Mario it seems I have a problem. I installed "super Geolocator" and as you can see on the picture it works well . But when I tried using the map from "HERE" after having written in "preferences geocoding" the same codes, i have only a black screen as you can see. What is the problem, could you help me? Thanks

[Mario]

I'm not the author of this app. I don't endorse or support apps written by others.

Have you tried to close and re-open the map panel after entering your HERE credentials? Or just click into the Map Panel and press <F5> once. Or click on the Refresh button in the Map Panel toolbar.
This all does the same: It reloads the Map Panel app.
The Map Panel does not know that you have just entered new credentials without a reload.

[jcldl]

OK thank you it's working now. I just re-entered codes and re-opened map panel.

[Jingo]

I mentioned the Refresh issue after adding the API credentials in another thread and Mario added a note to the help that says a refresh to the MAP panel is needed for the API credentials to appear.  I personally think the MAP should auto-refresh to avoid this once new credentials are added to preferences. 

Since the HERE functionality is part of the standard product now, this APP really isn't needed any longer.... except for learning and perhaps a different interface to gather reverse geo.  Ideally, I would do away with the custom data set that stores the API info... Mario - is there an easy way to Read and Write to the IMatch Preferences?  I check the documentation but couldn't find anything....

Ideally, the app would check the IMatch Preferences and, if empty, show the current tags to allow the user to enter the details and file the API keys directly to the IM preferences.  The app would then check on restart if the preferences exist and if NOT empty - these fields would no longer show and the preferences read into the params.

[Mario]

I personally think the MAP should auto-refresh to avoid this once new credentials are added to preferences. 

Apps cannot (and should not, for security reasons) be able to monitor IMatch app preferences and user settings.

In the rare case a user really runs into this issue and does not read the help carefully and does not figure out the "Just restart IMatch" himself I just tell him/her to do so. Much faster than implementing anything specific. As an alternative I could force the user to restart IMatch after making a change to the HERE key (or any of the other keys). I did not consider this important enough.

Ideally, I would do away with the custom data set that stores the API info... Mario - is there an easy way to Read and Write to the IMatch Preferences?  I check the documentation but couldn't find anything....

If this is so important for your app, you can query the API keys in your app right before you fire the request.
See the Map Panel app how the keys are retrieved during program start.

[Jingo]

Well.. it seems HERE has upgraded their API's to use API Keys instead of the old App Code and ID - so, I have updated the software to work with the latest API.  If you have the old codes, you can continue to use the original version (1.0) for now and it will continue to work.  New Users: You will need to get an API code and use the NEW version attached here.

IMatch is also still coded to only use the old codes - so new users will not be able to use the HERE maps until this is adjusted in a future release

Enjoy!

[Mario]

IMatch 2020 supports both the old app:code and the new API keys with the new rest endpoints and domains.