Added addr:housename to index

[krahulreddy]

For issue #448:

1. Added housename mapping to mappings.json.
2. Modified writeName function to include housename in fNames.
3. Modified filterNames function to set names.get("housename") as default if names is not null and names.get("name") is null.

Reason for including point 3 above:
Current implementation: In filterNames function, if the names map is not null, then names.get("name") is set as the default name. This fails if the map does not contain the name key.

Examples:

Name: [{name:es=La Adelita}]
fNames: [{}]

Name: [{operator=Gasopas}]
fNames: [{}]

Name: [{addr:housename=Caradon}]
fNames: [{housename=Caradon}]

I noticed that many of the places with addr:housename do not have name key. There should either be a hierarchy to select the "default" or the point 3 above could be opted.

[lonvia]

Reason for including point 3 above:
Current implementation: In filterNames function, if the names map is not null, then names.get("name") is set as the default name. This fails if the map does not contain the name key.

This is intentional. filterNames is really only there for handling pure name tags. These are the only ones we want to handle for any of the address bits (city, country, state, street) of a place. The housename is only interesting for the name of the place itself. That's why we have the extra writeNames function there that handles a couple of special names.

[krahulreddy]

This is intentional. filterNames is really only there for handling pure name tags. These are the only ones we want to handle for any of the address bits (city, country, state, street) of a place.

If this is the case, I see only one other way of fixing this issue:

When a search is performed, convert() function in ConvertToJson is the one dropping the other names. The getLocalized() function currently returns Null if map != null but the map.get("default") does not exist.

I think we can add a condition to check if map.get("default") is null, then any of the other fields in the map can be returned.

The housename is only interesting for the name of the place itself. That's why we have the extra writeNames function there that handles a couple of special names.

Even though the housename is added in the writeNames, it never really appears in any of the results, since only default is considered.

Let me know if this is the correct approach, or if I am missing something with regard to this.

[lonvia]

We really should define an order here. Right now you might get a random localized name, if I understand the code right. I suggest: housename, int, loc, reg, alt, old

Also, note that again only NAME has other names than the default and localised ones. So a special handling of the name would be a good idea.

[krahulreddy]

The latest commit handles the precedence order you suggested. This handling is only for the name field but in the same getLocalised() function. (If a separate function is used, most of the code will be repeated, so I did not go for it)

[lonvia]

But now 'default' is the falllback, while it was the first choice before.

[krahulreddy]

If default needs to be the first preference, I see two ways of doing it:

1. Add default as the first entry in the NAME_PRECEDENCE array.
2. Change the if condition from (fieldName.equals("name")) to (map.get("default") == null && fieldName.equals("name")).

Which option should I go for?

[krahulreddy]

If default needs to be the first preference, I see two ways of doing it:

1. Add default as the first entry in the NAME_PRECEDENCE array.
2. Change the if condition from (fieldName.equals("name")) to (map.get("default") == null && fieldName.equals("name")).

Which option should I go for?

Implemented option 1 in the latest commit as you suggested @lonvia.