Re: [Tagging] No U turn restriction in a roundabout

On 16.01.2018 22:39, OSMDoudou wrote: Hello, I was fixing incorrect restrictions tagging in the area, when I noticed restriction=no_u_turn on the highway segments forming the roundabout (not talking about the junctions with the roundabout, but really the roundabout itself). [1] Indeed the

Re: [Tagging] Short-term parking zones

+1 for a separate group On 16 January 2018 at 23:03, Kevin Kenny wrote: > On Tue, Jan 16, 2018 at 3:58 PM, Tod Fitch wrote: > >> On Jan 16, 2018, at 9:43 AM, Paul Johnson wrote: >> On Jan 16, 2018 05:36, "Stefan Nagy"

Re: [Tagging] Short-term parking zones

On Tue, Jan 16, 2018 at 3:58 PM, Tod Fitch wrote: > On Jan 16, 2018, at 9:43 AM, Paul Johnson wrote: > On Jan 16, 2018 05:36, "Stefan Nagy" wrote: > > Am 16.01.2018 12:10 schrieb marc marc: > >> we probably need to work on

[Tagging] No U turn restriction in a roundabout

Hello, I was fixing incorrect restrictions tagging in the area, when I noticed restriction=no_u_turn on the highway segments forming the roundabout (not talking about the junctions with the roundabout, but really the roundabout itself). [1] I find strange to tag the segments of the

Re: [Tagging] Sidewalks and cycleways as tags vs as extra lines

For simplicity, I think it should be no big problem changing the wiki to suggest using cycleway=separate, instead of suggesting not adding the cycleway=* tag. On Tue, Jan 16, 2018 at 11:00 AM, Andy Townsend wrote: > On 16/01/2018 10:17, "Christian Müller" wrote: >> >> But a

Re: [Tagging] Short-term parking zones

> On Jan 16, 2018, at 9:43 AM, Paul Johnson wrote: > > > > On Jan 16, 2018 05:36, "Stefan Nagy" > wrote: > Am 16.01.2018 12:10 schrieb marc marc: > we probably need to work on "default values". > but no one seems

Re: [Tagging] Sidewalks and cycleways as tags vs as extra lines and StreetComplete

Second paragraph here: https://wiki.openstreetmap.org/wiki/Key:cycleway#Cycle_tracks On Tue, Jan 16, 2018 at 10:39 AM, Dave F wrote: > > On 15/01/2018 14:47, Fernando Trebien wrote: >> >> The wiki also says that, when mapping a parallel cycleway as a >> parallel

Re: [Tagging] Short-term parking zones

On Jan 16, 2018 05:36, "Stefan Nagy" wrote: Am 16.01.2018 12:10 schrieb marc marc: > we probably need to work on "default values". > but no one seems motivated to work on the proposal. > Is 'default values' a better word for what I called 'implicit values' before or are

Re: [Tagging] Sidewalks and cycleways as tags vs as extra lines

> Gesendet: Dienstag, 16. Januar 2018 um 15:55 Uhr > Von: "Marc Gemis" > An: "Tag discussion, strategy and related tools" > Betreff: Re: [Tagging] Sidewalks and cycleways as tags vs as extra lines > > adding e.g. surface=paving_stones to the

Re: [Tagging] Sidewalks and cycleways as tags vs as extra lines

> Gesendet: Dienstag, 16. Januar 2018 um 14:50 Uhr > Von: "Mateusz Konieczny" > An: "Christian Müller" > Cc: tagging@openstreetmap.org > Betreff: Re: [Tagging] Sidewalks and cycleways as tags vs as extra lines > > Also, I am curious whatever you think that it

Re: [Tagging] Sidewalks and cycleways as tags vs as extra lines

adding e.g. surface=paving_stones to the cycleway and cycleway=paving_stones to the main road is tagging the same feature twice, not ? On Tue, Jan 16, 2018 at 3:26 PM, "Christian Müller" wrote: >> Gesendet: Dienstag, 16. Januar 2018 um 14:10 Uhr >> Von: "Marc Gemis"

Re: [Tagging] Sidewalks and cycleways as tags vs as extra lines

> Gesendet: Dienstag, 16. Januar 2018 um 14:24 Uhr > Von: "Volker Schmidt" > An: "Tag discussion, strategy and related tools" > Betreff: Re: [Tagging] Sidewalks and cycleways as tags vs as extra lines > > Filtering out separate cycleways that

Re: [Tagging] Sidewalks and cycleways as tags vs as extra lines

> Gesendet: Dienstag, 16. Januar 2018 um 14:10 Uhr > Von: "Marc Gemis" > An: "Tag discussion, strategy and related tools" > Betreff: Re: [Tagging] Sidewalks and cycleways as tags vs as extra lines > > There is a rule One Feature, One Object in

Re: [Tagging] Sidewalks and cycleways as tags vs as extra lines

> Gesendet: Dienstag, 16. Januar 2018 um 14:50 Uhr > Von: "Mateusz Konieczny" > An: "Christian Müller" > Cc: tagging@openstreetmap.org > Betreff: Re: [Tagging] Sidewalks and cycleways as tags vs as extra lines > > On Tue, 16 Jan 2018 14:32:27 +0100 >

