I have previously proposed the tag path=mtb
https://wiki.openstreetmap.org/wiki/Proposal:Tag:path%3Dmtb as a way to say
it's a purpose built mountain biking track (which if it has features like
jumps, skinnies, berms etc would make it such). Unfortunately the proposal
could not gain a consistent
On Fri, 14 Apr 2023 at 08:17, Graeme Fitzpatrick
wrote:
> On Thu, 13 Apr 2023 at 20:48, Greg Troxel wrote:
>
>> (admin_level 4/6/8, normally).
>>
>
> Would it work to add the admin_level= to the road to say which level of
> Government owns it?
>
> Then I would think that a search should be
)
On Thu, 23 Feb 2023 at 11:16, Andrew Harvey
wrote:
>
>>1. As far as non-emergency routing, the "locked" tag should be
>>ignored.
>>
>> As Andy points out you may have legal access but the gate is still locked
> preventing physical access. Therefore
>
>
>1. As far as non-emergency routing, the "locked" tag should be ignored.
>
> As Andy points out you may have legal access but the gate is still locked
preventing physical access. Therefore routers shouldn't just ignore the
fact that the gate is locked, they should either avoid the route or
led as a way only. Also, it
> assumes that every waterfall has a plunge pool - I'm not sure that's the
> case.
>
> On Thu, Dec 24, 2020, 12:25 AM Andrew Harvey
> wrote:
>
>> Mind you, you do need any of these tags to determine that. You can
>> automatically measure
> small pool with a waterfall".
>
> On Thu, Dec 24, 2020, 12:10 AM Andrew Harvey
> wrote:
>
>>
>>
>> On Thu, 24 Dec 2020 at 10:26, Paul Allen wrote:
>>
>>>
>>> Isn't that a plunge pool? https://en.wikipedia.org/wiki/Plunge_po
don't intend to address river tagging as part of the reservoir/lake/pond
> proposal[1]. Therefore, what makes the most sense is to simply scrub
> mention of pools and rivers from the proposal and leave it squarely focused
> on reservoirs, lakes, and ponds.
>
Yeah that sounds good, a
On Tue, 22 Dec 2020 at 22:34, Martin Koppenhoefer
wrote:
> > On 22. Dec 2020, at 06:49, Andrew Harvey
> wrote:
> > water=stream_pool
>
> isn’t this an oxymoron?
>
How so? It's a body of water so therefore water=*. It's usually a pool of
water along a stream, so the n
On Tue, 22 Dec 2020 at 19:15, Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:
>
>
>
> Dec 22, 2020, 00:42 by graemefi...@gmail.com:
>
>
>
> On Mon, 21 Dec 2020 at 23:24, Mateusz Konieczny via Tagging <
> tagging@openstreetmap.org> wrote:
>
> Dec 20, 2020, 23:29 by
Per the Proposal Process at
https://wiki.openstreetmap.org/wiki/Proposal_process#Voting it's normal to
send a new email with the subject like "Feature Proposal - Voting -
(Feature Name)" to the list.
Many people might not be reading every email in the RFC thread, but do want
to know when voting
Looks good to me.
Personally I'd usually try to add the operator and operator:wikidata tags
in combination to give more context.
On Wed, 16 Dec 2020 at 13:47, Graeme Fitzpatrick
wrote:
>
> On Sun, 6 Dec 2020 at 12:18, Graeme Fitzpatrick
> wrote:
>
>> Please visit
On Tue, 1 Dec 2020 at 09:23, Graeme Fitzpatrick
wrote:
> On Mon, 30 Nov 2020 at 23:29, Mateusz Konieczny via Tagging <
> tagging@openstreetmap.org> wrote:
>
>> I run into https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dcoast_guard
>> and despite that I have basically zero experience with such
Boardwalk isn't really a good surface value as boardwalks can be made up of
a variety of materials not only wood.
We do have bridge=boardwalk but that always feels award when
the boardwalk is only elevating 10cm off the ground.
On Sun, 22 Nov 2020 at 10:22, Mateusz Konieczny via Tagging <
The way I understood the tagging guidelines was that if there was nobody
parked there, could you drive along the lane as usual. If you can't then I
wouldn't include it as lanes=* and only tag it as parking:lane. If you can
drive along it when vacant, but you can still legally park there then I'd
The documented tag for that is place=locality, an in populated named place.
it's rendered and in Nomatnium.
On Sat, 7 Nov 2020, 12:44 pm Martin Søndergaard,
wrote:
> I am also very much a newcomer only having mapped for a few months, and
> so far I have constantly been running into the same
All great points there, I've ran into many of those myself. If you're
interested in helping work on solutions to these, discussion here is
probably the best place to start, once ideas gain some momentum you can
start a tagging proposal
https://wiki.openstreetmap.org/wiki/Proposal_process. Going
try to avoid it, you can naturally simply duplicate the
> geometry (and you don't even need to duplicate the nodes to do that).
> Am 04.11.2020 um 22:26 schrieb Andrew Harvey:
>
>
> On Wed, 4 Nov 2020 at 20:10, Philip Barnes wrote:
>
>> On Wed, 2020-11-04 at 07:26
On Wed, 4 Nov 2020 at 20:10, Philip Barnes wrote:
> On Wed, 2020-11-04 at 07:26 +1100, Andrew Harvey wrote:
>
>
>
> On Tue, 3 Nov 2020 at 23:14, Simon Poole wrote:
>
> We don't seem to have a tagging currently for dedicated pickup locations
> in this kind of context, bus
On Tue, 3 Nov 2020 at 23:14, Simon Poole wrote:
> We don't seem to have a tagging currently for dedicated pickup locations
> in this kind of context, bus stops etc are naturally taggable), if
> considered really useful I don't see why we couldn't introduce a
> amenity=...pickup... tag.
>
But if
On Wed, 4 Nov 2020 at 00:13, Lukas Richert wrote:
> Hi,
>
> While the original proposal did specify that generators are usually
> diesel, broadening the definition would only lead to a loss of detail, but
> the tagging would still be correct. I'm hesitant to use *offgrid* as a
> building that
On Sat, 31 Oct 2020 at 08:42, Steve Doerr wrote:
> On 29/10/2020 16:50, Lukas Richert wrote:
> > as I've received no further comments to the proposal and all points
> > brought up should be resolved,
> > https://wiki.openstreetmap.org/wiki/Proposed_features/electricity is
> > open for voting
Agree with Jan here, I didn't see the RFC either, but looking now I feel
there are still things which need discussing before voting.
In general I agree with the idea, but I don't feel like the issues at
https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/electricity are
resolved yet so
On Wed, 28 Oct 2020 at 13:20, Jonathon Rossi wrote:
> We've got emergency=landing_site for helicopters, maybe just
> emergency=parking?
>
I like that, areas set aside for parking by emergency vehicles.
___
Tagging mailing list
I've drafted a proposal for natural=rock_overhang at
https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:natural%3Drock_overhang
please
provide any feedback or suggestions.
On Mon, 26 Oct 2020 at 15:10, Andrew Harvey
wrote:
> Voting is closed now with 8 yes, 8 no, 2 abstain. no cl
.
On Mon, 12 Oct 2020 at 10:34, Andrew Harvey
wrote:
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:shelter_type%3Drock_shelter
> is
> open for voting now.
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.op
Hi Tan,
Just wanted to say thank you for all your work on the takeaway drinks
proposal. I know it takes a lot of effort putting together a detailed
proposal and addressing feedback. Personally I think it was a great
proposal which would have improved the OSM ecosystem, so quite
disappointed it
On Wed, 21 Oct 2020 at 20:20, Philip Barnes wrote:
> On Wed, 2020-10-21 at 20:04 +1100, Andrew Harvey wrote:
>
>
>
> On Wed, 21 Oct 2020 at 19:45, Robert Delmenico wrote:
>
> Ballarat in Victoria has kerb side parking where the first hour is free.
>
> There is some
On Wed, 21 Oct 2020 at 19:32, stevea wrote:
> In California, a common (not quite frequent, certainly not always)
> arrangement at malls, supermarkets and other places with parking lots
> (large and small) is a sign that reads "you can park here for three hours,
> but after that we have the right
On Wed, 21 Oct 2020 at 19:45, Robert Delmenico wrote:
> Ballarat in Victoria has kerb side parking where the first hour is free.
>
> There is some more information available here:
>
>
>
I agree these are very common arrangements.
On Wed, 21 Oct 2020 at 07:46, Martin Koppenhoefer
wrote:
> I am not usually mapping this detail of parking fees, but from my
> understanding the above suggested tags would work and could be seen as
> covered by current state of tagging, no need for a
On Tue, 20 Oct 2020, 5:34 pm Robert Delmenico, wrote:
> They mean the same thing, we tag different aspects of a bridge with
> different tags.
>
Not quite if I want to count how many bridges there are you'd count
man_made=bridge. Counting bridge=yes would give you an overcount as it's
only road
When you say busway is that just a road that only busses are allowed to
use, and specifically signposted for busses? if so then the suggested you
noted of highway=* + bus=designated + access=no would be correct.
On Sun, 18 Oct 2020 at 17:12, Joseph Eisenberg
wrote:
> There is an approved tag
On Thu, 15 Oct 2020 at 23:44, Volker Schmidt wrote:
> May I remind my dear mapper friends, that tags are just that: tags. From
> the database point of view these are just couples of arbitrarily chosen,
> character strings. OSM uses a convention to make it easier to memorize
> these strings by
On Tue, 13 Oct 2020 at 10:29, Brian M. Sperlongano
wrote:
> With the exception of the "plurality votes wins" aspect of this, it
> strikes me that this can largely be done today. Someone could post a wiki
> page with multiple alternatives and ask the community to vote/comment on
> different
On Tue, 13 Oct 2020 at 09:36, Paul Allen wrote:
>
> On Mon, 12 Oct 2020 at 23:23, Andrew Harvey
> wrote:
>
>> I wrote about changing from a for/against vote to a pick your preferred
>> option at https://www.openstreetmap.org/user/aharvey/diary/394419
>>
>>
I wrote about changing from a for/against vote to a pick your preferred
option at https://www.openstreetmap.org/user/aharvey/diary/394419
Interested to hear what others think about this.
___
Tagging mailing list
Tagging@openstreetmap.org
https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:shelter_type%3Drock_shelter
is
open for voting now.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
On Sat, 10 Oct 2020 at 09:35, Dave F wrote:
> Apologies for breaking the thread, but I was unable to connect to
> Tagging & missed the initial message in my email client.
>
> I'm the user in disagreement. (Although reading the current
> railway=station wiki page I'm not convinced there's an
On Wed, 7 Oct 2020 at 18:42, Martin Koppenhoefer
wrote:
> I know we have already been discussing this several times in the past, but
> due to recent editing disagreements in the wiki, I am raising it again.
>
> For several years, we had railway=station on a way documented in the wiki
> as the
On Wed, 30 Sep 2020 at 18:58, stevea wrote:
> This is useful because it shows not only where OSM mappers (like me) will
> need to update landcover
>
At least after the Australian fires, we still left natural=wood areas which
burned tagged that way, and in my view this is correct since they are
So it seems then that what you're mapping here isn't so much the active
fire front, it's the burnt area given you want it to stick around after the
flames are out.
During Australia's fires last season, I did contemplate mapping active fire
fronts, given I could see with my own eyes where the
All good feedback so far, it's pleasing to see I'm not the only one
interested in tagging these features.
On Sat, 5 Sep 2020 at 11:38, Jmapb via Tagging
wrote:
> Assuming that I located the correct crack, it was undoubtedly a case of
> overzealous tagging. The problem I see is that the
On Sat, 5 Sep 2020 at 01:23, Mateusz Konieczny
wrote:
> "A cave you might need a torch to explore" - note that caves may be
> smaller.
>
> In fact, some cave classifications have separate categories for caves
> small enough/open enough to be fully lit by sun and at least some consider
> rock
I've created a proposal to formalise shelter_type=rock_shelter, while
currently in-use, there is disagreement within the community on if this tag
should be used and features are commonly mis-tagged.
So I'm hoping with this proposal and voting we can come to some
consensus around it's use.
I'll
On Tue, 25 Aug 2020 at 06:27, pangoSE wrote:
> The POI IMO cannot logically have an adress itself, its a human symbol for
> designating something of interest within a feature like a building, park or
> whatever. Adresses are specialized designations used by the state and
> postal service. You
gt;
>> On Mon, Aug 24, 2020 at 12:10 PM Andrew Harvey
>> wrote:
>>
>>> In OSMCha you can create a Filter, and in the Filter creation screen set
>>> a polygon area you're interested in monitoring
>>>
>>
>> Andrew, how do you specify a polygon, a
wrote:
> On Mon, Aug 24, 2020 at 2:22 PM Andrew Harvey
> wrote:
>
>> On Mon, 24 Aug 2020 at 14:05, Jonathon Rossi wrote:
>>
>>> On Mon, Aug 24, 2020 at 12:10 PM Andrew Harvey
>>> wrote:
>>>
>>>> In OSMCha you can create a Filter, and
On Mon, 24 Aug 2020 at 14:21, Andrew Harvey
wrote:
> I think OSMCha is really good, but it does have room for improvement. I
> get confused between saving a filter and applying the filter, and there is
> a bug which will show the polygon from the previously selected filter, it's
> ve
On Mon, 24 Aug 2020 at 14:05, Jonathon Rossi wrote:
> On Mon, Aug 24, 2020 at 12:10 PM Andrew Harvey
> wrote:
>
>> In OSMCha you can create a Filter, and in the Filter creation screen set
>> a polygon area you're interested in monitoring
>>
>
> Andrew, how
, Graeme Fitzpatrick
wrote:
>
>
>
> On Mon, 24 Aug 2020 at 12:11, Andrew Harvey
> wrote:
>
>>
>> In OSMCha you can mark as good or bad, but no way to say it's been
>> reviewed without explicitly saying good/bad.
>>
>
> Thanks, Andrew!
>
> If yo
On Sun, 23 Aug 2020 at 14:55, pangoSE wrote:
> And we have no statistics or functionality to mark a changeser as revieed
> so nobody knows how many reviews are done and how many falls through the
> cracks. We could make a tool that lists all changesets with a review
> request and no comments.
>
On Sun, 23 Aug 2020 at 15:44, Graeme Fitzpatrick
wrote:
>
>
>
> On Sun, 23 Aug 2020 at 08:13, Clifford Snow
> wrote:
>
>> osmcha.org picks up the review request. Their interface makes it easy to
>> view and post a comment back to the user.
>>
>
> Thanks!
>
> Not exactly a very user-friendly
On Sat, 22 Aug 2020 at 17:25, Thibault Molleman
wrote:
> So what's the consensus on an apartment building (way) that has mailboxes
> for each person who has an apartment there.
> I've just been tagging those as:
> addr:housenumber = A1;A2;A3;A4;A5;A6;A7;A8;A9;A10;A11
>
Could you use
>
>
> And it may be useful to have tag to mark "yes this is actually a single
> housenumber despite
> that includes hyphen or something else that suggests range"
>
I would assume that to be the default, when there are multiple addresses
best to mark them all out individually or use a linear way
On Wed, 19 Aug 2020 at 04:26, Colin Smale wrote:
> There are two use cases here: one is "what is the address of this building
> (or whatever)" and the other is the reverse situation: "where can I find
> number XXX". As long as we have tagging that is potentially ambiguous we
> won't be able to
On Tue, 18 Aug 2020 at 19:15, Simon Poole wrote:
> The correct ways to model a range of house numbers is to use an address
> interpolation or explicitly list the numbers (using comma or semi-colons as
> delimitiers), anything else is woefully underspecified, not to mention
> other issues, for
> Data consumers see these hyphenated house numbers as one address, as well.
Is that a problem? An address range can be considered a single address.
> Create an address node for each housenumber and place each node somewhere
on the building outline (or inside the building)
I don't think that's
I'd suggest that if you vote no, it will be helpful for the community if
you could elaborate on why you're voting no, without enforcing a reason as
mandatory. Is it because this feature shouldn't be mapped, is it because
there is an alternative tag. So if the vote fails all this feedback can be
While you're talking about the destination tag, I think when using a
destination_sign relation it's best to apply the mode as eg.
bicycle=designated, eg
https://www.openstreetmap.org/relation/11345354#map=18/-33.82573/151.21308
for https://www.mapillary.com/map/im/VIq-OPTiw0BVI7gqdLR-iA
On Fri,
On Mon, 29 Jun 2020 at 22:21, Paul Allen wrote:
> Why cuisine=* rather than drink:*=yes for chocolate drinks? I consider
> cuisine
> to apply to food, not beverages. Soup and ice cream are edge cases, but
> chocolate
> drinks don't count as food as far as I'm concerned.
>
Sorry I wasn't aware
On Mon, 29 Jun 2020 at 21:17, Martin Koppenhoefer
wrote:
> > On 29. Jun 2020, at 12:18, Andrew Harvey
> wrote:
> >
> > I think it's better to have some kind of high level tag like
> amenity=drinks or shop=drinks which you order at a counter (as opposed to
> shop=bev
The way I see it these are essentially vendors which primarily sell made to
order drinks and mostly take away only (although some provide seating).
I think it's better to have some kind of high level tag like amenity=drinks
or shop=drinks which you order at a counter (as opposed to shop=beverages
It's a tricky one, but whatever is done I would need re-checking frequently
to know when it was cleared.
You could just add a single barrier=log somewhere as a rough approximation,
or add barrier=log to the way segment which is affected.
https://wiki.openstreetmap.org/wiki/Tag:barrier=log says it
Here in Australia they started off as rough areas based on local knowledge
and signage on the ground but now have mostly been replaced with imported
open data from the government.These legally declared boundaries are usually
declared based on parcels from the cadastre and so the open data usually
If the way is used by "law enforcement, emergency, and maintenance staff"
motor vehicles then I'd tag it highway=track and if it's designated for
walking then foot=designated + motor_vehicle=private, since it's wide
enough and occasionally used by vehicles, even for a path that is mostly
used for
I think the wiki already does a good job at communicating this.
iD already goes a step too far calling these "unmaintained track roads" but
if anything that would have prevented people tagging as highway=track just
because it is maintained, so not a factor in this case.
I think the default
On Wed, 27 May 2020 at 17:15, Daniel Westergren wrote:
> Yeah, the main problem is that a path can be anything and everything can
> be a path.
>
> I mostly use JOSM and prefer presets to remember to tag all relevant
> attributes. That means that a combined foot- and cycleway becomes a path...
>
On Tue, 26 May 2020 at 19:35, Volker Schmidt wrote:
> We have now been reviving the path discussion in 73 messages, and counting
> ...
> I still feel we are not understanding each other (or is it only me who is
> lost?)
>
To me a highway=path is a concept that is well defined in the wiki, and
On Tue, 26 May 2020 at 17:28, Arne Johannessen wrote:
> Kevin Kenny wrote:
> >
> > I took the liberty of revising the English translation in
> > https://wiki.openstreetmap.org/wiki/Key:sac_scale#Values to something
> > that I hope will be more helpful to English speakers.
>
> Overall, this
On Mon, 25 May 2020 at 19:44, John Willis via Tagging <
tagging@openstreetmap.org> wrote:
>
>
> Javbw
>
> On May 25, 2020, at 1:28 PM, Andrew Harvey
> wrote:
>
> We do have that: `sac_scale=hiking`
>
>
> And that is a good example of bad tagging I wan
a 'this is
> dangerous' assertion.
>
> Incomplete information should 'fail soft'.
>
> On Sun, May 24, 2020 at 8:32 PM Andrew Harvey
> wrote:
>
> > Agreed, the biggest question is how do you define that criteria for what
> is going to be tagged a a hiking trail and not a
On Mon, 25 May 2020 at 00:31, Daniel Westergren wrote:
> Well said John. When we now have highway=path, we need a subtag.
>
> Question is, on what criteria would we differentiate a trail from another
> "path"? Groomed vs beaten may not be specific enough. But by using some
> combination of
On Sun, 24 May 2020 at 16:29, Daniel Westergren wrote:
> Great discussion! I think we're discussing two different things here. One
> is about differentiating *trail* (not necessarily hiking trail) from
> other kinds of highway=path and the other is about *difficulty of a
> (hiking) trail* in
On Sat, 23 May 2020 at 15:53, Tomas Straupis
wrote:
> 2020-05-23, št, 04:51 Jarek Piórkowski rašė:
> > See also: not rendering roads or hamlets in very sparsely populated
> > areas because we have one map style which needs to accommodate central
> > European densities.
>
> OSM-Carto is a very
On Sun, 24 May 2020 at 07:42, John Willis via Tagging <
tagging@openstreetmap.org> wrote:
> =path is such a horrible catch-all tag and one that is extremely
> entrenched - I am surprised no one has implemented a path=trail subtag,
> similar to sidewalk, so we can separate all the hiking trails
On Fri, 22 May 2020 at 22:33, Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:
>
>
>
> May 22, 2020, 13:55 by andrew.harv...@gmail.com:
>
>
>
> On Fri, 22 May 2020 at 21:44, Daniel Westergren wrote:
>
> Yeah, I guess there's no way to force the user to add a surface tag when
>
On Fri, 22 May 2020 at 21:44, Daniel Westergren wrote:
> Yeah, I guess there's no way to force the user to add a surface tag when
> adding a highway=path. We could also use analyzing tools to look for recent
> edits with only highway=path and comment to users about the use of surface
> etc.
>
I
On Fri, 22 May 2020 at 20:54, Daniel Westergren wrote:
> Ok, so I realize there will not really be any other way to distinguish an
> urban, paved path from a small forest path, other than by other attributes
> than highway=path itself. Path=mtb is nice for paths specifically created
> for MTB
On Thu, 21 May 2020 at 22:49, Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:
>
>
>
> May 21, 2020, 14:17 by kevin.b.ke...@gmail.com:
>
> It's still tricky. Around here, few trails are actually signposted;
> some don't have a sign anywhere! They're marked with paint blazes in
>
On Thu, 21 May 2020 at 17:25, Daniel Westergren wrote:
> Expanding on the discussion about attributes for trails. What's the
> current status of the highway=path mess? OSM is increasingly becoming more
> useful for forest trails than for car roads (for which other sources are
> usually more
On Thu, 21 May 2020 at 12:35, Warin <61sundow...@gmail.com> wrote:
> The exclusion of the black trail as a possible 'excursion' in the main
> route is a judgment call. I'd be very careful about it.
>
> Why is one excluded where the other is not? Is that is going to be
> difficult to explain in a
On Thu, 21 May 2020 at 12:31, Warin <61sundow...@gmail.com> wrote:
> Hi,
>
>
> Thanks for doing this!
>
>
> The excursion description is
>
> "A signposted side track which rejoins at roughly the same point where
> it left, usually to visit a point of interest."
>
> That would exclude a track that
Agreed with Phake, any boundary that's used for administrative purposes
could be included, that's what I understand from
https://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative. That
doesn't mean that each area needs to have it's own legal entity and
administrator, nor need to be able to
On Thu, 7 May 2020 at 02:05, Florimond Berthoux <
florimond.berth...@gmail.com> wrote:
> 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 +
>
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
On Tue, 5 May 2020 at 18:45, Marc M. wrote:
> Le 05.05.20 à 04:56, Andrew Harvey a écrit :
> > cycleway:both:hazard becomes an issue when there are multiple hazards
> > that apply, so "doorzone" should be part of the key not the value.
>
> ; is a common separator
&
On Tue, 5 May 2020 at 02:35, Jan Michel wrote:
> On 03.05.20 19:16, Volker Schmidt wrote:
> > I would advocate a more generic approach that remains open to other
> > types of hazards (there are many, unfortunately).
> > A generic
> >
>
On Mon, 4 May 2020 at 00:30, Hubert87 wrote:
> (Two replies is one)
>
> Am 03.05.2020 um 15:29 schrieb Andrew Harvey:
>
> On Sun, 3 May 2020 at 23:14, Hubert87 wrote:
>
>> I like the idea of using "buffered".
>>
>> "doorzone" to m
On Sun, 3 May 2020 at 23:32, Volker Schmidt wrote:
> Here in Italy we do have both cycle lanes, cycle paths, and foot-cycle
> paths with dooring risk. So far I have not seen any tagging for these, but
> I would welcome a uniform approach for tagging this hazard on any type of
> cycling
I've started sketching this out at
https://wiki.openstreetmap.org/wiki/Proposed_features/Key:cycleway:lane:doorzone
but
I think we need more examples of the full range of scenarios as I've only
got two so far.
On Sun, 3 May 2020 at 23:35, Hubert87 wrote:
> Meant to also add a discriptive tag,
On Sun, 3 May 2020 at 23:14, Hubert87 wrote:
> I like the idea of using "buffered".
>
> "doorzone" to me, is a pretty laoded and subjective.
>
I don't see it as subjective. If there is parking directly next to the
bicycle lane and if a parked car opening a door would intersect with the
marked
I'm all for specifying elevation of mountain peaks etc in other datum which
may work better than WGS:84.
I think it's better to specify which datum the value is in, it'll be a
nightmare over time working out which datum the original mapper intended as
new datums are rolled out and are upgraded,
On Sun, 3 May 2020 at 18:56, Jan Michel wrote:
> Hi,
> I oppose adding this officially to the top-level cycleway:lane tag.
> I see this information as one more property of the cycleway, like
> surface, smoothness, width and so on.
>
> We already have a documented key 'cycleway:buffer' that is
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
For a while myself and others have been using cycleway:lane=doorzone to say
the bicycle lane is in a doorzone, I've now added documentation of this as
"in use" at https://wiki.openstreetmap.org/wiki/Key:cycleway:lane. However
this conflicts with the other "in use" cycleway:lane=exclusive/advisory,
On Thu, 23 Apr 2020 at 03:03, brad wrote:
> I've never seen an official IMBA rating on a sign.
>
I have,
https://wiki.openstreetmap.org/w/images/9/96/Serrata_Mountain_Bike_Track_Board_Map.jpeg
> I see both mtb:scale and mtb:scale:imba both used. The wiki for
> mtb:scale doesn't make sense.
I've been using mtb:scale:imba on any kind of trail where signage at the
site notes an IMBA rating, in this way it's verifiable based on the sign. I
don't know what "bikepark" and "north shore" mean here but while some of
these trails which have an IMBA rating can be consider together as part of
a
On Tue, 21 Apr 2020 at 03:42, Martin Koppenhoefer
wrote:
> Did you consider mtb=designated?
>
This was considered and mentioned in the rationale, mtb as a key is better
use as a mode specific access tag, which makes mtb=designated to usually
mean signposted or otherwise indicated for use by
Voting has opened for the locked tag proposal at
https://wiki.openstreetmap.org/wiki/Proposed_features/Key:locked.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
I've started a proposal
https://lists.openstreetmap.org/pipermail/tagging/2020-April/052174.html /
https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:path%3Dmtb which
aims to take this discussion over to the next stage, if you everyone could
take a look at the new proposal and if discussion
1 - 100 of 241 matches
Mail list logo
