-
Notifications
You must be signed in to change notification settings - Fork 823
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
Move amenity=post_box to z19+ #3431
Comments
Thanks for finding a clutter example - it should never look this way, it's just horrible!... Here's also more visible illustration of the San Francisco problem (which will be not too obvious until we deploy #3410): |
Are those actually post boxes in the first example - as in, somewhere you put mail that you want to send? I'm not American but they almost look like something you'd see for receiving mail: https://binged.it/2yiISg6 - especially this one with house numbers on it: https://binged.it/2yq38MG Plus, I would not want post boxes moved to z19, just because you've found somewhere that has an extreme density of post boxes (that's if they're even properly tagged) compared to the rest of the world. |
Thanks, that's good point - they should be probably tagged like this: https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dletter_box Still the problem are post boxes in the city, especially eclipsing roads, which will be visible after #3410. Look at the Post Street (!) example... |
Letter boxes were tagged like 5 years ago, when there was no other tag probably: https://www.openstreetmap.org/node/1559988088 the raise of a proper tag is quite fresh: |
Am Mo., 8. Okt. 2018 um 16:52 Uhr schrieb kocio-pl <[email protected]
:
Letter boxes were tagged like 5 years ago, when there was no other tag
probably:
These are not well tagged under the amenity key IMHO. I'm all for people
mapping whatever they like, but amenity is not a good key for private
things that nobody cares about then yourself.
|
I'm not sure - what about objects like |
Am Mo., 8. Okt. 2018 um 17:02 Uhr schrieb kocio-pl <[email protected]
:
I'm not sure - what about objects like amenity=waste_disposal +
access=private? But this is off topic here, it's strictly tagging problem.
bad as well.
|
Then we have like 5 mln problems, mostly showing private roads (3.8 mln)... https://taginfo.openstreetmap.org/tags/access=private#combinations |
Am Mo., 8. Okt. 2018 um 17:12 Uhr schrieb kocio-pl <[email protected]
:
Then we have like 5 mln problems, mostly showing private roads...
https://taginfo.openstreetmap.org/tags/access=private#combinations
no, that is not a problem according to my statement: "amenity is not a good
key for private things that nobody cares about then yourself.", this is
clearly not true for roads in general, and not even for private roads.
Private letterboxes and waste disposal is different to private roads.
|
Who do you think cares for roads with the private access? It's not even for delivery (other access value). |
Am Mo., 8. Okt. 2018 um 17:23 Uhr schrieb kocio-pl <[email protected]
:
Who do you think cares for roads with the private access? It's not even
for delivery (other access value).
of course these privately accessible roads are used for delivery, there is
no general authorization for people to use the road just because they have
to deliver something (basically there is no sign telling the exception for
delivery drivers, but it is usually implicit).
|
So are letter boxes - they are private, but post delivery uses them to fill them up with mails. |
The whole paragraph was about amenity, so roads do not matter. |
Why not? The discussion about |
We map road with access=private because OSM mapping is like an addiction,
which cannot be satisfied until everything visible is mapped. ;-)
If someone sees a street on aerial imagery which is not on the map, it will
be added. So better to add it and mark access=private, to satisfy the
armchair mappers.
Letter boxes are at least too small to see from aerial imagery, so are not
as problematic from this standpoint, at least until the advent of
micromapping.
…On Tue, Oct 9, 2018 at 7:10 AM kocio-pl ***@***.***> wrote:
Why not? The discussion about access=private might exclude every object
from tagging. But amenity=waste_disposal is the same - it might be
private, but in every case I know it's operated by some external cleaning
service, just like letter boxes.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#3431 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AoxshF5E2fl7Bs36T25c3Kv1GLRQ5YvOks5ui81jgaJpZM4XLOeZ>
.
|
@dieterdreist, there was discussion in a note about if the mail boxes were tagged probably or not. It didn't go anywhere though because its hard to tell as an arm chair mapper that doesn't live in that area, and there are to many to re-tag anyway. Plus, what other tag is there? There was also speculation that the mailboxes might have been originally by someone representing the local post office and that they are using them on a map for mail delivery and pickup. There is really no way to know. But its an assumption to say it was just micro mapped by an arm chair mapper that was just mapping whatever they felt like. Also, its an assumption to say they aren't important to anyone, the post office aside, because its something usable by the 30 or 40 houses in that area. Otherwise, your stuck debating scale of usefulness, which won't go anywhere. Or the same could same be said for neighborhood parks. "I don't live there or go that park. So why should it matter?" To me, that's not an answerable question and it shouldn't matter to what gets render or how. As far as the access debate goes. I think its worth debating because what is access anyway? People should map physical things and not worry about who can or can't use them. Since like my example above, everything geographical is important to someone and who knows if those people are using the map to see that item or not. It might help people visiting someone that has a really long drive to have us map it for their router, even if it is private, or what about private roads with a bunch of houses on them where the roads being mapped might be useful to emergency crews, despite their private access? I've gotten in a lot of debates with other mappers who deleted roads outside their houses because they didn't like people driving down them. Even though the roads are public or considered only for emergency situations. It gets to be a slippery slope of who can access the thing, why, and if it warrants mapping or not based on those variables. The same goes for private swimming pools. I was just reading about how fire crews in the L.A. area used pools mapped on OSM to help them fight the fires down there. So, I say its better not to get in a debate about it in the first place, since we can't know all the possible variables, and just map/render what's geographically there. |
@Adamant36 to be very clear, because I believe there may be a misconception
here, I was not arguing against mapping private things (other people are
though, for privacy reasons), I was arguing against the tag
amenity=letter_box which is both, a misuse of "amenity" (in my eyes) and
might bear the risk of being confused with amenity=post_box. People can map
their private letterboxes, no problem (I wouldn't render them in a generic
map like this though). Anyway, amenity=post_box and amenity=letterbox play
in totally different leagues. If you argue for post boxes and atms to go to
z19, I would not expect to see letterboxes before z21 or 22.
|
@dieterdreist, I appreciate the clarification. You might have a point. I'd have to think about it more. I'm not asking for anything related to letter boxes though and I'm pretty sure the mail boxes in my example are not letter boxes. I think there might be a definition difference between America and Europe in what counts as a post box, which could be part of the problem. We don't use the term letter box here. We call them mail boxes, where as the term post box is reserved for things at the post office. There are also mail boxes on residential street corners with multiple in boxes and an out going slot that serve everyone on the block. I don't consider them in the same league as the blue public mail boxes and they don't count as a letter box. Since multiple people on the block use them. They are semi private though. Random people can't drop mail in them and you need a key to get mail out. So maybe they would be considered private access or letterboxes, depending on your definition of those terms. Who knows though. That's why I think its better not to go down that road in the first place and to just assume they are mapped correctly. Although, you could be right and they very well might not be. I also agree with you that the density is probably an anomaly, but I like to think ahead a little and there is a lot of opportunity for way more dense mapping of post boxes in the future. So I figure its better to preempt it. Plus, there's also the other issues and the icon just inconsistent and doesn't fit in at z17. I feel like that's the "civic/activity" zoom level and z19 is the amenity (bench, bbq, post box, phone, etc) level. I think the fact that rendering is inconstant on Z17 is a real issue to. People should see on the map whats mapped. It should not be completely random what shows up at a zoom level. Sending some "less important" items down a few zoom levels is the only solution. I wish Z18 was utilized more to, but that's another issue. |
How about we compromise on z18?
I would be happier with ATMs at z18 too.
…On Wed, Oct 10, 2018 at 12:02 AM Adamant36 ***@***.***> wrote:
@dieterdreist <https://github.com/dieterdreist>, I appreciate the
clarification. You might have a point. I'd have to think about it more. I'm
not asking for anything related to letter boxes though and I'm pretty sure
the mail boxes in my example are not letter boxes. I think there might be a
definition difference between America and Europe in what counts as a post
box, which could be part of the problem.
We don't use the term letter box here. We call them mail boxes, where as
the term post box is reserved for things at the post office. There are also
mail boxes on residential street corners with multiple in boxes and an out
going slot that serve everyone on the block. I don't consider them in the
same league as the blue public mail boxes and they don't count as a letter
box. Since multiple people on the block use them. They are semi private
though. Random people can't drop mail in them and you need a key to get
mail out. So maybe they would be considered private access or letterboxes,
depending on your definition of those terms. Who knows though. That's why I
think its better not to go down that road in the first place and to just
assume they are mapped correctly. Although, you could be right and they
very well might not be.
I also agree with you that the density is probably an anomaly, but I like
to think ahead a little and there is a lot of opportunity for way more
dense mapping of post boxes in the future. So I figure its better to
preempt it. Plus, there's also the other issues and the icon just
inconsistent and doesn't fit in at z17. I feel like that's the
"civic/activity" zoom level and z19 is the amenity (bench, bbq, post box,
phone, etc) level. I think the fact that rendering is inconstant on Z17 is
a real issue to. People should see on the map whats mapped. It should not
be completely random what shows up at a zoom level. Sending some "less
important" items down a few zoom levels is the only solution.
I wish Z18 was utilized more to, but that's another issue.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#3431 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AoxshN3qmEPzS7RjpKQkNj2YGxxVjgL7ks5ujLp0gaJpZM4XLOeZ>
.
|
I would be fine with Z18. As it mostly solves the issue. It would probably work for ATMs also. It seems like z18 isn't really being used as a unique rendering level much though for some reason. @kocio-pl, is there a specific reason you went with z17 over z18 with the ATM thing and is there a good design reason or something why z18 doesn't get used that often in general for a rendering starting point? |
I'm cautious with that. As you both know, I search for universal rule and it currently seems to me that size rule is the most universal one, so I try to stick with that to have some solid foundation we could build on. I'm reluctant because of that:
|
sent from a phone
On 10. Oct 2018, at 14:46, kocio-pl ***@***.***> wrote:
the size of the post box is small, so it belongs to z19+
and fire alarm buttons on z22 because they are tiny ;)
Reality check: if we would go by the size rule, we would have to give parkings precedence over the shops they are encircling (in certain context). Desirable?
|
If we ever really start using z20+ it sounds pretty OK. It would be probably red, so it'd be enough to show what kind of object it is among similar sized objects.
I use relative size rule for a castle/defensive tower for example as a substitute of a real "show all belonging objects later than main one" rule (see #2896). In the meantime we have parkings showing their symbol and label according to their size alone, because I don't know how to detect when they belong to some other entity, |
@dieterdreist, there is no fire alarm button tag and even if there was, it doesn't mean this would be the place to render it anyway. So...You might have a point with letterboxes maybe, but 1. They aren't even rendered in the first place 2. There's no reason they couldn't be on z19 with ATMs etc if they were. I've been thinking about the size thing the last few days, maybe it would be a valid point that things like ATMs and post boxes shouldn't be rendered on z19, because then your left with no closer zoom level to render smaller things, except, there isn't anything smaller then them with tags at this point and who know if there ever will be. Except your one example of letter boxes. So unless your saying that the map shouldn't utilize a whole zoom level or that @kocio-pl's idea is bad from one example that isn't even rendered, I don't know what the issue is. Its not like rendering levels or @kocio-pl's idea can't be modified again in a couple of years when there's enough "tiny item tags" if need be. Plus, it probably wont be an issue once vector maps come along anyway. So, there's no reason to keep rendering things in a bad way until then, "just because." |
sent from a phone
On 11. Oct 2018, at 06:43, Adamant36 ***@***.***> wrote:
So, there's no reason to keep rendering things in a bad way until then, "just because."
What I tried to say is that the size rule does not work as an absolute measure with respect to what should be shown and when, nonetheless for every discussion it now appears as first argument.
It is by the way also inconsistent in itself, as it refers to the 2D projection of things and ignores height / volume.
|
It's a 2D map, so it makes a lot of sense as a basic metric and is easy to calculate for area rendering. Yet we use also height for towers, because it's also quite easy to use and for towers/masts it's their defining feature.
This rule is used as an absolute measure the whole design is founded on, but modified with some other factors. Even the biggest city is never shown before a country, for example. |
Now that ATMs are rendered at z19+ I think post boxes should also be. As they suffer from a lot of the same issues at higher zoom levels as ATMs did. I noticed @kocio-pl mentioned them in issue #1745 and the reasons are still valid.
My own reasons for wanting it at z19+ is that they clutter things up to much otherwise. Plus, the icon blocks more important icons and names at higher zoom levels. Also, its a small feature that is not used that often, and is only important on a neighborhood or even block level. Therefore, rendering it at z19+ just makes sense. Especially in more dense metro areas, where a lot of them are mapped.
https://www.openstreetmap.org/#map=17/38.77231/-121.36215 (clutter)
https://www.openstreetmap.org/#map=17/37.78930/-122.40474 (blocking more important things)
The text was updated successfully, but these errors were encountered: