Re: [Tagging] RFC proposed water property key 'ephemeral '

If I’ve understood it correctly, I would tag that as: seasonal=winter,spring,autumn ephemeral=summer From: Mateusz Konieczny Sent: Thursday, 24 May 2018 16:28 To: Tag discussion, strategy and related tools Cc: tagging@openstreetmap.org Subject: Re: [Tagging] RFC proposed water property

Re: [Tagging] Sample tagging for highways with no lane markings

From: Javier Sánchez Portero Sent: Wednesday, 23 May 2018 17:27 To: Tag discussion, strategy and related tools Subject: Re: [Tagging] Sample tagging for highways with no lane markings Anyway, for your example of the LR-333 road, most of the time it isn't enough wide for two cars to pass com

Re: [Tagging] opening_hours:sign=no - RFC

> -Original Message- > From: Warin <61sundow...@gmail.com> > Sent: Wednesday, 23 May 2018 09:31 > >> Could not this information be included in the note tag? > > note is free text for mapper > > unsigned is also used by tools like http://qa.poole.ch/ > > I don't think any data consumer wil

Re: [Tagging] Sample tagging for highways with no lane markings

From: yo paseopor Sent: Wednesday, 23 May 2018 04:11 To: Tag discussion, strategy and related tools Subject: Re: [Tagging] Sample tagging for highways with no lane markings oneway=no lanes=1 https://www.mapillary.com/map/im/jYQQwOGMPC6imwyGhMHMCg I would consider that wrong.

Re: [Tagging] Sample tagging for highways with no lane markings

Personally, I tend to tag roads that are wide enough for 2 lanes (two cars can pass each other without noticeably slowing down) and which are clearly meant to be two lane (one lane each direction) roads with: lanes=2 divider=no Yes, I know that is in violation of the strict reading of the wiki,

Re: [Tagging] access=disabled

> > With emergency and disabled as part of access restrictions, they > central question becomes, are these access tag values (like yes, no, > private, destination, delivery, customers, ...) or transport modes > (like foot, bicycle, motor_vehicle, ...) > > this is already documented on the access p

Re: [Tagging] Seasonal, intermittent, and ephemeral water tags

Sounds like candidates for: https://wiki.openstreetmap.org/wiki/Proposed_features/floodplain https://wiki.openstreetmap.org/wiki/Key:flood_prone https://wiki.openstreetmap.org/wiki/Tag:landuse=basin Depending if natural or man made. The floodplain proposal definitely needs more work,

Re: [Tagging] Seasonal, intermittent, and ephemeral water tags

> -Original Message- > From: Warin <61sundow...@gmail.com> > Sent: Saturday, 19 May 2018 12:33 > To: Tag discussion, strategy and related tools > > Think I have raised this before but not come to any firm conclusion > myself. > > I think that tagging > > seasonal=summer > > intermittent

Re: [Tagging] tagging arbiters (gone OT)

It’s not an carto-osm bug, it’s a level lower: https://github.com/openstreetmap/osm2pgsql/issues/230 If that ever gets implemented properly, then carto-osm and other data users can make use of it… From: Paul Johnson Sent: Saturday, 19 May 2018 12:12 To: Tag discussion, strategy and r

Re: [Tagging] Feature Proposal - RFC - Walkingbus_stop

As I said, it has poles, areas people wait, a fixed route, a repeating timetable, there is a "driver" and it's purpose is specifically to transport people from one location to another. The fact that you have to put in personal effort (walking) during the transportation within this framework does

Re: [Tagging] Feature Proposal - RFC - Walkingbus_stop

I agree that it definitely is "transport" and that it has all the features (pole, waiting area, timetable, fixed route) that make it very suitable to map as public_transport. The only thing we have to decide upon is how "public" a public_transport must be. Does it have to be available to all m

Re: [Tagging] access=disabled

