Re: [Tagging] new access value

On 09.10.2015 23:44, Richard Fairhurst wrote: > Friedrich Volkmann wrote: >> Contribute something useful, or get a life. > > Please retract that insult, and agree not to post such comments in the > future, or you will be removed from this list. What insult? Do you mean me or h

Re: [Tagging] new access value

On 09.10.2015 23:42, ajt1...@gmail.com wrote: >>> localised meaning does not always have to be parsed into universal >>> tags. >>> >>> Here in the UK we have very specific access legislation for paths. On a >>> bridleway, for example, cycling is permitted, but cycle racing is forbidden, >>> and

Re: [Tagging] new access value

On 08.10.2015 12:16, Lauri Kytömaa wrote: (...a lot. I try to narrow it down to the critical passages.) > sometimes the signs restrict the > traffic by "who", not by destination. I.e. in the Anreinerverkehr case, > [...] it's no longer about the destination, but which > group of people you, or

Re: [Tagging] new access value

On 08.10.2015 16:05, Marc Gemis wrote: > Just as your new value. That is not documented neither. A new value or a new > key, both have to be documented and implemented. A new tag value fits more into an existing tagging scheme than a new key. Some applications (such as even the standard

Re: [Tagging] new access value

On 08.10.2015 04:21, John Willis wrote: > How do they enforce it in Europe? Stickers on cars? Stop and ask? In cities, there are lots of 30 km/h speed limits, oneways and traffic_calming=* to deter cutters. Parking requires a sticker on the car. Residents need to pay for it (around 150 €/year in

Re: [Tagging] Shop values review

On 07.10.2015 20:26, Matthijs Melissen wrote: > On 7 October 2015 at 15:58, Daniel Koć wrote: >> builder > > Not sure what this is used for. I have mapped some craft=builder. Small offices, maybe with some storage for tools and construction materials. shop=* seems wrong. >>

Re: [Tagging] new access value

On 06.10.2015 23:11, John Willis wrote: > > >> On Oct 6, 2015, at 8:48 PM, Friedrich Volkmann <b...@volki.at> wrote: >> >> So if "destination" excludes off-wanderers and sightseers, what tag do you >> use when you need to include them? > > Yes

Re: [Tagging] new access value

On 06.10.2015 21:41, Florian Lohoff wrote: > Sorry - no - All of them are *=destination. Don't be sorry. Think forward. Help find a name for the missing tag. > If you include them? What would be the legal sign? I know > of none. You can put up signs which say - "Redheads only on > mondays" but

Re: [Tagging] new access value

On 06.10.2015 19:31, Florian Lohoff wrote: >> So if "destination" excludes off-wanderers and sightseers, what tag do you >> use when you need to include them? > > Whats the possible signage which can induce that? "no through traffic" "no thru traffic" "local traffic only" In Austria: Fahrverbot

Re: [Tagging] new access value

On 06.10.2015 07:15, Marc Gemis wrote: > And (Flemish) Dutch "aangelanden (verkeer)". > > We also have the difference between > "uitgezonderd plaatselijk verkeer" = "except destination" > "uitgezonderd aangelanden" = "except 'visitor'" > > and I even saw > > "uitgezonderd bewoners" = "except

Re: [Tagging] new access value

On 06.10.2015 02:08, Georg Feddern wrote: > Am 05.10.2015 um 12:01 schrieb Friedrich Volkmann: >> Many people have been using (motor_)vehicle=destination for this, but that's >> just wrong, because "destination" would mean that you are allowed to drive >> in

Re: [Tagging] new access value

On 06.10.2015 08:47, Colin Smale wrote: > Instead of trying to translate the words on the signs, why look at what the > relevant laws say. There is only room on the sign for one or two words, but > in the laws which define the signing there will/may be more detailed > definitions of what is meant;

Re: [Tagging] new access value

On 06.10.2015 09:04, Marc Gemis wrote: > And the Dutch/Flemish "plaatselijk verkeer" is better translated as > "local traffic"; now what the hell is the (legal) definition of that? > > Same as the Dutch bestemmingsverkeer I assume. I wouldn't assume that. > inhabitants, visitors,

Re: [Tagging] new access value

On 06.10.2015 10:35, Martin Koppenhoefer wrote: > would you be permitted if you wanted to ask for hotel pricing? Or room > availability? Yes. Asking means contact, and that's what it is about. > Many people have been using (motor_)vehicle=destination for this, but > that's > just wrong,

Re: [Tagging] new access value

On 06.10.2015 10:45, Simon Poole wrote: > Your Anrainer vs. Anrainerverkehr example for AT doesn't seem to be any > different than the Anwohner/Anlieger difference in DE, which > semantically for routing purposes boils down to private/destination > (which I suspect most routers wouldn't actually

Re: [Tagging] new access value

On 06.10.2015 11:09, Colin Smale wrote: > So to summarise, you are proposing a new value for access=*, which has some > overlap with "destination", "delivery" and "private" (and others), There is no overlap with "destination", although many mappers mix it up. Of course there is overlap with

Re: [Tagging] new access value

On 06.10.2015 11:29, Martin Koppenhoefer wrote: > I wouldn't do that, but I'd rather make it the opposite way (state that > destination does require contact). That would change the meaning of the tag, and how would you tag "Zufahrt gestattet" (or "Durchfahrt verboten" or "ausgenommen Ziele in

Re: [Tagging] new access value

On 06.10.2015 11:58, Simon Poole wrote: > Am 06.10.2015 um 11:29 schrieb Friedrich Volkmann: >> ... >> It's *not* destination, see my other posts. >> To put it more clearly: >> "destination" targets a location, while Anrainerverkehr targets people. >> You

Re: [Tagging] new access value

On 06.10.2015 12:25, Martin Koppenhoefer wrote: > Am 06.10.2015 um 12:10 schrieb Simon Poole >> Anrainer seems to be clearly covered by private Correct. > "private" is "Only with permission of the owner on an individual basis" > this is kind of vague, but from what it says literally it clearly

Re: [Tagging] new access value

On 06.10.2015 13:06, johnw wrote: > Destination is very good, because it implies people who are going to a > destination on that street/area. not free to roam around, not free to park > and wander off. > > =Destination is for people *visiting* the destination the road services. it > doesn’t

[Tagging] new access value

I intend to write a proposal for a new access=* value, but I don't know a reasonable tag name. So I'm asking you for suggestions. We need the tag for Austrian road signs labelled "ausgenommen Anrainerverkehr" or "ausgenommen Anliegerverkehr", where "ausgenommen" means "excepted" and

Re: [Tagging] new access value

On 05.10.2015 14:19, Simon Poole wrote: > IMHO you are translating far far too literally and trying to infer a legal > meaning from that translation creating an unnecessary and likely > make-believe edge case. I don't know what translation you are talking about, but this has been exhaustingly

Re: [Tagging] Immigration, asylum, refugee centers

On 24.09.2015 08:18, Warin wrote: > I have 'synced' the wiki page > https://wiki.openstreetmap.org/wiki/Tag:office%3Dgovernment with the Russian > source page. > It now reflects the use of the sub tag government= as documented on the > Russian page. Why does the yellow box say that the English

Re: [Tagging] Delete not marked walking routes?

On 20.09.2015 08:45, Pee Wee wrote: > What do you think? > > Is is OK to have (walking) routes in OSM that have no visible marks on the > ground and if so under what conditions? First of all, we need to distinguish ways and relations. A path may be visible or invisible, and a route may be

Re: [Tagging] [OSM-talk] Proposed mechanical edit: surface=soil to surface=dirt

On 01.09.2015 10:38, Anders Fougner wrote: > My proposal in case someone wants to help beginners with the surface tag: > *Illustrate* the surface hierarchy somewhere in the OSM wiki (e.g. at > ). > Right now the hierarcy is not illustrated, it is

Re: [Tagging] [OSM-talk] Proposed mechanical edit: surface=soil to surface=dirt

On 31.08.2015 12:41, moltonel 3x Combo wrote: > If you do want to consolidate tags, "earth" is a much better synonym > of "soil" and you should probably use that instead. It's not a synonym either. The wiki said for years that surface=ground is "probably the same as surface=ground", and now it

Re: [Tagging] [OSM-talk] Proposed mechanical edit: surface=soil to surface=dirt

On 31.08.2015 11:51, Christoph Hormann wrote: > On Monday 31 August 2015, Mateusz Konieczny wrote: >> See >> http://wiki.openstreetmap.org/wiki/Mechanical_Edits/Mateusz_Konieczny >> /surface%3Dsoil_to_surface%3Ddirt >> >> I plan to change surface=soil to surface=dirt. surface=soil is a >> clear

Re: [Tagging] waterway=derelict_canal

On 27.08.2015 13:51, Andy Townsend wrote: On 27/08/2015 12:15, Friedrich Volkmann wrote: There's no point in a disused:foo=bar namespace. That's either historical mapping or hiding from the renderer, both of which are wrong in OSM. Er, no. A disused:amenity=pub is something that still

Re: [Tagging] waterway=derelict_canal

On 26.08.2015 15:16, Chris Hill wrote: No, a pub that is closed is simply not open for business until it reopens the next day. A pub that is disused is no longer a pub. What about a pub that is closed for 2 months? What's the limit? Anyway, we have two points of view: 1) It's still a pub. In

Re: [Tagging] waterway=derelict_canal

On 24.08.2015 22:49, Chris Hill wrote: I think that 'disused=yes' is a dangerous tag and should be avoided. Suppose someone uses foo=bar + disused=yes. Someone else searches for foo=bar, he will find the objects with and without disused=yes. That's fine, because disused objects are still

Re: [Tagging] landcover=trees definition

On 17.08.2015 00:29, John Willis wrote: This is the crux of the landcover argument. Because landuse=* implies what the land is used for - therefore man-altered and decided usefulness. natural=* was then interpreted by taggers to be the opposite - the natural state of the land which was

Re: [Tagging] landcover=trees definition

On 16.08.2015 09:06, Martin Koppenhoefer wrote: I'm not very good at refraining from replying to trolls, but I think this time I have to do it... This is not the first time you refrain from replying when it comes to a definition of your landcover=* key. You simply have not managed to make up a

Re: [Tagging] landcover=trees definition

On 16.08.2015 04:00, Daniel Koć wrote: http://wiki.openstreetmap.org/wiki/Landcover There is no definition of the landcover=* key. The page features a wide range of keys including amenity=* and tourism=*. Even if there were a definition, it would be the wrong place. The definition belongs to

Re: [Tagging] landcover=trees definition

On 10.08.2015 12:29, Jean-Marc Liotier wrote: A pity - I just happen to have a problem that this proposal would solve... Take a look at this charming corner of Normandy: http://binged.it/1ht3p7v On the left, a dense urban location that is clearly landuse=residential. On the right, what is

Re: [Tagging] landcover=trees definition

On 16.08.2015 01:24, Martin Koppenhoefer wrote: grass isn't a use, landuse=grass is nonsense.(IMHO) Why, the land is used to grow grass. Thus, landuse=grass. landcover=x doesn't mean there is only x, it says the area appears as covered with x That depends on observation time. E.g. much of

Re: [Tagging] landcover=trees definition

On 03.08.2015 00:55, Daniel Koć wrote: I have just discovered that while landcover=trees has no Wiki page, it's quite established tag (I wouldn't say popular here, because it's just about 1% of forest/wood uses) and we could officially define as a generic tag for trees areas, when it's not

Re: [Tagging] Multiple values with semicolons (was: Voting - Blood donation 2)

On 20.07.2015 10:55, Marc Gemis wrote: On Mon, Jul 20, 2015 at 10:32 AM, Ruben Maes ruben.mae...@gmail.com mailto:ruben.mae...@gmail.com wrote: He proposes to use a semicolon-separated list, e.g. donation:compensation=payment;vouchers. There is also a third option: Dropping the pure

[Tagging] oil binding agent?

I am looking for the English term for granulate that is made to absorb oil that was spilled due to a leak or a vehicle accident and threatens ground water. The granulate is often stored in boxes along forest tracks in water protection areas. In Austria, the boxes are labelled ÖLBINDEMITTEL, which

Re: [Tagging] Feature Proposal - Voting - Grave

On 09.07.2015 13:49, Martin Koppenhoefer wrote: are you aware of the key tomb? http://wiki.openstreetmap.org/wiki/Proposed_features/tombs This is just a draft. It should be marked as abandoned, as you have not made an RFC for 4 years. and historic=tomb This has never been approved. The main

Re: [Tagging] access=student and entrance=inter-building: comments?

On 08.06.2015 08:52, johnw wrote: A month or so ago, new entrance=types came up, and I thought I had a couple new values for entrance. I’ve been thinking about them, and had these two ideas. Please comment on both. 1) Access=student - access designated for students of a

Re: [Tagging] How to tag a Driver and Vehicle Licensing Agency (US:DMV)

On 08.06.2015 16:48, Andreas Goss wrote: https://en.wikipedia.org/wiki/Driver_and_Vehicle_Licensing_Agency office=government name=Driver and Vehicle Licensing Agency short_name=DVLA https://en.wikipedia.org/wiki/Department_of_Motor_Vehicles office=government name=Massachusetts Registry of

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

On 10.05.2015 22:48, Eugene Alvin Villar wrote: Then there should be an effort to standardize the possible values of designation=* when applied to administrative entities. I think your current proposal is a good time to discuss that. The resulting standardized tags would need to be included in

[Tagging] Feature Proposal - Voting - admin_title=*

On 17.12.2014 16:25, I wrote: This is about a new attribute for administrative devisions. http://wiki.openstreetmap.org/wiki/Proposed_features/admin_title So far there were 3 alternative suggestions, which all have their drawbacks: 1) official_status: It remains unclear what the prefix means

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

On 10.05.2015 10:38, Eugene Alvin Villar wrote: I prefer designation=* since it it already a widely used tag that fits the intended purpose of the proposed admin_title=* tag. The question on whether the value should be human-readable or machine-readable can be solved by using correspondence

Re: [Tagging] RFC - Criteria for taging as either via_ferrata or path

On 24.04.2015 11:01, Richard Z. wrote: On Fri, Apr 24, 2015 at 04:27:23AM +0200, Friedrich Volkmann wrote: On 24.04.2015 02:16, Warin wrote: Via ferrata should not be lumped into path or footway .. they are very significantly different and cannot be used in place of a path or footway. Would

Re: [Tagging] RFC - Criteria for taging as either via_ferrata or path

On 24.04.2015 05:02, Warin wrote: The essence of a modern via ferrata is a steel cable which runs along the route and is periodically (every 3 to 10 metres (9.8 to 32.8 ft)) fixed to the rock. So you certainly agree that this is safer than an unsecured path. Nevertheless, a ferrata cannot be

Re: [Tagging] RFC - Criteria for taging as either via_ferrata or path

On 24.04.2015 02:16, Warin wrote: Via ferrata should not be lumped into path or footway .. they are very significantly different and cannot be used in place of a path or footway. Would you take a 3 year old along it? Did you read the discussion tab? Farratas are not more difficult nor more

Re: [Tagging] RFC - Criteria for taging as either via_ferrata or path

On 23.04.2015 11:59, Richard Z. wrote: there were ongoing discussions concerning this subject so I have ammended the wiki: http://wiki.openstreetmap.org/wiki/Proposed_features/via_ferrata#Criteria_for_taging_as_either_via_ferrata_or_path use highway=via_ferrata where people commonly use

Re: [Tagging] Way inside riverbank

On 14.04.2015 15:59, moltonel 3x Combo wrote: Changing topics, I've just stumbled on the wiki on the natural=water, water=river tagging that I wasn't aware of and is supposed to replace waterway=riverbank. 4 years after being approved, it still represents only about 3% of the riverbank

Re: [Tagging] inuse, defacto

On Fri, Apr 17, 2015 at 12:54 PM, Friedrich Volkmann b...@volki.at wrote: I recently came across a never proposed tag with some 600 uses marked de-facto. If that's the way to bypass the proposal process, I will never care about proposals any more. How do you know there was any intent

Re: [Tagging] Feature Proposal - RFC - trailhead

On 16.04.2015 06:25, Dave Swarthout wrote: But I'd be willing to bet that most trails are not part of a network of other trails or a route but are stand-alone. The trails I once hiked in the Adirondack Mountains in New York State all have names and trailheads but, with a couple of exceptions,

Re: [Tagging] Defacto: man_made=storage_tank

On 15.04.2015 11:54, Martin Koppenhoefer wrote: People put building=* on any structure +1, and I am fine with it, just wanted to comment on not all tanks are buildings and point out that in OSM all structures are buildings. Bridges? Masts? Fences? Rails? Flagpoles? Power lines? Maybe

Re: [Tagging] Feature Proposal - RFC - trailhead

On 14.04.2015 23:32, Gmail wrote: role=start is used for crosscountry ski routes relations. I like the idea to include trailheads as members of route relations. It's a more versatile approach than highway=trailhead. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse

Re: [Tagging] Fuel shops

On 23.03.2015 15:11, Martin Koppenhoefer wrote: 2015-03-23 14:55 GMT+01:00 Friedrich Volkmann b...@volki.at mailto:b...@volki.at: Ok, if it's only 2 or 3 liters, it's not really a fuel station, but rather a shop=car_parts. 2 liters of fuel are as much car_parts as a bakery

Re: [Tagging] Fuel shops

On 23.03.2015 11:02, Dave Swarthout wrote: An amenity is something the /general public/ might like or use or want to visit. These little shops are definitely not that. They sell small quantities of fuel, usually 2 or 3 liters, to local motorcycle drivers. That's why the general public might

Re: [Tagging] Proposal : Move smoking tag to active status

On 21.03.2015 01:54, Bryce Nesbitt wrote: Any objection to moving: http://wiki.openstreetmap.org/wiki/Proposed_features/Smoking because it is heavily used and obviously well established. I object. The feature page should document actual usage, and actual usage differs from proposed usage.

Re: [Tagging] Fuel shops

On 20.03.2015 00:48, Warin wrote: On 20/03/2015 9:39 AM, Bryce Nesbitt wrote: On Thu, Mar 19, 2015 at 3:01 PM, Andy Mabbett a...@pigsonthewing.org.uk mailto:a...@pigsonthewing.org.uk wrote: amenity=fuel fuel=bottled Which would render indistinguishable from a full service fuel

Re: [Tagging] Fuel shops

On 23.03.2015 15:36, Martin Koppenhoefer wrote: 2 liters of fuel are as much car_parts as a bakery is bicycle_parts. The definition says: A place selling auto parts, auto accessories, motor oil, car chemicals, etc. That fits perfectly. can you expand? Someone sitting

Re: [Tagging] Accepted or rejected?

On 18.03.2015 07:29, David Bannon wrote: And amazing how many people vote, compared to those that take part in the discussion. Indeed. I find that strange. I'd never vote on something I did not have an opinion on. And, as you lot know, if I have an opinion, I share it ! Maybe people just

Re: [Tagging] Increasing voting participation (Was Accepted or rejected?)

On 18.03.2015 14:36, fly wrote: Am 18.03.2015 um 12:55 schrieb Martin Vonwald: 2015-03-18 12:47 GMT+01:00 Markus Lindholm markus.lindh...@gmail.com: A thought, how difficult would it be to include in the wiki-page how many different mappers have actually used a specific tag. Perhaps via

Re: [Tagging] Accepted or rejected?

On 18.03.2015 23:09, Warin wrote: A person coming across something that they want to map and then finding it on the wiki .. If that person is not on the tagging group then they don't want to be concerned with making tags, they simply want to use them. Compare it to politics. Many people don't

Re: [Tagging] Accepted or rejected?

On 18.03.2015 22:40, Warin wrote: Firstly I see no point in casting a vote of 'abstention'.. why vote at all? An abstention indicates that someone has neither a strong positive nor negative feeling even after pondering. The world is not just black and white. When you look at my abstention

Re: [Tagging] Accepted or rejected?

On 18.03.2015 22:50, Warin wrote: I agree that a 'forum' is far better at engaging a community ... keeps topics more organised as replies are localised (that are no isolated branches for instance), avoids the 'digest mode' problem, some even have a system of not viewing post by someone they

Re: [Tagging] Accepted or rejected?

On 14.03.2015 21:11, Bryce Nesbitt wrote: On Sat, Mar 14, 2015 at 12:13 PM, Kotya Karapetyan kotya.li...@gmail.com mailto:kotya.li...@gmail.com wrote: Proposal: let's change it to 8 unanimous approval votes or 10 or more votes with at least 74 % approval ones? +1 on that.

Re: [Tagging] Accepted or rejected?

On 14.03.2015 21:27, Clifford Snow wrote: I would suggest adopting Conditional Approval approach. If the proposal receives sufficient votes, it becomes Conditionally Approved. Only after it becomes widespread and adopted by JOSM and iD it becomes an Approved tag. No. Editor developers aleady

Re: [Tagging] Accepted or rejected?

On 14.03.2015 12:50, Dan S wrote: When there is very low interest (i.e. very few votes) - which is pretty common - then even one dissenting vote is enough to make us step back and think again, whereas if there are enough votes to make majority approval a meaningful concept (I admit that 15 is

Re: [Tagging] Accepted or rejected?

On 14.03.2015 12:24, Jan van Bekkum wrote: The guideline to determine if a proposal is accepted is A rule of thumb for enough support is /8 unanimous approval votes/ or /15 total votes with a majority approval/, but other factors may also be considered (such as whether a feature is already

Re: [Tagging] Current status of the key smoothness=*

On 11.03.2015 23:23, David wrote: I am a little unsure what the problem is with the pictures. Could you be a bit more specific please Friedrich ? It would be very hard to have a set of pictures that cover every case but, as Jan said, if we are only one level out, thats still very useful

Re: [Tagging] square_paving_stones:width

On 11.03.2015 17:18, Mateusz Konieczny wrote: As described in paving_stones:n thread there is a problem with surface=paving_stones:integer values. To offer better alternative for storing information about size of square paving stones I am proposing this tag. What about rectangular paving

Re: [Tagging] Current status of the key smoothness=*

On 11.03.2015 17:29, Jan van Bekkum wrote: Perhaps we can extend the library of pictures in the wiki to give people a better feeling which rating means what. I agree that work on the pictures is needed. The values and their verbal descriptions are approved, and they look sound, while the bogus

Re: [Tagging] Leaf type of palm for leaf_type

On 10.03.2015 21:41, Bryce Nesbitt wrote: I'm seeking comments on adding palm to the leaf types at http://wiki.openstreetmap.org/wiki/Key:leaf_type A rendering engine can equate palm and broadleaved. Mappers are mapping palms very frequently, and having this key name I think would reduce

Re: [Tagging] Leaf type of palm for leaf_type

On 11.03.2015 17:58, Mateusz Konieczny wrote: It's all driven by technocrats who have no clue about what a tree or forest looks like in the real world. Small note, phrases like this are unlikely to be a good idea. Let's assume that technocrats don't read this. :-) -- Friedrich K. Volkmann

Re: [Tagging] Current status of the key smoothness=*

On 11.03.2015 12:56, jgpacker wrote: Is this claim over it's verifiability still current? Yes, it is, because the photos contradict the verbal value definitions. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

[Tagging] Feature Proposal - RFC - courtyard

On 13.02.2015 13:21, Friedrich Volkmann wrote: I'm now in favour of man_made=courtyard, because it is man made (as opposed to natural) without doubt, and it is similar to man_made=cutline. Both cutlines and courtyards are intentionally empty spaces, and both are only defined

Re: [Tagging] Feature Proposal - RFC - register

On 06.03.2015 12:09, Paul Johnson wrote: May be related to the United States Department of Agriculture's National Forest Service use permits. Typically a small wooden box with some pencils and waterproof application cards inside, on which you are either strongly encouraged or legally

[Tagging] Feature Proposal - RFC - register

http://wiki.openstreetmap.org/wiki/Proposed_features/register This is for books where people enter their names, routes and comments. These books are located on peaks, along trails, in buildings and in caves. In German we call them Gipfelbuch, Steigbuch, Hüttenbuch, Gästebuch, Höhlenbuch,

Re: [Tagging] Canopy radius for natural=tree

On 25.02.2015 11:47, Martin Koppenhoefer wrote: it is using the natural language notation with space (underscore) rather than diameter:crown. I feel that this differentiation became blurry due to the random use of : and _ for _type and :type suffixes. -- Friedrich K. Volkmann

[Tagging] Feature Proposal - RFC - goods_conveyor

http://wiki.openstreetmap.org/wiki/Proposed_features/Goods_conveyor I resurrected this old draft, because we need a tag for this and I know of no alternative tag currently in use. I wonder if goods may be misleading, because I think of goods as finished products, while many conveyors carry raw

Re: [Tagging] Feature Proposal - RFC - goods_conveyor

On 25.02.2015 15:42, Martin Koppenhoefer wrote: is this for belt conveyors and roller conveyors? There are also pneumatic conveyors (with tubes, e.g. postal pneumatic tubes) and there are chain conveyors. See the subtags section in the proposal. By proposal I mean the wiki page. -- Friedrich

Re: [Tagging] Feature Proposal - RFC - goods_conveyor

On 25.02.2015 17:16, Richard Z. wrote: there is aerialway=magic_carpet which is intended for human transport only but together with usage access keys could be used to tag that as well. I don't think so, because: - goods conveyors are not really aerialways - goods conveyors are not called magic

Re: [Tagging] Canopy radius for natural=tree

This construct does not come from a natural language. It's rather computer programming style, like class::subclass (see maxwidth:physical=*, name:en=* etc.), and it's also in spirit of mathematical notation (functions, subscripts), like diameter(crown). On 23.02.2015 23:48, Colin Smale wrote: No

Re: [Tagging] courtyards

On 09.02.2015 16:01, Stephen Gower wrote: Here in Oxford (where we have many examples of named quadrangles/courtyards) I see examples where they are tagged as highway=footway areas (e.g. http://www.openstreetmap.org/way/301895528 ) but more often the central section of lawn has been named

Re: [Tagging] courtyards

On 08.02.2015 22:17, Warin wrote: From a technical point of view they are typically associated with fire protection (way to leave the building, access for firefighters), If the courtyard is fully enclosed by buildings or by one building .. they are not part of a fire escape (protection),

[Tagging] courtyards

Courtyards use to be mapped as inner members of building multipolygons. We can also use the multipolygon relation to assign a name to the bullding. If we want to assign a name to the courtyard, we must assign it to the way. But then we need some kind of physical tag in addition. Applications won't

Re: [Tagging] patron saints

On 29.01.2015 13:24, Satoshi IIDA wrote: +1 to use wikidata. I had once thinking about same purpose. :) https://wiki.openstreetmap.org/wiki/Proposed_features/enshrine Sorry that I missed your proposal. Indeed, it seems that the wikidata id makes the tagging of related enshrines superfluous,

Re: [Tagging] patron saints

On 28.01.2015 05:01, John F. Eldredge wrote: On 01/25/2015 10:29 AM, Friedrich Volkmann wrote: Probable all christian churches (buildings) and most chapels are dedicated to patron saints. E.g. the Basilica Sancti Petri (Saint Peter's Basilica) in Vatican City is obviously dedicated to Sanctus

Re: [Tagging] patron saints

On 28.01.2015 12:34, Andy Mabbett wrote: There are sometimes more than one saint with the same name, This is where Wikidata tags provide useful disambiguation. You can either tag with: wikidata = Q12512 (resolves to https://www.wikidata.org/wiki/Q12512 ; the item for Saint Peter's

[Tagging] patron saints

Probable all christian churches (buildings) and most chapels are dedicated to patron saints. E.g. the Basilica Sancti Petri (Saint Peter's Basilica) in Vatican City is obviously dedicated to Sanctus Petrus (Saint Peter). As in this example, the patron saint is often part of the common name of a

Re: [Tagging] patron saints

On 25.01.2015 19:07, André Pirard wrote: I think that, when they have a name=* tag (when the mapper cared to find it, easy, they're all here (unités pastorales) http://liege.diocese.be/), almost all churches around here are tagged with the dedication. Looking at Liège in OSM, I see names like:

Re: [Tagging] Shop for watches

On 25.01.2015 11:46, Severin Menard wrote: I did not find anything on the Map Features regarding shop selling watches, what is quite common both in Europe and South America (at least). shop=jewelry Watches came out of use when people got mobile phones. The only remaining reason to wear watches

Re: [Tagging] patron saints

On 25.01.2015 23:30, Eugene Alvin Villar wrote: On 1/26/15, Lukas Sommer sommer...@gmail.com wrote: And I think it makes sense to define explicitly some things in the documentation. Things like – use always (or use never) “Saint”: “Saint Paul” vs “Paul”. That's a good point. In German, there

Re: [Tagging] Feature Proposal - RFC - addrN:*

On 21.01.2015 08:28, Markus Lindholm wrote: Before we get carried away by a zillion relations I think we have to answer the questions as to what purpose do we want to explicitly associate an address with a POI or a building. Is it so that the data consumer can find her way to a POI? That's

Re: [Tagging] Feature Proposal - RFC - addrN:*

On 22.01.2015 04:02, John F. Eldredge wrote: If you have a strictly delimited plot of land, with no house currently built upon it, but which is intended for later construction, does it have a house number? Or is the address only assigned once a building is built? When it is already intended

Re: [Tagging] AddrN

On 19.01.2015 12:06, Paul Johnson wrote: This seems like a particularly strange edge case for the address scheme, but I'm curious if any of those valid addresses are consider the primary? Usually the postal address which you give in your official documents is considered the primary. But this

Re: [Tagging] AddrN

On 21.01.2015 13:00, Andrew Shadura wrote: if that's the case, what's wrong with creating a node on the building for each additional valid address? People looking for an amenity could look up closest POIs after finding a secondary address. It's not a clean situation, It's a best guess

Re: [Tagging] AddrN

On 19.01.2015 17:41, Clifford Snow wrote: If these are conscription numbers, why not use the addr:conscriptionnumber tag? It is document in the wiki [1] and appears to be in use. It would also appear more accurate and less likely to lead to misuse. [1]

Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists

On 19.01.2015 12:10, Richard Z. wrote: ##== Disadvantages of semicolon separated lists == ##* parsing of values is required sure parsing is required. How terribly difficult is it to split a string by ;? It's trivial. Xxzme is one of those mappers who try to design tagging rules

Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists

On 21.01.2015 02:51, Никита wrote: payment=efectivo;visa;mastercard;american␣express payment=mastercard;visa;efectivo Now try to find *efectivo *with your regexes. With a perl regex: ^[^=]+=(.*;)?\s*efectivo\s*(;.*)?$ Usually you only have the value in your variable, so you only need:

Re: [Tagging] Feature Proposal - RFC - addrN:*

On 19.01.2015 12:37, Markus Lindholm wrote: Treating addresses as attributes might be fast and convenient but that kind of scheme becomes incoherent as there is no one-to-one relationship between addresses and other features. E.g. - There are MULTIPLE POIs that all relate to ONE address -

Re: [Tagging] Feature Proposal - RFC - addrN:*

On 19.01.2015 12:47, Andrew Shadura wrote: It doesn't actually matter if you agree or not, because it doesn't change the fact that buildings in CZ and SK don't have multiple addresses. I cannot judge this. If this is a fact, addr2 is not needed or even plain wrong for conscription numbers in CZ

  1   2   3   >