Re: [Tagging] maxwidth vs. maxwidth:physical vs. width

On 18/02/2015, Tobias Knerr wrote: > On 18.02.2015 10:39, moltonel 3x Combo wrote: >> Allow me to disagree: >> >> * maxheight is defined this way. Having maxwidth defined differently >> is asking for trouble. > > I agree with you that we should define all the ma

Re: [Tagging] maxwidth vs. maxwidth:physical vs. width

On 18/02/2015, Martin Koppenhoefer wrote: >> Am 17.02.2015 um 19:57 schrieb moltonel 3x Combo : >> maxfoo = min(maxfoo:physical, maxfoo:legal) > > -1, maxfoo was always defined as a legal restriction so this function should > go into your data evaluator but not be the rule

Re: [Tagging] maxwidth vs. maxwidth:physical vs. width

On 18/02/2015, Colin Smale wrote: > As lots of people frequently point out, what about emergency vehicles? > They can (often) ignore legal restrictions, but not physical ones: > > if(i_am_an_emergency_vehicle) > > maxfoo = min(maxfoo:physical, maxfoo:legal) > > else > > maxfoo = maxfoo:physical;

Re: [Tagging] maxwidth vs. maxwidth:physical vs. width

On 16/02/2015, Kytömaa Lauri wrote: > The width of the vehicle that could use the way can be wider than the way > itself [...] Another example where width != maxwidth:physical is a twisty tunnel. The longer a vehicle is, the more margin it requires to be able to pass. So a tunnel with width=2.5 c

Re: [Tagging] maxwidth vs. maxwidth:physical vs. width

