Multiple Hot Code sets / files

[Jamie]

Greetings,

I have gotten hot codes to work for one field. I would like, however, to use multiple hot codes for separate fields: one for country, one for cities and one for sublocations. In the PM documentation, the serial number example shows "either {serial} or {fbas}" to retrieve the name of the photographer.  By contrast, I want to map {countrycode} to countries in the country field and simultaneously map {citytaken} to city in a different one.  In short, different variable sets for individual fields.

I have tried loading multiple files (via Edit->Settings->Code Replacements), but the hot code replacements only work for the first file in the list. I gather that a multi-pass system would work, but it is cumbersome to have to swap the cr-settings file along with the Metadata template.

Am I missing something?  Any way to get this to work?   

Cheers,
Jamie

P.S. Why do I want this?
I am reverse geocoding gps-data, which needs the following manipulations:
1. I retrieve country name via the country code variable, to handle my multilingual context. I want English names for countries, but German names for states/provinces, cities and sublocation. (I am an American living permanently in Germany.)
2. For city names, the reverse geocoding contains a lot of variance. For example, I live in Bonn, which has 20+ different "quarters", reflecting the historical merging of individual villages. Frequently, the geocoded data returns "Bonn", but the next street over might return "Muffendorf", a part of Bonn.  So, I want to use hot code replacements to normalize them.
3. On sublocations, there is a "bug" in the handling of street names (at least for Germany) that returns the street number rather than the street name. (This is a known issue: http://forums.camerabits.com/index.php?topic=13395.msg67020#msg67020). Some locations are given correctly. Thus, my goal is to use the correct locations by setting the default //## with the {sublocation} variable, but map numbers to "" (i.e. empty).

[Jamie]

Greetings,

I have found a multi-pass solution that relies on just one hot code replacement file (HCRF).  I built a HCRF by combining each of the required variables. The first column is thus a mix, but the further columns hold only one data type. In the HCRF, I leave the irrelevant columns blank.  This way I can pass the images through a set of different metadata templates, each of them using the same HCRF. That way, I don't have to change the CR-settings.

I structured the HCRF as depicted below.  I then have 3 metadata templates that I call in 3 successive passes:

•    one for the field "country" based on {countrycode},
•    one for "city" based on {citytaken}, allowing me to recode the Bonn quarters but let other cities pass through untouched, and
•    one for "sublocation" based on {locationtaken}, usually overriding the street numbers, but still allowing for sublocation information that is correct.

Conflicts between the country codes, city names and sublocations should remain rare. So, this should work. 

It's a bit kludgy, as it mixes the data in column one. But, it works on the images I have tested so far.  If there is a better way, I am all ears.

Here's the HCRF: ("…" means more of the same)
//==   {countrycode}
//==   {citytaken}
//==   {locationtaken}
//##   country   cityrepl   sublocrepl  // variables for country, city replace and sublocation replace.
//??   {countrycode}   {citytaken}   {locationtaken}
AUT   Austria    // The country section, leaving the columns cityrepl and sublocrepl blank
CHE   Switzerland
DEU   Germany
…
Bonn      Bonn            // Start of city section with two tabs between tokens
Mehlem      Bonn-Mehlem
Muffendorf      Bonn-Muffendorf
…
1            // Start of sublocation section with 3 tabs. There is no content, because I want to cancel out street numbers.
2            // Since {locationtaken} is the default, non-numbered sublocations get passed through.
3         
…

As most German street numbers remain below 100, the list needn't be long. I can manage other cases manually (or add to the list ad hoc).

Cheers,
Jamie

[dennis]

Jamie,

Das ist kompliziert.

Hot codes weren't designed to compensate for "inaccurate" reverse Geo results.  Because PM gets it's results from a user-contributed database there will obviously be discrepancies.  Usually the locals know what their location is called, but the database could have descriptions from tourists (or worse) added to the database.  Even neighbors can disagree.

If you can boil this down to a simple "bug" with how PM handles multiple code replacement files, then we can look into it without kompliziert.

--dennis

[Jamie]

Hi Dennis,

vielen Dank für Deine Antwort.  New translation for kludgy = kompliziert.  Agreed.

I'd say there are three issues.

1. the "bug" in the handling of street names and numbers.
2. mapping data
3. multiple Hot Codes replacement files

To 1:
The handling of German street names/numbers is buggy.  An address like Hauptstraße 25 returns "25" in the sublocation.  This is better documented in the other thread (see link, above).  As discussed in the other thread, the cause is unclear: Is PM interpreting the OSM data wrong? Or, is the OSM data model flawed?  Can it come from the fact that German street numbers follow the name?

To 2:
Yes, I get your point about locals disagreeing. Alas, if OSM gets it's data only from users, then only a "post-geocode" workaround will help.  After all, city boundaries are official designations, as is any official subsection (true for all countries, depending on their law). No Bonner would disagree with calling where I live Bonn, Bonn-Muffendorf or Muffendorf. All three are correct, even officially so.

Ideally, OSM would get such data from official sources, thus yielding consistent results. But, if they don't, there is no practical way (pre-geocoding) to align every location everywhere. A have another software tool for tracking my running data that also relies on OSM.  For a long time, it reported our lovely Kottenforst as part of Königswinter.  Check the map:  Kottenforst is west of the Rhine and part of Bonn.  Königswinter is east of the Rhine, and is its own city.  They eventually corrected it. 

Thus, IMHO, a user of PM who wants accuracy and consistency has to resort to post hoc corrections via something like Hot Codes.

To 3:
Quite apart from my needs, it would seem a worthwhile addition to PM to allow multiple Hot Code Replacement files for different variables.  Suppose I wanted to replace sublocations, but I also while using your serial number solution for the photographers and for, say, some others variable, i.e. multiple, unrelated replacements.  Unless, I am missing something, this doesn't seem possible.

I do hope that you'll look into 1 and 3.

Nevertheless, my case proves Hot Codes's usefulness and elegance. If I can build something as wild as this, and get good results, it speaks for the tool.

Cheers,
Jamie