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 can

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

Re: [Tagging] new access value

On 09.10.2015 13:39, Richard Fairhurst 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 cannot be auth

Re: [Tagging] new access value

On 09.10.2015 08:30, Marc Gemis wrote: > You didn't read my complete mail then. I wrote that it would be better to > use something like access:destination:traffic_sign=... > because I realised that traffic_sign on a road would be a bad idea. With access:destination:traffic_sign=* you get the same

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

Re: [Tagging] new access value

On 08.10.2015 14:59, Florian Lohoff wrote: > You dont get it dont you? This quarrel is pointless. Contribute something useful, or get a life. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Tagg

Re: [Tagging] new access value

On 08.10.2015 11:49, Marc Gemis wrote: > Why don't you tag it with access=destination in combination with a > traffic_sign=xxx ? Because traffic_sign=* does not change the meaning of access tags. These tagging approaches are completely independent of each other. The traffic sign approach will ne

Re: [Tagging] new access value

On 08.10.2015 07:05, Marc Gemis wrote: > While this missing tag might be theoretically useful, I wonder how you car > navigation will benefit from it ? > Will it start by "Hallo Mary, you want to drive to X street, but there is a > "people living there and their visitors only access restriction and

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

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 th

Re: [Tagging] new access value

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

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

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 do

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

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: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 "deliv

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 di

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

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

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

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 disc

[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 "Anrainerverke

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 ver

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 actuall

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 just

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

On 01.09.2015 10:13, moltonel 3x Combo wrote: > But as a user of surface=soil, could you tell me what difference you > see between soil and earth (from an osm POV) ? To me, those two are > actual osm synonyms, but 'earth' is documented and 55x more popular. See my other message (Message-ID: <55e55

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 inc

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 dup

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 disuse

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

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 th

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

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

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 no

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 i

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 > wrote: > > He proposes to use a semicolon-separated list, e.g. > donation:compensation=payment;vouchers. There is also a third option: Dropping the pure donation:compens

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

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 scho

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 Mo

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

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

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

Re: [Tagging] Meeting point

On 24.04.2015 18:18, Mateusz Konieczny wrote: >> tourism=information > > It makes no sense, as this tag means "Information for tourists and > visitors". And meeting points is something else. > > I would tag it as meeting_point=yes (as it is not only for tourism). I have only seen it in touristic

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

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

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 us

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 d

Re: [Tagging] inuse, defacto

>> On Fri, Apr 17, 2015 at 12:54 PM, Friedrich Volkmann 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 mo

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

[Tagging] inuse, defacto

As you all know, Template:Proposal_Page (used in proposals) has another set of statuses than Template:ValueDescription (used in feature pages). The latter defines: inuse: the feature is in use defacto: the tag is in widespread use, but no formal proposal process has taken place Now that's quite a

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 exception

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 76-80/14

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

Re: [Tagging] Fuel shops

On 23.03.2015 15:11, Martin Koppenhoefer wrote: > 2015-03-23 14:55 GMT+01:00 Friedrich Volkmann <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 liter

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] 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 > > wrote: >> >> amenity=fuel >> fuel=bottled >> >> >> Which would render indistinguishable from a full service fuel station. T

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

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'

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 votes

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] 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 : >> >>> 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 >>> TagInfo. >> >> T

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 peop

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

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 develope

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 1

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 alr

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 usefu

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

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] 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: > values. To offer better alternative for storing information about size of > square paving stones I am > proposing this tag. What about rectangular paving stones

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 woul

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 __

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 obli

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

[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, Pilgerbuc

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 mag

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

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 http://

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

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

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

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

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

Re: [Tagging] patron saints

On 25.01.2015 23:30, Eugene Alvin Villar wrote: > On 1/26/15, Lukas Sommer 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 are name vari

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) ), > almost all churches around here are tagged with the dedication. Looking at Liège in OSM, I see names l

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

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 watche

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

  1   2   3   >