Localization of `addr:` editor is needed for better usability on Brazil (pt-BR)

[jgpacker]

For reference, this is the current addr: editor:

For a brazilian's eyes, this is a confusing order and size of fields(and probably for other countries). I have seen a considerable number of new mappers get it wrong and put or repeat name or addr:street on the addr:housename field.

The reason for that is because addr:housename is not used in Brazil, and that addr:street is always supposed to be the first (and one of the largest) fields when filling forms. I have talked with some experienced mappers of other areas about this, and they echoed my feeling about how this is misleading(for a brazilian) and how it is a common mistake by new mappers.

According to the way addresses are written in Brazil, the form's fields and order should be like the image below:

where addr:door is "Complemento" (not so commonly used, but almost always present in forms), and addr:suburb is "Bairro" (it refers to a urban limit with admin_level=10 that is present in most cities of Brazil).

I will invite other brazilians to post their comments and any review of my suggestion if necessary.

[nighto]

+1! addr:housename is having the same value as name in, idk, 90% of the changesets with addressed-points that I review here in Rio de Janeiro area.

It'd be very interesting to have settings like these like locale. A typical address here looks like this:

Avenida Atlântica, 123 - loja A - Copacabana
Rio de Janeiro/RJ
12345-678

These would translate to:

addr:street, addr:housenumber - addr:door - addr:suburb
addr:city/addr:state
addr:postcode

The addr:door could have another tag. This happens when a building has subdivisions with different stores. Also happens when there are some groups of houses that belong to the same terrain (like a very small condo, tipically with less then 10 houses), so that the house address is Rua Street_name, 123 - House 1.

[PauloCarvalhoRJ]

+1

[vgeorge]

+1

[nighto]

Discussing on the list (talk-br), I now understand that it'd be better to use addr:housename instead of addr:door, giving it's spread use and similar meaning.

[jgpacker]

To clarify, what is being discussed is that addr:door would not meet all cases of "Complemento", which roughly means "Additional Information", and might be addr:unit and addr:flats too. However there are some drawbacks to using addr:housename, mainly having a different meaning than in other countries, and not being a legitimate use.

We still have not reached a consensus yet.

[AndrewHain]

Looking at Taginfo there are a lot of numbers and descriptive words in various languages showing up, so this problem isn’t confined to Brazil. Is the key simply too prominent and should it be confined to the full list of tags, at least if not already in use?

[jgpacker]

We still have not reached a consensus in the brazilian mailing list, but I will say my opinion on the matter(and from a brazilian perspective):

1. The tag addr:housename is too rarely used to have such a perceived importance in the form. It is the largest and the first field.
2. Also, in some cases, the user will be trying to input information that belongs to fields like addr:door, addr:unit and addr:floor, and since he doesn't find it, he might put it where he feels it belongs to.

I believe localizing this form would be the best solution, however solving these two issues would help a lot, and we could wait some time to see the results.

And yes, there are other countries with a different order of fields(mainly having addr:housenumber after addr:street); I confirmed it is the case in most countries of South America. I believe addr:housename is also rarely used (correctly) in those countries.

[jfirebaugh]

See #1427 for the general request for localizable address fields.

[jgpacker]

Is there any plan on how to address this? I would be happy to send a pull request for the brazilian preset.

Fortunately it would be easier to localize for Brazil, since it's locale is unique to the country: pt_BR.

[jfirebaugh]

To address this, we would need:

• A way to describe address formats -- i.e. which fields to include and how to arrange them.
• A web service that iD can query to lookup an address format (or a key which could be mapped to one) based on the location being edited. This is not likely to be something that can be built in to iD itself, as any data source that could potentially suffice (e.g. national borders) and provide sufficient resolution would be too large to include. It's possible that a geocoder like Nominatim would work, but this would require investigation, and we would have to be careful not to overload it with many queries.
• Rework of the UI code for the address preset to support custom field inclusion and arrangement.
• Local knowledge to fill in the address format database.

[hlaw]

I think the solution above (especially for determining the location) would not only be useful to the format of the addr fields, but also to address a number of issues on localisation of iD to different geographical regions.

e.g. in my region (Hong Kong), I would like to see the removal of (besides addr:housename and postcode) the access tag for horse (as it makes no sense here and only serves to prompt users to enter horses=no all over).

The lookup for name completion should also be localised too. There are lots of local chainstores other than McDonalds and Starbucks, but they would not be numerous enough globally to show up in the global name-suggestion-index.

The other day I also had an exchange with mappers in Taiwan over the translation of trunk / primary road etc into Chinese. Some would feel that it would be useful to new mappers in a region to incorporate the local tagging convention into the translation (e.g. analogous to translating it as "inter-state roads" instead of trunk, etc). This would however be misleading if local mappers use iD to map places elsewhere. A scheme to determine the location being edited and apply some specific adaptation to presets or translations would be very useful.

The above may perhaps be too far off, but they show some useful possibilities to be considered for any service / reworking considered above.

Back to your second point, perhaps Nominatim is an overkill. What is needed may be a server which could determine what country / region a specific point is in. And iD may built in a simplified / low resolution version of the national borders (UTFgrid?) and consult the server only in border line cases.

[jfirebaugh]

Rolling this into #1427; will cross reference the discussion here.

[jfirebaugh]

This is now possible, and I've added a format for Brazil based on the discussion here in f2a9154bf27f25e1b88cd4fd884dcb4fe00ae8d8. It wasn't clear what the consensus was about addr:door/addr:housename so I left it out. Feel free to send a PR if you want to adjust the format.

[nighto]

Thanks @jfirebaugh! =)