Re: [Tagging] Sidewalks and cycleways as tags vs as extra lines

> Gesendet: Dienstag, 16. Januar 2018 um 14:00 Uhr > Von: "Andy Townsend" > An: tagging@openstreetmap.org > Betreff: Re: [Tagging] Sidewalks and cycleways as tags vs as extra lines > > "replacing" sidewalk=* with e.g. sidewalk:left=* is not a good idea > since there are

[Tagging] Surface value for irregular, flat stones with variable gaps

"So it would be "jointed large rounded natural stones cut to a flat top"? Smoothness similar to setts, but appearance similar to cobblestones? Also, [1] describes some pavements as "Cobbles chosen for flat upper surface" which is possibly not the same as being cut, but possibly what is meant by

Re: [Tagging] Sidewalks and cycleways as tags vs as extra lines

On Tue, 16 Jan 2018 14:32:27 +0100 "Christian Müller" wrote: > No, cycleway=opposite is actually harder to use. Without the wiki > documentation noone knows what this actually means, it is not self- > explanatory. And cycleway:left=opposite is? > Besides, using a value

Re: [Tagging] Sidewalks and cycleways as tags vs as extra lines

On 16/01/2018 13:10, Marc Gemis wrote: I would love to have this confirmed by the makers of e.g. navigation software. It is not clear to me whether you are a data consumer that has this problem or whether you think they might have a problem. From the perspective of someone consuming the data

Re: [Tagging] Sidewalks and cycleways as tags vs as extra lines

> Gesendet: Dienstag, 16. Januar 2018 um 13:06 Uhr > Von: "Mateusz Konieczny" > An: "Christian Müller" > Cc: tagging@openstreetmap.org > Betreff: Re: [Tagging] Sidewalks and cycleways as tags vs as extra lines > > On Tue, 16 Jan 2018 11:17:31 +0100 >

Re: [Tagging] Sidewalks and cycleways as tags vs as extra lines

Filtering out separate cycleways that accompany roads would be plain wrong. A bicycle router should get me on cycleway (and off the road). Double tagging, i.e. cycleway=track on the road plus a separate parallel highway=cycleway is only undesirable. I remove the redundant cycleway=track when I

[Tagging] Surface value for irregular, flat stones with variable gaps

Hi. "I think this cobblestone:flattened can be a good value" In my opinion no. Because it does not create a regular shape in any way. surface=cobblestone/cobblestone:flattened was roads created from local rough stones(left by the glacier) stones are rounded by nature(smoothed by glaciers) just

Re: [Tagging] Sidewalks and cycleways as tags vs as extra lines

> > This is indeed problematic. A lot of use cases preprocess osm data and > filter out separate/parallel cycleways and paths. It would be nice to > have a compromise in the wiki as to suggest that a minimum of tags on > the motorized way should remain _even if_ a parallel way exists. I would

Re: [Tagging] Sidewalks and cycleways as tags vs as extra lines

On 16/01/2018 10:17, "Christian Müller" wrote: But a simple (read ideally one or two tags) attribute that enables data users to bisect a set of motorized ways by the sidewalk or sidepath property may simplify a lot of queries. sidewalk=separate is currently used a fair bit to indicate that

Re: [Tagging] Sidewalks and cycleways as tags vs as extra lines and StreetComplete

On 15/01/2018 14:47, Fernando Trebien wrote: The wiki also says that, when mapping a parallel cycleway as a parallel line, one should not use the cycleway=* tag on the motorised way For clarity, could you confirm which wiki page that is written. DaveF

Re: [Tagging] Surface value for irregular, flat stones with variable gaps

On Tue, Jan 16, 2018 at 8:44 AM, althio wrote: > Great post and superb reference site Fernando. Thanks! :D > I think this cobblestone:flattened can be a good value (not with the > current definition in the wiki, but with intended usage by mappers). > It would apply to

Re: [Tagging] Sidewalks and cycleways as tags vs as extra lines

On Tue, 16 Jan 2018 11:17:31 +0100 "Christian Müller" wrote: > cycleway=* and sidewalk=* should be marked deprecated/legacy, > in favor of the colon variants. I strongly disagree, cycleway=opposite is for example easier to use than cycleway:left=opposite that carries no useful

Re: [Tagging] Difference between lighthouses and beacons

On 16/01/2018 10:25, Andrew Davidson wrote: OK. So a lighthouse has to have a rotating light then? A lighthouse does not have any particular type of light, or any light at all, but it will have a lamp room at the top ___ Tagging mailing list

Re: [Tagging] Short-term parking zones

Am 16.01.2018 12:10 schrieb marc marc: we probably need to work on "default values". but no one seems motivated to work on the proposal. Is 'default values' a better word for what I called 'implicit values' before or are you talking about something else? -- E-Mails signieren & verschlüsseln

Re: [Tagging] Short-term parking zones

