Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Names of POIs instead of their housenumbers #962

Closed
kocio-pl opened this issue Sep 20, 2014 · 31 comments
Closed

Names of POIs instead of their housenumbers #962

kocio-pl opened this issue Sep 20, 2014 · 31 comments

Comments

@kocio-pl
Copy link
Collaborator

We have some unnecessary data drop, because some points show only their address's housenumbers instead of names, like this:

http://www.openstreetmap.org/way/32256425

This is the building, where we have also cafe (visible) and two more points:

http://www.openstreetmap.org/node/3073006499
http://www.openstreetmap.org/node/3073006498

both of which have their names, but we see only the numbers (the same as the building, of course!).

I propose to get rid of that numbers (if only the name tag is given) and show the name instead. Those points should also have a dot in size of the pink one (the one we use for less popular and unnknown shops), but in the color of the name text we will show.

If the name is not given, maybe we should still show the numbers (I would be against it in my home city, but maybe there are some good cases supporting current rendering - who knows). However I would add the dots to all of them to show that there is a POI, not the strange house numbering.

Another improvement would be adding more icons and showing them, but I see a reluctance for adding them, plus there are still a tons of "numbered" points we will probably never catch in the iconized styles.

@matkoniecz
Copy link
Contributor

Note - it is possible that there is POI filling entire building. In this case both POI and housenumber should be displayed.

@kocio-pl
Copy link
Collaborator Author

Oh, yes - that would be great, too! I guess the number would be shown only when there is enough space - the name should always have precedence in rendering.

I also think when the POI is filling building AND that POI has a name, we should probably not display the icons if it is only a dot, because for me it suggests it's a point inside the building, not the whole one. Example:

http://www.openstreetmap.org/way/260678867

However when we have no name, the dot would still be useful to hint there is something interesting:

http://www.openstreetmap.org/way/260678872

@HolgerJeromin
Copy link
Contributor

Number plus Poi name is probably a usability Problem (even if i like it). Josm has a style with for example
4|BakeryName
I think most people will think the number and the seperator is part of the name. No problem with cities with all numbers mapped, but other places has only numbers available on the pois.

@kocio-pl
Copy link
Collaborator Author

They can be rendered with different text style - like brown bold (restaurant name) and black regular (number). Plus if they are in separate lines it would be not that much problem even if given POI has the same text style as the number.

@pnorman
Copy link
Collaborator

pnorman commented Sep 22, 2014

They can be rendered with different text style - like brown bold (restaurant name) and black regular (number). Plus if they are in separate lines it would be not that much problem even if given POI has the same text style as the number.

I'm not sure how this would look. Could you post some pictures of examples rendered like this?

@kocio-pl
Copy link
Collaborator Author

Unfortunately, for now I have to do other things (new work, as I mentioned...), but I will get back to TileMill and try to show it.

@matthijsmelissen
Copy link
Collaborator

I propose to get rid of that numbers (if only the name tag is given) and show the name instead.

If I'm not mistaken, you are proposing to render names of abitrary tags. I don't think that's a good idea, and we should restrict what we render. For example, what if one of the nodes was something silly like a named GSM antenna with a tagged address?

Part of the problem in the example will disappear once we start rendering amenity=doctors. The other tag, craft=electronics repair (with space) is probably a tagging mistake.

I don't see a concrete solution for this problem without rendering arbitrary tags, so I will close this issue.

@kocio-pl
Copy link
Collaborator Author

I really don't agree with closing that issue now.

Don't necessary think about all ("arbitrary") tags. Yes, I tend to like more broad solutions, but that's to negotiate. Say - let's only include some most common cases I see in my city, like "shop", "craft" and "amenity". Or just all the already documented in the wiki and some most common according to taginfo. It's not an all-or-nothing game (all the numbers to all the names).

I understand there are many other people, who are more strict in what they like to have rendered, but let be honest: the numbers instead of dots (at least) are just a random patterns with no use for anybody. They only take the valuable space, dully repeating information of the building itself. Do you really want to tell the current state of things is useful and not confusing? I guess not, no matter how broad/restrictive you think about what to render.

That problem is happening now, so how ignoring already existing problem is better than avoiding potential one? We can try out some solution - if it doesn't work, we can revert it or take another approach. That's called "evidence-based policy" and I like it a lot, even if some of my assumptions will (inevitably) die in the process.

I remember some people on the polish forum fearing the rendering of unknown shops will discourage people from correcting the bad ones. But rendering dots instead of nice basket still in such cases is a smart move in my opinion: "there is something interesting, but it's less interesting than fully iconized, common type of shop - check, if it's really correctly tagged: the award is more notable icon!". Dots (with names, whenever we're sure it won't hurt) instead of housenumbers should have similar effect.

@matthijsmelissen
Copy link
Collaborator

Sorry, it's still not exactly clear to me what solution you are proposing. Could you try to describe what exactly you would like to change once more?

