Windows > JRiver Media Center 32 for Windows

NEW: Reverse GeoCoding

<< < (2/4) > >>

Yaobing:

--- Quote from: zybex on May 16, 2024, 03:15:39 am ---Yaobing, maybe it's worth it to cache the query results locally with a large expiry time, or a manual "clear cache" option? The coordinates for London tend to stay the same over time.

--- End quote ---

Good idea.


--- Quote ---Edit: Maybe it's already done, or is this only for the current batch?
7. Changed: During Reverse GeoCoding, if the GPS coordinates match (or are close enough) to an already processed image, we use the known data, instead of hitting the server again.

--- End quote ---
That is for the current batch.


--- Quote ---One other option is to allow the enter to add its own API key for the service. This would reduce congestion, and some users may want to get a paid key.

--- End quote ---

I have thought about it and will try that too.  Not sure if the server cares about that.  It is called "API KEY", not "User Key".

JimH:
Request here:  https://yabb.jriver.com/interact/index.php/board,13.0.html

Doof:
Any reason not to direct users to register for their own API key and have MC use their own instead of a shared key? Even with the one second delay, you run the risk of hitting their limit once this version gets out into the hands of more users. Additionally, it would give users the flexibility of being able to pay for a higher tier key and geocode a higher volume of photos if they need to.

Yaobing:

--- Quote from: Doof on May 18, 2024, 12:36:15 am ---Any reason not to direct users to register for their own API key and have MC use their own instead of a shared key? Even with the one second delay, you run the risk of hitting their limit once this version gets out into the hands of more users. Additionally, it would give users the flexibility of being able to pay for a higher tier key and geocode a higher volume of photos if they need to.

--- End quote ---

There is no reason, other than not knowing how the server intends this key to be used.  I am implementing it for the next build.

darichman:
Excellent. Thanks so much for incorporating this Yaobing & team :)

I prepared four files and did some testing
1. Has Coordinates, Has Place Tags already
2. Has Coordinates, No Place Tags
3. No coordinates, Has Place Data
4. No coordinates, No Place Data

Currently MC can help me address 1 & 2.

Where existing data is in the Place fields, MC will update/over-write existing entries (as expected)
Overall seems to work very well with a few test files (have not tried in bulk noting the API issues!)
I have not seen any errors, just a few quirks and incosistency with how granular the location data is in Geocode

Agree some fields end up empty. I tagged some from a recent farmstay not far from a major city in Australia lat 153°7'0.27"E  long 27°57'9.93"S
  [Country] Australia
  [State] Queensland
  [City] empty
  [Sublocation] Boyland, Boyland Road

Sublocation: I am not sure how the API handles sublocation queries...
See above, has two entries. I'm guessing we are limited by how data is stored on the geocode site (preference above would be for 'Boyland' to be the City and 'Boyland Road' to be the sublocation.

For a file with lat 27°29'2.12"S & long 153°1'36.66"E
It gives me [Sublocation] South Brisbane,South Brisbane,Stanley Street,Queensland Children's Hospital
   Country = Australia, State = Queensland, City = Brisbane City as expected
All of the entries populated in Sublocation are correct, but it would generally be desired to have a single entry, or to comma delimit them (or even nest them if they are predictably hierarchical)?
I am not sure why  South Brisbane would be duplicated in the above example.
See 'Sublocation Tag.jpeg' attached
Another consequence of this is that there must be a character limit when Lightroom reads the IPTC location field (see truncated value in LR IPTC Fields.jpeg)
Otherwise all Country, State, City, Sublocation visible in LR IPTC as expected

Would you consider using \ as the delimited in [Places] such that it can be nested in views?

Some indicator that the query is occurring could be helpful eg in the status bar Eg 'updating location data file 1/4' etc

I agree with others that I would pay for a user API if this were available. Can sometimes have a thousand photos to tag at a time, not to mention a library of several hundred thousand I may be going back to ;) Don't want to stretch the friendship and get MC banned. And obviously would like longevity and reliability of the service.

Next feature will be 'Add coordinates from Map' to address scenarios 3 & 4 above :)

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version