How to organize IMatch to allow "Named Destinations" and Geolocation data

Started by lnh, August 02, 2014, 10:33:42 PM

Previous topic - Next topic

lnh

Some photos are taken at a known, named destination such as "Disneyland-Paris" or for this example, the "Empire State Plaza" in Albany NY USA.

I can geocode-reverse geocode as such:

GPS Lat: 42.650339
GPS Lon: -73.759369
GPS Alt: 42 m

Location Metadata:
City: Albany
Location: State Street 158
ISO CC: USA
Country: United States
State/Province: New York

That is great, but I'd also like to somewhere code this as a picture taken at: "Empire State Plaza."

So far, I've just made a @keywords category called "NAMED DESTINATIONS" and it becomes a regular hierarchical keyword. I suppose you could also just not use the street address (State Street 158 in this case) and just put "Empire State Plaza" instead, but ideally both pieces of information would be nice to maintain.

Where I'm going is I'd like a data driven category which is similar to the default "Location" category which will fill in a hierarchy like:

Country
- State/Province
   - NAMED DESTINATIONS

Photos which don't have any "NAMED DESTINATIONS" associated with them would not be shown in the hierarchy.

Of course I could just create an explicit location hierarchy when creating the original category such as NAMED DESTINATIONS|country|state|name, but it would be nice to let IMatch do the work so as not to double encode the same data.

The other thing I've tried is to mimic the "location" setup except use an alternate field like "XMP::dc\description\Description\0" to hold the named destinations.

Country
- State/Province
   - XMP::dc\description\Description\0

This approach comes close, but the hierarchy still displays country and state entries even if there are no values in the XMP::dc\description\Description\0 field. Also, it seems odd subverting a standard field for not it's intended use. Also, after reading the help, I still couldn't figure out how to make use of the @keywords|NAMED DESTINATIONS as part of a data driven category.

Any suggestions?

jch2103

Empire State Plaza is just a few miles away from where I currently am...!

Personally, I'd just use 'Location' = Empire State Plaza instead of the street address you get with a reverse look-up, as I don't find the street address all that helpful.

However, you could combine your idea of named destinations with a data-driven hierarchy of country/state/city as a 4th level in that hierarchy. Only those named hierarchies within, say, Albany would be listed under Albany. Disneyland-Paris would presumably be listed under '77777 Marne-la-Vallée'.

Lots of options!


Edit: Be sure to use 'Other' in each level of these data-driven categories, to account for missing information at different levels. That will also help you find incomplete location hierarchy information.

John

lnh

Quote from: jch2103 on August 02, 2014, 11:08:40 PM
Empire State Plaza is just a few miles away from where I currently am...!

Personally, I'd just use 'Location' = Empire State Plaza instead of the street address you get with a reverse look-up, as I don't find the street address all that helpful.

However, you could combine your idea of named destinations with a data-driven hierarchy of country/state/city as a 4th level in that hierarchy. Only those named hierarchies within, say, Albany would be listed under Albany. Disneyland-Paris would presumably be listed under '77777 Marne-la-Vallée'.

Lots of options!


Edit: Be sure to use 'Other' in each level of these data-driven categories, to account for missing information at different levels. That will also help you find incomplete location hierarchy information.

After playing around I think I found an OK solution.
I've defined a data driven category called Named Destinations with the simple structure of:

Country
- State/Province
   - Location

The trick is that in the geocode location field I place two values when I want to create a named location. The named location comes first and follows this format from the example previously given:

/*Empire State Plaza*/;State Street 158

Then in the definition of the 3rd level (location) I set a filter pattern regular expression "\*/{1}$" (without the quotes).

The result is that only /*empire state plaza*/ shows in the list (for some reason the capitalization disappears). Would there be a way to use regular expressions to do this but also strip off the /*   */ delimiters?

Any critiques or suggestions to refine this or another approach?

jch2103 - I grew up in the capital district and was recently back visiting family, so ended up taking some photos around the plaza.