Re: [Tagging] Tagging for the renderer : One-way "flow" bicycle tracks

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 co

Re: [Tagging] Difference between "yes" and "designated" in access tags (was: Re: How to Tag Steps in a Bridleway)

On Tue, 30 Apr 2024 at 09:04, stevea wrote: > In my mind "designated" means "for this infrastructure / mode-of-travel > pair, DO use this." Like legislatively or because a sign says so and > quotes a local ordinance or traffic code statute. "We built this, use > it." (Say, for your own safety

[Tagging] [RFC] Feature Proposal - Surcharges and Discounts

Please see my proposal for surcharges and discounts at https://wiki.openstreetmap.org/wiki/Proposal:Surcharges_and_Discounts Please discuss this proposal on its Wiki Talk page. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetma

Re: [Tagging] Help explain the difference between path and track

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 w

Re: [Tagging] How are protected_area (and national_park) boundaries determined?

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 m

Re: [Tagging] Path or track with many fallen trees

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

Re: [Tagging] Feature Proposal - RFC - shop=bubble_tea

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

Re: [Tagging] Feature Proposal - RFC - shop=bubble_tea

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 > sho

Re: [Tagging] Feature Proposal - RFC - shop=bubble_tea

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

Re: [Tagging] Conditional destinations (hgv, bicycle, maxweight…)

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, 3

Re: [Tagging] Have our tagging voting rules changed recently?

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 tak

Re: [Tagging] We should stop using hyphens to denote address ranges

> 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 a

Re: [Tagging] We should stop using hyphens to denote address ranges

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 exa

Re: [Tagging] We should stop using hyphens to denote address ranges

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 co

Re: [Tagging] We should stop using hyphens to denote address ranges

> > > 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 wi

Re: [Tagging] We should stop using hyphens to denote address ranges

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 https://wiki

Re: [Tagging] Call for verification (Was: Re: [OSM-talk] VANDALISM !)

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 syst

Re: [Tagging] Call for verification (Was: Re: [OSM-talk] VANDALISM !)

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. >

Re: [Tagging] Call for verification (Was: Re: [OSM-talk] VANDALISM !)

13:02, 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! >

Re: [Tagging] Call for verification (Was: Re: [OSM-talk] VANDALISM !)

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

Re: [Tagging] Call for verification (Was: Re: [OSM-talk] VANDALISM !)

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 &g

Re: [Tagging] Call for verification (Was: Re: [OSM-talk] VANDALISM !)

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

Re: [Tagging] Call for verification (Was: Re: [OSM-talk] VANDALISM !)

> >> 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

Re: [Tagging] We should stop using hyphens to denote address ranges

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 can

[Tagging] Feature Proposal - RFC - Tag:shelter_type=rock_shelter

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 le

Re: [Tagging] Feature Proposal - RFC - Tag:shelter_type=rock_shelter

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 shel

Re: [Tagging] Feature Proposal - RFC - Tag:shelter_type=rock_shelter

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 definitio

Re: [Tagging] [Talk-us] Large fire perimeter tagging?

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 flame

Re: [Tagging] [Talk-us] Large fire perimeter tagging?

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 s

Re: [Tagging] railway=station areas

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 com

Re: [Tagging] railway=station areas

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 genui

[Tagging] Feature Proposal - Voting - Tag:shelter_type=rock_shelter

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

[Tagging] Should the tag proposal process force voters to vote for an option?

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://lists.op

Re: [Tagging] Should the tag proposal process force voters to vote for an option?

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 >> >>

Re: [Tagging] Should the tag proposal process force voters to vote for an option?

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 taggi

Re: [Tagging] Proposal to change key:man_made to key:human_made

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 usi

Re: [Tagging] How are busways mapped, which are not guideways?

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 for

Re: [Tagging] Proposal to change key:man_made to key:human_made

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 s

Re: [Tagging] Parking fee only after some time period

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 p

Re: [Tagging] Parking fee only after some time period

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: > > > https://www.ballarat.vic.gov.au/city/parking/smarter-parking-ballarat#:~:text=Your%20first%20hour%20of%20parkin

Re: [Tagging] Parking fee only after some time period

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

Re: [Tagging] Parking fee only after some time period

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

Re: [Tagging] Feature Proposal - Voting - Takeaway drink shops

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 did

Re: [Tagging] Feature Proposal - Voting - Tag:shelter_type=rock_shelter

k_overhang. 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:

Re: [Tagging] Feature Proposal - Voting - Tag:shelter_type=rock_shelter

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.

Re: [Tagging] Tagging from fire_service_areas - landuse:emergency

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 Tagging@openstreetmap.org

Re: [Tagging] Feature Proposal - Voting - electrcity=*

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 woul

Re: [Tagging] Feature Proposal - Voting - electrcity=*

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 now.

Re: [Tagging] Feature Proposal - RFC - electricity=*

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 has

Re: [Tagging] Feature Proposal - RFC - Rideshare Access

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

Re: [Tagging] Feature Proposal - RFC - Rideshare Access

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

Re: [Tagging] Feature Proposal - RFC - Rideshare Access

would 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

Re: [Tagging] Basic cartography features missing, why?

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 thr

Re: [Tagging] Basic cartography features missing, why?

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 pr

Re: [Tagging] lanes - is "parking allowed" a parking lane?

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 in

Re: [Tagging] surface=boardwalk? is it duplicate of surface=wood?

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 < tagging

Re: [Tagging] Defining amenity=coast_guard

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 o

Re: [Tagging] Feature Proposal - RFC - Emergency=Rescue Stations

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 https://wiki.openstreetmap.org

Re: [Tagging] Feature Proposal - RFC - Emergency=Rescue Stations

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 is

Re: [Tagging] Feature Proposal - RFC - Emergency=Rescue Stations

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 graemefi...@gma

Re: [Tagging] Definition of lake/pond as applied to stream/plunge pools

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

Re: [Tagging] Definition of lake/pond as applied to stream/plunge pools

e pools are a part of rivers (per WP definition), and I > 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

Re: [Tagging] Definition of lake/pond as applied to stream/plunge pools

in a > 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

Re: [Tagging] Definition of lake/pond as applied to stream/plunge pools

/stream is modeled 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 >&

Re: [Tagging] Combining "locked=yes" with various access tags

> > >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

Re: [Tagging] Combining "locked=yes" with various access tags

) 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