With emergency and disabled as part of access restrictions, they central question becomes, are these access tag values (like yes, no, private, destination, delivery, customers, ...) or transport modes (like foot, bicycle, motor_vehicle, ...) access=no emergency=yes implies that it is a transpo

Re: [Tagging] access=disabled

"disabled" is not one of the access types documented on the wiki. I would say setting capacity and capacity:disabled to the same value makes it clear already that the whole parking lot is only for disabled parking, and it follows a documented tagging scheme that relevant data consumers should al

Re: [Tagging] type=route tagged on a way?

Well, if this particular way of tagging things is generally supported by data consumers, then I would consider it a documentation error instead of a tagging error. But if it’s not used by data consumers in this form (while the same information on a relation is), and clearly the people creati

[Tagging] type=route tagged on a way?

I've noticed there are 9377 cases of type=route tagged on ways instead of relations: https://taginfo.openstreetmap.org/tags/type=route I've been unable to find any documentation of this tagging approach on the wiki. https://wiki.openstreetmap.org/wiki/Relation:route#Route_types_.28route

Re: [Tagging] Conflicting wiki docu for aerialway=goods and aerialway=station

From: Martin Koppenhoefer Sent: Wednesday, 16 May 2018 04:39 Bonus question: would you say it makes sense to add public_transport=station (plus eventually subtags to state which kind of vehicle) to aerialways? IMO (for whatever that’s worth), aerialways and their stations (along with their

Re: [Tagging] Conflicting wiki docu for aerialway=goods and aerialway=station

Not involved in aerialway tagging at all, but I would say that things like aerialway=station or railway=station applies to each place with significant infrastructure where a vehicle might stop for any type of loading/unloading activity, including goods/freight only. While public_transport=statio

Re: [Tagging] tagging of one-way cycle lanes

> -Original Message- > From: Marc Gemis > Sent: Monday, 14 May 2018 19:40 > > The wiki page on cycling infrastructure from the Lübeck Stammtish, > mentioned this explicitly "und/oder", see [1] > > I also see that they use cycleway:left/right=sidepath, I have never > used that, I used bic

Re: [Tagging] tagging of one-way cycle lanes

From: Martin Koppenhoefer Sent: Monday, 14 May 2018 19:07 according to the wiki, you can't use "cycleway:left" and "cycleway:right" at the same time. Would you agree this requirement should be removed? This particular wiki page seems to be somewhat misleading in that case. cycleway:left=

Re: [Tagging] tagging of one-way cycle lanes

> -Original Message- > From: Marc Gemis > Sent: Monday, 14 May 2018 18:55 > >> cycleway:left=opposite_lane (or cycleway:right, depending) >> oneway:bicycle=no > > I would expect that the above is for the case that there is only a > contra-flow lane. And that for drive with the flow you ha

Re: [Tagging] tagging of one-way cycle lanes

From: osm.tagg...@thorsten.engler.id.au Sent: Monday, 14 May 2018 18:37 if there is only one cycle lane, but it’s allowed to travel in both directions on an otherwise one-way road use: cycleway:left=opposite (or cycleway:right, depending which side, as seen from the forward direction of

Re: [Tagging] tagging of one-way cycle lanes

Just a plain cycleway=opposite_lane is somewhat ambiguous, so I would recommend an explicit cycleway:left or cycleway:right. opposite_lane indicates that there is one cycle lane, which only allows traffic in the direction opposite of the oneway traffic. Bicycle traffic in one-way direction w

Re: [Tagging] tagging of one-way cycle lanes

As far as I can tell, for two-way streets, there is no differences, it’s just more explicit. Given the difference in usage numbers (1522 vs. 254509) I would go with just cycleway=lane (I actually checked these numbers before I made that last post). For one-way streets, I’m not sure how m

Re: [Tagging] tagging of one-way cycle lanes

To get back to your original question… From: Volker Schmidt Sent: Thursday, 10 May 2018 03:11 To: Tag discussion, strategy and related tools Subject: [Tagging] tagging of one-way cycle lanes I want to tag a road (one of thousands in this country) that has two lanes for cars (one in

Re: [Tagging] tagging of one-way cycle lanes

From: Paul Allen Sent: Saturday, 12 May 2018 05:49 To: Tag discussion, strategy and related tools Subject: Re: [Tagging] tagging of one-way cycle lanes On Fri, May 11, 2018 at 8:06 PM, Paul Johnson mailto:ba...@ursamundi.org> > wrote: None of these three things are a problem now, except

Re: [Tagging] tagging of one-way cycle lanes

> -Original Message- > From: Marc Gemis > Sent: Saturday, 12 May 2018 02:21 > > Is OsmAnd interpreting the lanes tag correctly in the presence of > cycle lanes when it is tagged like you [Paul Johnson] do ? Nope. In fact, no matter if you specify lanes=2 or lanes=4, it will show the cyc

Re: [Tagging] tagging of one-way cycle lanes

> From: Martin Koppenhoefer > Sent: Friday, 11 May 2018 21:45 > while I would generally agree with the idea of having officially 3 lanes, > I would have thought that lanes would have to be painted on the road, not > just indicated by signs. Under the strict reading of the definition on the w

Re: [Tagging] tagging of one-way cycle lanes

I would tag that as: oneway=yes lanes=3 lanes:psv=1 vehicle:lanes=yes|yes|no psv:lanes=yes|yes|designated parking:lane:left=parallel parking:condition:left=ticket sidewalk=both This sign clearly defines how many lanes there are and that it’s a psv lane (not just a bus lane): ht

Re: [Tagging] tagging of one-way cycle lanes

A lot of residential roads here don’t have markings, like here: https://www.google.com.au/maps/@-27.2131302,153.0260346,3a,55y,45.38h,68.9t/data=!3m4!1e1!3m2!1sci60ZE7unqEW6wDOP9Gh6Q!2e0 But they are clearly intended to be 2 lane roads. (Which can be seen from the reflectors that are somet

Re: [Tagging] tagging of one-way cycle lanes

I've always been editing using JOSM and using the "lane and road attributes" mapstyle for visualization (which is pretty much the only editor/map style I'm aware of that has support for the large majority of lane related tags, making it pretty much the defacto standard implementation given the t

Re: [Tagging] tagging of one-way cycle lanes

I'm not sure why we are wasting any time on discussing possible changes to the definition of the lanes tag her. The tag goes back to pretty much the start of OSM and is in widespread usage. Any change in definition that fundamentally changes what value goes into the key given a specific situat

Re: [Tagging] tagging of one-way cycle lanes

> From: Marc Gemis > Sent: Friday, 11 May 2018 14:44 > > When the "lanes" tag was introduced the community choose to only > count the "full width segments for motorised traffic". Perhaps > because traffic law in some countries (e.g. Belgium [1]) define > them that way. So people started using

Re: [Tagging] complete tagging of all 'right of way'-cases FOLLOWUP

A few comments: * I don't think this should "obsolete" the highway=give_way nodes completely. For simple cases with oneway=yes roads the highway=give_way node on the way is the easiest way to map them. Also for any "four-way give way" situation, tagging the intersection node is clear and unambi

Re: [Tagging] tagging of one-way cycle lanes

See also: https://wiki.openstreetmap.org/wiki/Proposed_features/lanes_General_Extension#The_issues_with_the_lanes_tag (which is from the approved proposal that established the :lanes suffix). From: osm.tagg...@thorsten.engler.id.au Sent: Thursday, 10 May 2018 15:28 To: 'Tag discussion

Re: [Tagging] tagging of one-way cycle lanes

The “lanes=count” key gives the number of full lanes for motorized traffic. This gives a good estimate for total carrying capacity for vehicle traffic on this road for software that isn’t too concerned about the details, or simply older software that doesn’t know about the :lanes suffix. If

Re: [Tagging] tagging of one-way cycle lanes

If I may correct your suggestion, that’s not quite right. To quote the wiki for lanes: The lanes=* key should be used to specify the total number of marked lanesof a road. The following lanes should be included: * General purpose

Re: [Tagging] Feature Proposal - RFC - key:spacing=*

> -Original Message- > From: Daniel Koć > Sent: Monday, 7 May 2018 06:03 > > However I think that measuring spacing is worse than just measuring > the number of trees. It's more mapper friendly and less error prone. I've you have a long road with trees along it, it's easy and fast to est

Re: [Tagging] Feature Proposal - RFC - key:spacing=*

> -Original Message- > From: Christoph Hormann > Sent: Sunday, 6 May 2018 03:37 > To: Tag discussion, strategy and related tools > > Subject: Re: [Tagging] Feature Proposal - RFC - key:spacing=* > > If i try to ignore the rendering related aspects of your proposal it > boils down to bein

Re: [Tagging] Feature Proposal - RFC - Walkingbus_stop

Well, but based on your description, these are not planned routes in any way. They are purely transient emergent behaviour based on the fact that a lot of people want to move between these two points, and this is the obvious way to go. Take the people away, and the phenomenon disappears. This is

Re: [Tagging] Feature Proposal - RFC - Walkingbus_stop

If they are unmarked on the ground, are they documented somewhere? Or is it simply a case of "this is a common route a lot of people walk during certain times as there is a strong flow of people from A to B and this is the most commonly used route"? (In which case they aren't really something t

Re: [Tagging] Feature Proposal - RFC - Walkingbus_stop

Without a "driver", fixed "stops" and a defined schedule, that sounds more like what's currently already mapped using route=foot relations? > -Original Message- > From: Erkin Alp Güney > Sent: Saturday, 5 May 2018 23:28 > To: tagging@openstreetmap.org > Subject: Re: [Tagging] Feature Pr

Re: [Tagging] Feature Proposal - RFC - Walkingbus_stop

If there are actual poles and stop signs, you can only “board” at these places and at specific times, and the “driver” stays with the group from the first to the last stop, then yeah, I can see this as being very different from a “school crossing guard” which generally stays at one specific cros

Re: [Tagging] Feature Proposal - RFC - Walkingbus_stop

To add to this, based on a discussion in #osm, please be careful what you map. If there are poles with signs for the stops, map them. If there are public signs describing the routes, map them. But any stops or routes that are private information only between organizers and parents/students sh

Re: [Tagging] Feature Proposal - RFC - Walkingbus_stop

You'll probably also need a type of route relation for this? Also, public_transport=platform is only valid with at least one transport type specific tag, e.g. bus=yes or tram=yes. So there should probably be a walkingbus=yes or walking_bus=yes tag on that. (Whichever is chosen, it should be th

Re: [Tagging] Outdoor deckchairs

There are a decent number of one seat benches already mapped: https://overpass-turbo.eu/s/ynN From: Martin Koppenhoefer Sent: Monday, 30 April 2018 20:16 To: Tag discussion, strategy and related tools Subject: Re: [Tagging] Outdoor deckchairs 2018-04-30 12:03 GMT+02:00 mailto:osm.

Re: [Tagging] Outdoor deckchairs

Looking at the specified dimensions, that thing is 1m wide (which I assume is the outside dimension, so make it maybe 90cm available to sit in between). I don’t think 2 average adults that aren’t in the habit of swapping body fluids are going to feel very comfortable occupying it together.

Re: [Tagging] Outdoor deckchairs

A “one person bench” doesn’t seem as rare as people seem to think… https://www.wayfair.com/furniture/pdp/wildon-home-elmore-one-seat-bench-ut2860.html https://www.wayfair.com/furniture/pdp/17-stories-madhav-one-seat-bench-stss5585.html https://www.wayfair.com/furniture/pdp/andover-mills-delan

Re: [Tagging] Outdoor deckchairs

That definition seems overly strict. There is a tag to define how many places a bench has. And I don't think "1" is an invalid value for that... > -Original Message- > From: Martin Koppenhoefer > Sent: Monday, 30 April 2018 18:33 > To: Yves > Cc: Tag discussion, strategy and related too

Re: [Tagging] musical_instrument tag for publicly available musical instruments

Obviously, you would have to use a separate node inside the area that is tagged as the bar to tag the piano… If you want to go into this much detail about what’s inside the bar (or anything else for that matter), tagging the area and then putting things inside it is much more manageable then

Re: [Tagging] musical_instrument tag for publicly available musical instruments

The musical_instrument *key* is generally used to name the specific type of musical instrument: https://taginfo.openstreetmap.org/keys/musical_instrument You are correct that it's mostly used in combination with shop=musical_instrument (a place selling them) or craft=musical_instrument (a place

Re: [Tagging] tagging cycleable city-models focused on simulating road network

[TIC] training=practical_application_of_traffic_rules From: Martin Koppenhoefer Sent: Monday, 23 April 2018 22:20 To: Tag discussion, strategy and related tools Subject: Re: [Tagging] tagging cycleable city-models focused on simulating road network 2018-04-23 13:03 GMT+02:00 Paul Allen

Re: [Tagging] RFC - Key: spacing=*

This looks very useful. If the better rendering for tree_row gets anywhere, I would very much like to see the same applied to ways tagged as barrier=bollard (representing a row of bollards) as well (which are currently unfortunately not rendered at all). spacing=* sounds like a good key for

Re: [Tagging] tagging cycleable city-models focused on simulating road network

In addition to training=cycling we should probably also support training:cycling=yes as a single place might offer training in more than one field. From: Paul Allen Sent: Monday, 23 April 2018 21:04 To: Tag discussion, strategy and related tools Subject: Re: [Tagging] tagging cycleable cit

Re: [Tagging] How to map Outdoor Fitness Equipment

Sounds fine in general. I think there already some tagging scheme for individual playground equipment? Haven’t used that yet or checked it out in detail, but whatever that scheme is, it would probably make sense to follow a similar pattern for fitness_station (which may very well be what you

Re: [Tagging] Small gate only for foot access

Just because it’s not as often used in this way doesn’t mean it’s wrong. It would be in line with the usage I’ve seen in the access:lanes tag, e.g. access:lanes=yes|yes|bus or access:lanes=bicycle|yes|hsv I’m not questioning that: access=no foot=yes is correct to allow access for foo

Re: [Tagging] Small gate only for foot access

I believe the correct shorthand for access=no foot=yes would be just access=foot ? From: Adam Snape Sent: Friday, 20 April 2018 19:17 To: e.rossin...@alice.it; Tag discussion, strategy and related tools Subject: Re: [Tagging] Small gate only for foot access Hi, Is it a kissing gate

Re: [Tagging] Identifying language regions

I noticed that French Community is a member of the Belgium relation twice. Once with subarea as role, and once with an empty role. Probably an error? From: André Pirard Sent: Thursday, 19 April 2018 11:34 To: Tag discussion, strategy and related tools ; Yuri Astrakhan Subject: [Tagging] Id

Re: [Tagging] Feature Proposal - RFC - Carpet hanger

I would be willing to argue that there is a place for both keys actually. The man_made one to describe the physical thing. The amenity one to describe that this is a publicly accessible amenity.. The amenity key implies the man_made key, but not the other way around. > -Original Message-

Re: [Tagging] no_u_turn restrictions for every entry/exit into a roundabout when the way is split because of physical separation?

Yes, that's from https://wiki.openstreetmap.org/wiki/Proposed_features/Defaults which André Pirard linked to just recently here. Personally, I'm not a huge fan of the syntax. I would prefer the use of sub-relations. You would then have a type=defaults relation, with apply_to members that speci

Re: [Tagging] recent change to https://wiki.openstreetmap.org/wiki/Tag:power%3Dtower

The change didn’t just delete the information, it specifically listed it all under: Possible tagging error * tower:type= suspensio

Re: [Tagging] no_u_turn restrictions for every entry/exit into a roundabout when the way is split because of physical separation?

Putting information about the legal default into OSM is not the problem. It’s just that nobody has developed a schema for it yet. And to repeat myself for the Xth time, I fully agree that it is a good idea to work out such a schema. Interpreting the law and putting the result of that interpre

Re: [Tagging] no_u_turn restrictions for every entry/exit into a roundabout when the way is split because of physical separation?

> I find it's less than productive for finding solutions to problems the > wiki is currently advising to leave unresolved (such as this), or > ambiguous (like primary vs trunk vs motorway in the US). It doesn't tell you to leave the problem unsolved. It only tells you that tagging the legal def

[Tagging] recent change to https://wiki.openstreetmap.org/wiki/Tag:power%3Dtower

I'm asking on behalf of Gazer75 (he isn't subscribed to the mailing list). He pointed out that there was a recent massive deletion of 9/10th of the page in the wiki: https://wiki.openstreetmap.org/w/index.php?title=Tag:power%3Dtower

Re: [Tagging] no_u_turn restrictions for every entry/exit into a roundabout when the way is split because of physical separation?

I never said anything about _not_ having some way to encode such default rules. In fact, if you look at my recent posts here, you will see that I specifically pointed out the current lack of such a schema as an issue that needs to be solved. I also pointed out that the lack of “permission” relat

Re: [Tagging] no_u_turn restrictions for every entry/exit into a roundabout when the way is split because of physical separation?

I tought it was obvious, but let me spell it out: such restrictions represent a default which we should be recorded somewhere (not necessary inside OSM) once and observed by data consumers, not by creating potentially 10’s of relations to again and again encode the default behaviour. Thi

[Tagging] Suggestion for allowing traffic_sign member on restriction relation and specifically documenting possible source values.

Hi, I would like to suggest that we allow (and document) an additional member here: https://wiki.openstreetmap.org/wiki/Relation:restriction#Members The role would be "traffic_sign" and it would be a single node that marks the physical location (so not a node on a highway, but beside it at

Re: [Tagging] no_u_turn restrictions for every entry/exit into a roundabout when the way is split because of physical separation?

https://wiki.openstreetmap.org/wiki/Good_practice#Don.27t_map_your_local_legislation.2C_if_not_bound_to_objects_in_reality From: Paul Johnson Sent: Thursday, 5 April 2018 23:38 To: Tag discussion, strategy and related tools Subject: Re: [Tagging] no_u_turn restrictions for every entry/exit i

Re: [Tagging] no_u_turn restrictions for every entry/exit into a roundabout when the way is split because of physical separation?

No. And that’s exactly my point. There are restrictions being added for which I don’t see any basis except “it’s physically a bad idea”. There is no explicit no u-turn sign, and you can see the road markings in bing imagery here: https://www.openstreetmap.org/edit#map=21/-27.21439/153.02286

Re: [Tagging] no_u_turn restrictions for every entry/exit into a roundabout when the way is split because of physical separation?

Yes, but all the cases I pointed out either have no road markings at all, or a dashed line once the two lanes come together. (I happen to live 300m from these.) From: Martin Koppenhoefer Sent: Thursday, 5 April 2018 20:27 To: Tag discussion, strategy and related tools Subject: Re: [Tagging

Re: [Tagging] no_u_turn restrictions for every entry/exit into a roundabout when the way is split because of physical separation?

Actually, it’s not just relatively harmless “noise”. Because such no_u_turn restrictions are indistinguishable from e.g. this one: https://www.openstreetmap.org/relation/8182004 (which I just created), that actually has a sign “on the ground”: https://www.google.com.au/maps/@-27.2141567,153.001

Re: [Tagging] Tagging turn restriction defaults

I was going to make a post about exactly this shortly… In all of Queensland, u-turns at signal controlled intersections are prohibited by default, except if explicitly permitted with a “u-turn permitted” sign. This raises two issues: a. How to specify that regional legislation b.

Re: [Tagging] no_u_turn restrictions for every entry/exit into a roundabout when the way is split because of physical separation?

Looking at the issues, I can’t actually find any that matches the activity currently performed by that user (and new turn restrictions). From: Clifford Snow Sent: Thursday, 5 April 2018 12:11 To: Tag discussion, strategy and related tools Subject: Re: [Tagging] no_u_turn restrictions for

Re: [Tagging] no_u_turn restrictions for every entry/exit into a roundabout when the way is split because of physical separation?

https://www.openstreetmap.org/changeset/57747093 shows the following for me, are you not seeing this? Comment from Ds5rUy 2 days ago What's the rational for adding the no_u_turn restrictions for every single entry/exit to a roundabout where th

Re: [Tagging] no_u_turn restrictions for every entry/exit into a roundabout when the way is split because of physical separation?

Well, the edits seem to be made in JOSM, and the speed seems to be too low to be a bot. So I do think they are made by hand. But this (and tens of other changesets are all titled "Added turn restrictions source: Probe”. I don’t know what “Probe” is, but I assume it’s some automated tool some

[Tagging] no_u_turn restrictions for every entry/exit into a roundabout when the way is split because of physical separation?

I've noticed that someone from the Microsoft Open Map team is very busy adding turn restrictions all over the place ( https://www.openstreetmap.org/user/shawat94/ ). In my local neighbourhood, I noticed that he added no_u_turn restrictions to all the nodes where a road into in/out of a roundabo

Re: [Tagging] highway=stop and highway=give_way to traffic_sign=stop and traffic_sign=give_way

As I see it, the traffic_sign tags indicated the position of the traffic sign (if any), while the highway tags (on a node on the highway) indicate the position of the stop or give way line on the road (which may exist even in the absence of a sign) or where the line would be. From: yo paseop

Re: [Tagging] Attendant on amenity=fuel

There is also an automated key mentioned on the wiki. This applies mostly to self_service I would guess, and I assumed automated=yes indicates that you can pay at the pump. I didn’t mention the following because taginfo showed that it’s not used and there pretty surely is no software sup

Re: [Tagging] Attendant on amenity=fuel

Based on the information provided here: https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dfuel#Service and what was stated in previous posts on the mailing list, I would guess that the correct tags would be: Only serviced by attendant: self_service=no full_service=yes Self ser

Re: [Tagging] Attendant on amenity=fuel

While it has never been used before, the logical key to me would be self_service:conditional following the usual rules for conditional keys. At least you can choose during the day if you fuel by your self or not. So I would treat it as not self service during the day. I consider this a

Re: [Tagging] Shop=tailor vs craft=tailor

“tailor” sounds very much like a craft to me. On the other hand, it’s hard to argue with 1 tagged objects. >From the title of the issue, I assume that craft wasn’t being rendered before? >Which might very well explain why everyone used shop to tag it… From: James Sent: Sunday, 18

Re: [Tagging] Tagging fraction house numbers?

Actually, that can easily happen if you have 1½ but some software wants to convert it to simple ASCII and doesn't add a space between the 1 and 1/2 when converting the ½. While if the original text already is "1 1/2" this doesn't happen. Obviously, in a perfect world, where everything is Unicod

Re: [Tagging] Rubberised playground surface

After googling a bit, the term I see most often is either "wet pour rubber" or "softfall rubber". > -Original Message- > From: Toby Murray > Sent: Tuesday, 13 March 2018 01:55 > To: Tag discussion, strategy and related tools > > Subject: Re: [Tagging] Rubberised playground surface > >

Re: [Tagging] Tagging request: missing admin_level tags

> -Original Message- > From: Kevin Kenny > Sent: Monday, 12 March 2018 11:15 > To: Tag discussion, strategy and related tools > > Subject: Re: [Tagging] Tagging request: missing admin_level tags > I'm glad we're in agreement here. This was my key point: the fact > that the existing rende

Re: [Tagging] Tagging request: missing admin_level tags

I agree that the priorities need to be codified (for the standard style), but this remains unchanged, no matter if the boundaries are rendered by polygon or by way. Also, this is not something that should be decided or controlled by the mapper/data. The map database just collects all the ava

Re: [Tagging] Tagging request: missing admin_level tags

Also, I don't understand why the information would need to be manually tagged on the ways at all. Duplicating derivable information in a database seems like a very stupid move to me. All the required information is there already. If some part of the process wants to go on information attached to

Re: [Tagging] Tagging request: missing admin_level tags

This sounds like an absolutely horrible idea to me that totally goes against the tagging paradigms that have been in effect so far. Also, as Simon pointed out, a single way can belong to multiple multipolys at the same time, each with different admin levels, or even ways that in itself represen

Re: [Tagging] discrepancy in shop definition and "wholesale" value

Addendum: My personal mental definition of a “shop” is a “a place you can show up without appointment, pick from available wares, pay on exit, and directly take the thing you bought home”. What they sell (e.g. clothes, groceries, only in bulk packaging) or if access is restricted (specific

Re: [Tagging] discrepancy in shop definition and "wholesale" value

The term “Big-box store” is not one I’ve ever heard used in Australia, and is not something that I would immediately associated with something like Costco. Given that the existing tag is already in widespread (and largely correct) usage and possibly specifically supported by existing software, I

Re: [Tagging] discrepancy in shop definition and "wholesale" value

Here in Australia, I would consider “Costco” to be a “shop”. And they name themselves as “Costco Wholesale”. While they do require a membership, that membership is open to anyone without restrictions. Except for the need of a membership (which they happily sell you for 60 bucks the first time yo

Re: [Tagging] Feature Proposal - RFC - Kerb

> Perhaps. I'm ambivalent about this type of usage (i.e. I don't plan to do this myself, but if someone wants to I'd rather them use these tags rather than the primary kerb=* key). I'd say we should get more input before adding kerb:both/left/right, and we should probably keep that as part of an se

Re: [Tagging] Feature Proposal - RFC - Kerb

> However, if someone really wants to tag a highway=* to indicate a kerb is on the outer edge, it's better to not use the kerb=* key but rather kerb:left/kerb:right/kerb:both, so there is no confusion. Ah yes, kerb:both, I didn't think about that. Still pretty new to mapping and still getting used

Re: [Tagging] Feature Proposal - RFC - Kerb

>> I assume that if I have a way that runs along the physical location of the kerb >> (e.g. because it's a closed way or part of a multi-poly that's used to define a >> landuse area) I could tag that way with kerb= to indicate the type of kerb? > I believe that to be an acceptable method. Howeve

Re: [Tagging] Storm drains

> >manhole=drain is clearly wrong I would say. > Around here most of the storm drains are identical in appearance to regular manholes: > round, about 60 cm diameter, flat on the asphalt, with a removable 2-3 cm thick iron lid - > the lid is just perforated. Seem's there's no picture in the wiki,

Re: [Tagging] Storm drains (was Feature Proposal - RFC - Kerb)

I've been digging through the wiki and taginfo too since I read your last post. Haven't found anything either. I guess nobody has bothered tagging storm drains yet? manhole=drain is clearly wrong I would say. I'll probably go with man_made=storm_drain if I don't find anything better.

Re: [Tagging] Feature Proposal - RFC - Kerb

I assume that if I have a way that runs along the physical location of the kerb (e.g. because it's a closed way or part of a multi-poly that's used to define a landuse area) I could tag that way with kerb= to indicate the type of kerb? In that case, how should the type of kerb shown in this imag

<    1   2