Add addr:milestone support to Nominatim

[matheusgomesms]

I would like to propose support of addr:milestone from Nominatim: https://wiki.openstreetmap.org/wiki/Key:addr:milestone

It is a way to tag places that are usually in rural areas, by some highway, and have no official addr:housenumber, but use it as a proper address. It is usually stated in a sign/website (and even used by postal letters). Examples:

Highway A-1, km 12 (fictitious)
Rodovia BR-116, km 16.5 (a place that advertises in their website this address, and uses it for postal purposes).

The proposed tagging can be seen in the last OSM link, and Nominatim probably should handle it the same way as it does with addr:housenumber, but also appending 'km' before the addr:milestone value, if it is not in miles.

Rationale for this request: this happens in diverse parts of the world, but very likely people don't use it in OSM for many reasons (not officially approved, lack of support by search engines and apps etc), classic egg/chicken problem that happens in OSM all the time.

In Brazil, we are working towards a full national import of addresses, which contains millions of addresses, including several ones like this. So we are probably picking this tag to be used for those cases, and would like to see Nominatim supporting it.

Finally, we saw that there are at least 4500 cases, worldwide, that have 'km' (or similar) in addr:housenumber, and could benefit from this tagging.

addr:milestone in Taginfo: https://taginfo.openstreetmap.org/keys/addr:milestone#overview

[matheusgomesms]

PS: also probably related to #69

[lonvia]

The simple implementation would be to just interpret the value as an an alternative to addr:housenumber but that doesn't give you the optional unit. I've been looking through the existing usages and it would be good if you clarify the use of this tag before you start importing this tag in a larger number.

First of all there is the question of the unit. Many uses seem to have no unit at all but the wiki page does not define a default. Is it universal that the unit comes before the number? There are at least three objects where the unit is used as a suffix. And then, there are a lot of tags, which use Km. as unit. Does that mean that the expected format is different in other countries? From a data user point of view: must the unit always be there when searching for the address or is it frequently left out?

Then there are quite a few objects with have a addr:milestone and a addr:housenumber, e.g. https://www.openstreetmap.org/node/6817599738. How does that work?

It looks like we need understanding of fractional numbers here. The tagging of this also seems rather diverse. Some use a comma, might just be a tagging error. Some have additional zeros at the end. How do you search for that? Can it be interpreted as a string (meaning the zeros always have to be there) or must it be interpreted as a number (search may or may not have additional zeros).

There are also combinations of addr:place and addr:milestone, e.g. https://www.openstreetmap.org/node/11066782731 That looks suspect.

[GEOtemala]

The proposed addr:milestone=* tag should always substitute entirely the use of addr:housenumber=*.

The use of the prefix "Km." is something that is widely used in general, as this denotes the address is making reference to a milestone. It very common to refer in that form to an address which uses those markers as part of an actual address. This is mostly used as a reference only and does not necessarily read an exact distance (from a milestone) on any highway.

The use of addr:place in combination with addr:milestone has not been discussed before, but I agree on this needing to be further agreed upon in order to establish a common procedure on OSM. I have mixed feelings on that (addr:place) specific tag.

Some places around the world frequently use an additional meter reading to define a location more accurately, and is usually written as Km. 35 + 250 in those cases where the + 250 represent the location (approximately 250 meters after the actual Km. 35 milestone) - something that could be adopted for this proposal as well.

Another common variable (mentioned already above) is the use of a 'period' or a 'comma' to define the decimals & separating the thousands. The US, Australia & Great Britain (as well as many other countries) commonly use the 'period' as a decimal separator, while the EU and yet other countries around the globe use the comma. In order to follow a certain criteria, and since OSM is originally a British creation, I'd suggest using the 'period' as the decimal separator, while the 'comma' would be used to separate the thousands. This would also need to be included on the proposal to avoid even more confusion.

[santamariense]

The proposed addr:milestone=* tag should always substitute entirely the use of addr:housenumber=*.

I have a different point of view. In Brazil, it is not rare to find both values, as I commented here. So, they can coexist.

