Re: [Tagging] Feature Proposal - RFC - parking=street_side
See "Parking-Protected Bike Lanes | The City of Portland, Oregon": https://www.portlandoregon.gov/transportation/77882 在 2020年10月27日週二 01:45，Supaplex 寫道： > Do you have an example picture/mapillary or similar of such a street? You > call this case yourself "parking lane" and the way you describe it, it > sounds like a typical case for parking:lane:* = > parallel/diagonal/perpendicular, but not for > parking:lane:*/parking=street_side. "street_side" is intended for cases > where the parking spaces are structurally (especially structured by curbs) > located on one side of the carriageway. (That means, if - hypothetically - > no vehicles were parked there, you could still not drive there because curb > extensions or street furniture would block a continuous drive.) > > A cycleway located behind this parking area is no longer part of the > roadway and would therefore not be "lane" but "track". But maybe I > misinterpreted the case you meant? > > > Am 26.10.20 um 15:49 schrieb Paul Johnson: > > On Sat, Oct 24, 2020 at 6:40 AM Supaplex > wrote: > > > Hey all, > > I would like to invite you to discuss a proposal for "parking = > street_side" for areas suitable or designated for parking, which are > directly adjacent to the carriageway of a road and can be reached directly > from the roadway without having to use an access > way:https://wiki.openstreetmap.org/wiki/Proposed_features/parking%3Dstreet_side > > The proposed tagging can be used on separate parking areas as well as with > the parking:lane-scheme. It aims not only to differentiate such > street-accompanying parking areas from others, especially > "parking=surface", but also addresses a contradiction in the current use of > the amenity=parking and parking:lane-scheme, which I would like to mention > briefly at this point: the use of "layby"/"lay_by". > > The value "layby" was originally intended for forms of resting places, as > they seem to be especially common in rural areas of Great Britain, Ireland > or the US: short-stop rest-areas along through-traffic roads intended for > breaks during a car-trip (see Wikipedia for a > definition:https://en.wikipedia.org/wiki/Rest_area#Lay-bys). On areas with > "amenity=parking" this key is also used in this sense (and mostly in Great > Britain). > > Within the parking:lane-schema, however, the value "lay_by" (written with > an underscore) has gained acceptance. According to the Wiki, this value is > defined identically to the layby's mentioned above. Its actual use, > however, differs from this and includes mainly street-side parking, as we > address them in our proposal. > > > How does this work out when the parking lane is not the curb lane? This > arrangement is increasingly common in North America, where the parking > isn't at the side of the road, one or more bicycle lanes are. > > > > ___ > Tagging mailing > listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging > > ___ > 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] automated edits seem to remove crossing=zebra drastically
Am Di., 27. Okt. 2020 um 00:38 Uhr schrieb Dave F via Tagging < tagging@openstreetmap.org>: > > > On 26/10/2020 23:26, Martin Koppenhoefer wrote: > > > > crossing_ref as far as I have understood the tag, is not about the > > type of crossing, > > I think you've misunderstood. then I am happy I never used this tag. If this is about the type of crossing, and crossing=* is also about the type of crossing, why should I prefer one over the other? Or should I put both tags? People have told me the crossing_ref was for the zebra markings, and I have seen a lot of people putting them on traffic light crossings with zebra markings. Cheers Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] automated edits seem to remove crossing=zebra drastically
On 26/10/2020 23:26, Martin Koppenhoefer wrote: crossing_ref as far as I have understood the tag, is not about the type of crossing, I think you've misunderstood. DaveF ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] automated edits seem to remove crossing=zebra drastically
Am Mo., 26. Okt. 2020 um 17:12 Uhr schrieb Dave F < davefoxfa...@btinternet.com>: > 'Zebra' shouldn't be use on the primary tag 'crossing' > > crossing_ref was created for use within the UK because many parts of the > rest of the world didn't understand what was meant by 'zebra'. It is, after > all, a nickname: > > https://wiki.openstreetmap.org/wiki/Key:crossing_ref > crossing_ref as far as I have understood the tag, is not about the type of crossing, but about the presence of zebra road markings. At least around here, they are common also on traffic light controlled pedestrian crossings. Cheers Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Proposal for admission=* tag
to avoid a lot of relations, I think we should have 2 functions (or pois within the feature): 1. place where you can buy the tickets, and 2. place where the tickets are checked this could also be the same place (e.g. ticket office where you have to pass through in order to enter the POI). Of places to get the ticket there are at least 3 kind: a machine issuing tickets, a person where you can buy tickets, or a place where you can get tickets which you already reserved or bought before. All the simpler cases (ticket office within or at the perimeter of the POI), we do not really need a relation, a specific tag would be sufficient. Sometimes it could be a property of "entrance=*" or barrier=gate objects Cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - parking=street_side
On 26/10/2020 15.19, Jeroen Hoek wrote: On 26-10-2020 19:31, Matthew Woehlke wrote: Alternatively, clients might look at the sort of highway running through a parking area. A highway=tertiary is probably "street-side parking", while a highway=service, service=parking_aisle probably is not. That's not a bad thought, but it would require connecting the street-side parking area to the highway (e.g., by extending the area to the middle of the carriage way), which goes against the principle of mapping what is there. If parking is on both sides of the street, the parking area already crosses the street, and even if it doesn't, logically the parking area *does* connect to the street. I disagree with the argument that mapping thus is somehow "wrong", and indeed, I usually map parking that way. The problem with the parking area potentially being misleading (which anyway is an issue of the consumer not considering how the adjacent highway infringes on the parking area) can be solved by also mapping the spaces. I don't think renderers tend to have this information available in any case. Perhaps, but at that point we're tagging for the renderer. I was thinking of other clients (e.g. routers). -- Matthew ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Proposal for admission=* tag
On 26-10-2020 17:52, Janko Mihelić wrote: > I have a feeling the poi role is a bit vague. I would keep it optional, > with only admission and issue being required for the admission relation > to work. Wouldn't issue be optional as well if any admission:issue:* tags are used? For example, the roaming ranger scenario where no ticket shop exists. You could consider requiring having at least one of those (an admission:issue:* tag or an admission role member) for a valid relation. > For example, your restaurant example, if the restaurant is poi, and one > entrance is admission, what if someone adds a second entrance and > forgets to add it to the admission relation? Then the system breaks > down, and the router routes you through the second entrance. > I would keep it simple, and add the whole restaurant as admission. > > But I'm sure there are examples where a third role would be necessary. > I'd like to keep this for a different proposal, and keep it simple for now. That's understandable. How will you handle the theme park with separately mapped entrances though? If you omit the entrances from the relation, and these have something like access=customers, routers won't know that there is an admission relation with information on where to get tokens/tickets and what it admits access to. Routers that try to use the admission relation, won't know that they could offer navigation to the entrances, rather than to the middle of the POI. Or am I over-thinking this? If the entrances are role 'admission', and the ticket office/shop/machine role 'issue', then where do you link the relation to the park itself? >> admission:issue:* > > I like this one. So in addition to relation members with the "issue" > role, you can also get the ticket through all the admission:issue:xxx=* > ways. I'll add it to the wiki. Nice. :) ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - parking=street_side
On 26-10-2020 19:31, Matthew Woehlke wrote: > Alternatively, clients might look at the sort of highway running > through a parking area. A highway=tertiary is probably "street-side > parking", while a highway=service, service=parking_aisle probably is > not. That's not a bad thought, but it would require connecting the street-side parking area to the highway (e.g., by extending the area to the middle of the carriage way), which goes against the principle of mapping what is there. I don't think renderers tend to have this information available in any case. Another notion I had was that renderers could just use capacity=* as a measure of how visible a parking amenity should be, but that would require knowing the capacity, which is not always plausible (and it could lure mappers into tagging a capacity value they deem suitable for rendering reasons). Of course, using capacity=* as well as parking=* can be useful to highlight huge parking facilities at an earlier zoom-level (I think Carto uses only the area size at the moment to do this). All in all simply adding this sub-tag value seems the clearer option. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - parking=street_side
On 25/10/2020 03.58, Jeroen Hoek wrote: Our proposal facilitates this: renderers can render street-side parking however they wish, because the tag tells them it is street-side parking. Alternatively, clients might look at the sort of highway running through a parking area. A highway=tertiary is probably "street-side parking", while a highway=service, service=parking_aisle probably is not. That said, I'm not adamantly opposed to the proposal, having encountered situations myself where such a tag would have made how to map this sort of thing much more obvious. -- Matthew ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Proposal for admission=* tag
pon, 26. lis 2020. u 18:13 Justin Tracey napisao je: > > Another thing worth addressing in the proposal is how this relates to > public transit systems. Things like a ferry that require a ticket for > entry might translate pretty directly, but what about bus or light rail > systems where you buy your ticket at a shop=ticket (or similar) to ride > anywhere on the system? Does this apply to those too? What about systems > where you can buy a ticket on a bus, but the ticket is also good for > transfers to the light rail or subway stations that require a ticket for > entry? The answer could be "no, don't use this for entire transit > systems", but either way, public transit is prominent enough in OSM that > I think it's worth explicitly addressing it in the proposal (and > discussing here, if need be). > I was thinking about public transit while I wrote this proposal, and I think it's more or less compatible. I was also thinking about motorways and vignettes you have to buy at a shop. But I decided to not include those because it would open a can of worms, and the proposal would never see the light of day. My plan is to roll out this proposal for simpler use cases, and if that works, we can apply it to public transport and maybe motorways. You're right, I'll add a line in the wiki that this shouldn't be used for public transport or motorway payment for now. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - parking=street_side
Do you have an example picture/mapillary or similar of such a street? You call this case yourself "parking lane" and the way you describe it, it sounds like a typical case for parking:lane:* = parallel/diagonal/perpendicular, but not for parking:lane:*/parking=street_side. "street_side" is intended for cases where the parking spaces are structurally (especially structured by curbs) located on one side of the carriageway. (That means, if - hypothetically - no vehicles were parked there, you could still not drive there because curb extensions or street furniture would block a continuous drive.) A cycleway located behind this parking area is no longer part of the roadway and would therefore not be "lane" but "track". But maybe I misinterpreted the case you meant? Am 26.10.20 um 15:49 schrieb Paul Johnson: > On Sat, Oct 24, 2020 at 6:40 AM Supaplex wrote: > >> Hey all, >> >> I would like to invite you to discuss a proposal for "parking = >> street_side" for areas suitable or designated for parking, which are >> directly adjacent to the carriageway of a road and can be reached directly >> from the roadway without having to use an access way: >> https://wiki.openstreetmap.org/wiki/Proposed_features/parking%3Dstreet_side >> >> The proposed tagging can be used on separate parking areas as well as with >> the parking:lane-scheme. It aims not only to differentiate such >> street-accompanying parking areas from others, especially >> "parking=surface", but also addresses a contradiction in the current use of >> the amenity=parking and parking:lane-scheme, which I would like to mention >> briefly at this point: the use of "layby"/"lay_by". >> >> The value "layby" was originally intended for forms of resting places, as >> they seem to be especially common in rural areas of Great Britain, Ireland >> or the US: short-stop rest-areas along through-traffic roads intended for >> breaks during a car-trip (see Wikipedia for a definition: >> https://en.wikipedia.org/wiki/Rest_area#Lay-bys). On areas with >> "amenity=parking" this key is also used in this sense (and mostly in Great >> Britain). >> >> Within the parking:lane-schema, however, the value "lay_by" (written with >> an underscore) has gained acceptance. According to the Wiki, this value is >> defined identically to the layby's mentioned above. Its actual use, >> however, differs from this and includes mainly street-side parking, as we >> address them in our proposal. >> > How does this work out when the parking lane is not the curb lane? This > arrangement is increasingly common in North America, where the parking > isn't at the side of the road, one or more bicycle lanes are. > > > ___ > 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] Proposal for admission=* tag
On 2020-10-24 9:32 a.m., Janko Mihelić wrote: > Here is my proposal on the wiki: > https://wiki.openstreetmap.org/wiki/Proposed_features/Admission > > In short, we don't have any way to connect places that need a ticket for > entrance, with the place that sells those tickets. Usually those places > are close together, but sometimes they are not. > In those cases, it would be nice that a router could either show us this > information, or route us to the ticket issuer first, and then to the > original place we were going to. > > The tags I proposed would be: > access=admission for the place that needs a ticket > admission=issue for the place that sells the ticket > admission:to=* to tag both with the same name, so we can link them, or > relation type=admission that connects the two places. > > What do you think? > > Janko > Another thing worth addressing in the proposal is how this relates to public transit systems. Things like a ferry that require a ticket for entry might translate pretty directly, but what about bus or light rail systems where you buy your ticket at a shop=ticket (or similar) to ride anywhere on the system? Does this apply to those too? What about systems where you can buy a ticket on a bus, but the ticket is also good for transfers to the light rail or subway stations that require a ticket for entry? The answer could be "no, don't use this for entire transit systems", but either way, public transit is prominent enough in OSM that I think it's worth explicitly addressing it in the proposal (and discussing here, if need be). - Justin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Proposal for admission=* tag
pon, 26. lis 2020. u 15:20 Jeroen Hoek napisao je: > On 26-10-2020 13:44, Janko Mihelić wrote: > > I would use a separate role for the poi (point-of-interest) itself, so > data consumers know what the subject of the relation is (the poi), where > its places of admission (entrances) are, and where tickets are issued. > I have a feeling the poi role is a bit vague. I would keep it optional, with only admission and issue being required for the admission relation to work. For example, your restaurant example, if the restaurant is poi, and one entrance is admission, what if someone adds a second entrance and forgets to add it to the admission relation? Then the system breaks down, and the router routes you through the second entrance. I would keep it simple, and add the whole restaurant as admission. But I'm sure there are examples where a third role would be necessary. I'd like to keep this for a different proposal, and keep it simple for now. For neatness and extensibility, perhaps admission:issue:* can be used as > namespace for these? Data consumers then know that any admission:issue:* > key means tickets can be got there, and you can document the common > types (e.g., admission:issue:website, admission:issue:phone, > admission:issue:roaming=yes (or something like that, for the roaming > ranger edge case)). > I like this one. So in addition to relation members with the "issue" role, you can also get the ticket through all the admission:issue:xxx=* ways. I'll add it to the wiki. Janko ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] automated edits seem to remove crossing=zebra drastically
'Zebra' shouldn't be use on the primary tag 'crossing' crossing_ref was created for use within the UK because many parts of the rest of the world didn't understand what was meant by 'zebra'. It is, after all, a nickname: https://wiki.openstreetmap.org/wiki/Key:crossing_ref DaveF On 16/09/2020 15:33, Martin Koppenhoefer wrote: Am Mi., 16. Sept. 2020 um 16:27 Uhr schrieb Dave F via Tagging mailto:tagging@openstreetmap.org>>: I thought the correct tag for this was crossing_ref. Have you cross checked to see if they've been swapped instead of removed? crossing_ref is a different kind of beast, as some people use it to tell whether there are zebra markings (can also apply to traffic light controlled crossings). Frankly, I do not like the tag for zebra crossings, because this approach requires me to set 3 tags (one of crossing=zebra / marked / uncontrolled(?) +, crossing_ref=zebra + highway=crossing, on every zebra crossing while I could use 2 and be done (highway=crossing with crossing=zebra). Cheers Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - parking=street_side
On Sat, Oct 24, 2020 at 6:40 AM Supaplex wrote: > Hey all, > > I would like to invite you to discuss a proposal for "parking = > street_side" for areas suitable or designated for parking, which are > directly adjacent to the carriageway of a road and can be reached directly > from the roadway without having to use an access way: > https://wiki.openstreetmap.org/wiki/Proposed_features/parking%3Dstreet_side > > The proposed tagging can be used on separate parking areas as well as with > the parking:lane-scheme. It aims not only to differentiate such > street-accompanying parking areas from others, especially > "parking=surface", but also addresses a contradiction in the current use of > the amenity=parking and parking:lane-scheme, which I would like to mention > briefly at this point: the use of "layby"/"lay_by". > > The value "layby" was originally intended for forms of resting places, as > they seem to be especially common in rural areas of Great Britain, Ireland > or the US: short-stop rest-areas along through-traffic roads intended for > breaks during a car-trip (see Wikipedia for a definition: > https://en.wikipedia.org/wiki/Rest_area#Lay-bys). On areas with > "amenity=parking" this key is also used in this sense (and mostly in Great > Britain). > > Within the parking:lane-schema, however, the value "lay_by" (written with > an underscore) has gained acceptance. According to the Wiki, this value is > defined identically to the layby's mentioned above. Its actual use, > however, differs from this and includes mainly street-side parking, as we > address them in our proposal. > How does this work out when the parking lane is not the curb lane? This arrangement is increasingly common in North America, where the parking isn't at the side of the road, one or more bicycle lanes are. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Proposal for admission=* tag
On 26-10-2020 13:44, Janko Mihelić wrote: > Although, now that I think of it, you can add the whole theme park > to the relation, and add role "admission", that doesn't hurt. I would use a separate role for the poi (point-of-interest) itself, so data consumers know what the subject of the relation is (the poi), where its places of admission (entrances) are, and where tickets are issued. > With ski resorts, you would need to put all the aerialways in the > relation as "admission", and ticket shops as "issue". You don't put > the ski slopes or the whole ski resort with admission, because you > can still hike through there, you just can't use the ski lifts. If you have a ticket that grants access to several ski-lifts, you could just create a relation with those ski-lifts as poi members. > Another example is a big nature park. There is one or two official > entrances, but you can just hike to that park without seeing any > entrances or boards that say "You have to have a ticket". There is a > possibility you buy a ticket from a ranger you accidentally meet. So > do we put all the paths in that park in the relation? Or is putting > the whole park boundary, and the oficial entrances enough? Perhaps you can omit the admission role completely in that case. If the poi (the park) is part of the relation, you would already know that a valid ticket is needed. Additional tags on the relation could indicate that you may be checked randomly at the poi. You also document that omitting the issue role means that you have to use other methods to acquire a ticket. You already propose admission:website, so I would document that if that exists, data consumers and users know that tickets can be bought online. You might consider adding another addmission:* tag to indicate that tickets may be bought from a roaming agent. For neatness and extensibility, perhaps admission:issue:* can be used as namespace for these? Data consumers then know that any admission:issue:* key means tickets can be got there, and you can document the common types (e.g., admission:issue:website, admission:issue:phone, admission:issue:roaming=yes (or something like that, for the roaming ranger edge case)). So for the park example: type=admission name=Mihelić Park admission:roaming_checks=yes admission:issue:roaming=yes admission:issue:website=https://example.com/tickets admission:token=ticket;qr_code poi -> (park outline) For the ski-resort: type=admission name=Awesome Ski Resort Aerialways and Bar admission:token=lanyard poi -> (ski lift 1) admission -> (ski lift 1) poi -> (ski lift 2) admission -> (ski lift 2) poi -> (guest only après-ski bar) admission -> (entrance of that bar) issue -> (ticket shop in the village) issue -> (ticket machine at summit of mountain) Would that work? ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Proposal for admission=* tag
ned, 25. lis 2020. u 16:16 Martin Koppenhoefer napisao je: > as an additional datapoint > shop=ticket is the only one with significant usage: (15000) > > https://taginfo.openstreetmap.org/search?q=ticket#values > > From its definition, it could also not be suitable (unclear), or maybe it > is? > > https://wiki.openstreetmap.org/wiki/Tag%3Ashop%3Dticket > > vending=admission_tickets also has some usage: (189) > > https://taginfo.openstreetmap.org/search?q=admission#values > > and rarely > ticket=admission (10 times) > I think these are prime candidates for this tag. I think any amenity can be a place where you get issued a ticket. There could be a restaurant that gives you keys for the tennis court it owns. I think that is also a case where you can use this tag. You just add admission:token=keys. That way you see a tennis court on OsmAnd, click it, and it directs you to the restaurant, and says you need to get a key. Although, ticket=admission sounds redundant. Janko ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Proposal for admission=* tag
It's easy to see how we would tag simple cases, like a cinema and a ticket shop. Just add a relation, type=admission, cinema gets the role "admission", and the ticket shop gets the role "issue". The question is, how do we tag edge cases. For example, a big amusement park. In my opinion, there should be a relation with all the turnstiles with role "admission", and all the ticket offices with role "issue". The amusement park in general doesn't even need to be in the relation. All the other private entrances should be tagged access=private or something like that. So the router can only route through the turnstiles, and then, if it knows how to read the admission relation, it sees that first you need a ticket. Although, now that I think of it, you can add the whole theme park to the relation, and add role "admission", that doesn't hurt. Another example is a big nature park. There is one or two official entrances, but you can just hike to that park without seeing any entrances or boards that say "You have to have a ticket". There is a possibility you buy a ticket from a ranger you accidentally meet. So do we put all the paths in that park in the relation? Or is putting the whole park boundary, and the oficial entrances enough? With ski resorts, you would need to put all the aerialways in the relation as "admission", and ticket shops as "issue". You don't put the ski slopes or the whole ski resort with admission, because you can still hike through there, you just can't use the ski lifts. Does this sound good to you all? Are there more edge cases? Janko ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
