Openstreetmap-carto: Hide addr:interpolation lines from display

[ccamara]

Actual behaviour

There is a useful tag called addr:interpolation which is used to interpolate address numbers in places where only a few address numbers are available (https://wiki.openstreetmap.org/wiki/Addresses#Using_interpolation). This information is currently rendered as a dashed line
(see screenshot below from this location)

Expected behaviour

Whereas I acknowledge their usefulness, I am less sure that rendering them adds useful information to the map. On the contrary: IMHO they only add clutter, as seen in the previous image.
Therefore, I suggest removing that information from the render, as it is only useful for calculating addresses, but not for visualization.

[mboeringa]

Looking at your image, I really wonder why this information was added in the first place in this region. Clearly, your image shows that individual addresses are being added on buildings.

Address interpolation in my interpretation was just a way to add rough indications of building addresses in poorly mapped regions, that likely did not even have individual or any buildings at all.

In the example you showed, I would advice to remove the addr:interpolation line objects from OSM, as they serve no purpose, and in fact will probably even make any routing worse as the actual addresses of individual buildings are already there.

[polarbearing]

The interpolation lines, when mapped properly, are useful when the location of each individual number is not yet captured (houses present or not does not matter here). They are a useful hint for further mappers to go there and collect the numbers.

Thus, when used as intended, they are an important information both for searching an address visually on the map, and for going out and improving it.

Thus I agree with @mboeringa that they should remain being rendered, and that in you example the duplicate tagging should be improved. In your example the interpolation is mapped very coarsely over the length of the street. Breaking that into shorter segments for each block (that does not have numbers yet) would be an easy step before collecting the numbers individually.

[ccamara]

Thanks for your prompt feedback! However, I would like to point out that I am not questioning whereas this particular tagging is correct or not (there was a discussion on the Spanish community -in which I have to admit I did not take part, just as observer- and was decided that even it was not the best possible option, it was better than not having that interpolation).

What I wanted to do is to use that image as an example in order to raise the question of the need for displaying such information and should it not be necessary, remove it from the render (@polarbearing you state that it is visually useful, but I have to admit that I still don't understand why you say so).

[andrzej-r]

When used sensibly the dashed line provides useful information and does not add visual clutter. By "sensibly" I mean it connects groups of addresses not separated by other objects like streets parks etc. Keep them, please.

In poorly mapped cities it may make sense to draw such lines along the whole length of the streets but ultimately we want to switch to more accurate addressing. Barcelona is quite well mapped city so I am not quite sure what is the purpose of these address interpolation lines.

[StyXman]

In Latina America, where blocks are ~100m long, they also are a 100 house numbers 'long'. Of course, as there are not 50 houses per side, just a few numbers are assigned; for instance, I lived in 858 and my neighbor had 850. Interpolation is used heavily in these cases; see:

https://www.openstreetmap.org/search?query=Buenos%20aires#map=17/-34.60083/-58.41189

That's probably the reason why interpolations are rendered; there are more useful than in the Barcelona case.

[polarbearing]

Visually useful has been explained by @andrzej-r and @StyXman , here are more examples.

[sommerluk]

In Latina America, where blocks are ~100m long, they also are a 100 house numbers 'long'.

That seems to be a quite common practice. Same thing in Benin (new address system in Cotonou).

[geesona]

I did quite a lot of mapping in Birmingham UK where there a whole lot of
terraced houses and the interpolation was used quite frequently and
effectively. See:

https://www.openstreetmap.org/#map=18/52.44222/-1.93379

On 25/06/18 07:54, Lukas Sommer wrote:
>

In Latina America, where blocks are ~100m long, they also are a
100 house numbers 'long'.

That seems to be a quite common practice. Same thing in Benin (new
address system in Cotonou).

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/gravitystorm/openstreetmap-carto/issues/3276#issuecomment-399790445,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AhPipJ0EzF0MVJi5vxHaDQmLd1K_6ev1ks5uAAp-gaJpZM4U1EjB.

[matkoniecz]

@ccamara Are you aware of cases where addr:interpolation is used correctly and is still unwanted?

[matkoniecz]

I am not questioning whereas this particular tagging is correct or not

I am questioning whatever this tagging is correct and from look at it I am convinced that this addr:interpolation lines are incorrect and should be deleted, as addresses are mapped.

See https://wiki.openstreetmap.org/wiki/Addresses#Using_interpolation

As long as we don't have a node or building outline for each house(number) along a way, it's also possible to use automatic number interpolation.

As this is incorrect tagging it is not something that should be supported. I opened https://www.openstreetmap.org/note/1436012

In case that wiki is wrong - please discuss it on @tagging mailing list.

[matkoniecz]

@ccamara And thanks for an ideal bug report - there is a link to location, image, explanation what is wrong.

It may be give as example how ideal bug report should look like.

[kocio-pl]

I think that rendering is OK and there's no need to change it.

[matkoniecz]

So I close this as problem is in OSM data, I opened https://www.openstreetmap.org/note/1436012 to cover this issue.

[matkoniecz]

I am marking as invalid as this problem requires an OSM edit(s), not change in the map style.

[ccamara]

To @matkoniecz and the rest of people who have commented on this issue.
Thanks for your explanations, but without any aim to raise polemics, I still do not understand the reasons for displaying such lines (whereas I do understand the need of a correct tagging/mapping).

Currently, and if I didn't miss something, the arguments that I have received not to consider my suggestion are based on two facts: A) that particular use of mapping/tagging is not correct, and B) there are other areas where addr:interpolation is used appropriately. IMHO, and with al my due respect, those are not valid arguments to take such a decision.

My reasons for not displaying the addr:interpolation lines (not only those that I used on the provided image, which I acknowledge they may need to be removed) are the following:

1. These are the only features that are displayed on the osm-carto which do not exist in real world and cannot be verified. Roads, names, trees, buildings, amenities... do exist in real world, are easily recognizable and, hence, are displayed. Even more: there are some features that do exist but cannot be seen, like underground cables, which are not displayed on the map (and for good reasons! -Glad the map does not display such features). addr:interpolation is the only exception to that rule, at least that I am aware of.
2. addr:interpolation is only useful for routing or finding a place, which is a feature that is not handled by carto-osm but by other independent projects, such as nominatim or OSMAND+ to name just a few.
3. IMHO (but this is an opinion which may not be shared) addr:interpolation add unnecessary clutter to the map. There is a great concern on this project's issue to provide a general purpose map yet display only the minimal useful information (that seems to be the main reason not to display some features requested by other users). My suggestion supports this perspective.
4. Even in the provided examples with a correct use of that feature, I still don't see any advantage in displaying them. In other words: I don't see why the map is better with those lines rendered than if they were not present.

It is for those reasons that I suggest that this issue should be reopened/considered and those lines removed from the render.

[StyXman]

1. They are not physical entities, but you can go check: every corner has a street sign displaying the name of the street and the numeration in that block:

http://letras-uruguay.espaciolatino.com/aaa/tyrrell_eduardo/corone7102062010.jpg

1. I don't agree. The fact that you're not used to what we have in latin america does not mean is not useful for us in a map. Most maps have the numbering of the streets on them:

https://3.bp.blogspot.com/-XRaXoxzaiI0/UXlYUyUB7VI/AAAAAAAAy-Y/SArwGVLMwuQ/s1600/Mapa_centro_Cordoba.jpg

1. Again, the fact that you can't use them does not mean that people from these areas can't.

[polarbearing]

addr:interpolation is only useful for routing or finding a place, which is a feature that is not handled by carto-osm

As said before, when I see a long building on the map, with No 12 on one end and No 24 on the other, the interpolation line tells me that 16 is somewhere between them. No need for Nominatim or a router.

[matkoniecz]

ad 1

These are the only features that are displayed on the osm-carto which do not exist in real world and cannot be verified

I would consider addresses to be more verifiable than minor administrative boundaries. Note that addr:interpolation usage is intended to be like ones in https://github.com/gravitystorm/openstreetmap-carto/issues/3276#issuecomment-399789581 - not extremely long lines in areas where individual addresses are tagged.

See

In your example the interpolation is mapped very coarsely over the length of the street. Breaking that into shorter segments for each block (that does not have numbers yet) would be an easy step before collecting the numbers individually.

If you think that addr:interpolation tagging as in the initial picture is desirable and OK - we should discuss that on tagging mailing list (or somewhere else), but not here.

---

ad 2

addr:interpolation is only useful for routing or finding a place, which is a feature that is not handled by carto-osm

Are you proposing to stop rendering all addresses? Because that would go against goals of this project listed on https://github.com/gravitystorm/openstreetmap-carto/blob/master/CARTOGRAPHY.md

---

ad 3

addr:interpolation add unnecessary clutter to the map

Also in areas where this tag is correctly used?

---

ad 4

Even in the provided examples with a correct use of that feature, I still don't see any advantage in displaying them.

see @polarbearing "when I see a long building on the map, with No 12 on one end and No 24 on the other, the interpolation line tells me that 16 is somewhere between them"

[pnorman]

addr:interpolation is reasonably common and I've never seen there to be a problem with clutter when properly mapped. I reviewed locally in a typical usage and didn't see anything wrong. What I don't like about it is how the symbology isn't obvious, and a dashed line can easily be interpreted to be something else.

[ccamara]

Just to make sure that I made myself understood (since by reading previous comments I am afraid I failed miserably :( ):

I am not at all against rendering street numbers, which if I am not wrong, are tagged using addr:num. I find them both useful and verifiable.

As said before, when I see a long building on the map, with No 12 on one end and No 24 on the other, the interpolation line tells me that 16 is somewhere between them. No need for Nominatim or a router.

I'm afraid that's not completely true: what makes me infer that number 16 is between number 12 and number 24 is not the existence of a dashed line (which corresponds to addr:interpolation) but to the existing of two nodes, 12 and 24, which have been tagged with addr:num. That's why I am suggesting is to get rid of that dashed line. People can infer that information without it. Machines don't, and hence they need that line (but that doesn't mean that needs to be rendered).

Also in areas where this tag is correctly used?

Yes. What I am trying to argue all the time is that displaying that information doesn't provide any information per se. As I was saying before, what it is really useful to display are address numbers. Let me put it this way: Would it be useful to have a dashed line without address numbers on their start and end? Would someone be able to infer its meaning without them? Definitely, not. Does that mean that addr:interpolation lines are unnecessary? Definitely, not.

Are you proposing to stop rendering all addresses?

Definitely not! Hope I have made myself understood. I have never talked about address numbers, not addresses, only the dashed line that results from tagging addr:interpolation.

If you think that addr:interpolation tagging as in the initial picture is desirable and OK - we should discuss that on tagging mailing list (or somewhere else), but not here.

I've never said so, and that's the debate I don't want to discuss here (I agree that that should be done in the tagging mailing list). For the record, I also suggested the author of that changeset to remove them, so I am not supporting it. But that's not my point. I only used that image to raise the discussion that I hope I made clear on this comment. Even seeing other correct usages my opinion still persists, although I have to admit that that is much less problematic.

[dieterdreist]

best thing to do if the interpolation lines are disturbing: map all
housenumbers and remove the interpolation :)

[ccamara]

Hahaha, nice one. I wish I could.

[ccamara]

In an unexpected turn on the events I think I have now understood your position. If I only have a number 12 and 24 with no interpolation line, it is likely that 16 is somewhat in the middle, but it may also be that there's no such number. In that case (which I don't know if is even possible) it may be useful to display something (a dashed line for example :wink:) stating that there are more numbers between but have not been mapped yet.

If that scenario makes sense, I would go for addr:interpolation after apologizing for the inconvenience.

[StyXman]

If I only have a number 12 and 24 with no interpolation line, it is likely that 16 is somewhat in the middle, but it may also be that there's no such number. In that case (which I don't know if is even possible)

It is possible, in other parts of the world that you seem never have been to. As I said

for instance, I lived in 858 and my neighbor had 850.

So there were (and are, those number haven't changed) no 852, 854 or 856. Nor on the other side, but for the life of me I can't remember my other neighbor's number (probably something like 866).

[dieterdreist]

sent from a phone

On 28. Jun 2018, at 19:22, Carlos Cámara [e-mail] wrote:

If I only have a number 12 and 24 with no interpolation line, it is likely that 16 is somewhat in the middle,

likely the 16 is in between or interpolation lines would not help either, a more interesting question is number 15 (or any other odd number between 12 and 24), because it might be in between or on the other side of the road (and maybe 15 is not close to 16, even and odd numbers might not be “in sync”).

[ccamara]

likely the 16 is in between or interpolation lines would not help either, a more interesting question is number 15 (or any other odd number between 12 and 24), because it might be in between or on the other side of the road (and maybe 15 is not close to 16, even and odd numbers might not be “in sync”).

But that cannot be inferred from a dashed line on the map :wink:

[polarbearing]

But that cannot be inferred from a dashed line on the map

If you have a better proposal please go ahead, but there seems agreement here to keep the lines in principal. However, if you have more than one interpolations in an area, you usually see that e.g. one side of the road is even and the other is odd.