Re: [Tagging] Feature Proposal - crossing=marked
On Tue, 14 May 2019 at 05:10, wrote: I must admit that I only map crossings when they are between formed footpaths eg https://www.google.com/maps/@-28.070784,153.4361817,3a,75y,133.97h,57.19t/data=!3m6!1e1!3m4!1saeYx4cpvnikG8KXcdh0pGw!2e0!7i13312!8i6656 https://www.openstreetmap.org/way/553154851, not where there is only a grass footpath. > I do generally map crossings as long as they have lowered kerbs, like here: > > > https://cdn.discordapp.com/attachments/558999688670609448/577570543851536401/unknown.png That one, I would have terminated the crossing at the marked road, rather than taking it to the other side > or even: > > > https://cdn.discordapp.com/attachments/558999688670609448/577571624585527296/unknown.png & that I wouldn't have marked at all. Does it show up in OSMose / OSM Inspector etc as an error because it's not "attached" to anything? Thanks Graeme > > https://www.openstreetmap.org/node/6465544169 > > > > > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Apps of delivery
Wow, thanks for all that, Jason! I don't use any of these delivery services myself, nor know any restaurant owners, so wasn't aware that sort of thing happened, although I knew they were more expensive than picking your meal up yourself. So, yes, delete the URL & only go with what is on the restaurant's door / menu. On Tue, 14 May 2019 at 02:07, Jmapb wrote: > One weakness of both of these schemes is that there's no obvious way to > indicate that the restaurant also does deliveries itself -- which many of > them do, and prefer to do, since they don't have to give a cut to a dot-com > middle man. > Maybe =self-delivered / own_delivery / "restaurant's name" ? Thanks Graeme ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - crossing=marked
Forgot that part: > On my walk yesterday, other than the implied crossing at every > intersection (but see "don't map local law") I noted the following: I do generally map crossings as long as they have lowered kerbs, like here: https://cdn.discordapp.com/attachments/558999688670609448/577570543851536401/unknown.png or even: https://cdn.discordapp.com/attachments/558999688670609448/577571624585527296/unknown.png https://www.openstreetmap.org/node/6465544169 ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Apps of delivery
Le 13.05.19 à 18:35, Martin Koppenhoefer a écrit : >> there's no obvious way to indicate that the restaurant also does >> deliveries itself > > Right, maybe we should introduce a code for this to be added along the > delivery partners, something like “self”? (naturally this would break if > a company called self would offer delivery services). > Maybe the delivery:partner tag should be called delivery:operator (self > would fit better)? or use the name of the poi in the delivery:operator value : delivery:operator=deliveroo; so you 'll never have a clash between the "fake" value and the name of a company ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Apps of delivery
On 5/13/2019 12:35 PM, Martin Koppenhoefer wrote: verifiable facts about a restaurant (or other feature) might not always be verifiable in the feature itself, but still be verifiable for everybody interested in it (elsewhere). If the URL is accessible for everybody it would satisfy the verifiability requirement, wouldn’t it? Here's one story from a local restaurant: Fancy place, doesn't even do takeaway, much less delivery. One day the telephone starting ringing like crazy with takeaway orders. Eventually (the callers didn't initially make it clear) the restaurant owner discovers these are online orders from a delivery service that are being phoned in by the service's employees. He checks the service's website and there's his restaurant -- listed as new, featured on the neighborhood's page, and offering special discounts. The menu is there -- entirely wrong! Not just the prices, but the menu at this restaurant changes seasonally and the dishes were all from six months ago. He couldn't have filled the orders if he'd wanted to, because the ingredients were not in stock. This delivery service never contacted him for permission to be listed. It never warned him that he was about to be featured. And now he's angry, and the customers placing these orders are angry at the restaurant and giving it bad reviews. Explaining the situation to the low-level employees making the phone calls is not effective. He spends the rest of the day trying to contact someone in management at the delivery service to have the restaurant removed. They refuse. They're doing him a favor. Get with the times, etc. The fact that he's physically incapable of filling these orders doesn't sway them. He threatens legal action, they threaten back! So he hires a lawyer, who writes a cease-and-desist letter. The service removes him from the front page, but doesn't actually delete his listing until weeks later. If this all sounds like a racket, well yes, it is! But it's a legal grey area, so instead of being dismantled as a criminal enterprise, this delivery company is valued at millions of dollars. I have another friend who runs a restaurant, and she also reported being bullied by delivery services. Not as dramatic a story, but also listed without permission. So that's two data points, but these are the only two restaurateurs I know. So this is why I believe that the appearance of a restaurant in a delivery service's database should not be considered a verifiable property of the restaurant itself. If it's signed on the door or the menu, sure! But these services also engage in restaurantname.com domain squatting, hosting fake restaurant websites intended to drive delivery, so I wouldn't even trust a restaurant's website unless it links to more than one service. (I suppose if you successfully place an order and receive your food through a particular service, that's another form of verification. But be aware that the restaurant may have been coerced into this relationship.) Jason ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Apps of delivery
sent from a phone > On 13. May 2019, at 18:06, Jmapb wrote: > > I'm reluctant to recommend the OSM database as the best place to collect > links to the individual restaurant pages of various delivery services. I > prefer this "delivery:partner=*" recommendation on > https://wiki.openstreetmap.org/wiki/Talk:Key:delivery . The value could be > semicoloned, eg delivery:partner=deliveroo;menulog;ubereats. > +1 > And if delivery:*=* is adopted, I'd recommend to start with delivery:*=yes > and make the url optional. > +1 > One weakness of both of these schemes is that there's no obvious way to > indicate that the restaurant also does deliveries itself -- which many of > them do, and prefer to do, since they don't have to give a cut to a dot-com > middle man. > Right, maybe we should introduce a code for this to be added along the delivery partners, something like “self”? (naturally this would break if a company called self would offer delivery services). Maybe the delivery:partner tag should be called delivery:operator (self would fit better)? > On principal I'm not a fan of giving airtime to these delivery services > because of their predatory behavior > yes, just because we agreed on a tagging scheme doesn’t imply we have to add these tags ;-) > ...s are used I would strongly recommend that they be based only on > physically (or photographically) verifiable signage, not just on the fact > that a restaurant can be found in the online database of a given service -- > I’ve hardly seen signage (yet), but some restaurants have flyers and advertising on the bill. > which might be entirely involuntary, and therefore not, in fact, a verifiable > property of the restaurant itself. > verifiable facts about a restaurant (or other feature) might not always be verifiable in the feature itself, but still be verifiable for everybody interested in it (elsewhere). If the URL is accessible for everybody it would satisfy the verifiability requirement, wouldn’t it? Cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Apps of delivery
On 5/12/2019 8:19 PM, Graeme Fitzpatrick wrote: On Sun, 12 May 2019 at 19:28, Tony Shield mailto:tony.shield...@gmail.com>> wrote: Like the idea. delivery_contact might be better. I prefer delivery over contact Maybe (using our local companies as an eg) delivery:ubereats="url" delivery:menulog="url" delivery:deliveroo="url" with "url" in each case being that delivery companies online menu for that restaurant? I'm reluctant to recommend the OSM database as the best place to collect links to the individual restaurant pages of various delivery services. I prefer this "delivery:partner=*" recommendation on https://wiki.openstreetmap.org/wiki/Talk:Key:delivery . The value could be semicoloned, eg delivery:partner=deliveroo;menulog;ubereats. And if delivery:*=* is adopted, I'd recommend to start with delivery:*=yes and make the url optional. (=yes might ultimately be a better idea... any app who wanted to link to the delivery services could forward the restaurant name and address to the service's search url, and we wouldn't have the duty of maintaining the individual restaurant links for each service. It means the links wouldn't be available directly from https://openstreetmap.org, but I'm fine with that.) One weakness of both of these schemes is that there's no obvious way to indicate that the restaurant also does deliveries itself -- which many of them do, and prefer to do, since they don't have to give a cut to a dot-com middle man. On principal I'm not a fan of giving airtime to these delivery services because of their predatory behavior -- listing restaurants without their consent, and squatting on restaurantname.com websites to steer traffic to their service. I've complained about these guys in the talk-us list; I'm not sure if their behavior worldwide is as sleazy as it is here in NYC but I wouldn't doubt it. If these proposed tags are used I would strongly recommend that they be based only on physically (or photographically) verifiable signage, not just on the fact that a restaurant can be found in the online database of a given service -- which might be entirely involuntary, and therefore not, in fact, a verifiable property of the restaurant itself. Jason ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - crossing=marked
> 1. Combined foot/cycle crossing - a side path from a combined > foot/cycleway onto a very lightly trafficked suburban street. Marked > with signs bearing the silhouette of a bicycle about 50 m in advance > of the crossing. No markings on the pavement. (This crossing is part > of my daily commute. The street that it crosses is quite busy, and > the sign with the bicycle silhouette has no apparent effect on the > drivers. Pedestrians divide into the quick and the dead.) On the intersection node between footway and road way: highway=crossing crossing=unmarked You may tag the traffic_sign (here and in other cases) separately, how to do that is topic all it's own. > 2. Combined foot/cycle crossing - a combined foot/cycleway crossing > a busy two-lane street at grade. Signage both ~50 m in advance and > at the crossing. Flashing yellow lights (meaning 'proceed with > caution') flank the sign at the crossing. The lights can by turned > on by a pedestrian or cyclist pushing a button. Zebra-stripe > pavement markings. On the intersection node between footway and road way: highway=crossing crossing=uncontrolled (or crossing=zebra) You may tag the traffic_sign separately > 3. Zebra-stripe pavement markings at an intersection controlled by a > 4-way STOP sign. On the intersection node between footway and roadway: highway=crossing crossing=uncontrolled (or crossing=zebra) On a separate node on the road way placed at the stop line: highway=stop (This tag is a big ugly like that, because it depends on consumers figuring out in what direction it applies based on proximity to the intersection, but again, that's a topic all it's own.) (And additionally, given that this is specifically an all way stop, on the intersection node of the two road ways: highway=stop stop=all > 4. Zebra-stripe pavement markings at an intersection controlled by a > traffic light, with no 'WAIT/WALK' pedestrian signals. On the intersection node between footway and road way: highway=crossing crossing=uncontrolled (or crossing=zebra) Either on the intersection node of the two road ways, or if dual carriage, on separate nodes on the road ways placed at the stop line (coming into the junction): highway=traffic_signals > 5. Zebra-stripe pavement markings at an intersection controlled by a > traffic light, with 'WAIT/WALK' pedestrian signals, and a countdown > timer giving the seconds remaining to cross. On the intersection node between footway and road way: highway=crossing crossing=traffic_signals Either on the intersection node of the two road ways, or if dual carriage, on separate nodes on the road ways placed at the stop line (coming into the junction): highway=traffic_signals > 6. The same, with the pedestrian or cyclist requesting the WALK > signal by pressing a button. On the intersection node between footway and road way: highway=crossing crossing=traffic_signals If the pedestrians HAVE to push the button to get a WALK (not just "can push, which may make it faster or just be a placebo [more common than you think]"), also: button_operated=yes Either on the intersection node of the two road ways, or if dual carriage, or if dual carriage, on separate nodes on the road ways placed at the stop line (coming into the junction): highway=traffic_signals > 7. Zebra-stripe pavement markings, together with a sign displaying > the silhouette of school children, in the middle of a block in front > of a school. This crossing may be supervised during school > arrival/departure times. on the intersection node between footway and roadway: highway=crossing crossing=uncontrolled (or crossing=zebra) maybe: supervised=(valid time expression) > 8. Zebra-stripe pedestrian markings delineating the preferred > footpath in a parking field, and running generally perpendicular to > the parking aisles. If there is no intersecting node between this way and a road way, then this is not a crossing, it's just a footway that happens to be marked using zebra stripe pattern. If there IS an actual intersection between this way and a roadway, then the same as any other such crossing, on the intersection node between footway and road way: highway=crossing crossing=uncontrolled (or crossing=zebra) > And I'm now in confusion about how to tag any of them. For all of these, if you want to go down into micromapping territory, in addition to the above: 2 nodes on the footway, where the footway crosses the kerb on either side of the street with: barrier=kerb kerb=lowered (if it is, other values otherwise obviously) (if the kerb itself is mapped as a way, then these two nodes are the intersection nodes between the footway and the kerb way) and the part of the footway between the two kerb nodes (with the highway=crossing node being between them along this way), split at the kerb nodes and tagged as: highway=footway footway=crossing crossing=(whatever it is) ___ Tagging mailing list