@kocio-pl
Copy link
Collaborator Author

Sure. =}

In short: let's make all the POI's with housenumbers visible as fat dots, and let's decide when we're safe to add names to some of them.

What's your opinion about that?

@matthijsmelissen
Copy link
Collaborator

Reopened for further discussion.

@dieterdreist
Copy link

2014-10-01 0:14 GMT+02:00 kocio-pl [email protected]:

In short: let's make all the POI's with housenumbers visible as fat dots,
and let's decide when we're safe to add names to some of them.

can't we have both, e.g. write the housenumber above, below or aside the
name?

@matthijsmelissen
Copy link
Collaborator

let's make all the POI's with housenumbers visible as fat dots, and let's decide when we're safe to add names to some of them.

I don't think the fact that a POI has a housenumber alone is a reason to render it.

can't we have both, e.g. write the housenumber above, below or aside the name?

Personally I think it would make the map to crowded.

@kocio-pl
Copy link
Collaborator Author

kocio-pl commented Jan 8, 2015

I don't think the fact that a POI has a housenumber alone is a reason to render it.

Well - maybe it shouldn't, but now it looks like it IS the reason in many cases. What I want is to have something more consistent regarding to rendering of POIs. What we have now is:

  1. name+proper icon if available
  2. ...then name+plain purple dot...
  3. ...and then just the housenumber with no name, if the housenumber is available, but the POI doesn't fit in 1. or 2.

I prefer dropping rendering of housenumbers of POI's completely and treat this case as in case 2.

@Rovastar
Copy link
Contributor

Rovastar commented Jan 8, 2015

I thought the purple dot was just for shops on our whitelist that didn't have a specific icon....It is not for all POIs

I am really not sure what they issue is here you cannot display everything.

The issue seem to be certain POIs don't get displayed.

Yes we know doctors is one that has been crying out for ages and will solve one of your issues.
But we are actively making a point of only displaying things that are specifically on a valid list of things to display. The shops is one example of this, I expect more in the future.
If there are no valid POI we display the house number. I am not sure it is inconsistent. It seems very simple and consistent to me.

And remember boys and girls every change or absence of a change will result in someone not being happy by it.

Math, why has this been reopened? shrug

@kocio-pl
Copy link
Collaborator Author

kocio-pl commented Jan 8, 2015

If there are no valid POI we display the house number. I am not sure it is inconsistent. It seems very simple and consistent to me.

I try to be as accurate as I can, but it seems I fail at explaining... It surprises me a lot that you don't see the inconsistency, I see the problem exactly at this point:
If they are "valid" - the name is what is the most interesting thing, not the number.
If they are "invalid" (and what are the definition of "validity": just a technical or something more?) - why we show them at all?

I speak from the point of view of big city micromapper. There are a lot of shops/craft/services POI in some areas, and you can expect all those places are more or less similar. I can even live with degradation pattern: icon+name -> dot+name - > dot without name. But then suddenly you see the housenumbers a few times on the building - looks like they're not the points, but multiple number rendering of given building, aren't they?

That example looks just like a messy building housenumber rendering if you don't know that these are other POIs:

http://www.openstreetmap.org/way/32256425

We can't not only identify them as something different than the property of the building, but also we can't distinguish one from the another. Dot-with-no-name rendering also suffers from this second problem, but at least we avoid the first one.

@kocio-pl
Copy link
Collaborator Author

