Change address preset in France

[letypequividelespoubelles]

This issue is double :

• in France, all administratives boundaries (between cities, departement, region, etc) are already mapped. So it is not needed (and even unwanted) to have city (and postal code) for every OSM element. So as iD is (I think) one of the most used osm editor, especially for beginners, it should not encourage to add those unwanted tags. It is really unwanted and not just useless because a few cities merge every year. The french community change the boundary of the merged cities every time it is needed, but won't check city name / postcode of every element. So it will lead to a deterioration of the data quality. Plus, having information in double could lead to poor data quality, just because of mistake /mispelling.

• it is not wanted to have street and address number for POI in France (see discussion on same subject on the StreetComplete git here). So, is it possible to have contact:housenumber=* and contact:street=* as a preset for POI instead of what's now ?
  Thanks

[1ec5]

Out of curiosity, are addr:housenumber nodes in France kept separate from amenity=letter_box nodes and the post:housenumber tagging scheme?

[gileri]

Out of curiosity, are addr:housenumber nodes in France kept separate from amenity=letter_box nodes and the post:housenumber tagging scheme?

Of the 579 amenity=letter_box in France, only 2 have an addr:housenumber tag. But 364 have post:housenumber.

[quincylvania]

@letypequividelespoubelles Could you link to documentation showing the French standards for address mapping? We want to support local mapping patterns when appropriate, but these seem rather nonstandard for OSM. Addresses are useful even when admin boundaries are mapped since:

• The address's city may not always line up with the location's city
• It's much easier for data consumers to display addresses based on tags instead of querying boundaries

The linked StreetComplete issue seems more about buildings vs. POI addresses and I don't think has clear consensus.

[pyrog]

@1ec5 amenity=letter_box are used when letter boxes are grouped nodes. We use post:housenumber in this case.

@quincylvania

It's much easier for data consumers to display addresses based on tags instead of querying boundaries

Yes, but this is not the usage in France. We have an official national address database and we don't want to duplicate any addresses.

It is painful for the french communities to remove addr: tags on each POIs added by beginners.

The linked StreetComplete issue seems more about buildings vs. POI addresses

This issue is about addresses (on buildings).
We prefer adresses on nodes, but SC "forced" contributors to add it on polygons for buildings.

I don't think has clear consensus.

It's a big challenge to clean the wiki, especially for addresses. That's why the french wiki is not yet clear.

[cquest]

For the first part of the issue, I don't think it is a matter of french standards, but a more global unwanted data redundancy problem in the database.

Remember the is_in=* tag ? This is/was useful when the municipality boundaries are/were largely missing. When they are present, they do not add any information and become useless so we removed them years ago in large part.

An address (or POI) consumer that is not currently using the boundary relation is in serious troubles if they use OSM data directly. Pushing this logic to some extreme (to test it) would mean we have to add addr:country on each address to be sure some (lazy) data consumer are ok ?

A few exceptions may exist, where the cityname or postal code of the postal address does not match the one you can get solely from the boundaries, but should exceptions become the tagging rule ? I don't think so.

For the second part of the issue, offering to enter address details on a lot of objects generates a lot of duplicates in the database.
When an existing addr:* node exists, used to define the address location, a nearby POI node with the same tag creates confusion. Which one is defining the address location ? When we recreate addresses databases from OSM data (like our BANO, open national address database), we try to deal with that by looking at the node with the smallest number of tags, but this is really a hack.

In an ideal editor, when a nearby addr:* tag already exists, it could be proposed to add on POIs the corresponding contact:* to create a link (avoiding a complex relation based solution), without creating duplicated confusing data.

Here also, it is not a french thing but more global data redundancy (thus quality) issue ;)

[1ec5]

A few exceptions may exist, where the cityname or postal code of the postal address does not match the one you can get solely from the boundaries, but should exceptions become the tagging rule ? I don't think so.

Without commenting on the situation in France, I don’t think it’s prudent to generalize that situation to the whole world in all its diversity of addressing schemes. The exception you’re describing is exceedingly common in some countries, so it would be more productive to determine whether we need an exception for France or more flexibility from country to country than to aim for global database consistency.

United States as a counterexample

In the United States, the city part of the address is derived from the local post office’s name(s) rather than a strict boundary test. addr:city may reflect a home or business owner’s preference for a vanity city over the postal service’s preferred city. (Most suburbs’ names are only vanity cities.) To be sure, mappers do sometimes omit the city and state from these addresses, and some imports have had to omit this information due to inadequate sources. This forces geocoders to consider boundaries as a fallback mechanism, but it isn’t the norm for manually entered addresses.

The United States has 160 million distinct addresses, presumably more than France.

Vietnam as a counterexample

In Vietnam, addr:city is only used inside of cities. Elsewhere, addr:district and addr:province are tagged instead. Before #2252 added the full complement of address fields for addr:subdistrict, addr:district, addr:city, and addr:province, mappers were constantly stuffing the full address into addr:street.

I don’t know how many addresses there are in Vietnam, but I’ve included this counterexample to show that iD’s behavior isn’t americentric by any means.

[1ec5]

By the way, another consideration is user behavior: many users are in the habit of entering a full address, just like when sending a letter or ordering something from an online retailer. If iD presents only the house number and street fields, I think we can expect more cases where an inexperienced mapper stuffs the full address in addr:street, no matter how that field is labeled or what options appear in the dropdown. At least that was what motivated me to add the U.S. addr:state field in #2402 and the various Vietnamese place name fields in #2252.

[pyrog]

I don’t think it’s prudent to generalize that situation to the whole world in all its diversity of addressing schemes

French contributors don't want to generalise this scheme 😃
Probably other countries use it ?(especially in Europe).

so it would be more productive to determine whether we need an exception for France or more flexibility from country to country

👍

[Bibi56]

A few exceptions may exist, where the cityname or postal code of the postal address does not match the one you can get solely from the boundaries, but should exceptions become the tagging rule ? I don't think so.

More over, like for the name* we get from Wikipedia, iD could present the postal code and commune as read only but editable when using the "low level" editor part (the raw attribute/value table).

@1ec5 did you miss "in France" in the title?

[1ec5]

@1ec5 did you miss "in France" in the title?

No, I was specifically responding to #8332 (comment), which spoke of a “more global unwanted data redundancy problem in the database”. Apologies if I read too much into that comment.

More over, like for the name* we get from Wikipedia, iD could present the postal code and commune as read only but editable when using the "low level" editor part (the raw attribute/value table).

Presenting prefilled but disabled fields would mitigate the UX concern I had in #8332 (comment). But I think it would require iD to perform a Nominatim query much more frequently than it does now. If I’m not mistaken, the dropdown’s suggested values are only based on addr:city and addr:postcode values in already downloaded OSM data.