On 16/02/2015, Martin Koppenhoefer wrote: > 2015-02-16 10:42 GMT+01:00 Martin Vonwald : >> * maxwidth: this is a legal limitation; nothing wider than the given >> value may use the feature > > +1, there is also the synonym "maxwidth:legal" (IMHO not advisable, as this > is the same than the more

Re: [Tagging] Electronic or 'e' cigarettes?

On 01/02/2015, Tac Tacelosky wrote: > Another legitimate terms for these shops is a "vape shop", and the practice > of using any sort of electronic cigarette is now referred to as "vaping". > This is a better term than "smoking", as the product emits vapors, not > smoke. > > We are enthusiastic ab

Re: [Tagging] length=

On 27/01/2015, Mike Thompson wrote: >> The way in OSM is only a (sometimes not precise) drawing of an existing >> feature and can be different from the reality. > > How precise is the value of the "length" tag? From what is the value > derived? In my experience of hiking trails in Ireland, the le

Re: [Tagging] Tagging Voting system- time for reform?

On 24/01/2015, Dave Swarthout wrote: > "Nobody votes because it's a borderline pointless endeavor." I'd like to defend the voting system a bit. In my opinion it's working fine. The only issue is that people have wrong expectations as to what voting provides. As has already been pointed out, ther

Re: [Tagging] Deprecation of associatedStreet-relations

On 25/01/2015, Andreas Goss wrote: > Fully borken or not. In my opinion a assiciatedstreet relation that does > not include every element is broken. At that point all the advantages > are gone. To me "breaking the relation" would mean that all the addresses it contains are now unusable. In your e

Re: [Tagging] Deprecation of associatedStreet-relations

On 25/01/2015, Marc Gemis wrote: > My experience is that it is very hard to place every house in the right > relation before you know the actual address. Especially with corner houses > and in rural areas where the driveways to the farms do not always connect > to the street with the address. > An

Re: [Tagging] Deprecation of associatedStreet-relations

On 24/01/2015, Andreas Goss wrote: > I really don't get this. If you are able to add house numbers, why would > you be likely to fuck up street names? If at all seeing addr:street when > on the ground is good, because you can be sure it's you are adding it to > the right building and can also fix

Re: [Tagging] Deprecation of associatedStreet-relations

On 24/01/2015, Tobias Knerr wrote: > On 24.01.2015 13:12, moltonel 3x Combo wrote: >> Recomended isn't mandatory. The name tag of associatedStreet is only >> of use to mappers (to find the relation in the editor), not consumers. > > Not mandatory, but still used in

Re: [Tagging] Deprecation of associatedStreet-relations

On 24/01/2015, Andreas Goss wrote: >> A novice user will hardly break an associatedStreet relation > > Remove house. Replace with new outline at the same place. Add tags > again. Done. associatedStreet relation broken. Your editor will probably hace displayed a warning at step 1. At the end of th

Re: [Tagging] Deprecation of associatedStreet-relations

On 24/01/2015, Tobias Knerr wrote: > On 23.01.2015 21:53, moltonel 3x Combo wrote: >> The counter-argument is that a novice is less likely to break the data >> when updating an area that is mapped using associatedStreet. I like >> the fact the fact that people need not even

Re: [Tagging] Deprecation of associatedStreet-relations

On 22/01/2015, Johan C wrote: > From an OSM point-of-view, which includes being friendly towards novice > users, relations should be avoided whenever possible. And associatedStreet > relations are avoidable. The counter-argument is that a novice is less likely to break the data when updating an a

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

On 23/01/2015, moltonel 3x Combo wrote: >> name=purple >> name#2=orange >> name#3=green >> >> How do you query for green in overpass? In JOSM? > > josm: name(#\d+)?=green > overpass: I don't know it enough Note that if "key#index=value" be

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

On 23/01/2015, Никита wrote: >> the classic example being the name key. > This is bad example. We have many tags with their own semantic: > http://wiki.openstreetmap.org/wiki/Names#Key_Variations We don't need > name_1, name_2 or name#1 or name#2 keys. Of course when you can figure out names that

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

On 23/01/2015, althio wrote: > Visually for index I would go for "#" or "-" but I don't know if that > is acceptable regarding special characters status. > > name=* > name#2=* > name#3=* I really like using '#' as the index separator. It is sometimes pronounced "number". It hasn't been used befor

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

On 22/01/2015, fly wrote: > Am 22.01.2015 um 21:32 schrieb Tod Fitch: >> key:1=value1 >> key:2=value2 >> key:3=value3 > > No not at all, this makes it worse. Numbers are way to general and you > gain little. > > : is usualy used for subkeys so key1, key2 would even be better. Subkeys are not alwa

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

On 22/01/2015, Tod Fitch wrote: > With respect objects that have multiple values for a key, the arguments seem > to come down to either: > > 1. key=value1;value2;. . . ,valueN > 2. key:value1=yes + key:value2=yes + . . . + key:valueN=yes 3. key=value > As a programmer I can parse either set usin

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

On 22/01/2015, Martin Koppenhoefer wrote: > a minor issue with semicolon separated lists: we don't have yet defined how > to escape actual semicolons in values. To me, that is actually a major issue (putting blank fields in the same basket). Defining how litteral semicolons and blank fields shou

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

On 22/01/2015, Charles Basenga Kiyanda wrote: > I have to add fuel to a heated discussion, but in the whole exchange on > whether or not semicolon lists should be allowed/used, the most obvious > example (to me) that requires semicolon lists was not mentionned, > namely: opening hours. That's pro

Re: [Tagging] Electronic or 'e' cigarettes?

On 22/01/2015, fly wrote: The wiki page is very recent with only two contributors. I wouldn't be surprised if "e-cigarette" in the db was also contributed by no more than 1-2 mappers. I suggest contacting them to make sure that they are ok with "e_cigarette", and then make the

Re: [Tagging] Electronic or 'e' cigarettes?

On 22/01/2015, Andreas Goss wrote: >> Using "-" instead of "_" goes against a very established tagging practice. > > Only for whitespace as far as I know. So I don't see a issue here. That surprises me, but looking at a dump of Ireland (taginfo search is too coarse, so I used some local data I ha

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

On 22/01/2015, Dmitry Kiselev wrote: > As I think, > > replace > key=val1;val2 > with > key: val1 =* > key: val2 =* key:subkey=* is only usable (or even recomended) for standardized subkeys. If instead you have a random value (like a road reference or a street name), another scheme

Re: [Tagging] Electronic or 'e' cigarettes?

On 22/01/2015, althio wrote: > Existing pages: value "e-cigarette" is referenced in the wiki. > > http://wiki.openstreetmap.org/wiki/Tag:shop%3De-cigarette > http://wiki.openstreetmap.org/wiki/Key:shop#Others Using "-" instead of "_" goes against a very established tagging practice. The wiki pag

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

On 19/01/2015, NopMap wrote: > > There seems to be an edit war on the wiki page > http://wiki.openstreetmap.org/wiki/Avoid_semi-colon_value_separator > > I personally think that the problem has been discussed many times and it is > well understood that semicolon lists only work for some special ta

Re: [Tagging] Ethnic shops

On 16/01/2015, Martin Koppenhoefer wrote: > ethnicity (total use 65) > http://taginfo.openstreetmap.org/keys/ethnicity Thanks for that, it's certainly better than convenience=*, I'll change my tagging. ___ Tagging mailing list Tagging@openstreetmap.org

Re: [Tagging] Ethnic shops

On 15/01/2015, Eric Sibert wrote: > Hi all, > > I'm wandering on how to tag shops that are offering services with > specific ethnic orientation. For instance: > - convenience specialized for Italian, Portuguese, Chinese products... > - clothes typical from one country/area > - hairdresser for Afri

Re: [Tagging] Basic philosophy of OSM tagging

On 16/01/2015, Pieren wrote: Historical contributors and leaders will tell you that there is no > "official committee" in OSM. But, to be a litle provocative, I would > say we already have two committees for tagging scheme: > - the JOSM presets maintainers > - the DWG AFAIK the DWG's influence o

Re: [Tagging] Basic philosophy of OSM tagging

On 14/01/2015, Warin <61sundow...@gmail.com> wrote: > Are 'we' tagging for > > What things are? eg highways > OR > What things are used for? eg amenity Why does it have to be one exclusive_or the other ? Both what things are and what they are used for is important. There's normally always a way to

Re: [Tagging] Boundary Relations. What's a subarea used for?

On 08/01/2015, Steve Doerr wrote: > On 08/01/2015 01:21, Dave F. wrote: > >> Are they relevant? If so, what are they for? The wiki suggests they're >> superseded: >> http://wiki.openstreetmap.org/wiki/Relation:boundary#Relation_members >> > > No it doesn't, it says they're 'optional, disputed, and

Re: [Tagging] Replying to raw digests considered harmful

On 28/12/2014, Paul Johnson wrote: > Could you please consider either subscribing to the nondigested version of > the mailing list or use > procmail to split each digest into it's constituent messages >

Re: [Tagging] oneway=no spams

On 28/12/2014, Ole Nielsen / osm wrote: > It depends. Sometimes it is useful to add this tag. I typically add it to > bidirectional cycle paths along roads as you would normally expect such > cycleways to be oneway. Adding a oneway=no indicates that it has been > surveyed and found to be bidirecti

Re: [Tagging] Mapping of kids areas

On 19/12/2014, Никита wrote: >> but of course you can map things more precisely. > Exactly this was discussed. I was only arguing for using "playground + subtags" instead of "playground vs children_area" and noting that "playground=yes" could be added to the main amenity instead of mapping the pl

Re: [Tagging] Mapping of kids areas

On 19/12/2014, Никита wrote: >> just tag the amenity with playground=yes. > > That doesn't work. We have a 20 km^2 airport. Will you really tag it with a > 20 km^2 playground (child_area)? Tagging playground=yes on an amenity is just intended as a tagging shortcut (like atm=yes), but of course yo

Re: [Tagging] Mapping of kids areas

On 19/12/2014, Никита wrote: > Instead of 4 or 10 tags in OSM, > real people use words: "детская площадка" (leisure=playground), "детская > игровая комната"(kids_area=*) - this is much simpler and native way to map > objects. This will work for short term, since we want to use kids_area. We > cann

Re: [Tagging] Mapping of kids areas

On 19/12/2014, Никита wrote: > Ok, lets try: > > leisure=playground (usually outdoor), kids_area (almost always indoor, esp > in Russia during winter) > leisure=playground (poor equipment, often vandal resistant), kids_area > (fragile or expensive equipment is not rare) > leisure=playground (almos

Re: [Tagging] Mapping of kids areas

On 19/12/2014, Martin Koppenhoefer wrote: > 2014-12-19 12:12 GMT+01:00 Никита : >> >> IMO, kids_area=* is prefered when you have bigger feature: >> >> name=Joe pub >> amenity=pub >> kids_area=yes >> kids_area:fee=no >> >> or explicitly using: >> amenity=kids_area >> fee=no >> operator=Joe pub >> o

Re: [Tagging] I don't like acronyms [fork from: access in the wiki]

On 04/12/2014, althio forum wrote: >>> - psv > public_service or public_transport >>> - hov > carpool >>> - hgv > heavy_goods >> >> while I would support this move, I think >> we should spell these out and not reduce the information >> so psv should become "public_service_vehicle", > > I think tha

Re: [Tagging] Various alt_name values?

On 29/11/2014, Lukas Sommer wrote: > Okay. I’ll try a summary: [...] Thanks for those insights. Note that this multiple-values discussion has gone beyond the alt_name key (which is itself a multiple-value key for the name key, making 'multiple alt_name values' kind of silly), so you should look

Re: [Tagging] Various alt_name values?

On 27/11/2014, Andy Mabbett wrote: > On 27 November 2014 at 11:59, moltonel 3x Combo wrote: > >> To me, the semincolon scheme as a general solution is a very bad idea, > >> Either the data user forgets to do the split, or he does it when it wasn't >> the

Re: [Tagging] Various alt_name values?

On 27/11/2014, Martin Koppenhoefer wrote: > 2014-11-27 12:59 GMT+01:00 moltonel 3x Combo : >> Either the >> data user forgets to do the split, or he does it when it wasn't the >> mapper's intent, or litteral semincolons in the data get in the way. > > Ye

Re: [Tagging] Various alt_name values?

On 27/11/2014, Colin Smale wrote: > Big +1 for that. -1. On what do you base your assumption that nominatim is the only software implementing numbered keys ? How is documenting what a major osm software does a bad thing ? For better or worse, the numbered keys scheme sees a good bit of use accor

Re: [Tagging] what does maxheight=none mean?

On 30/10/2014, Pieren wrote: > On Wed, Oct 29, 2014 at 6:24 PM, moltonel 3x Combo > wrote: > >> And both tags are >> definitive, whereas "maxheight:signed=no" (or whatever) is just >> waiting for a better tooled or experienced mapper to do the survey. >

Re: [Tagging] what does maxheight=none mean?

On 29/10/2014, Pieren wrote: > On Mon, Oct 27, 2014 at 8:21 PM, Friedrich Volkmann wrote: > >> (...) But when we see nothing, it's plain wrong to add something to the >> database. > > But it's a common practice today in OSM. It seems you missed the long > discussions about "noname=yes" or "oneway

Re: [Tagging] natural=bay as nodes are evil

On 29/10/2014, Richard Z. wrote: > On Tue, Oct 28, 2014 at 05:21:06PM +0100, moltonel 3x Combo wrote: >> On 28/10/2014, Richard Z. wrote: > well even if the issues were nonexistent, mapping the area of a bay seems > to me like mapping an artificially introduced concept for which

Re: [Tagging] natural=bay as nodes are evil

On 28/10/2014, Christoph Hormann wrote: > On Tuesday 28 October 2014, moltonel 3x Combo wrote: >> I admit I don't fully understand how your algorythm works. I can't >> imagine how you reduce everything to nodes and still retain >> information about orientation

Re: [Tagging] natural=bay as nodes are evil

On 28/10/2014, Richard Z. wrote: > On Tue, Oct 28, 2014 at 11:18:43AM +0100, Martin Koppenhoefer wrote: >> 2014-10-28 10:57 GMT+01:00 Richard Z. : >> >> The assumption is that a large bay will typically be more important than a >> smaller bay. For a good rendering you'd show only the more importan

Re: [Tagging] natural=bay as nodes are evil

On 27/10/2014, Christoph Hormann wrote: > Since for label rendering you don't really need a polygon there is > little point in actually generating it in the first place. But i have > implemented and used techniques not unlike the algorithm described for > rendering bay and strait labels, like in

Re: [Tagging] natural=bay as nodes are evil

On 27/10/2014, Christoph Hormann wrote: > On Monday 27 October 2014, Janko Mihelić wrote: >> >> Reverse geocoding. A boat comes to a bay, captain looks on a screen, >> and it says "You are in Guantanamo Bay". > > But this is exactly what does not work with a hand mapped polygon either > since the

Re: [Tagging] what does maxheight=none mean?

On 27/10/2014, Holger Jeromin wrote: > moltonel 3x Combo wrote on 27.10.2014 11:04: > >> * It can lead to mapping errors ... a bridge is >> added somewhere else, etc. > > The problem of outdated information is completely unrelated to this tag. I disagree, an importan

Re: [Tagging] natural=bay as nodes are evil

On 27/10/2014, Christoph Hormann wrote: > On Monday 27 October 2014, moltonel 3x Combo wrote: >> > >> > This extremely simple approach will probably result in reasonable >> > polygons for label placement in more than half the cases. You can >> > easily impr

Re: [Tagging] natural=bay as nodes are evil

On 27/10/2014, Richard Z. wrote: > On Mon, Oct 27, 2014 at 10:44:01AM +0100, moltonel 3x Combo wrote: >> I'm really curious what your method to figure out the bay area from >> the node is, because even as a human I find that most bay nodes can >> lead to many differen

Re: [Tagging] natural=bay as nodes are evil

On 27/10/2014, Christoph Hormann wrote: > On Monday 27 October 2014, moltonel 3x Combo wrote: >> I'm really curious what your method to figure out the bay area from >> the node is, because even as a human I find that most bay nodes can >> lead to many different interp

Re: [Tagging] what does maxheight=none mean?

On 27/10/2014, Martin Koppenhoefer wrote: > 2014-10-27 11:04 GMT+01:00 moltonel 3x Combo : >> The maxheight=* tag maps the physical limitation, not the sign (which >> can be absent or even wrong). Tagging maxheight=none really makes no >> sense. > > no, the m

Re: [Tagging] what does maxheight=none mean?

On 27/10/2014, moltonel 3x Combo wrote: > I'd even argue that tagging "I surveyed this but couldn't see a > limitation" is useless: the sign might get added later, some mapper > might be able to measure the maxheight, the value above 4m might be > important fo

Re: [Tagging] what does maxheight=none mean?

On 27/10/2014, Holger Jeromin wrote: > Tom Pfeifer wrote on 27.10.2014 10:20: > >> As said before I am not against keeping a record of a bridge being >> checked, >> just the value =none is misleading. >> >> Another problem is that the tag is on the way under the bridge, and >> not the bridge way i

Re: [Tagging] natural=bay as nodes are evil

On 26/10/2014, Christoph Hormann wrote: > I don't see what information is missing and cannot be easily determined > automatically with a properly placed node that is contained in an > area - except for the outer edge of course, which is usually > ill-defined though as you said yourself. > > If you

Re: [Tagging] what does maxheight=none mean?

On 26/10/2014, Tom Pfeifer wrote: > Martin Koppenhoefer wrote on 2014-10-26 20:26: >>> Am 24.10.2014 um 20:53 schrieb Tom Pfeifer: >>> >>> I would recommend to add maxheight=unsigned to the English and other wiki >>> pages, and list maxheight=none as incorrect tagging. >> >> >> unsigned maxheight

Re: [Tagging] Feature Proposal - Voting - relation type=person

On 15/10/2014, Pieren wrote: > On Wed, Oct 15, 2014 at 11:34 AM, Ilpo Järvinen > wrote: > >> Not that it would interest me personally to find some distant relative's >> grave, but I've been on multiple occassions on with somebody who has been >> looking for a grave of a relative "that is supposed

Re: [Tagging] Feature Proposal - Voting - relation type=person

On 15/10/2014, Martin Vonwald wrote: > 2014-10-14 23:31 GMT+02:00 moltonel 3x Combo : >> Finding the tomb you want in a cemetery is *hard* and I'd love to be >> able to use OSM for it (probably via a specialized smartphone app). A >> particular tomb is like any POI, OS

Re: [Tagging] Feature Proposal - Voting - relation type=person

On 14/10/2014, Pieren wrote: > Third mistake : It is not strictly reserved for "notable" people and > can be used to name all graves in a cemetery (which might be forbiden > in some countries). Privacy is never mentionned. To solve this, you > could enforce a link to wikipedia because they are alr

Re: [Tagging] Feature Proposal - Voting - relation type=person

On 13/10/2014, Janko Mihelić wrote: > I think OSM isn't a place for this. Number of the grave should be enough, > and naming people in the grave (if they are not famous) looks like data for > other databases. What are other uses for this relation type? Home of a > person, workplace of a person, cu

Re: [Tagging] New key proposal - paved=yes/no

On 21/09/2014, Tod Fitch wrote: > Despite being actively discouraged, "paved=yes/no" is > used. And two of the top values for "surface=*" are "paved" and "unpaved", A lot of those are historical values, before the practice of distinct surface values took hold. > clearly taggers find the concept

Re: [Tagging] include smoothness=* in JOSM presets?

On 31/08/2014, Simon Poole wrote: > > As somebody who participates in at least two outdoor activities in which > road conditions are an important comfort factor* (inline skating and > riding a road bike) it would be great to have a reasonably reliable > indication of what to expect on a certain ro

<    1   2