2018-01-14 16:01 GMT+01:00 Matej Lieskovský : > Upon further analysis of empty relations, I suspect they will be far more > problematic than I expected. While it is on the wiki since 2010 and feels > like a powerful tool, it does not seem to be used (let alone

Re: [Tagging] Short-term parking zones

we probably need to work on "default values". but no one seems motivated to work on the proposal. Le 16. 01. 18 à 11:52, Matej Lieskovský a écrit : > Ok, once again: I am sorry for even mentioning something that is > actually documented on the wiki. I've since then thought about the data >

Re: [Tagging] Short-term parking zones

Ok, once again: I am sorry for even mentioning something that is actually documented on the wiki. I've since then thought about the data model and I can see how problematic it would be. Can we please move on to finding a solution? On 16 January 2018 at 09:25, Simone Saviolo

Re: [Tagging] Surface value for irregular, flat stones with variable gaps

Great post and superb reference site Fernando. On 15 January 2018 at 20:45, Fernando Trebien wrote: > > To make differences more evident, I believe we could define in the wiki: > - pebblestone: loose small rounded natural stones > - cobblestone: jointed large rounded

Re: [Tagging] Difference between lighthouses and beacons

On 16/01/18 21:17, Martin Koppenhoefer wrote: can't see a lighthouse in your link. It's the really big building with the beam of light coming out of it--you can't miss it This is a photo of the Rome lighthouse (it is also called "lighthouse", and has a rotating light):

Re: [Tagging] Sidewalks and cycleways as tags vs as extra lines

> Gesendet: Montag, 15. Januar 2018 um 15:47 Uhr > Von: "Fernando Trebien" > An: "Tag discussion, strategy and related tools" > Betreff: [Tagging] Sidewalks and cycleways as tags vs as extra lines and > StreetComplete > > The wiki also says

Re: [Tagging] Difference between lighthouses and beacons

2018-01-16 11:04 GMT+01:00 Andrew Davidson : > > Oh my. Hope someone has mapped the lighthouse in Las Vegas ( > http://vegasvacationbids.com/luxorhotelatnight.jpg). can't see a lighthouse in your link. This is a photo of the Rome lighthouse (it is also called "lighthouse",

Re: [Tagging] Difference between lighthouses and beacons

On 16/01/18 20:32, Martin Koppenhoefer wrote: sure, for example here's a "famous" lighthouse in Rome, far from the sea: https://www.openstreetmap.org/node/249332339 Oh my. Hope someone has mapped the lighthouse in Las Vegas (http://vegasvacationbids.com/luxorhotelatnight.jpg).

Re: [Tagging] Difference between lighthouses and beacons

On 16/01/18 19:34, Malcolm Herring wrote: The main point that I was trying to make is that a simple pile or lattice tower with a light on top should not be tagged as man_made=lighthouse, but man_made=beacon. Not always. A lighthouse is a structure housing a major marine navigation light.

Re: [Tagging] Difference between lighthouses and beacons

2018-01-16 10:13 GMT+01:00 Malcolm Herring : > On 16/01/2018 08:43, Martin Koppenhoefer wrote: > >> probably with exceptions, e.g. this is a lighthouse from 1911 (i.e. >> historic) with a lattice structure, generally considered a lighthouse: >>

Re: [Tagging] Difference between lighthouses and beacons

On 16/01/2018 08:43, Martin Koppenhoefer wrote: probably with exceptions, e.g. this is a lighthouse from 1911 (i.e. historic) with a lattice structure, generally considered a lighthouse: https://en.wikipedia.org/wiki/Adziogol_Lighthouse I can see a house! To be clear, the OP asked what the

Re: [Tagging] Difference between lighthouses and beacons

2018-01-16 9:34 GMT+01:00 Malcolm Herring : > On 16/01/2018 00:21, Graeme Fitzpatrick wrote: > >> In what way would you consider that these are not lighthouse's? Just >> because they don't have accommodation? >> > > Point taken. I was referring to the historical

Re: [Tagging] Difference between lighthouses and beacons

On 16/01/2018 00:21, Graeme Fitzpatrick wrote: In what way would you consider that these are not lighthouse's? Just because they don't have accommodation? Point taken. I was referring to the historical structures rather than any modern replacements. The main point that I was trying to make

Re: [Tagging] Short-term parking zones

2018-01-15 11:07 GMT+01:00 Martin Koppenhoefer : > > On 14. Jan 2018, at 12:32, Matej Lieskovský > wrote: > > > > If you create a single empty relation with the details of the parking > zone rules, > > you can then tag every road with the id of

Re: [Tagging] Short-term parking zones

2018-01-14 15:05 GMT+01:00 Matej Lieskovský : > Citation provided: > https://wiki.openstreetmap.org/wiki/Relation#Size > https://wiki.openstreetmap.org/wiki/Relation:route#Size > > Notice that the border relation you linked is already version 790 (and > borders change

Re: [Tagging] Short-term parking zones

2018-01-14 12:32 GMT+01:00 Matej Lieskovský : > Greetings, > > if you group all the streets in a single relation, the relation is likely > to be rather big. > This can be hard on the server. > You're saying that having a relation with 1000 objects in it is "hard on