I guess after office is rendered as dot, the remaining part is mainly craft (see #3126) and some amenities. Maybe we won't get rid of housenumbers for POIs, but it would be enough for me if they will be rare.

@jidanni
Copy link

jidanni commented Sep 7, 2019

In https://help.openstreetmap.org/questions/70669/house-numbers-not-shown-on-map?
addresses are not rendered despite plenty of room remaining for them.
Perhaps in some cultures addresses aren't important?
Well in others they are vital. As vital as the building title.

A: "I told you to go to the McDonalds at 1500 Main St., Not 1701 Main St.!"
B: "Hard to tell from the map. And who would have assumed there was a second one."

Anyway we are mapping the ground truth, and now I bet the Most Famous Addresses in the World are no longer visible.

@jidanni
Copy link

jidanni commented Sep 22, 2019

I think names places should always have their house number shown.

Here we see
https://en.wikipedia.org/wiki/10_Downing_Street has its house number
shown twice, while
11 https://www.openstreetmap.org/way/105957600
12 https://www.openstreetmap.org/way/37743391
lack them.

@jeisenbe
Copy link
Collaborator

10_Downing_Street has its house number shown twice

Ah, that's happening because there are 2 different features: the entrance node at the door https://www.openstreetmap.org/node/1931404517 and the building area https://www.openstreetmap.org/relation/1879842 which both have the same addr:housenumber=10.

However, the housenumber of the building relation is only shown right now because building names are labeled with ST_PointOnSurface, while the addr:housenumber is rendered with Mapnik's label-placement algorithm.

We can fix this by changing addresses to also use ST_PointOnSurface - see #1644, and PRs #3233, #3690, #3712, #3781, and #3874

@jidanni
Copy link

jidanni commented Sep 22, 2019

@jeisenbe OK. Let's hope one day even normal places with plenty of room to show their house numbers,
https://www.openstreetmap.org/way/717830616
https://www.openstreetmap.org/way/340547893
will get them rightfully restored. Thanks.

@jeisenbe
Copy link
Collaborator

jeisenbe commented Sep 22, 2019

If you want to make sure that a particular house number can be rendered, note that this style also renders house numbers for nodes with entrance=* + addr:housenumber=*.

Most of the numbers in this example are from such entrance nodes, and displaying them at the location of the entrance usually leaves room for POIs in the building or the building name:

z19-monop-before
https://www.openstreetmap.org/#map=19/50.63295/3.06320

In the case of https://www.openstreetmap.org/way/340547893 - this is an amenity=school grounds, so showing the addr:housenumber at the centre would be less helpful than at the entrance, located at the entrance to the the main office or reception where map users should be routed.

https://www.openstreetmap.org/way/717830616#map=19/24.20949/120.83998 is a 15 by 20 meter building at 24 degrees north, so there is only room to show the name in the center of the building at z19, but there might be room to show the addr:housenumber if it is added to an entrance=yes or entrance=main node, and this will also help routing and navigation.

EDIT: apparently there is controversy about whether it is correct to tag building entrances with addresses instead of the whole building when there is only one address in the building: https://wiki.openstreetmap.org/wiki/Talk:Key:addr#Where_to_put_addr:housenumber.3F

@jeisenbe
Copy link
Collaborator

jeisenbe commented Sep 22, 2019

Reading the comments above, especially #962 (comment) by @kocio-pl, I agree that it's odd to show the addr:housenumber for all points, including those that have other main feature tags.

Currently the code is:

FROM planet_osm_polygon
          WHERE (("addr:housenumber" IS NOT NULL) OR ("addr:housename" IS NOT NULL) OR ((tags->'addr:unit') IS NOT NULL))
            AND building IS NOT NULL

and

 FROM planet_osm_point
          WHERE ("addr:housenumber" IS NOT NULL) OR ("addr:housename" IS NOT NULL) OR ((tags->'addr:unit') IS NOT NULL)

This means that for polygons, the housenumber is only displayed if there is a building tag, but for points, the housenumber is displayed for anything in the database, leading to duplicate rendering when there is both an entrance= node and another poi node with the same addr:housenumber, or when an unnamed building has an entrance= node or any POI node with an addr:housenumber inside.

A properly tagged building with a POI node and entrance node could have 3 copies of the number rendered at high zoom levels. This may imply that tagging each of the features with the addr is a mistake, but I'm not sure that is true. Tagging both the entrance and the POI is probably correct, so that the addr is linked to the POI.

I suppose fixing this would require either intersecting ways and nodes in SQL to remove duplicates?

Also, some mappers believe it is incorrect to add the addr to more than one node, see https://wiki.openstreetmap.org/wiki/Talk:Key:addr#Where_to_put_addr:housenumber.3F

@jidanni

This comment has been minimized.

@jidanni

This comment has been minimized.

@jidanni

This comment has been minimized.

@jidanni

This comment has been minimized.

@jidanni

This comment has been minimized.

@jeisenbe

This comment has been minimized.

@jeisenbe
Copy link
Collaborator

This issue was reopened with the idea:

"let's make all the POI's with housenumbers visible as fat dots, and let's decide when we're safe to add names to some of them.”

As several comments have mentioend above, this sort of catch-all rendering is not a good idea (see #1 and #240) - this style has a main goal of preventing tag fragmentation and supporting mappers with feedback.

There is also a different idea. that we should not render the addr:housenumber label for nodes which also have another main key like amenity= or shop= or office= - but that is a different rendering idea and should probably be a separate issue with a title like “Do not render housenumbers for nodes which also have a POI main feature tag which is not rendered”, if anyone thinks that is worth pursuing.

So I would recommend closing this issue, and the similar issue #4216, as not a good idea to fix.

@imagico
Copy link
Collaborator

imagico commented Oct 21, 2020

My reading of the suggestion this issue makes (see #962 (comment)) is to render features tagged with addr::housenumber and name but no further classifying tags with a name label instead of a housenumber label - essentially a slight variation of #4216. As such i agree this should be closed for the reasons explained in #4216 (comment).

If there are other ideas meant to be pursued by this issue it would as @jeisenbe points out probably be best to open a separate issue explaining the specific idea. Note however anything involving a catch-all or in other words basing rendering decisions on the presence of some key independent of the specific tag used is to be seen critically under the goal of constructive mapper support, avoiding tagging fragmentation and for an intuitive and easy to understand relationship between the data and the resulting rendering.

@imagico imagico closed this as completed Oct 21, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

10 participants