Re: [Tagging] Feature Proposal - RFC - Tag:traffic_calming=hillocky
Hi, It's seems "speed bumps" is the way it's called : http://speedbumps.co.za/Our-Products/ https://www.dreamstime.com/speed-bumps-wenceslas-square-some-yellow-prague-rain-image104614297 https://www.ebay.co.uk/c/2293575914 speed humps here https://www.ebay.com/itm/Round-Circle-Speed-Humps-75mm-Traffic-Calming-Bumps-BLACK-OR-YELLOW-/113999252188 Le sam. 19 déc. 2020 à 23:27, Brian M. Sperlongano a écrit : > I've seen these in the US also, but I never knew what they were called. I > understand that the purpose of them is simply to make noise when a car > drives over them, as they don't slow you down in any appreciable way like a > speed bump/hump. > > We already have a tag for "a traffic calming device that makes noise when > a car drives over it", which is a rumble strip > (see: traffic_calming=rumble_strip). Note, I am talking about the kind > that go all the way across the road, and not the kind in the shoulder of > the road that make noise when you veer out of your lane. > > I usually think of rumble strips as grooves in the road, but it strikes me > that these micro-speed-bump things are essentially the same thing -- they > make noise when a car goes over it to alert the driver of something. > > I'm uncomfortable with hillock/hillocky as a value. Cursory searches seem > to indicate that this isn't a term in use, in any flavor of English. > > On Sat, Dec 19, 2020 at 5:08 PM Martin Koppenhoefer < > dieterdre...@gmail.com> wrote: > >> >> >> sent from a phone >> >> > On 19. Dec 2020, at 22:53, Jeremy Harris wrote: >> > >> > traffic_calming=multi_bump ? >> >> >> or >> traffic_calming=mini_bumps ? >> >> when they come up with something smaller that could still be micro_bumps >> ;-) >> >> >> Cheers Martin >> >> ___ >> Tagging mailing list >> Tagging@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/tagging >> > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Florimond Berthoux ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] The saga of landuse=reservoir vs water=reservoir
Hello, Le mer. 16 déc. 2020 à 16:19, Brian M. Sperlongano a écrit : > If you are not willing to have this question put up for a proposal (where, > as with any proposal, you are free to present your argument for all to > consider), your arguments are in bad faith, and again, must be dismissed > without consideration. Your desire to bypass our democratic process and > upend community consensus for tagging you don't like is frankly insulting > to the rest of us that work hard to achieve consensus in tagging. Why > should we waste time debating you, if you aren't willing to accept the > outcome of the community decision-making process? > There are no such things as "democratic process" or "community consensus" in tagging in OSM. So please, we must be tolerant with others' freedom to express their opinions. Bien à vous. -- Florimond Berthoux ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Is there a good way to indicate "pushing bicycle not allowed here"?
’bicycle’ tag is for the transport mode, cycling. I only use dismount if there is a board saying so. Why ? Because I tag the board not the written law in a book. About the value, I propose : bicycle=banned Le mer. 22 juil. 2020 à 17:36, Tod Fitch a écrit : > > > On Jul 22, 2020, at 8:09 AM, Jmapb wrote: > > If this unfortunate tagging practice really needs to be preserved (the > idea of retagging so many bicycle=no ways is certainly daunting) then I'd > suggest a new key, dismounted_bicycle=*, which will function as a > regulation key (like smoking=*) rather than a vehicle access key. Total > bicycle prohibition would be encoded with both bicycle=no and > dismounted_bicycle=no, and other dismounted_bicycle=* values can be > developed for whatever the regulations are in particular situations. > > Why? The suggestion that all the places that properly tagged bicycles=no > now need to be revisited and have a new dismounted_bicycles=no tag added > implies that the people who took “no” to mean something other than “no” > prevail and the rest of us have to go back and re-tag things. > > Since many miles/kilometers of ways will need to be retagged either way, > why not go with the straight forward “no means no” and “dismount means > dismount”? Makes a lot more sense to me that “no only really means no if > there is an additional dismounted_bicycle=no” tag too. > > Cheers! > > —Tod > > > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Florimond Berthoux ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Is it bicycle_parking=stands?
Hi, bollard ? Le dim. 5 juil. 2020 à 12:54, Mateusz Konieczny via Tagging < tagging@openstreetmap.org> a écrit : > In use it is a bicycle parking stand, you > can attach a bicycle by frame, > frame is supported. > > But it is not in a traditional reversed U > shape, but rather in O shape > > > https://commons.m.wikimedia.org/wiki/File%3ABicycle_parking_-_stand_in_ring_form.jpg > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Florimond Berthoux ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reviving the path discussion - the increasing importance of trails in OSM
Le jeu. 28 mai 2020 à 22:07, Kevin Kenny a écrit : > My very first attempts at editing with JOSM, some years ago, were > adding hiking paths. I followed JOSM's templates, with > 'Highways->Ways->Path' appearing to be a natural match, and got > `highway=path foot=designated etc.` for the constructed path. > > I uploaded the result. > > Another mapper gave me a (very mild) scolding, changed them all to > `footway`, and steered me to the JOSM templates for dedicated footway, > dedicated cycleway, bridleway, combined foot/cycleway, and so on. > Since then,I've been using those, which causes `highway=path` to > appear for any combined foot/cycleway, but causes `highway=footway` to > appear for anything from a broad paved path in a city park to a > technical wilderness trail. > > According to Florimond, that's correct. According to Daniel, that's > read as an assertion that the technical trail is an urban footway. > According to the Wiki, it depends on what page you read and how far > you get into the comments. According to the mapped data, it varies > considerably according to where you are. (Near me, there's a major > cycleway - paved doubletrack - that's 'highway=path bicycle=designated > foot=yes'. I walk a few km on it nearly every day.) To a data > consumer, it's "oh well, I don't know what it is" and either an > optimistic assumption that it's routable or a pessimistic assumption > that it isn't. > I agree that the wiki is too much wordy and definition and instruction is placed in too many places. Adding words don't make documentation clearer it makes things more complicate to read, to understand and to maintain. We should use simple rules : key definition is only on its page, value definition on the its page or on the key page if there is no need for special page. Keep definition as simple as possible. -- Florimond Berthoux ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reviving the path discussion - the increasing importance of trails in OSM
Hello, That's crazy how much people get confused about the triplets path/footway/cycleway highway=path for mixed path highway=footway for foot path highway=cycleway for cycle path Nothing to do with surface, localization, or whatever other properties, just there main usage. We should not map multiple feature in one tag. The wiki explain it well : https://wiki.openstreetmap.org/wiki/Key:highway highway footway : For designated footpaths; i.e., mainly/exclusively for pedestrians. This includes walking tracks and gravel paths. If bicycles are allowed as well, you can indicate this by adding a bicycle=yes tag. Should not be used for paths where the primary or intended usage is unknown. [...] highway cycleway : For designated cycleways. Add foot=* only if default-access-restrictions do not apply highway path : A non-specific path. [...] Le mer. 27 mai 2020 à 14:00, Daniel Westergren a écrit : > > Would it be wrong to set sac_scale=hiking on an urban footway? I’m worried >> that we’ll get highway=path, foot=designated, cycle=designated, >> surface=paved, width=2.5, lit=yes, rubbish_bins_every=100m, >> sac_scale=hiking. >> > > Same with mtb:scale. > > A footway or cycleway should, in my opinion, never have sac_scale or > mtb:scale, unless we introduce explicit values like sac_scale=no and > mtb:scale=no. If it has sac_scale=hiking or above, or mtb:scale=0 or above > (remember, mtb:scale is based on the *Singletrail *Scale and even a value > of 0 should only be used for a singletrail), then it's not a footway or > cycleway, but a path. And if it has a sac_scale or mtb:scale value, then we > should already tell by that, that it's not accessible to everyone. > > And a path should never get surface=paved, asphalt or similar, because > then it's not a path, but a footway or cycleway. > > But again, with the current use of highway=path it can be and is used for > anything. That's why depend on subtags (trolltags) and that's what we need > to get away from. > > So yes, if we could separate footway, cycleway and path clearly from each > other, then we can know that a path is always (if it's used correctly) used > for unpaved paths that may not be accessible to people of all abilities. > > As for "hiking paths", it's also a word that confuses me. I think we're > here talking about the way (that has certain physical characteristics), not > the route, however people may use them (anyone can hike on a path, whether > it's part of a route or not). And if we can't organize paths hierarchically > like roads, then also context becomes irrelevant when separating footway > and cycleway from path. > > /Daniel > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Florimond Berthoux ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Change of wiki page Key:access
I have encounter this issue many times : reality vs traffic sign. No vehicle acces to the wood in Paris, except that cyclist go there and that normal. A living street sign on a transit road. Etc. I would like to be able to tag separately the sign/law and the 'on the ground' reality. For the default I'd say tag the reality if there almost no change to be blamed for violating the sign. So for me the new tag would be motor_vehicle=no bicycle:dejure=no Or if there is a little change to be blamed, bicycle:defacto=yes is nice too. Could work also for highway : highway=tertiary highway:dejure=living_street Le lun. 25 mai 2020 à 00:30, Mateusz Konieczny via Tagging < tagging@openstreetmap.org> a écrit : > > > > May 24, 2020, 23:42 by vosc...@gmail.com: > > The strict wording introduced by Florian is simply not practically > applicable here. > My questions are: > Is Italy the only country with this problem? > > Poland used to be similar, though police sometimes setup trap where they > were fining people - > in sudden campaigns with several traps appearing for several hours every > few months. > > Favorite traps included cycleways crossing roads, where cyclists were > obligated by law to dismount > due to missing cyclist crossings. > Some routes had such crossing every 200 - 250m, nobody was following that > law. > > I was tagging legal status, and had some discussions with other mappers > whatever it is desirable to do it this way. > > Currently most of missing cyclist crossings are added[1], signs (for > example in forests) > more commonly explicitly allow bicycles, oneway:bicycle=no is becoming > more common > at least in some cities... > > [1] It turned out that blocker was completely idiotic law requiring > pedestrian + cyclist crossings > to be at least 7 m wide, for smaller ones including cyclist crossing was > against rules. > > Is there any better proposal for tagging the situation "from all I can see > on the ground, you are allowed ride through with your bicycle" > > Not sure what I would do in cases where access law as written and access > law as executed > would completely diverge. > > Setup new tags specially to allow to tag both verifiable legal status and > verifiable > de facto status? > > bicycle=no > bicycle:de_facto=permissive > > (even bicycle=permissive, bicycle:ignored_law=no would be an improvement > over > current state of not tagging legal status) > > It is out of OSM scope but I also had some successes with requests to add > missing > "except bicycles" under various traffic signs (on average in last years - > about one added every month), > in some cases it was simpler than inventing fitting tagging scheme for > really absurd cases. > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Florimond Berthoux ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tag:amenity=motorcycle_taxi not approved
Le dim. 10 mai 2020 à 01:25, Martin Koppenhoefer a écrit : > On 9. May 2020, at 22:50, Florimond Berthoux > wrote: > > Yeah, that's the point... > > Keep it simple. > You know taxi key ? You know motorcycle key ? Yeah, you can contribute > without checking yet another wiki tag page. > > By the way, this how a taxi moto looks like in Paris > > https://www.city-bird.com/wp-content/uploads/2018/08/DSC3972_R1_optimise_bas.jpg > > > > imagine you are ordering a taxi for yourself and 2 colleagues to the > airport and instead of a taxi (cab) they send you 3 taxi moto. Would that > be equally ok, wouldn’t it matter, taxi is taxi? > I don't care, English is not my mother tongue and tags is not the English language : «Tags is an intermediate language between human and machine, at the end its just characters with definitions, but some are easier to use for mapping and computing.» -- Florimond Berthoux ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tag:amenity=motorcycle_taxi not approved
Yeah, that's the point... Keep it simple. You know taxi key ? You know motorcycle key ? Yeah, you can contribute without checking yet another wiki tag page. By the way, this how a taxi moto looks like in Paris https://www.city-bird.com/wp-content/uploads/2018/08/DSC3972_R1_optimise_bas.jpg Le ven. 8 mai 2020 à 23:32, Joseph Eisenberg a écrit : > The tag motorcycle=yes is already documented as defining legal access > restrictions for motorcycle riders, like access=yes or foot=yes > See https://wiki.openstreetmap.org/wiki/Tag:motorcycle%3Dyes > > -- Joseph Eisenberg > > On Fri, May 8, 2020 at 1:34 PM Florimond Berthoux < > florimond.berth...@gmail.com> wrote: > > > > Hi, > > > > 5) As a French I have to give you again the universal answer : > amenity=taxi + motorcycle=yes + whateveryourvehicle=yes|designated :) > > > > Tags is an intermediate language between human and machine, at the end > its just characters with definitions, but some are easier to use for > mapping and computing. > > > > (I read some disrespectful arguments in the following mails...) > > > > Regards > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Florimond Berthoux ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tag:amenity=motorcycle_taxi not approved
Hi, 5) As a French I have to give you again the universal answer : amenity=taxi + motorcycle=yes + whateveryourvehicle*=yes|*designated :) Tags is an intermediate language between human and machine, at the end its just characters with definitions, but some are easier to use for mapping and computing. (I read some disrespectful arguments in the following mails...) Regards Le jeu. 7 mai 2020 à 20:51, Joseph Eisenberg a écrit : > The voting period closed for amenity=motorcycle_taxi with 11 votes to > approve and 8 votes in opposition, therefore it is not approved, since the > 74% majority requirement was not met. > > > https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:amenity%3Dmotorcycle_taxi#Voting > > Opposing voters preferred using amenity=taxi + motorcycle=yes or > amenity=taxi + taxi=motorcycle > > Surprisingly, at least 2 opposing voters would be willing to use > amenity=taxi + taxi=submarine or taxi=airplane for a location where you > could hire a submarine or airplane. > > However, several "yes" voters were strongly opposed to expanding the > definition of amenity=taxi which currently is limited to taxicabs > (generally assumed to be 4-wheel motor vehicles in contemporary British > English). > > So, what's the next step? > > 1) Propose using taxi=motorcar, =motorcycle, =boat, =airplane, and get > that idea officially rejected (it appears it would be certain to fail), or > is that a waste of everyone's time? > > 2) Make a proposal to clarify the definition of amenity=taxi as only > applying to motorcars, then try to propose the tag again? > > 3) Propose amenity=ojek and just hold the vote in the Indonesian > community, like how the Japanese mapper community proposes locally-relevant > definitions? > > 4) Give up on mapping things which are not found in western Europe, and > recognize that this is in practice a project dominated by > English/German/American culture, which will not accept new ideas which were > not invented in the West? > > -- Joseph Eisenberg > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Florimond Berthoux ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Doorzone bicycle lanes
Hazard tag seems to be used when there is a sign, so I'm not confident to use it for doorzone. There is two choices : 1. describe the layout of the street lanes + cyclelanes + : parking lane + sidewalk then add the widt of the cycle lane. Data consumer can deduce if the lane is dangerous or not + objective + complete without feature tagged twice - harder to compute doorzone state - harder to tag (a cyclist willing to tag doorzone has to tag parking lanes and width) example : cycleway=lane cycleway:width=1m parking:lane=parallel => doorzone (I could add more tags, for buffer, but I keep simple as possible.) 2. just tag doorzone feature (opposite arguments +/-) example : cycleway=lane cycleway:left:doorzone=yes Before writing this email I was not pro 1., but it's only 2 tags against 1, problem is that you must measure the lane and that is little difficult (our eyes are bad at that). At the end if the two way of tagging is documented for doorzone I'm ok with both. Le mer. 6 mai 2020 à 16:16, Peter Elderson a écrit : > Seems to me that the hazard is a general hazard applying to all mixed > traffic/parking situations. I would not map such a general hazard. Mapping > events and risks, unless indicated by signage or markings, doesn't seem > like a good idea to me. > > In specific cases the hazard may deserve mapping, then it should be tied > to specific OSM-objects, I think. If a parking "lane" is next to a > cycle-lane, then you might want to see that when rendering or weigh in/warn > when routing. > > In that case I think maybe the best solution is to map the parking "lane" > next to the cycling lane. The hazard then follows from the proximity. > > Best, Peter Elderson > > > Op wo 6 mei 2020 om 15:49 schreef : > >> Hmm okay, convinced. I only hope noone else comes with that topic later >> again then, but to me it's ok. >> >> -- Lukas >> *Gesendet:* Mittwoch, 06. Mai 2020 um 14:15 Uhr >> *Von:* "Andrew Harvey" >> *An:* "Tag discussion, strategy and related tools" < >> tagging@openstreetmap.org> >> *Betreff:* Re: [Tagging] Doorzone bicycle lanes >> >> >> On Wed, 6 May 2020 at 22:08, Martin Koppenhoefer >> wrote: >> >>> >>> >>> sent from a phone >>> >>> > On 6. May 2020, at 13:20, lukas-...@web.de wrote: >>> > >>> > I agree with that, but then note that for "justice" we would need a >>> foot:doorzone=yes, too, because when a sidewalk is in the parking car's >>> doorzone (I think most sidewalks next to parking:lane=parallel are), there >>> is hazard for pedestrians, too. It might be not soo dangerus because >>> pedestrians have much lower speed than cyclists often have, but if we want >>> to tag that hazard I think we would have to affect both, foot and bicycle. >>> >>> >>> >>> indeed there is much fewer risk for pedestrians and I would not tag it. >>> Next thing would be to add hazards for roof tiles that may fly from roofs >>> in case of storm? Snow sliding from roofs in winter? There may be many >>> hazards if you think it through... >>> ;-) >> >> >> I agree with Martin here, I don't think "foot:doorzone" is really needed >> as the concept only applies to bicycles. >> ___ Tagging mailing list >> Tagging@openstreetmap.org >> https://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 > -- Florimond Berthoux ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Doorzone bicycle lanes
Hi, I'm happy to see that doorzone tag is used, I think it's a good way to evaluate bad cycle infrastructure. Le dim. 3 mai 2020 à 10:52, Andrew Harvey a écrit : > > > On Sun, 3 May 2020 at 18:17, Martin Koppenhoefer > wrote: > >> I am not completely sure, if I get this right, do you mean the area where >> a door that is opened, would intersect with the space of a cycle lane? >> > > Exactly, see also https://en.wikipedia.org/wiki/Dooring. Personally when > riding I use the cycle lane as a buffer between parked cars and just ride > outside of the cycle lane. There's been cases of mappers removing the > cycleway=lane tag saying it's unsafe due to the doorzone, but that's wrong > since there is a cycle lane there, so a dedicated tag would help > alleviate this. > > >> Maybe this could be tagged as a “hazard”, i.e. a property, rather than >> forming a subtype of cyclelanes? >> https://wiki.openstreetmap.org/wiki/Proposed_features/hazard >> > > That's an interesting idea. They key to note is that this is not usually a > signposted hazard rather comes about due to the position of a parallel > parking lane next to the cycle lane. > > cycleway:hazard=doorzone could apply. Though there could be other kinds of > hazards which apply as well and it's unclear how that would work. I still > would learn towards cycleway:lane:doorzone=yes as being my preferred option > though, since you can tag =no as well. > I think sub properties of a feature should go with this scheme mainfeature:subpropertie=values(yes/no/enumeration/absolute values/...) This help to respect orthogonality : values of a key should not conflict So yes for : cycleway:lane:doorzone=yes/no/buffered buffered for the case there is a buffer marked between car park lane and cycle lane like this : https://cyclingsavvy.org/wp-content/uploads/2018/08/BikeLaneBuffer.jpg no means that the cyclelane is wide enough to not be doored (no buffer though). And I'd say yes also for : cycleway:lane:exclusive cycleway:lane:width cycleway:lane:color etc. ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Florimond Berthoux ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] With leisure=common deprecated, Senegal & Mali need a replacement
+1 for highway=pedestrian + area=yes That how we map a town square in France (and every where else I guess ?) Le mer. 29 avr. 2020 à 23:18, Joseph Eisenberg a écrit : > I agree, the area in this spot ( > https://www.mapillary.com/map/im/jYNQFMwHiNEZRCnpi71heA) is a moderly > sized open area of bare earth, with buildings on 3 sides and a paved > streets on a long side. It appears to be used for sports and recreation, > and for walking. I suspect it might be a "de facto" leisure=pitch - in the > USA it would be an "empty lot" used for soccer/baseball/etc. It could also > be a highway=pedestrian + area=yes - an open pedestrian area or "town > square" - those are usually paved in some way in developed countries, but > that's not a requirement. It does not appear to be a park. > > There was not any formal discussion to deprecate leisure=common, and > mappers are certainly free to keep using that tag. It was marked as > deprecated by one wiki user, about a year ago. > > But since the tag it is not well defined, it will be hard for database > users to interpret what it means. > > -- Joseph Eisenberg > > On Wed, Apr 29, 2020 at 1:41 PM Mateusz Konieczny via Tagging < > tagging@openstreetmap.org> wrote: > >> >> >> >> Apr 29, 2020, 21:37 by skqu...@rushpost.com: >> >> On 4/29/20 14:34, Jean-Marc Liotier wrote: >> >> Here is a 360° picture of a square in Dakar: >> https://www.mapillary.com/map/im/jYNQFMwHiNEZRCnpi71heA - larger than a >> street (it occupies a whole city block), used as a multipurpose common >> area (pickup soccer games are a staple but parking or lounging around >> also occur, and the occasional popular event) and usually surfaced with >> sand or whatever the ground is. >> >> We have long tagged it leisure=common (389 ways in Senegal and 486 in >> Mali according to http://overpass-turbo.eu/s/TqN) - which is a bit of >> stretch from the British legal definition, but worked well enough and >> did not conflict with its British usage. But leisure=common is now >> deprecated >> >> So, what should we use instead ? >> https://wiki.openstreetmap.org/wiki/Tag:leisure%3Dcommon suggests using >> leisure=park - which isn't too much of a stretch functionally but evokes >> greenery that does not occur here (though British commons are just as >> green and we were happy with leisure=common)... Any other ideas ? Or I'm >> going to use leisure=park+surface=sand ! >> >> >> While leisure=park might work, there is also leisure=recreation_ground >> to consider. >> >> >> leisure=recreation_ground sounds fitting to me and is without baggage of >> legal >> status bundled into leisure=commons >> >> This specific place looks like leisure=pitch. And for example in Poland >> some >> sport pitch may be used for an occasional event, festival of various >> types. >> >> Note: I am unfamiliar with on-the-ground situation in Africa >> ___ >> Tagging mailing list >> Tagging@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/tagging >> > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Florimond Berthoux ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging and rendering places without a name
Le mar. 21 avr. 2020 à 06:03, Warin <61sundow...@gmail.com> a écrit : > On 21/4/20 5:31 am, Florimond Berthoux wrote: > > Hi Hidde, welcome, > > The wiki definition is « Used to indicate that a particular location is > known by a particular name, to indicate what sort of "place" it is. A place > tag should exist for every significant human settlements (city, town, > suburb, etc.) and also for notable unpopulated, named places. » > > So place is used to precise that : > 1. there is place at this position or on this area > 2. it has a name > 3. to define what kind of place > > So by the definition I see no issue of having place without a name tag, as > long as it has a name :) > > Errr If it has a name, tag it. If you don't know its name then how do you > know it is a place? > Ask the mappers who do that, I guess that mapping a village or a town on remote you can guess it has a name without knowing it. > > This is different than landuse for instance : > A farm has the landuse farmyard, and may have other landuse like > greenhouse_horticulture, plant_nursery, orchard, meadow, ... > A barn alone or with some other building in the middle of a meadow can has > landuse=farmyard but it’s not a farm, it could has a place=locality if it > has a name. > > > If a building has a name then use the name tag on the building, do not add > a tag place=* to it! > I was talking about the place of the barn and around the barn, not the barn itself of course. > > > > Le sam. 18 avr. 2020 à 22:23, Hidde Wieringa a > écrit : > >> Hello, >> >> This is the first time posting to this mailing list. In case this is the >> wrong place to post my question, feel free to point me to the correct >> mailing list/forum. >> >> I opened an issue in the OSM carto Github repository ( >> https://github.com/gravitystorm/openstreetmap-carto/issues/4115) with >> the question if places tagged with place=* but without a name could be >> rendered. The follow-up pull request >> https://github.com/gravitystorm/openstreetmap-carto/pull/4120 proposes a >> rendering for unnamed places. >> >> A discussion erupted, about the conceptual consequences of rendering a >> place without a name. This goes against the wiki ( >> https://wiki.openstreetmap.org/wiki/Key:place) where the tag name=* is >> marked as required. The first line in the wiki is *"Used to indicate >> that a particular location is known by a particular name, to indicate what >> sort of "place" it is. [...]"*. However indicating what sort of place it >> is, does not require a name. Indicating that a place of some sort exists at >> a certain location is also valuable data (a quick count of Nigeria gives >> ~9800 nodes of places without a name versus ~69000 nodes of places with a >> name). >> >> I wish to question the assumption that every place always has or requires >> a name. The comment of 'sommerluk' on the Github issue ( >> https://github.com/gravitystorm/openstreetmap-carto/issues/4115#issuecomment-612847759) >> indicates that there may indeed be small populated places without a name, >> although larger populated places always have a name in practice. >> >> Also, regions of the world where on-the-ground mapping is not popular >> will mostly be mapped by remote mappers. Because of that, mapped places >> will usually not get a name (yet), because mappers are not locally familiar >> with the place. The data is still useful for humanitarian aid (for example >> see https://tasks.hotosm.org/contribute?difficulty=ALL&text=nigeria for >> the many projects in the HOT tasking manager for improving data in Nigeria, >> in particular missing residential areas). Rendering these places in a >> visual way makes using the data easier. Later, the unnamed places could >> still be given a name by a mapper with that knowledge. >> >> The tough question is when some place is considered a 'place' and may be >> mapped when the name is unknown. >> >> I am curious about further reactions on this topic. >> >> Kind regards, >> *Hidde Wieringa* >> _______ >> Tagging mailing list >> Tagging@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/tagging >> > > > -- > Florimond Berthoux > > ___ > Tagging mailing > listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging > > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Florimond Berthoux ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging and rendering places without a name
Hi Hidde, welcome, The wiki definition is « Used to indicate that a particular location is known by a particular name, to indicate what sort of "place" it is. A place tag should exist for every significant human settlements (city, town, suburb, etc.) and also for notable unpopulated, named places. » So place is used to precise that : 1. there is place at this position or on this area 2. it has a name 3. to define what kind of place So by the definition I see no issue of having place without a name tag, as long as it has a name :) This is different than landuse for instance : A farm has the landuse farmyard, and may have other landuse like greenhouse_horticulture, plant_nursery, orchard, meadow, ... A barn alone or with some other building in the middle of a meadow can has landuse=farmyard but it’s not a farm, it could has a place=locality if it has a name. Le sam. 18 avr. 2020 à 22:23, Hidde Wieringa a écrit : > Hello, > > This is the first time posting to this mailing list. In case this is the > wrong place to post my question, feel free to point me to the correct > mailing list/forum. > > I opened an issue in the OSM carto Github repository ( > https://github.com/gravitystorm/openstreetmap-carto/issues/4115) with the > question if places tagged with place=* but without a name could be > rendered. The follow-up pull request > https://github.com/gravitystorm/openstreetmap-carto/pull/4120 proposes a > rendering for unnamed places. > > A discussion erupted, about the conceptual consequences of rendering a > place without a name. This goes against the wiki ( > https://wiki.openstreetmap.org/wiki/Key:place) where the tag name=* is > marked as required. The first line in the wiki is *"Used to indicate that > a particular location is known by a particular name, to indicate what sort > of "place" it is. [...]"*. However indicating what sort of place it is, > does not require a name. Indicating that a place of some sort exists at a > certain location is also valuable data (a quick count of Nigeria gives > ~9800 nodes of places without a name versus ~69000 nodes of places with a > name). > > I wish to question the assumption that every place always has or requires > a name. The comment of 'sommerluk' on the Github issue ( > https://github.com/gravitystorm/openstreetmap-carto/issues/4115#issuecomment-612847759) > indicates that there may indeed be small populated places without a name, > although larger populated places always have a name in practice. > > Also, regions of the world where on-the-ground mapping is not popular will > mostly be mapped by remote mappers. Because of that, mapped places will > usually not get a name (yet), because mappers are not locally familiar with > the place. The data is still useful for humanitarian aid (for example see > https://tasks.hotosm.org/contribute?difficulty=ALL&text=nigeria for the > many projects in the HOT tasking manager for improving data in Nigeria, in > particular missing residential areas). Rendering these places in a visual > way makes using the data easier. Later, the unnamed places could still be > given a name by a mapper with that knowledge. > > The tough question is when some place is considered a 'place' and may be > mapped when the name is unknown. > > I am curious about further reactions on this topic. > > Kind regards, > *Hidde Wieringa* > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Florimond Berthoux ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Footways where pedestrians may only walk in one direction: oneway:foot=yes or foot:backward=no?
Bicycle is a vehicle (in OSM transportation mode hierarchy at least) An other way to explain Martin point is by saying that oneway key is an alias of vehicle:backward|forward oneway=yes -> vehicle:backward=no oneway=-1 -> vehicle:forward=no oneway=yes -> vehicle:backward=no oneway:bicycle=no -> bicycle:backward=yes Why not, I’m ok with that, for me oneway:foot is easier to read and understand (that’s why it’s more used I guess). At the end it’s just a matter of definition. So to answer the question, I don’t think there is a good and deep reason to recommend foot:backward|forward over oneway:foot. Regards. Le jeu. 16 avr. 2020 à 13:50, Andrew Harvey a écrit : > But on a highway=footway,cycleway,path you can't drive a vehicle, so in > those cases if there is a oneway=yes it's fair to assume it applies to all > modes of transport on that way, unless otherwise indicated. Sure you can > add oneway:foot=yes if you like, but oneway=yes should be interpreted as > the same on a highway=footway. > > On Thu, 16 Apr 2020 at 21:14, Paul Allen wrote: > >> On Thu, 16 Apr 2020 at 11:48, Warin <61sundow...@gmail.com> wrote: >> >>> >>> What reason is there for excluding other modes of transport? >>> >>> >> Many ways permit more than one mode of transport. Does oneway apply >> to all modes? Does that mean I can only walk in the same direction that >> traffic is permitted on a oneway street? That's why oneway excludes other >> modes of transport. >> >> -- >> Paul >> >> If "oneway" cannot be used then what do you think should be used? >>> >>> >>> ___ >>> Tagging mailing list >>> Tagging@openstreetmap.org >>> https://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 > -- Florimond Berthoux ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Can highway=cycleway be limited to MTB?
tags. >> >> All other tags like surface, smoothness, mtb:scale, route=mtb still >>> apply. leisure=track would still apply to short loop tracks like a BMX pump >>> track or a velodrome, but not to longer A to B tracks. >>> >>> Thoughts? I can help work on the wiki proposal for these tag changes >>> (mtb= as an access tag and path=mtb) but keen to hear feedback here first. >>> >> >> *Summary:* >> - When would/could I use the proposed mtb= access tag if land managers >> only define bicycle=, and what is a MTB (as mentioned above)? >> > > I would mostly use the bicycle access tag and only use mtb if it's > specifically signposted for mountain bikes specifically. > > >> - Your proposed path=mtb would be a specialisation of highway=path (like >> service=parking_aisle) which seems odd and against highway=path being a >> non-specific path? >> > > I agree, which is why I don't like highway=path + path=mtb since path=mtb > contradicts highway=path. highway=path says it's a non-specific path and > then path=mtb says it's specifically for mountain bikes. But it's the best > compromise for the people who say highway=cycleway (the tag for designated > bicycle paths) can't be used for mountain bike paths (which are just a > specific type of bicycle path). > > >> Objectively how would I know what is a MTB path, many signposted IMBA >> green trails don't have berms and rollovers? >> > > Good question. I would look at how it's generally used, indented to be > used by, who built it, who maintains it. > > >> What does this tag provide that just adding mtb:scale=* doesn't already? >> > > I guess it provides a way to say it's a mountain biking track but without > knowing or wanting to make a determination of the exact mtb:scale. Also > mtb:scale on a highway=track is still a track so it provides some way to > say whats a mountain biking track. Some people here have been very vocal > that presence of mtb:scale should not be the only way to distinguish a > mountain biking track for an urban cycleway, this started back at > https://github.com/cyclosm/cyclosm-cartocss-style/issues/208#issuecomment-607100435 > . > > >> I think general purpose routers should ignore highway=path if they don't >> want to understand path grading, the same can be said for highway=track. >> Personally I've only added mtb:scale:imba=* here from signposted trails, >> just never thought adding mtb:scale=* was helping anyone so didn't put in >> the effort, but could now. >> > > If you know the mtb:scale:imba then that's enough, addition the additional > mtb:scale should be optional, any good router and rendering engine should > be able to deal with all combinations of mtb:scale:imba and mtb:scale tags. > > I'll put together a proposal on the wiki so we can start getting something > more concrete down and then do a round of feedback then voting. > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Florimond Berthoux ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Can highway=cycleway be limited to MTB?
mtb:scale=yes is like surface=yes it has no real meaning, mtb:scale is a scale from 0 flat surface to 6 obstacle taller than a human. Actually I think mtb:scale is easier to use than smoothness : it's a more objective tag. (Sometime I think stating smoothness with average size of gravel/obstacle in cm would be much easier and objective tagging, but that is an other subject.) Le sam. 4 avr. 2020 à 23:57, Marc M. a écrit : > Le 04.04.20 à 15:47, Kevin Kenny a écrit : > > how does a mapper who isn't expert enough to grade accurately > > the difficulty of a MTB trail, but can > > clearly see, 'a road bike wouldn't work here' > > it's very subjective > an example of a situation that was not well described with > surface/inclined/... tags ? > > you may use =yes as default value when you don't use a more precise > value -> mtb:scale=yes ? > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Florimond Berthoux ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Can highway=cycleway be limited to MTB?
Le sam. 4 avr. 2020 à 10:18, Snusmumriken a écrit : > On Fri, 2020-04-03 at 20:53 +0200, Florimond Berthoux wrote: > > For this one https://www.youtube.com/watch?v=B7wbi4wGbsg (Andrew's > > example) > > We're on the edge of tags definition : this a path limited cyclist, > > where a mountain bike almost mandatory to ride there. Some features > > help the cyclist. > > > > I would tag may be that with : > > higway=path > > access=no > > bicycle=yes > > mtb=designated > > mtb:scale=2 > > For a path like that I wouldn't add bicycle=yes, because I think that > it implies that an average person on an average bike could use it. > bicycle=yes is an access tag it says only that cyclist has a legal right to ride there. «Key:bicycle Legal restriction for bicycles. » https://wiki.openstreetmap.org/wiki/Key:bicycle It doesn't say anything about it difficulties, that the job of mtb:scale key. -- Florimond Berthoux ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Can highway=cycleway be limited to MTB?
Thank you Volker for this sum up For this example https://youtu.be/gJQtmxsx7j4?t=201 We have a path made specifically for mtb, with lot of mtb features, and it's in a mountain bike "sport center". For this kind I see nothing wrong to use leisure=track + sport=mtb For this one https://www.youtube.com/watch?v=B7wbi4wGbsg (Andrew's example) We're on the edge of tags definition : this a path limited cyclist, where a mountain bike almost mandatory to ride there. Some features help the cyclist. I would tag may be that with : higway=path access=no bicycle=yes mtb=designated mtb:scale=2 For Singletrail-Skala S4 or S5 http://www.singletrail-skala.de/s4 http://www.singletrail-skala.de/s5 I have difficulties to consider these examples as a cycleway, they are barely paths. Le ven. 3 avr. 2020 à 16:34, Volker Schmidt a écrit : > We need to get some order into this discussion before changing wiki pages, > please. > > Designated cycle paths or, more often, designated mixed foot-cycle paths, > with the blue round signs, that are unpaved (fine-gravel or even grass > surfaces) exist in different countries in Europe. > (we have established ways of tagging) > > In OSM there is a stupid mix-up: highway=path can be used for an unpaved > hiking/walking path (often shared with MTBs, gravel bikes, touring bikes, > horses, donkeys, ...) and shared foot-cycle paths (with foot=designated and > bicycle designated; paved in most cases). This is unfortunate, but so > widely established that we cannot change it. > (we have established tagging for both cases) > > In OSM highway=cycleway implies bicycle=designated and is mostly used for > bicycle-only paths in some countries and for mixed bicycle-foot paths in > others, depending ohte Access Defaults. > (established tagging again) > > The vast majority of ways used by MTBs are shared with pedestrians and > often with other bicycles (touring bikes, gravel bikes) > (we have established tagging for these) > > There are very few (relatively) ways reserved for MTB > (we have no established tagging for these yet, and some may be wrongly > tagged as highway=cycleway) > > There are very few (relatively) ways reserved for BMX bikes > (we have no established tagging for these yet, and some may be wrongly > tagged as highway=cycleway) > > So let's calmly address the very few cases for which we have no > established tagging yet. > And please do not use misleading tagging for these few situations that may > have a detrimental effect on the huge majority of cases that we do have > established approaches for. > > I think the leisure=track approach could work, bu let's look around a bit > first. > I am not familiar with the tagging, but I have seen in the US designated > areas and tracks for 4wd vehicles, how are those tagged? Maybe that could > be a model. > > Volker > > -- Florimond Berthoux ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Can highway=cycleway be limited to MTB?
Hello, The first time I saw cycleways on the map in the Alps on mountains I was surprised, and not really confident with the tagging. I think I agree that a cycleway should be useable by any kind of bicycle. What we have today to tag mtb ways : If it’s a shared path with pedestrian (hiking) or horses or used for farming/forest etc we have keys highway=path and highway=track. I think we all agree with that. Mtb route can be used also over them. For a leisure sport park for mountain biking I think leisure=track + sport=mtb could be used I guess https://wiki.openstreetmap.org/wiki/Tag:leisure%3Dtrack Example : https://youtu.be/cD8XaOatg5I?t=307 The problem here is that I don’t see what a way made only for mtb which is not a leisure=track could looks like. For me if it’s in the wilderness it can be used by anyone, like hikers so it should be a highway=path. Do you have examples (photos, videos) ? Le jeu. 2 avr. 2020 à 10:11, Andrew Harvey a écrit : > My view based on current usage, reading of the wiki and general opinion is > that highway=cycleway is meant for any path that is either > designed/intended for bicycles or specifically designated (signposted) for > bicycles, irrespective of if it's an urban track or mountain biking track. > > So a mountain bike track and an urban cycle track should both be tagged > with highway=cycleway as the primary tag. surface= and smoothness= can help > for both to help guide users on which kind of bicycle the track is suitable > for, and mtb:scale=/mtb:scale:imba= are used to indicate this is a > designated mountain biking track. > > highway=path is specifically for a general use / unspecified path, which a > mountain biking track may be if it's informal/shared, but purpose built and > signposted mountain bike tracks don't fall into that category. > > A similar thing applies to hiking tracks, sometimes they are designated > walking paths so use highway=footway + surface + sac_scale, but sometimes > they are just an unmarked or mixed use path so are highway=path + surface + > sac_scale. > > Open to other opinions or comments. > > On Thu, 2 Apr 2020 at 18:56, Phyks wrote: > >> Hi, >> >> A discussion in CyclOSM issue tracker [1] spotted that there exists >> around 3500 highway=cycleway around the world which have specific >> mountain bikes (MTB) tags. In particular, around 800 highway=cycleway >> around the world declare a mtb:scale greater than 2, which would make >> them impassable without a proper mountain bike. Such cycleways would not >> be passable with a regular city bike. One example of such a case is at >> [2]. >> >> Looking at the wiki page [3], >> "the highway=cycleway tag indicates a separate way for the use of >> cyclists" >> which does not mandate explicitly that a cycleway be accessible with any >> kind of bikes and should also cover dedicated paths for MTB. However, >> the documentation around cycleways and bike features is very oriented >> towards city cycling and there is no illustration about MTB-specific >> cycleways. >> >> So, is this considered a valid tagging or should it be represented by >> another highway class (path, track, etc)? If this is valid, I propose to >> add a statement in the wiki explicitly mentioning that cycleways can be >> restricted for specific kinds of bicycles, for future questions. >> >> Best, >> >> [1] https://github.com/cyclosm/cyclosm-cartocss-style/issues/208 >> [2] https://www.openstreetmap.org/way/86978431#map=17/41.26426/-73.91907 >> [3] https://wiki.openstreetmap.org/wiki/Tag:highway%3Dcycleway >> >> -- >> Phyks >> >> _______ >> Tagging mailing list >> Tagging@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/tagging >> > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Florimond Berthoux ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Tag:amenity=motorcycle_taxi
My point is : don't merge features in the same tag !
That makes thing more difficult to tag and more difficult to consume.
Indonesia is big but world is bigger, and I'm pretty sure we can find
examples where different kind of vehicles shares the same taxi spot.
(You can use any british word for that taxi spot tag I don't mind).
Le ven. 21 févr. 2020 à 08:32, Joseph Eisenberg
a écrit :
> > In Paris there are parking shared between bicycle and motorcycle, and
> parking shared between bicycle and dock less vehicles (scooters).
>
> Unlike parking spaces, a motorcycle taxi stand is never shared between
> motorcycles and cabs or tricycles here in Indonesia, since each type
> of vehicle has different characteristics: speed, capacity, distance
> that can be traveled. The markets and the prices are different.
>
> Often a market or train station will have 3 stands for 3 types of
> hired vehicles (motorcycles, taxicabs, and pedicabs/tricycles), with
> each at a separate corner, or on different sides of the street.
>
> > amenity=taxi
> > taxi:motorcycle=yes
> > taxi:car=yes
> > taxi:tricycle=yes
>
> This is discussed in the proposal page:
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:amenity%3Dmotorcycle_taxi#Why_not_use_amenity.3Dtaxi.3F
>
> While some have proposed using {{tag|amenity|taxi}} plus the
> additional tags {{tag|motorcar|no}} + {{tag|motorcycle|yes}} for
> motorcycle taxi stands, this has several disadvanages:
> 1) It would imply that a taxicab and a hired motorcyle "ojek" are the
> same feature.
> 2) it requires using 3 tags instead of one.
> 3) If only amenity=taxi is tagged, it would now become ambiguous: is
> this actually a taxicab stand, or might it be a motorcycle stand which
> is missing a tag?
> 4) It will confusing for travelers who generally expect a "taxicab" to
> be 4-wheeled motorcar capable of carrying at least 4 passengers and
> their luggage. This is quite different than a motorcycle which can
> only carry one passenger with a small amount of baggage.
> 5) Many database users currently interpret {{tag|amenity|taxi}} as a
> motorcar taxicab via use of a standard "taxi" icon such as
> https://en.wikipedia.org/wiki/File:Taxi_Icon.png - this would be
> broken by such a change.
> 6) Motorcyles have different abilities: In contrast to a family or
> group which needs a 4 to 6 seat taxicab, single travelers may strongly
> prefer to hire motorcycles when available, due to their lower cost and
> ability to fit through smaller spaces in congested cities and rural
> areas with narrow roads and paths. Motorcar taxicabs with 4 wheels in
> 2 tracks cannot access {{tag|highway|path}} features and narrow roads,
> but motorcycles may be permitted and feasible due to their narrow
> width and single track.
>
> So a different tag is proposed to avoid confusion and more precisely
> tag these features.
>
>
>
> On 2/21/20, Florimond Berthoux wrote:
> > Hi,
> >
> > I'm always suspicious about tags with underscore in it, because they
> often
> > mix different features together.
> > My examples are parking, bicycle_parking, motorcycle_parking. In Paris
> > there are parking shared between bicycle and motorcycle, and parking
> shared
> > between bicycle and dock less vehicles (scooters).
> > Creating a new key for each combination would be awful.
> >
> > So I prefer to split the amenity "you can pay someone there to have a
> ride"
> > and what kind of vehicles you can find there.
> > That could looks like this:
> > amenity=taxi
> > taxi:motorcycle=yes
> > taxi:car=yes
> > taxi:tricycle=yes
> > ...
> >
> > (or other more British words ;)
> >
> >
> > Le jeu. 20 févr. 2020 à 08:50, Joseph Eisenberg
> >
> > a écrit :
> >
> >> I would like to formally request comments on the proposal for
> >> amenity=motorcycle_taxi:
> >>
> >> "A place where motorcycle taxis wait for passengers"
> >>
> >>
> >>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:amenity%3Dmotorcycle_taxi
> >>
> >> In many countries, motorcycles for hire are much more common than
> >> automobile taxis.
> >>
> >> In these places, motorcycle drivers wait at stands, often with a small
> >> shelter, and they can be hired to take one or more passengers to
> >> various destinations. A fare is paid for a one-way trip. The passenger
> >> usually rides behind the driver. In some countries two or even three
> >> passengers can be carried on one motorcycle "taxi".
> >>
>
Re: [Tagging] Tagging venues which give away free condoms?
Hi, condom=yes condom:fee=no (condom is available here) (free condom, yeah!) As I suggested in the free drinking_water thread, fee is already used a lot and has its wiki page. Le jeu. 20 févr. 2020 à 21:45, Rory McCann a écrit : > Hello fellow tagging fans, > > > Some places give away free condoms to fight the spread of STDs (incl. > HIV/AIDS). Is there a good way to map that in OSM? > > I suggest `free:condoms=yes/no`, since it's descriptive, matches the > `sells:X=yes/no` scheme. And the `vending:X=yes/no` scheme. > `vending:condoms=yes/no` has 17 uses, but `vending=condoms` has 1800 > uses. "vending" implies a _machine_. But what I imagine is a place with > a pile of free condoms ready to take. Either bars, or sexual health > clinics might have this. > > `free=condoms` doesn't read as obvious as `Free Condoms? Yes!" > (`free:condoms=yes`). A tagging scheme which data consumers can easy > "deduce" when a human reads the text is a good tagging scheme IMO. > > There is `medical_service:condom_distribution=yes/no` with 94 uses, > which reads too medical. A nighclub with a bowl of free condoms doesn't > seem like a "medical service", and doesn't sound like a "distribution > centre". > > Clearly if the `free:condoms` tag is missing, you should presume it's > the same a `free:condoms=no`. > > Any feedback? Thoughts? (Hopes? Fears? Dreams? 🙂) > > > -- > Rory > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Florimond Berthoux ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Tag:amenity=motorcycle_taxi
Hi, I'm always suspicious about tags with underscore in it, because they often mix different features together. My examples are parking, bicycle_parking, motorcycle_parking. In Paris there are parking shared between bicycle and motorcycle, and parking shared between bicycle and dock less vehicles (scooters). Creating a new key for each combination would be awful. So I prefer to split the amenity "you can pay someone there to have a ride" and what kind of vehicles you can find there. That could looks like this: amenity=taxi taxi:motorcycle=yes taxi:car=yes taxi:tricycle=yes ... (or other more British words ;) Le jeu. 20 févr. 2020 à 08:50, Joseph Eisenberg a écrit : > I would like to formally request comments on the proposal for > amenity=motorcycle_taxi: > > "A place where motorcycle taxis wait for passengers" > > > https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:amenity%3Dmotorcycle_taxi > > In many countries, motorcycles for hire are much more common than > automobile taxis. > > In these places, motorcycle drivers wait at stands, often with a small > shelter, and they can be hired to take one or more passengers to > various destinations. A fare is paid for a one-way trip. The passenger > usually rides behind the driver. In some countries two or even three > passengers can be carried on one motorcycle "taxi". > > Motorcycle taxis are also known as "motos" or "bike taxi", or by other > local names, such as "ojek" here in Indonesia and in Singapore, > "boda-boda" in Uganda, and "okada" in Nigeria. > > While some have proposed using amenity=taxi plus additional tags for > motorcycle taxi stands, this is quite confusing for travelers who > generally expect a "taxi" to be 4-wheeled motorcar capable of carrying > 4 people and luggage. So a different tag is proposed to avoid > confusion and more precisely tag these features. > > - Joseph Eisenberg > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Florimond Berthoux ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Unremovable bollards
So I guess you'll be against mapping roads also ? 1.35 millions deaths, that something to consider https://en.wikipedia.org/wiki/List_of_countries_by_traffic-related_death_rate Le dim. 16 févr. 2020 à 22:52, Warin <61sundow...@gmail.com> a écrit : > On 16/2/20 10:29 pm, Florimond Berthoux wrote: > > Hi, > > Checking https://taginfo.openstreetmap.org/keys/bollard#values > unremovable is already used a lot, though irremovable is used also but > four times less. So I guess you can document the value. > (And no tag doesn't mean unremovable of course.) > > I would like to add that there's a common type in Paris "Potelet sécable" > breakable bollard which are designed to break in two piece if pushed too > much. [1] <http://urbaco.be/pdf/fprod/FP-BOBSEC(V1-FR).pdf> > Only a small piece break, so they can be repaired quickly and for not much > money. > They are used a lot when firemen should be able to go with their trucks on > an pedestrian area. > > No sure if those breakable bollards should be tag as bollard=unremovable > with subtag (unremovable=breakable) or directly bollard=breakable. > > > Umm... > > Bollards are there to protect people. With the present threats I would > think identifying which bollards could be easily driven through on a public > map/data base would be a bad idea. > > > So I would be firmly against the idea of the subtag value '=breakable'. > -- Florimond Berthoux ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Unremovable bollards
Hi, Checking https://taginfo.openstreetmap.org/keys/bollard#values unremovable is already used a lot, though irremovable is used also but four times less. So I guess you can document the value. (And no tag doesn't mean unremovable of course.) I would like to add that there's a common type in Paris "Potelet sécable" breakable bollard which are designed to break in two piece if pushed too much. [1] <http://urbaco.be/pdf/fprod/FP-BOBSEC(V1-FR).pdf> Only a small piece break, so they can be repaired quickly and for not much money. They are used a lot when firemen should be able to go with their trucks on an pedestrian area. No sure if those breakable bollards should be tag as bollard=unremovable with subtag (unremovable=breakable) or directly bollard=breakable. [1] http://urbaco.be/pdf/fprod/FP-BOBSEC(V1-FR).pdf <http://urbaco.be/pdf/fprod/FP-BOBSEC(V1-FR).pdf> Le sam. 15 févr. 2020 à 19:54, Hauke Stieler a écrit : > Hi all, > > there's the "bollard" key with documented value "rising" and "removable" > [0] but I often encounter also bollards which cannot be removed easily. > I would love to see the "unremovable" value in the documentation. Should > I open a proposal page for this one value? That sounds a bit of an > overkill to me. > > My suggestion is the value "unremovable": > A bollard which cannot be removed without destroying it or at least > cause severe damage to it. A bollard which can only be removed by > authorized people with some sort of key is still "removable". > > I would not use the value "fixed" or "irremovable" for two reasons: The > "unremovable" value is used more often [1] and would be a good > counter-value for "removable". > > Hauke > > [0] https://wiki.openstreetmap.org/wiki/Key:bollard > [1] https://taginfo.openstreetmap.org/keys/?key=bollard#values > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Florimond Berthoux ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] implied surface values?
Unpaved and paved values are valuable values. It is not possible to tag the word with precision, all values are imprecision of the real world. Just some are more precise than others. StreetComplete can have a quest for that, and there is a ticket about it https://github.com/westnordost/StreetComplete/issues/279 Le jeu. 13 févr. 2020 à 05:45, Sebastian Martin Dicke via Tagging < tagging@openstreetmap.org> a écrit : > That can be a problem. If I survey streets on ground it is problematic > if it is tagged in such way. Then I struggle with a map app that show me > the surface, but with no visible difference between a sett or similar > surface or just surface=paved. Additionally I use StreetComple to find > missing surfaces. Surfaces mapped in such way you use are not considered > as a missing surface. When are are more than just a few mapper in the > country, it is better to omit surfaces if you was not at the place to > find the right value. Some other mapper will do it later. But it is more > difficult to find places with need for a specific surface tag, if there > are already „raw“ values. Mapping works as team work, everybody do a > small part. You should just omit things if you can not be sure. > > Regards > > Sebastian > > On 12.02.20 13:29, Shawn K. Quinn wrote: > > The most I usually do without a survey is surface=paved or > surface=unpaved, with exceptions when I can see clearly what it is from > the satellite imagery (like surface=grass). > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Florimond Berthoux ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] implied surface values?
As a cyclist living in city with too many road with (bad) setts I’m happy to know when a road is asphalt or not. @Volker, wiki says that only trunk and motorway imply paved, check their pages. Though like I already said, implying tags is bad because it let data reader guess what you think is implying which differ from people and location. Guessing leads to errors, where as when there is tag the reality is stated. Le mer. 12 févr. 2020 à 12:53, ael a écrit : > On Wed, Feb 12, 2020 at 11:14:54AM +, Philip Barnes wrote: > > On Tuesday, 11 February 2020, Volker Schmidt wrote: > > > OK, you confirm that the "paved is implied" statement in the wiki page > is > > > to be read as "assuming we are in Germany ... paved is implied" and is > not > > > referring to some wiki page that I have not yet detected (that was my > > > question). > > > > > In the UK too paved is implied, I have never used paved. Surface tags > such as asphalt, setts, concrete add the detail of what sort of paved. > > +1. Some of the Amazon people do seem to be adding unnecessary and > unsurveyed surface=asphalt tags to many roads in the UK which I find > quite irritating. > > ael > > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Florimond Berthoux ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] highway=path for *all* mixed foot/bicycle highways?&In-Reply-To=<88cad950-d9cc-3c2e-9015-a54d7206a...@gmx.com>
That’s why we render surface quality tags (surface/tracktype/smoothness) in CyclOSM on every road. So the reader can know the real state without bad assumptions*, and choose if he prefer whoosh or plod depending of his ride style. https://www.cyclosm.org/#map=15/49.1637/2.6323/cyclosm *Though we render for the moment no surface tags as paved, but there is a ticket for that.. [/advertisement] Le mar. 11 févr. 2020 à 02:19, Andrew Davidson a écrit : > On 11/02/2020 1:40 am, Marc Gemis wrote: > > Curious to understand why this is a cycleway and not an asphalted path. > > > > When I look at it what I'm hearing is whoosh: > > https://www.openstreetmap.org/user/Richard/diary/20333 > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Florimond Berthoux ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] highway=path for *all* mixed foot/bicycle highways?&In-Reply-To=<88cad950-d9cc-3c2e-9015-a54d7206a...@gmx.com>
Hi, « Implied tag is the root of all evil » as a wise man once said. I begin to think that implied tag is bad, let the data consumer do that. As long as the data is not set I consider the data imprecise. For instance in France I will assume by default that every road is paved, but it doesn’t mean that every unpaved road are tagged properly... In France I tag cycleway when it’s a legal cycle path (square / round traffic sign, bicycle logo on the ground), footway where only pedestrian as the right to go there, and path when it’s unclear or mixed with proper access tags I don’t assume surface, though I try to tag every time when it’s not paved. (This discussion has the smell of tag to render (as the hedge area discussion) :() Le lun. 10 févr. 2020 à 09:49, AndreasTUHU a écrit : > I agree that 'surface' tag should be mandatory but in Hungary 54 percent > of the mixed foot-cycle-ways misses this tag. > Additionally, the 20 percent of foot-cycle-ways has no 'segregated' tag. > Not ideal conditions for converting mixed cycleways to path :) > I don’t understand, for me a mixed cycleway has no sense, if it’s mixed well it is a path segregated or not. > So in Hungary we will contiune to use the "cycleway scheme". > > Best regards, > András > > Volker Schmidt ezt írta (időpont: 2020. febr. 6., Cs, > 0:19): > >> Your first point is correct and it applies here in Italy as well. >> >> The default surface argument is weak. We do have unpaved official cycle >> and foot-cycle paths. >> The surface tag is mandatory in my view. >> The same applies to sidewalks and minor roads. >> >> And the "path" approach for foot-cycle-way is very frequent in some >> countries. So it's there. I would not deprecate other tagging practices >> though. >> >> _______ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Florimond Berthoux ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to tag an utilitarian fountain?
man_made=water_tap drinking_water=yes https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dwater_tap Though amenity=drinking_water is good enough as a generic tag that is useful when you don’t want to spend time in the wiki to find the precise set of tags. Le jeu. 6 févr. 2020 à 17:04, Paul Allen a écrit : > On Thu, 6 Feb 2020 at 15:50, European Water Project < > europeanwaterproj...@gmail.com> wrote: > > I also agree that removing amenity=drinking_water as a tag makes sense. >> The physical attributes of a node/way still exists - irrespective of >> whether the water is drinking quality. For example, a spring which has >> water polluted after a big storm, stays a spring. >> > > How are you going to handle an amenity=drinking_water that is a tap? It's > not > a fountain (ornamental or otherwise). It's not a spring. > > -- > Paul > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Florimond Berthoux ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] change bicycle_parking=floor to surface
The bicycle_parking key is used for lots of things... > > buildings/sheds > > stands/racks > > A very poor key! > > > I think the key should be replaced. > I agree that buildings/sheds should not be used for this key, since we cannot precise the type of "rack" inside the shed/building. building or indoor can be used to precise that feature. Otherwise the key should not be replaced, it's already widely used, and building/shed count only for 3% of them (5400 values). Only those two values can be depreciate. > Buildings and sheds already have a key building=* so those values can be > depreciated. > > > Stands/racks are all indications of how the bike is held while parked. > > bicycle_holding=stand/rack/bollard/post/* ? > > > Then the issue of securing the bicycle? > > bicycle_secure=lock,supervised,provided_lock,* > > > ??? > Useless I think, bicycle_parking is good enough for that. -- Florimond Berthoux ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] change bicycle_parking=floor to surface
Hi, I think it's not exactly the same feature, one thing interesting in the bicycle_parking for cyclist it to know if you can secure your bike. With floor value I know there is nothing to lock my bike with. Whereas surface value for parking tag just say that is a parking facility on the ground (not underground or in a multi-storey). For instance you can have a bicycle_parking=floor in a parking facility parking=multi-storey. Though I don't know the best english word for this feature, as long as it's documented it's fine for me. Le ven. 31 janv. 2020 à 07:46, John Willis via Tagging < tagging@openstreetmap.org> a écrit : > https://wiki.openstreetmap.org/wiki/Key:bicycle_parking > > It lists “floor” as the value for a wide open outdoor space with no stands > or other affordances designated for parking bicycles. > > this seems weird to me. the ground / asphalt area next to a supermarket is > not a “floor”. > > we use “surface” in car parking lots, and there are many of other types of > indoor tags for tagging when a bike is in a building or shed (similar to > parking=multilevel). > > I think that the values be standardized and the wiki changed. > > there is 60 uses of (undocumented) =surface and ~260 uses of (documented) > =floor. > > we should standardize how we tag parking lots for any vehicle if it is > just a flat outdoor surface. > > Javbw > > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Florimond Berthoux ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Continuous Sidewalk or Cycleway
We do now: Le sam. 25 janv. 2020 à 23:51, Volker Schmidt a écrit : > Florimond, > > already in your otherwise interesting map that you presented in > Heidelberg, you do not consider all categories: > 1) sidewalk > (cycleway on a sidewalk ? there is no specified tag for that afaik) 2) cycleway > -> blue 3) combined foot-cycleway (as sidewalk) > -> light blue 4) segregated foot-cycleway (as sidewalk; with separate lanes for > pedestrians and bicycles) > -> blue + one outline in green > Volker > check https://www.cyclosm.org -- Florimond Berthoux ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Continuous Sidewalk or Cycleway
No, I'm not talking about cycling on a sidewalk (I don't know why you thought that ??), I discuss continuous sidewalk and continuous cycleway together because it's the same layout, the same problem. And I'm doing that because I'm interesting in cycling infrastructure more than others. For instance this is a typical dutch continuous sidewalk/cycleway https://www.mapillary.com/app/?lat=52.3608851685737&lng=4.867902368825185&z=17&pKey=ru8z7_PBx5Ao2LU6TX2XfQ&focus=photo&x=0.4098509000113021&y=0.620642840587665&zoom=0 Anyhow I updated the page https://wiki.openstreetmap.org/wiki/Continuous_Sidewalk continuous_sidewalk/continuous_cycleway=yes/no are now tags, so no more collision and can be used on the junction node or on the way. Le sam. 25 janv. 2020 à 18:36, Peter Elderson a écrit : > Ah, I see. You are talking about cycling on the sidewalk. Indeed, very > unusual in Nederland. To me it's strange to tag continuous_sidewalk mainly > for cycling. > > You talk of junction=continuous_sidewalk, I see no reason to even consider > that. > If you have a cycleway, footway or footcycleway around a roundabout, it > still has crossings with the roads.which can and often will differ, so IMO > the crossing nodes would carry the attributes. > > Well, I have given my thoughts, good luck with the proposal! > > Best, Peter Elderson > -- Florimond Berthoux ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Continuous Sidewalk or Cycleway
Le sam. 25 janv. 2020 à 15:19, Peter Elderson a écrit : > Florimond Berthoux : > >> With a table the pedestrians have to cross the road, it is the opposite >> for the continuous sidewalk that's why I'm in favor to add a new value >> > traffic_calming=continuous_sidewalk >> > > Well, any crossing involves different ways crossing each other, and should > be considered from all angles involved. A way can't cross another way > without being crossed itself. > Crossing key is defined as such «This tag is used for more accurately describing specific types of pedestrian crossings across roads» Continuous sidewalk is a sidewalk, so pedestrian don't cross a road but a sidewalk, so crossing key cannot be applied. > Give ways: >> If there is traffic sign or painting you can add a give way tag. >> If there is none, you cannot add a give way, or you would interpret the >> law which is not on the ground. >> >> Crossing: >> I thought of using crossing key but there are issues: >> - the tag is only for pedestrians crossing the road, where as a >> continuous sidewalk is a sidewalk cross by cars (though we could change the >> definition of crossing to embrace more situations) >> > > I would not even consider that a change: as said above, a way can't cross > another way without being crossed by the other way. > > >> - continuous cycleways exist too (and it’s the main reason I’d like to >> tag them) >> > > In Nederland, cycleways tend to be continuous by design, but that does not > imply anything. All the regular traffic rules apply. Only continuous > pedestrian surface (including elevation, pavement, lining) is significant. > It is in effect a pedestrian area or living street, where other traffic is > tolerated but has no rights. Also, traffic coming from an area like that > has no priority whatsoever. Movements of vehicles on the pavement are > considered "special manoeuvres" and the driver has to give way to all > others. > Yes in Netherland you don't know what crossing a kurb every 50m on bicycle means, but there is a difference of having the cycleway going down to join the level of the road and crossing it than having the cycleway staying higher than the road on a cycleway. not continuous : https://www.mapillary.com/app/?lat=52.10055&lng=5.0864573&z=18.24231017301564&pKey=ZoLEx4v54zKtpXwEAiT_nw&focus=photo 5m further continuous : https://www.mapillary.com/app/?lat=52.1002844&lng=5.0863681&z=18.24231017301564&pKey=_hSpfQK3eiU4HbKEEFePIw&focus=photo - it collides with continuous sidewalk, you may have continuous sidewalk >> and a crossing, it’s not a normal case but I have at least one example in >> Paris where zebras were added on a continuous sidewalk, hence the need for >> another tag. >> > > This would just be extra lining to emphasize priority for pedestrians. It > looks like a zebra but It would still be a "continuous_sidewalk" crossing. > Calling it a zebra crossing while it is continuous sidewalk would send the > wrong message. > No, I want to tag both features, I not here to interpret the world, the law or else, I just want to say there is a continuous sidewalk with zebra on it. > For the moment my concern is about would it be possible to have tag >> collision with junction. >> And I just realize that a cycleway can be a junction=roundabout, and >> being continuous at the intersection with roads in and out of the >> roundabout. >> > > That is very common around here for cycleways around a roundabout, but it > doesn't mean anything unless traffic signs (stop signs, give_way signs or > shark's teeth) are present. Pedestrian roundabouts, .i.e. continous sidwalk > around a roundabout, I have never seen that, but if present, it would imply > absolute priority for pedestrians and nothing for cyclists! > > >> So I guess we have to create a key. >> >> > I don't see how that follows from your arguments! > A node on the way where it crosses the middle line of the continuous > pavement (whether drawn as a way or not) tagged with either > traffic_calming=continous_sidewalk or crossing=continuous_sidewalk) covers > all cases mentioned, I think. Just an extra value. > > I think that would be enough for basic rendering, routing and > traffic-oriented maps. > You'll not be able to tag a roundabout on the ways of a cycleway (junction=roundabout) and tag on the way of the continuous cycleway (junction=continuous_sidewalk) since it already have junction=roundabout, two feature on the same tag -> collision. -- Florimond Berthoux ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Continuous Sidewalk or Cycleway
What are the features of a continuous sidewalk ? The main feature is to have a... continuous sidewalk, which means the layout of the sidewalk is the same before, at the junction and after. If you look only at the sidewalk you would not see any difference in surface or height. (At least for the perfect case.) A continuous sidewalk is more comfort and secure for pedestrians (and cyclists) since there is no kurbs to cross and cars have to go slower. And bind with that you can have legal implications like right of way for pedestrian, give way for car going on the main road, etc. The law cannot be tagged since it's not on the ground, but the layout of a continuous sidewalk can be. Besides that, In the point of view of a car drivers you have (most of the time) a traffic calming it's almost like a table, though the ramp can vary a lot from only a small kerb here http://www.gablenberger-klaus.de/wp-content/uploads/2014/08/K-Spielstra%C3%9Fe-1.jpg to a real ramp https://www.mapillary.com/app/?focus=photo&pKey=vrI5-QaNkUDqSw5uaCWXKA&lat=53.07202360058028&lng=8.790521908123765&z=17&x=0.5058547386437018&y=0.589992689065802&zoom=0 So traffic calming is not always the case. With a table the pedestrians have to cross the road, it is the opposite for the continuous sidewalk that's why I'm in favor to add a new value traffic_calming=continuous_sidewalk Give ways: If there is traffic sign or painting you can add a give way tag. If there is none, you cannot add a give way, or you would interpret the law which is not on the ground. Crossing: I thought of using crossing key but there are issues: - the tag is only for pedestrians crossing the road, where as a continuous sidewalk is a sidewalk cross by cars (though we could change the definition of crossing to embrace more situations) - continuous cycleways exist too (and it’s the main reason I’d like to tag them) - it collides with continuous sidewalk, you may have continuous sidewalk and a crossing, it’s not a normal case but I have at least one example in Paris where zebras were added on a continuous sidewalk, hence the need for another tag. For the moment my concern is about would it be possible to have tag collision with junction. And I just realize that a cycleway can be a junction=roundabout, and being continuous at the intersection with roads in and out of the roundabout. So I guess we have to create a key. Le ven. 24 janv. 2020 à 10:48, Marc Gemis a écrit : > I made a quick sketch: > > https://photos.smugmug.com/OSM/Screenshots/Screenshots-1/i-w92ZnDZ/0/90e60837/X4/Bezuidenhoutseweg%20-%20Google%20Maps-X4.png > Of course, this info is then only available for the cars following the > blue road. Cycling navigation along de Bezuidenhoutseweg will not be > able to take this info into account. If you want that, you will have > to draw the cycleway as a separate OSM way. > > On Fri, Jan 24, 2020 at 10:37 AM Marc Gemis wrote: > > > > Add a node where the way, which represents the road for the cars, > > crosses the cycleway. There does not have to be a way representing the > > cycleway. We do the same for zebra crossings for pedestrians all the > > time. We add the node where the path that the pedestrians have to > > follow crosses the road for the cars. > > > > regards > > > > m. > > > > On Fri, Jan 24, 2020 at 7:49 AM Peter Elderson > wrote: > > > > > > Op vr 24 jan. 2020 om 07:38 schreef Marc Gemis : > > >> > > >> could this be solved with highway=crossing and a new, dedicated value > > >> for crossing? > > >> And you could map the kerbs before and after that crossing. > > > > > > > > > (How) would this work where sidewalks are not mapped as separate ways > but with sidewalk=yes? > > > > > > Best, Peter Elderson > > > ___ > > > Tagging mailing list > > > Tagging@openstreetmap.org > > > https://lists.openstreetmap.org/listinfo/tagging > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Florimond Berthoux ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Continuous Sidewalk or Cycleway
Hello, How to map a continuous sidewalk or cycleway ? In order to solve this question I created a wiki page to sum up my first try to tag this: https://wiki.openstreetmap.org/wiki/Continuous_Sidewalk The main idea is to use the tag: junction=continuous_sidewalk|continuous_cycleway on node or ways of a feature. Helpful comments are welcome. -- Florimond Berthoux ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] RFC free_water
Well, if the ice cream parlour sells only bottle water it should be tagged drinking_water:fee=yes if the ice cream parlour gives free tap water and sell bottle water it should be tagged drinking_water:fee=no Giving free bottle water is rare, the only common case I see is hotel for their customers, so most people with drinking_water:fee=yes would not expect free bottle water. I think fee should have the value for the lowest fee of a service. Fee apply to a service if I believe the Cambridge dictionary https://dictionary.cambridge.org/dictionary/english/fee «an amount of money paid for a particular piece of work or for a particular right or service» I consider bottle water more like a product than a service, where as drinking water is more like a service. Le mar. 21 janv. 2020 à 11:21, European Water Project < europeanwaterproj...@gmail.com> a écrit : > > Hi Martin, > > haha .. https://moneyinc.com/10-expensive-bottled-waters-world/ > > Acqua di Cristallo Tributo a Modigliani > > A $60,000 750 ml bottle of world no comment. > > There are plenty of restaurants and cafés which don't sell water to non-customers. > > I just don't believe there is an equivalency between > > - free and NOT (fee) ; and > - NOT (free) and fee. > > Best regards, > > Stuart > > On Tue, 21 Jan 2020 at 11:06, Martin Koppenhoefer wrote: >> >> >> >> sent from a phone >> >> > On 21. Jan 2020, at 10:22, European Water Project < europeanwaterproj...@gmail.com> wrote: >> > >> > If a cafe is tagged "drinking_water:fee=yes", it could lead people erroneously to believe that the tagged cafe sells water ? >> >> >> I’ve yet to see a cafe that doesn’t sell water. >> >> Btw, I guess you are less interested in tagging luxury water? I’ve once seen a tourist aiming shop in Berlin that sold japanese (IIRR) bottled water for something like 5 Euros half a liter (takeaway, not a cafe). >> >> Cheers Martin >> >> >> ___ >> Tagging mailing list >> Tagging@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/tagging > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging -- Florimond Berthoux ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] RFC free_water
Le lun. 20 janv. 2020 à 16:16, European Water Project a écrit : > > Dear Florimond, > > What seems preferable about drinking_water:free= is that > it is a tag that offers a complete response . > > drinking_water:fee, necessitates a follow up qualification. If no, then for > whom if not for everyone ? If yes, then how much and is it the same fee for > customers and non-customers alike? No, for me these tags are equal drinking_water:free=no <=> drinking_water:fee=yes drinking_water:free=yes <=> drinking_water:fee=no drinking_water:free=customers <=> drinking_water:fee=free_for_customers -- Florimond Berthoux ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] RFC free_water
Le sam. 18 janv. 2020 à 18:37, European Water Project a écrit : > drinking_water:fee=yes/no > drinking_water:fee:conditional="no @ customers" alternavite: > drinking_water:fee:customers=no > I can see how this works from a logic point of view, but still seems a bit > convoluted > > I still prefer this because in one tag, we get almost everything. I do > realize there is some inconsistency with this tag name. > drinking_water:free= Ok, I understand, if we look at https://taginfo.openstreetmap.org/keys/fee#values other values exist like unknown, donation or even time table. There also some tags meaning "free for customers" but different syntax, it's little messy, so maybe we should normalize that with drinking_water:fee=free_for_customers ? (There is also drinking_water:fee=customers but I don't understand what it can means, only customers have to pay ? that's weird.) The problem I have with drinking_water:free is that free is not a tag currently, and it would be an alias for drinking_water:fee with opposite value. > I even think that drinking_water:free = yes might be a sufficient tag for all > cafes, bars, clubs and restaurants willing to participate in the refill > revolution. And that the bottle precision might only be necessary for those > refusing bottles and insisting on serving a glass of water. I agree. -- Florimond Berthoux ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] RFC free_water
Hi, I added my proposal: drinking_water:fee=yes/no drinking_water:fee:conditional="no @ customers" alternavite: drinking_water:fee:customers=no drinking_water:bottle=yes/no I think that the key bottle=* can fit your needs to know if you can refill you bottle easily or not. https://wiki.openstreetmap.org/wiki/Key:bottle I suffix it by drinking_water because bottle alone would look like a lost tag in a cafe/restaurant tag table. Regards. Le sam. 18 janv. 2020 à 07:50, European Water Project < europeanwaterproj...@gmail.com> a écrit : >> >> >>2. Re: RFC free_water (Joseph Eisenberg) > > >>> Joseph, I have just turned off the digest feature ... so hopefully this will be the last of this wacky system which has been driving me crazy. > > I have just added a top section to the discussion page for : > https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Free_Water > > I propose that everyone contribute in this section without verbage or rationale an elegant and complete solution which solves the below. > 1. Is there free drinking water available ? > 2. For whom is it free ? if it is the case that there is free water available > 3. If it is free for everyone, can you bring your own container ?. (bottle) > > My current preferred solution which is now on the top of the discussion page is : > drinking_water:free = > drinking_water:free:container = > > After making a proposal, it would seem to make sense to explain why they believe their set of tags is the best. > > I hope this can help expedite the process. > > Best regards, > > Stuart -- Florimond Berthoux ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging Free Water for cafés, bars, restaurant
Le mer. 15 janv. 2020 à 23:47, Joseph Eisenberg a écrit : > > Thank you for pointing out the tag "drinking_water=yes/no" > > Looking at the wiki page for this tag and for the related tag > amenity=drinking_water, it is strongly implied that this is for a > drinking water supply which is self-service. > > Examples include water taps, drinking fountains, wells, and springs. > Features where this is commonly used include camping and wilderness > accomodations. This is how you read the pages, for me it’s free to use it everywhere just to tag if drinking water is available or not. Of course default tags can be assumed, drinking_water on an amenity=toilets is probably free. > So it may be reasonable to have a different tag for the situation > where the drinking water is only available by requesting it from the > employees of a business. self_service key https://wiki.openstreetmap.org/wiki/Key:self_service can be used for this like: drinking_water:self_service=yes/no/... > I note that "drinking_water:fee" is not mentioned at > "Key:drinking_water" or "Tag:amenity=drinking_water" pages, and it has > only been used 7 times. As long as you know tags fee and drinking_water, and the meaning of the token ’:’ (A:B -> B of A), new tags can be created easily and be understood by every one without new page to write. As we are talking about drinking water in a Cafe/Pub/Bar drinking_water can be optional though we can use drinking_water:fee. drinking_water in a cafe can be assumed to not be self_service by default. -- Florimond Berthoux ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging Free Water for cafés, bars, restaurant
Because https://wiki.openstreetmap.org/wiki/Any_tags_you_like Tags are already defined and used. free_water would be in conflict with tags fee and drinking_water. free_water is two words with two concepts (price and service) drinking_water:fee use the usual main:sub_propertie tagging pattern I have no opinion about container, but I can remember an old discussion about tagging the property of street food shop where you are able to bring you own "container" (food box). In my pattern it would be drinking_water:container=* Le mer. 15 janv. 2020 à 22:09, European Water Project < europeanwaterproj...@gmail.com> a écrit : >> >> 5. Re: Tagging Free Water for cafés, bars, restaurant >> (Florimond Berthoux) >> >>>> Hello Florimond, While I don't necessarily feel the solution you propose is preferable, I do share your love of KISS though. > > > I have tried to fairly incorporate the main feedback from the tagging maillist discussion. > https://wiki.openstreetmap.org/wiki/Proposed_features/Free_Water > > Why do you think your proposal is preferred to the one outlined in the draft proposal ? > free_water = > free_water:container = > > Best regards, > > Stuart > > > - >> >> >> Message: 5 >> Date: Wed, 15 Jan 2020 20:25:53 +0100 >> From: Florimond Berthoux >> To: "Tag discussion, strategy and related tools" >> >> Subject: Re: [Tagging] Tagging Free Water for cafés, bars, >> restaurant >> Message-ID: >> >> Content-Type: text/plain; charset="utf-8" >> >> Hi, I go quickly through the email thread and didn't saw the simple >> solution: >> >> use drinking_water >> https://wiki.openstreetmap.org/wiki/Key:drinking_water >> «drinking_water=* indicates whether a feature provides drinking water, >> specifically whether water is drinkable for humans. » >> So if a cafe provide the service of supplying drinking water, I would use >> the usual access values with this key >> drinking_water=yes/no/private/... >> >> and use fee >> https://wiki.openstreetmap.org/wiki/Key:fee >> «The fee tag is for specifying whether a fee is usually charged for a >> service, or for access. » >> the service here is the drinking water so >> drinking_water:fee=yes/no >> And if more precision is needed use drinking_water:fee:conditional=* >> >> Of course most of the cafe give drinking water (though may be not >> completely drinkable...) so drinking_water can be optional here. >> >> No new tag is needed here, KISS ;) >> >> Le lun. 13 janv. 2020 à 10:20, European Water Project < >> europeanwaterproj...@gmail.com> a écrit : >> >> > Dear All, >> > >> > I thought this subject could wait, but it is becoming pressing early than >> > I expected. >> > >> > As part of our project (and that of similar non-profits - most of which >> > are not open data but nevertheless great organisations), we want to >> > voluntarily encourage cafés, bars and restaurants to offer free tap water >> > bottle refill to anyone off the street. Refill has had significant success >> > in the UK and surprising the feedback is that the impact of increased >> > customer traffic far outweighs any issue of cannibalization. >> > >> > If it is not already the case, could we develop a tagging standard for >> > this case. Maybe "amenity = cafe & free_water = yes" >> > >> > It would be important to develop at the same time a distinct tag for >> > another cause, which we support but will not be targeting is restaurants >> > which offer free tap water for paying customers. >> > Maybe "amenity = restuarant & free_carafe = yes" >> > >> > Many thanks, >> > >> > Stuart >> > >> > PS : >> > >> > The European Water Project progressive web app powered by OpenStreetMap, >> > Wikidata and Wikimedia Commons data can be found : >> > https://europeanwaterproject.org >> > >> > >> > >> >> >> >> -- >> Florimond Berthoux >> > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging -- Florimond Berthoux ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging Free Water for cafés, bars, restaurant
Hi, I go quickly through the email thread and didn't saw the simple solution: use drinking_water https://wiki.openstreetmap.org/wiki/Key:drinking_water «drinking_water=* indicates whether a feature provides drinking water, specifically whether water is drinkable for humans. » So if a cafe provide the service of supplying drinking water, I would use the usual access values with this key drinking_water=yes/no/private/... and use fee https://wiki.openstreetmap.org/wiki/Key:fee «The fee tag is for specifying whether a fee is usually charged for a service, or for access. » the service here is the drinking water so drinking_water:fee=yes/no And if more precision is needed use drinking_water:fee:conditional=* Of course most of the cafe give drinking water (though may be not completely drinkable...) so drinking_water can be optional here. No new tag is needed here, KISS ;) Le lun. 13 janv. 2020 à 10:20, European Water Project < europeanwaterproj...@gmail.com> a écrit : > Dear All, > > I thought this subject could wait, but it is becoming pressing early than > I expected. > > As part of our project (and that of similar non-profits - most of which > are not open data but nevertheless great organisations), we want to > voluntarily encourage cafés, bars and restaurants to offer free tap water > bottle refill to anyone off the street. Refill has had significant success > in the UK and surprising the feedback is that the impact of increased > customer traffic far outweighs any issue of cannibalization. > > If it is not already the case, could we develop a tagging standard for > this case. Maybe "amenity = cafe & free_water = yes" > > It would be important to develop at the same time a distinct tag for > another cause, which we support but will not be targeting is restaurants > which offer free tap water for paying customers. > Maybe "amenity = restuarant & free_carafe = yes" > > Many thanks, > > Stuart > > PS : > > The European Water Project progressive web app powered by OpenStreetMap, > Wikidata and Wikimedia Commons data can be found : > https://europeanwaterproject.org > > > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Florimond Berthoux ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] recreational vs functional routes
Beside my proposal for bicycle subtype route, I read again the tourism wiki page https://wiki.openstreetmap.org/wiki/Key:tourism « Places and things of specific interest to tourists including places to see, places to stay, things and places providing information and support to tourists. » and « tourism=yes : To add tourist interest to something described by other tags. » So, if a route is a thing of specific interest to tourist, I see no good reason to not tag it with tourism=yes. (And I don't understand why it shouldn't be used on relation since here it's the route relation which is touristic.) Le mar. 7 janv. 2020 à 20:24, joost schouppe a écrit : > Hi, > > Has there been any previous discussion regarding tagging recreational > versus functional routes? > > Especially for car routes, I haven't seen any way to tag touristic routes > for driving cars, like the Turist Veger in Norway or the Route des Cols in > France. It is also of specific interest for cycling. For example, in > Belgium we have a very dense "node network" for cycling for fun, but those > routes aren't exactly interesting for commuting. On the other hand, we have > "cycle highways" which can be boring and focus on actually getting > somewhere. > > In the case of cars, the lack of clarity prevents mapping. In the case of > cycling, it would be really useful for routers to be able to differentiate. > > Similar differences might exist for bus (fpr example for hop-on/hop-off > tourist buses in cities) and maybe even for walking. > > I think maybe another optional tag for route relations might be useful, > perhaps just function=recreational/practical or something. > > -- > Joost Schouppe > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Florimond Berthoux ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] recreational vs functional routes
Asking me how do I know that Eurovelo 3 is for tourism or bicycle trekking is like asking me how do I know that Paris is the capital of France. « Is there a sign saying that Paris is the capital of France? May be we should remove that tag, don't you think?... » You don't need sign post to have a route, do you have a sign post at the intersection of those routes ? https://www.openstreetmap.org/#map=12/45.1485/-4.1705 I doubt that. This is how the Wiki define a route: « A *route* is a customary or regular line of passage or travel, often predetermined and publicized. Routes consist of paths taken repeatedly by people and vehicles: a ship on the North Atlantic route, a car on a numbered road, a bus on its route or a cyclist on a national route. » https://wiki.openstreetmap.org/wiki/Relation:route So to paraphrase this for road biking route : « A road bicycle *route* is a customary or regular line of passage or travel, often predetermined and publicized as such. Road bicycle routes consist of paths taken repeatedly by road cyclist. » And if you don't know then don't tag it and don't manage it. Le sam. 11 janv. 2020 à 23:35, Joseph Eisenberg a écrit : > > > I am not against distinguishing more types of cycling routes, I am all for it, as long as it's verifyable, mappable with clear tagging, and manageable. > > +1 > > I started using Openstreetmap because I wanted to add touring routes > and recreational bike routes in RideWithGPS and then found out that > http://ridewithgps.com uses Openstreetmap data which I could edit. And > I get to work and take kids to school and shop by bike - I haven't > owned a car for 9 years. > > So I would love to have more information about what streets and roads > are best for getting from point A to B, and which ones are nice for > training rides and which ones are fun for tours. > > But tags have to be verifiable: if the next mapper can't confirm that > a tag as right, the data in Openstreetmap will not be maintained > properly. Subjective tags cannot work. > > I have seen this happen: before I mapped here, I used to try to > improve the bike routes in Portland Oregon for Google Maps. But since > there was no definition of a "preferred" bicycle street, and it was > hard to delete a preferred route once it was added, the bike layer was > full of disconnected segments. Some were from old city maps of bike > routes, some were based on the personal preference of the mapper, and > some were actually signed or marked on the ground, but you couldn't > tell them apart. > > If there is a sign or marking that specifies that a certain route is > designed for mountain bikes or for bike racing, then sure, you can tag > that. But most bike routes do not have anything to specify that they > are more for commuting or more for recreation, and in that case we > can't tag the distinction. > > Fortunately, database users (like routing applications) can look at > other Openstreetmap data, like surface=* tags on ways, and external > data like elevation models, to determine if a route is a difficult > single-track trail through the hills versus a flat paved path along a > canal, and use this to help route cyclists appropriately. > > - Joseph Eisenberg -- Florimond Berthoux ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] recreational vs functional routes
Le sam. 11 janv. 2020 à 22:22, Peter Elderson a écrit : > > Florimond Berthoux : >> >> So I propose to use for bicycle route >> bicycle:type=trekking/road_bike/commute/mtb >> > > I don't think commute is a type of bicycle? Trekking maybe, but here in Nederland they call a lot of bicycles "trekking" when they are really just city bikes with a few extra gears and some fancy accessories. > We also don't have a type "road bike". We do have "Omafiets" (Grandmother's bike), mainly used by schoolgirls and young women. Grandmothers have e-bikes, nowadays. bicycle:type describe the type of cycle activity of the route not precisely the type of the bicycle. (Though commuter bike is a type of bicycle and you have road biking in Netherland https://en.wikipedia.org/wiki/Dutch_National_Road_Race_Championships). So values should be (if my english is right): bicycle:type=trekking/road_biking/commuting/mtb -- Florimond Berthoux ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] recreational vs functional routes
Le sam. 11 janv. 2020 à 21:20, marc marc a écrit : > > Le 11.01.20 à 21:05, Florimond Berthoux a écrit : > > What do you think ? > > avoid the word "type" in a key as it as no additional meaning. > type can be everything (type of operator, difficulty, use, length, ...) That's why I use bicycle:type, so it means the type of cycling the route is used for. -- Florimond Berthoux ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] recreational vs functional routes
I found that this problem has a solution for relation route=piste (snow sports) with the key piste:type=* https://wiki.openstreetmap.org/wiki/Key:piste:type Three of you have proposed to use like for piste relation a single new key to precise the subtype of the a route Joost Schouppe with: function=recreational/practical Marc Marc with: usage=tourism/transport Richard with: route_type=* I proposed multi-tags like tourism/commute/road_bike/mtb=yes, though I'm not confident with this scheme. Tags can conflict with already defined tags (tourism), or a vehicle type which could misinterpret as access tags (road_bike and mtb). So I propose to use for bicycle route bicycle:type=trekking/road_bike/commute/mtb That can be distinguish by looking at the signposts, or board, or the kind of people (or their bike) who use the route. If necessary semicolon can be used to for multiple bicycle:type though I guess that'd be rare. For other relations I don't know, I don't map or use them much. However I guess that road relation can have a road:type=* tag also. What do you think ? -- Florimond Berthoux ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] recreational vs functional routes
Le jeu. 9 janv. 2020 à 22:05, Peter Elderson a écrit : > > Florimond Berthoux het volgende geschreven: > > Ok, you need examples : > this Eurovelo 3 is for tourism > https://www.openstreetmap.org/relation/9351172#map=12/48.8454/2.4130&layers=C > this REVe Nord-Sud is for commute/every day cycling > https://www.openstreetmap.org/relation/8664006#map=14/48.8784/2.3599&layers=C > as you can see in this video https://youtu.be/1dGtSZbUKew > and this is for road cycling > https://www.openstreetmap.org/relation/163270#map=15/48.8577/2.2333&layers=C > as you can see in this video https://www.youtube.com/watch?v=VLwNlVjTOKU > > > I can't see the signposting of the routes in the videos, I assume because I > don't know where to look? You don't need signpost to have a route. The topic is not how to map that, but how can I tag more precisely the purpose of a cycle route. -- Florimond Berthoux ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] recreational vs functional routes
Ok, you need examples : this Eurovelo 3 is for tourism https://www.openstreetmap.org/relation/9351172#map=12/48.8454/2.4130&layers=C this REVe Nord-Sud is for commute/every day cycling https://www.openstreetmap.org/relation/8664006#map=14/48.8784/2.3599&layers=C as you can see in this video https://youtu.be/1dGtSZbUKew and this is for road cycling https://www.openstreetmap.org/relation/163270#map=15/48.8577/2.2333&layers=C as you can see in this video https://www.youtube.com/watch?v=VLwNlVjTOKU mtb:scale / surfaces tags are for ways not relation. Of course nobody will blame you if you use a touristic route for commuting, and adding a tag tourism=yes doesn’t imply it can’t be used by every day cyclists. What the point? If you are a commuter you’ll focus on fast and safe route, so you’ll prefer REVe Nord-Sud than Eurovelo 3 at this place https://www.cyclosm.org/#map=18/48.86796/2.35391/cyclosm For instance, this information can be used for rendering map (like CyclOSM on which I work) or routers (a tourist profile routing will prefer tourism route). Le jeu. 9 janv. 2020 à 16:10, Peter Elderson a écrit : > waymarked mtb routes are tagged route=mtb on the relation > waymarked cycling routes are tagged route=bicycle on the relation. > > I don't know how I could verify that a cycling route is either touristic > or for commute/everyday cycling or both. Even if advertised as touristic it > can be used for commute/everyday cycling, ande the other way around. > I do not foresee significant mapping of these purposes. > > Best, Peter Elderson > > > Op do 9 jan. 2020 om 15:08 schreef Martin Koppenhoefer < > dieterdre...@gmail.com>: > >> Am Do., 9. Jan. 2020 um 10:41 Uhr schrieb Florimond Berthoux < >> florimond.berth...@gmail.com>: >> >>> tourism=yes : if the cycle route is a touristic purpose route >>> commute=yes : if it's a route for commute and every day cycling >>> >> >> >> where do you get this information from? Is it verifiable? >> >> >> >>> road_bike=yes : if it's a route to do road biking sport >>> mtb=yes : if it's a cycle route mtb oriented >>> >> >> >> to some extent the mtb=yes tag this is already covered (in greater >> detail) by presence of mtb:scale tags >> maybe it could be extended for road_bike as well (e.g. mtb:scale=-1). >> Also smoothness could help. >> >> https://wiki.openstreetmap.org/wiki/Key:mtb:scale >> https://wiki.openstreetmap.org/wiki/Mountain_biking >> https://wiki.openstreetmap.org/wiki/Key:smoothness >> >> Cheers >> Martin >> >> >> _______ >> Tagging mailing list >> Tagging@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/tagging >> > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Florimond Berthoux ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] recreational vs functional routes
Hi, I would like also to be able to map four kind of cycle routes : touristic, commuting, road bike, mountain bike (mtb). Today we can map mtb and general cycling route (most of them are touristic though not limited to them). But unfortunately mtb and cycling routes are split in two kinds of routes. I'd prefer to have cycle route for every kind of cycling and precise the type by an other tag (with the possibility to set multiple kind of cycle route for the same relation). So what I’m thinking is to add tags to cycle route relation in order to precise there use https://wiki.openstreetmap.org/wiki/Cycle_routes#Relations tourism=yes : if the cycle route is a touristic purpose route commute=yes : if it's a route for commute and every day cycling road_bike=yes : if it's a route to do road biking sport mtb=yes : if it's a cycle route mtb oriented And for general route (and car routes) I’d say that type=road relation is what you need https://wiki.openstreetmap.org/wiki/Tag:route%3Droad (By the way the Route des Grandes Alpes in France is also a cycle route https://fr.wikipedia.org/wiki/Route_des_Grandes_Alpes ) Le mar. 7 janv. 2020 à 20:24, joost schouppe a écrit : > > Hi, > > Has there been any previous discussion regarding tagging recreational versus functional routes? > > Especially for car routes, I haven't seen any way to tag touristic routes for driving cars, like the Turist Veger in Norway or the Route des Cols in France. It is also of specific interest for cycling. For example, in Belgium we have a very dense "node network" for cycling for fun, but those routes aren't exactly interesting for commuting. On the other hand, we have "cycle highways" which can be boring and focus on actually getting somewhere. > > In the case of cars, the lack of clarity prevents mapping. In the case of cycling, it would be really useful for routers to be able to differentiate. > > Similar differences might exist for bus (fpr example for hop-on/hop-off tourist buses in cities) and maybe even for walking. > > I think maybe another optional tag for route relations might be useful, perhaps just function=recreational/practical or something. > > -- > Joost Schouppe -- Florimond Berthoux ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] amenity=tourist_bus_parking
Sorry I don't understand the point of the questions. Legally a cargo bike is a bicycle (or a tricycle which is the same) in France. But road laws (Code de la route) only apply on roads open to public traffic in France so the diversity can be wider than the law. And we don't tag the law in OSM. Le lun. 6 janv. 2020 à 00:05, Martin Koppenhoefer a écrit : > > On 5. Jan 2020, at 23:22, Volker Schmidt wrote: > > > > x=designated means access only for x and and there is a sign, ore something > > equivalent, stating this > > x=designated AND y=designated means access only for x and for y and there > > is a sign, ore something equivalent, stating this > > > sure, the reason why I was asking these questions is that people told me that > cargo bike wasn’t a defined vehicle class in the French jurisdiction. > If you see a sign motor_vehicle=designated you know that a motorcycle and a > motorcar are both permitted on the way. > IIRR the thread about cargo bicycle parking went dead without providing > answers about implications or legalities, that’s why I was asking again. > > Cheers Martin -- Florimond Berthoux ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Cycle boxes for two-stage left turns
Hello, I think it’s a good thing to map these two stage turn for bicycles. I can’t see better solution than using relation (unless doing surface mapping...). Le lun. 6 janv. 2020 à 04:21, Jarek Piórkowski a écrit : > - relation with tag type=bicycle_two_stage_turn (comments on this > particularly welcome! it doesn't really seem to be a route=bicycle > since it doesn't have a designated network=*?) If we copy what we have in France for give way for cyclist at traffic light https://wiki.openstreetmap.org/wiki/FR:Bicycle#Panonceaux_de_C.C3.A9dez-le-passage_cycliste_au_feu type=restriction restriction:bicycle=two_stage_turn And the relation have three members with from, via, to. > - optionally segregated=yes if there is a designated, separated > waiting area for the bikes rather than only a painted area that is > also driven over by other vehicles (would usually be at particularly > wide intersections or at T-intersections) I disagree, today the use of segregated key is for path where the segregation is made from painting line. https://wiki.openstreetmap.org/wiki/Key:segregated If we use the key segrageted for physically segragation by kerb or island that can lead easily to mistakes. May be use waiting_area=painting_box if there is only painting, and waiting_area=track ? island ? if it is physically protected. I think it can be interessting to know if the two stage turn is mandatory or not for the cyclist, I’m not talking about national law here but only if there is a traffic sign saying this obligation. mandatory=yes ? -- Florimond Berthoux ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] amenity=tourist_bus_parking
Le dim. 5 janv. 2020 à 18:41, Martin Koppenhoefer a écrit : > > is “designated” implying that other vehicles cannot (legally or physically?) > use the parking, or that there are specific measures so that the designated > vehicles fit perfectly into the fixtures? No, that would depend on the other access keys, I think the wiki is clear https://wiki.openstreetmap.org/wiki/Tag:access%3Ddesignated "The value designated is not meant to imply that OpenStreetMap access=* permissions have been automatically "designated" only to that transport mode!" -- Florimond Berthoux ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] amenity=tourist_bus_parking
Hi, Real case in Paris, we have : bicycle parking, motorcycle parking, bicycle-motorcycle parking mixed, free floating (dock less) scooter-bicycle parking, and cargo bike parking. How can I map that with only motorcycle_parking and bicycle_parking tags ??? I can't properly. Using access tags is the good way to go, so we can use [vehicle]=yes/no/designated. Designated is to explicitly say that the place is specifically made for them. In the point of view of a data consumer, adding tags just for each (sub) use case is a maintenance nightmare, and most will not update there software for each case. If you render a map for instance, the first step would be to render every parking area the same way, then may be you'd go into detail and render each type of them. Le sam. 4 janv. 2020 à 22:12, Volker Schmidt a écrit : > > I have just detected the wiki page "amenity=tourist_bus_parking" > It has so far only 16 uses (including one by myself a few minutes ago) > I am not happy with this new tag. Agreed, we have the tags > amenity=bicycle_parking and amenity=motorcycle_parking, but they have been > with OSM for years, whereas the tourist_bus parking is new (from Feb 2019) > and has so far very few uses. > > My feeling is that we should not add more humanities along that line, like > RV_parking, hgv_parking, snowmobile_parking, cargo_bike_parking and so on, > but try to think,of something better. > In particular I would like some tagging scheme that allows you to identify a > parking facility, and within that same facility (which carries the name) the > parking sub-facilities for cars, buses, HGVs, motorcycles, ...That would > make more sense.The parking I have just inserted has two separate areas and > separate entrances for cars and tourist buses, but it has only one name. > Another frequent situation are motorway stations where parking is usually > split into cars, busses, and HGVs. > Hopefully it's just my ignorance and someone else has already implemented the > prefect tagging scheme somewhere. > > Volker > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging -- Florimond Berthoux ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] What access key for cargo bike ?
Well, I don’t know what the french law say, but that’s not an issue, we don’t tag the law ;) I’m really here just to know the english word. In France we also say "vélo cargo" (cargo bike), so I’d go for cargo_bike if none disapprove. Le ven. 20 déc. 2019 à 10:42, Martin Koppenhoefer a écrit : > > > > sent from a phone > > On 20. Dec 2019, at 09:42, Volker Schmidt wrote: > > Just for information the size limits for bicycles in Italy (from Polizia di > Stato): > > > > in other words the Italian law doesn’t distinguish between cargo bikes and > other bikes. What about France? > > Cheers Martin > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging -- Florimond Berthoux ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] What access key for cargo bike ?
Hello, What's the english word for this kind of bicycle https://en.wikipedia.org/wiki/Freight_bicycle ? It's to tag the access to this new kind of bicycle parking designed for cargo bikes in Paris https://framapic.org/w4zmjIvtoxim/1qsfbMKa1iVI.jpg I'd like to have the word for all the kinds of those bicycle type not just a part of them. Taginfo doesn't help me here. Tags would be : amenity=bicycle_parking [english for freight bicycle]=designated The access key could be use also for other features like ramp, barrier, elevator... -- Florimond Berthoux ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