[matheusgomesms]

It seems @GEOtemala updated his proposal, so I think many points addressed by @lonvia are now fixed. Wrt the rest, let me say what I believe:

Then there are quite a few objects with have a addr:milestone and a addr:housenumber, e.g. https://www.openstreetmap.org/node/6817599738. How does that work?

In those cases (as @santamariense pointed out that it is not uncommon), I believe the implementation would be one followed by the other (in Uruguay, the mentioned case, I would say the full address would be "Ruta 6 Vieja, km 33 a 34, 2".

It looks like we need understanding of fractional numbers here. The tagging of this also seems rather diverse. Some use a comma, might just be a tagging error.

This looks like a possible tagging error, combined with the fact in Latin America (pointed case) comma is the separator, not a dot. It seems the updated proposal addresses that, which means the value should respect what is the norm in OSM.

Some have additional zeros at the end.

This also looks a mapping error. It seems it was imported, so probably these numbers were treated as strings.

There are also combinations of addr:place and addr:milestone, e.g. https://www.openstreetmap.org/node/11066782731 That looks suspect.

Finally, this case looks the mapper preferred to use addr:place instead of addr:street. But it can be clearly seen that there is a highway nearby, and the milestone there is referred to that highway.

---

Thank you for all the comments, Sarah! The new proposal seems to address your concerns, I believe, and it was important to receive all your points.

Do you have any recommendation, from Nominatim point of view, to even improve the proposal? https://community.openstreetmap.org/t/rfc-feature-proposal-addr-milestone/121295

[muralito]

In those cases (as @santamariense pointed out that it is not uncommon), I believe the implementation would be one followed by the other (in Uruguay, the mentioned case, I would say the full address would be "Ruta 6 Vieja, km 33 a 34, 2".

Be aware that this addr:milestone "Ruta 6 Vieja, km 33 a 34, 2" is caused by importing bad quality data. The value is ill formated. The addr:milestone value (at least in Uruguay is a distance, sometimes rounded to kilometer, sometimes to hundred meters.) This km 33 a 34,2 implies an indefinition of 1.2 km, not acceptable for an address.

Also, most of the time the addr:milestone data are not, and will not be in OSM database, but the info that is in OSM database are the highway=milestone nodes in the rural highways (mostly kilometer away), and the geocoding procees should be able to deduct that when a user looks for "Ruta 6 km 35.500" it means a point in "Ruta 6" in the middle of the markers for km 35 and km 36. Also the distance between markers it isn't exactly 1000 meters, it can be more, it can be less...

The reverse geocoding process should also use this address data in rural areas, addr:street is the higwhay, and the addr:milestone could be estimated if there are highway=milestone nodes near the location being reverse geocoded.

[muralito]

Some have additional zeros at the end.

This also looks a mapping error. It seems it was imported, so probably these numbers were treated as strings.

No, it isn't an error. It was an import but all the schools that have wikidata tag were curated manually.
The address for this school in text is:
Line1 (way and milestone): Ruta 15 km 104,500
Line2 (rural area, so no city, only state): Rocha
Line3 (country): Uruguay
(yes, for numbers the "," in spanish is like the "." in english)
In the souce data probably the meters and kilometers were separated by ",", but as addr:milestone in OSM is a distance, it was replaced by ".".

All the components of this text address are in the respective addr:* tags.

[muralito]

Then there are quite a few objects with have a addr:milestone and a addr:housenumber, e.g. https://www.openstreetmap.org/node/6817599738. How does that work?

This problem is caused by an import made by Kaart a few years ago. This should'nt be imported.
An address in Uruguay couldn't have addr:housenumber and addr:housenumber simultaneously.
And there is no way to fix it, just delete, because the addr:housenumber is fake, and the addr:milestone is also fake (not a distance, but "33 a 34" which means "from km 33 to km 34", that is simply not an address.

[muralito]

There are also combinations of addr:place and addr:milestone, e.g. https://www.openstreetmap.org/node/11066782731 That looks suspect.

Yes, it also looks suspect to me, but I don't know how address are formatted in Spain.
In all the address formats that I am aware of, the addr:milestone component is always associated to the nearest road, it needs a road in which you measure the distance.

[muralito]

The proposed addr:milestone=* tag should always substitute entirely the use of addr:housenumber=*.

This is the correct format in Uruguay, but i cannot extrapolate to all the countries.

The use of the prefix "Km." is something that is widely used in general, as this denotes the address is making reference to a milestone. It very common to refer in that form to an address which uses those markers as part of an actual address. This is mostly used as a reference only and does not necessarily read an exact distance (from a milestone) on any highway.

This tag is somewhat not standarized until now, so sometimes the tag value is prefixed, and sometimes not. As the prefix "Km" or "Km." (the dot shouldn be there beacuse is a ISO unit, not an abvreviation) is used in spoken and written language, it should be interpreted in natural language that the following value is a distance

The use of addr:place in combination with addr:milestone has not been discussed before, but I agree on this needing to be further agreed upon in order to establish a common procedure on OSM. I have mixed feelings on that (addr:place) specific tag.

As the tag addr:place is used when there isn't an addr:street to tag, and addr:milestone needs and addr:street to refer, it seems that addr:place and addr:milestone should'nt be a valid combination of tags.

Some places around the world frequently use an additional meter reading to define a location more accurately, and is usually written as Km. 35 + 250 in those cases where the + 250 represent the location (approximately 250 meters after the actual Km. 35 milestone) - something that could be adopted for this proposal as well.

Common use here is to say "Km 35,500" so the addr:milestone="35.500", numerically the value of "35.500" and "35.5" is the same, but the way the people speak and write address is just that, when the data consumer sees the addr:milestone just display "Km"+addr:milestone (as a value, it should be localized with the right separator used in the language of choice)

Another common variable (mentioned already above) is the use of a 'period' or a 'comma' to define the decimals & separating the thousands. The US, Australia & Great Britain (as well as many other countries) commonly use the 'period' as a decimal separator, while the EU and yet other countries around the globe use the comma. In order to follow a certain criteria, and since OSM is originally a British creation, I'd suggest using the 'period' as the decimal separator, while the 'comma' would be used to separate the thousands. This would also need to be included on the proposal to avoid even more confusion.

Yes. If the proposal is that "addr:milestone" is a distance it should be in english in OSM, and only the value, no prefixes.

[muralito]

The proposed addr:milestone=* tag should always substitute entirely the use of addr:housenumber=*.

I have a different point of view. In Brazil, it is not rare to find both values, as I commented here. So, they can coexist.

Sure, no problem. We should make a list of which combination and restrictions are valid in which countries or territories, just to document clearly all this knowledge and don't keep disusing cases in posts.

[muralito]

It looks like we need understanding of fractional numbers here. The tagging of this also seems rather diverse. Some use a comma, might just be a tagging error. Some have additional zeros at the end. How do you search for that? Can it be interpreted as a string (meaning the zeros always have to be there) or must it be interpreted as a number (search may or may not have additional zeros).

Yes, an understanding of fractional numbers is needed. Maybe the comma use should be replaced by period, but i suspect that as the comma is used in spanish written addresses, the people could, or would search for
"Ruta 3 Km 192,5" or "Ruta 3 km 192,500" but in a ideal implementation this shouldn't only search for a corresponding addr:street and addr:milestone tag, which could'nt be there, but also check if the road has highway=milestone's and interpolate between them.
E.g. I have a problem with the car and need to pass an address to the tow service, maybe there isn't a valid house/property address in several kilometers around, but I just tell them the road name/number and the milestone and the tow service can locate me. Obviously no address is needed if you or your navigation app can share the coordinates with them.

[lonvia]

May I suggest that you move the discussion to https://community.openstreetmap.org/t/rfc-feature-proposal-addr-milestone/121295/10? This is a wider tagging discussion and all highly relevant for the larger OSM community.