Re: [Tagging] Feature Proposal - RFC - Tag:traffic_calming=hillocky

2020-12-19 Thread Florimond Berthoux
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

2020-12-16 Thread Florimond Berthoux
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"?

2020-07-22 Thread Florimond Berthoux
’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?

2020-07-05 Thread Florimond Berthoux
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

2020-05-28 Thread Florimond Berthoux
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

2020-05-28 Thread Florimond Berthoux
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

2020-05-25 Thread Florimond Berthoux
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

2020-05-10 Thread Florimond Berthoux
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

2020-05-09 Thread Florimond Berthoux
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

2020-05-08 Thread Florimond Berthoux
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

2020-05-06 Thread Florimond Berthoux
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

2020-05-03 Thread Florimond Berthoux
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

2020-05-01 Thread Florimond Berthoux
+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

2020-04-21 Thread Florimond Berthoux
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=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

2020-04-20 Thread Florimond Berthoux
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=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?

2020-04-16 Thread Florimond Berthoux
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?

2020-04-06 Thread Florimond Berthoux
. 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?

2020-04-05 Thread Florimond Berthoux
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?

2020-04-04 Thread Florimond Berthoux
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?

2020-04-03 Thread Florimond Berthoux
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?

2020-04-02 Thread Florimond Berthoux
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

2020-02-21 Thread Florimond Berthoux
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".
> >>
> >> Motorcycl

Re: [Tagging] Tagging venues which give away free condoms?

2020-02-21 Thread Florimond Berthoux
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

2020-02-20 Thread Florimond Berthoux
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

2020-02-16 Thread Florimond Berthoux
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

2020-02-16 Thread Florimond Berthoux
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?

2020-02-13 Thread Florimond Berthoux
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?

2020-02-12 Thread Florimond Berthoux
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?=<88cad950-d9cc-3c2e-9015-a54d7206a...@gmx.com>

2020-02-11 Thread Florimond Berthoux
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?=<88cad950-d9cc-3c2e-9015-a54d7206a...@gmx.com>

2020-02-10 Thread Florimond Berthoux
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?

2020-02-06 Thread Florimond Berthoux
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

2020-02-03 Thread Florimond Berthoux
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

2020-02-01 Thread Florimond Berthoux
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

2020-01-28 Thread Florimond Berthoux
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

2020-01-25 Thread Florimond Berthoux
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=4.867902368825185=17=ru8z7_PBx5Ao2LU6TX2XfQ=photo=0.4098509000113021=0.620642840587665=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

2020-01-25 Thread Florimond Berthoux
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=5.0864573=18.24231017301564=ZoLEx4v54zKtpXwEAiT_nw=photo
5m further continuous :
https://www.mapillary.com/app/?lat=52.1002844=5.0863681=18.24231017301564=_hSpfQK3eiU4HbKEEFePIw=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

2020-01-24 Thread Florimond Berthoux
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=vrI5-QaNkUDqSw5uaCWXKA=53.07202360058028=8.790521908123765=17=0.5058547386437018=0.589992689065802=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

2020-01-23 Thread Florimond Berthoux
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

2020-01-21 Thread Florimond Berthoux
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

2020-01-21 Thread Florimond Berthoux
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

2020-01-19 Thread Florimond Berthoux
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

2020-01-18 Thread Florimond Berthoux
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

2020-01-16 Thread Florimond Berthoux
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

2020-01-15 Thread Florimond Berthoux
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

2020-01-15 Thread Florimond Berthoux
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

2020-01-15 Thread Florimond Berthoux
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

2020-01-12 Thread Florimond Berthoux
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

2020-01-12 Thread Florimond Berthoux
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

2020-01-12 Thread Florimond Berthoux
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

2020-01-11 Thread Florimond Berthoux
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

2020-01-09 Thread Florimond Berthoux
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=C
> this REVe Nord-Sud is for commute/every day cycling 
> https://www.openstreetmap.org/relation/8664006#map=14/48.8784/2.3599=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=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

2020-01-09 Thread Florimond Berthoux
Ok, you need examples :
this Eurovelo 3 is for tourism
https://www.openstreetmap.org/relation/9351172#map=12/48.8454/2.4130=C
this REVe Nord-Sud is for commute/every day cycling
https://www.openstreetmap.org/relation/8664006#map=14/48.8784/2.3599=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=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

2020-01-09 Thread Florimond Berthoux
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

2020-01-07 Thread Florimond Berthoux
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

2020-01-07 Thread Florimond Berthoux
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

2020-01-05 Thread Florimond Berthoux
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

2020-01-05 Thread Florimond Berthoux
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 ?

2019-12-20 Thread Florimond Berthoux
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 ?

2019-12-19 Thread Florimond Berthoux
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