Re: [Tagging] Tagging type of ownership of a road

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 able

Re: [Tagging] Gorges, Canyons, Ravines: natural=valley or new tag?

To me a canyon is narrow with steep cliffs on either side (a place where you'd go canyoning https://en.wikipedia.org/wiki/Canyoning) and a gorge is much wider and may have less steep sides but then you have the Grand Canyon in the US which is wide and less steep sides. I'd vote for separate ta

Re: [Tagging] How to distinguish public and private offices?

On Thu, 15 Aug 2019 at 07:32, Mateusz Konieczny wrote: > Unfortunately many office=* tags represent something that is accessible - > for example > office=insurance is used far more often than shop=insurance (what is > causing throuble > as there are > > - actual offices of companies without publi

Re: [Tagging] Multiple values in isced:level

I'll still be using a range with a -. so 0-2 to mean from 0 to 2 inclusive. I've used it all over my state for schools together with the grades key. To me it's a lot clearer and simpler than the semicolon or multiple yes/no values. On Sat, 17 Aug 2019 at 16:53, Lanxana . wrote: > Hi! > > so, aft

Re: [Tagging] Multiple values in isced:level

t's less error prone and simpler, as they all should be easily interpreted by the downstream data consumer. On Tue, 20 Aug 2019 at 04:53, Jo wrote: > Wonderful, thank you for your contribution to standardising, by doing your > own thing anyway. Really great. > > Jo > > &

Re: [Tagging] Tag for a milk_shake shop?

I'd tag it as amenity=cafe, even without selling coffee I still think it fits into https://wiki.openstreetmap.org/wiki/Tag:amenity=cafe, just with a cuisine tag to specify milk_shakes are the main cuisine. On Fri, 6 Sep 2019 at 00:06, ael wrote: > How do I tag a shop that sells milk shakes? > >

Re: [Tagging] Divided highways, and not so divided highways, one way or two

On Thu, 10 Oct 2019 at 21:23, Warin <61sundow...@gmail.com> wrote: > On 10/10/19 20:46, Martin Koppenhoefer wrote: > > Am Do., 10. Okt. 2019 um 08:40 Uhr schrieb Frederik Ramm < > frede...@remote.org>: > >> The original mapper claims that using two separate oneway=yes ways is >> clearer and easier

Re: [Tagging] swimming=* access tag

A big +1 from me, I've been mapping with swimming=* to indicate access on waterways and bodies of water for a while, and agree it should be documented on the access page. swimming=designated where the area is explicitly marked or signposted for swimming (possibily in conjunction with leisure=swimm

Re: [Tagging] swimming=* access tag

On Thu, 24 Oct 2019 at 19:25, Martin Koppenhoefer wrote: > Am Mi., 23. Okt. 2019 um 12:03 Uhr schrieb Robert Skedgell < > r...@hubris.org.uk>: > >> I wonder whether it would be worth adding a swimming=* access tag to the >> wiki and the list under "Water-based transportation" section of the page

Re: [Tagging] How to describe footpath border?

I presume you would also be able to use most of the existing barrier values from https://wiki.openstreetmap.org/wiki/Key:barrier? How do you think it should would it work if you have multiple, say a nature strip (the section of grass or small trees between the sidewalk and road) AND some other bar

Re: [Tagging] amenity=hospital on things that are not hospitals - is it a good idea?

+1 I'd support updated the wiki page to favour tagging the symbol and not using amenity=hospital. On Mon, 28 Oct 2019 at 21:13, marc marc wrote: > Le 28.10.19 à 09:44, Mateusz Konieczny a écrit : > > "sign having a hospital icon and no name can simply be tagged > > type=destination_sign + amenit

Re: [Tagging] Changeset 62867521

I just added my thoughts to the changeset comment. I agree that name should be the proper name only and all other information can go in other tags or the description field. Generally an "official" (I use the term loosely) trail will be signposted and potentially part of a hiking route, and an "inf

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

On Sat, 7 Dec 2019 at 13:07, Martin Koppenhoefer wrote: > On 7. Dec 2019, at 01:51, Peter Elderson wrote: > > I think a simple oneway=yes on a hiking route relation could say it's > signposted for one direction. > > > > I would prefer being more explicit in the tag name, e.g. > sign_direction=fo

Re: [Tagging] Incomplete addresses

I agree, it's pedantic to add the suburb and state since these can easily be derived from the admin boundaries, and often from a ground survey you won't be able to know the suburb anyway so best to just enter the data that you can survey. That said, it can still be useful to tag the suburb on the

Re: [Tagging] Incomplete addresses

On Tue, 7 Jan 2020 at 19:26, Shawn K. Quinn wrote: > On 1/7/20 02:16, Lionel Giard wrote: > > The ID template must not be taken a mandatory field, but only as a > > suggestion on what information is generally useful for this feature (in > > the entire world, as i think that the template are not d

Re: [Tagging] What values of 'emergency=' should be on the main Map features page?

On Sun, 19 Jan 2020 at 00:20, Joseph Eisenberg wrote: > Should we remove some of the rare values of "emergency=" which have > got into Map Features? > No just because it's may have a low tag count doesn't mean it's not a good tag. > Like some other key pages, the Key:emergency page is a big li

Re: [Tagging] What values of 'emergency=' should be on the main Map features page?

On Sun, 19 Jan 2020 at 10:40, Graeme Fitzpatrick wrote: > There would seem to be possible grounds for a new tag of > emergency=rescue_station, broken down into what type of rescue that station > carries out: > eg type (that word that everybody loves!) / field / area / rescue=water > (swimmers) /

Re: [Tagging] key damage and HOT

ruins:building=yes is not just tagging for other mappers, it's accurately describing the feature on the ground, a ruined building. It's not quite a building=yes, but not really nothing left on the ground, so it's just part of the lifecycle. On Thu, 6 Feb 2020 at 19:23, Paul Allen wrote: > On Thu

Re: [Tagging] key damage and HOT

On Fri, 7 Feb 2020 at 01:21, Paul Allen wrote: > On Thu, 6 Feb 2020 at 13:40, Andrew Harvey > wrote: > >> ruins:building=yes is not just tagging for other mappers, it's >> accurately describing the feature on the ground, a ruined building. It's >> not

Re: [Tagging] key damage and HOT

On Fri, 7 Feb 2020 at 10:47, Paul Allen wrote: > On Thu, 6 Feb 2020 at 23:29, Andrew Harvey > wrote: > >> >> I disagree with the whole premise. To me both building=yes+ruins=yes and >> ruins:building=yes means exactly the same thing and should be interpreted >&

Re: [Tagging] Annual Shows

If it's on the same day every year on a predictable schedule, I guess it could be added, but if not I'd say no OSM isn't the best place for that kind of data. We don't map every single "Olympics" or "World Championship" sporting events. At the same time I've mapped Parkrun's which only popup week

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

I agree with Peter, it'll probably be better to start with the basics, get that approved so at least there is some improvement, then move forward with the more complicated parts of the proposal. In terms of the role names proposed I noticed that it is a very similar to a schema I came up with for

Re: [Tagging] How to map an OpenStreetMap map?

But those uses are mostly the source the mapper used to find out about the tag they are adding, which is different to the source of the map. source:map=survey means I got the map=* key from a survey. So if you use map:source=openstreetmap then source:map:source=survey says I found it as being a m

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

I think including the actual route is useful and makes life easier for downstream users (they don't need a routing engine to show the route), could this be optional so you can create a public transport route relation via waypoints only if you prefer as a starting point, but then still allow it to b

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

I think if people want to save the full route with way members, that should be allowed. If someone wants to do a first pass with just using waypoint nodes or just the stop_positions, I think that's fine too. So I'm against the proposal in the current form for this reason.

Re: [Tagging] Shelter for bats in an old building

https://wiki.openstreetmap.org/wiki/Lifecycle_prefix disused:building=service On Sat, 21 Mar 2020 at 19:13, s8evq wrote: > Hi everyone, > > How would you tag a small building that used to be an electricity building > where the army put power generators for the (backup) power of an airfield. > T

Re: [Tagging] Shelter for bats in an old building

> suggests that it is "mounted on a support". Is that a requirement for > using the tag? > > -- Joseph Eisenberg > > On 3/21/20, althio wrote: > > On Sat, 21 Mar 2020 at 12:24, Andrew Harvey > > wrote: > > > >> https://wiki.openstr

[Tagging] Feature Proposal - RFC - Key:locked

I've put together a proposal for Key:locked at https://wiki.openstreetmap.org/wiki/Proposed_features/Key:locked which I'm proposing to use on barriers like gates to describe physical access restriction via a lock. Taginfo records 908 current uses https://taginfo.openstreetmap.org/keys/locked and i

Re: [Tagging] Feature Proposal - RFC - Key:locked

On Thu, 26 Mar 2020 at 15:31, Warin <61sundow...@gmail.com> wrote: > There are also bicycle storage things with locked access. > Agreed, I've updated the proposal to apply to bicycle_parking=shed|lockers|building. For example the bicycle cage might just be there for shelter but not secured with a

Re: [Tagging] Can highway=cycleway be limited to MTB?

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

Re: [Tagging] Can highway=cycleway be limited to MTB?

On Thu, 2 Apr 2020 at 20:12, Volker Schmidt wrote: > If a highway is mtb:scale=2 it is definitely not a cycleway. It is a > highway=path with mtb:scale=2 > If this were to encounter a "cycleway" with mtb:scale=2 , I would consider > this an error and retag it as highway=path without hesitation. >

Re: [Tagging] Can highway=cycleway be limited to MTB?

On Thu, 2 Apr 2020 at 21:35, Volker Schmidt wrote: > There is another aspect: > The wiki page highway=cycleway states also > " Tagging a way with highway > =cycleway implies that > the route is designated for bicycles." > Formal mountain bike trac

Re: [Tagging] Can highway=cycleway be limited to MTB?

On Thu, 2 Apr 2020 at 21:51, Marc M. wrote: > Le 02.04.20 à 12:13, Yves a écrit : > > I disagree here, a cycle map should not ignore mtb:scale > > please keep the principle of least surprise in mind. > highway=cycleway not-for-bicycle is like a "highway=footway + foo=no" > or like "building=yes f

Re: [Tagging] Can highway=cycleway be limited to MTB?

On Thu, 2 Apr 2020 at 23:17, Florimond Berthoux < florimond.berth...@gmail.com> wrote: > 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

  1   2   3   >